SQL / Reporting

Status: Entwurf · Spec-Kandidat: ja

Entscheidung OP-16: REST API als primärer Reporting-Pfad

Direkter SQL-Zugriff für BI/Reporting ist nicht der primäre Pfad (Entscheidung OP-16, 2026-04-29). Stattdessen:

BI-Konsumenten greifen über die REST API zu.
JSONB→Spalten-Projektion wird dynamisch im Query-Layer erzeugt (jsonb_to_record), nicht als statische mdm.v_<key>-Views in der DB.
Direkte DB-Verbindungen für BI-Tools sind nicht vorgesehen; der Service-Layer ist die einzige Zugriffs-Schicht auf mdm.*.

Rationale: keine View-Drift bei Metadatenänderungen, Typinformationen aus DDM_ENTITY_TYPE_ATTRIBUTE direkt nutzbar, kein Migrations-Overhead je Entitätstyp.

Operative Views (verbleiben in `mdm.*`)

Die folgenden Views sind keine Reporting-Views, sondern Stewardship-Inboxen und Auth-Infrastruktur:

View	Zweck
`mdm.v_principal`	Unified-Principal-Lookup (User + Service Account)
`mdm.v_principal_role_active`	Aktive Rollenzuweisungen transitiv über Gruppen
`mdm.v_effective_permission`	RBAC + ACL — muss vom Service-Layer genutzt werden
`mdm.v_relation_min_violations`	Stewardship-Inbox: `min_to_per_from`-Unterschreitungen
`mdm.v_relation_max_violations`	Alarm: `max_to_per_from`-Überschreitungen
`mdm.v_entity_attribute_drift`	Stewardship-Inbox: Schema-Drift je Entity
`mdm.v_index_drift`	Stewardship-Inbox: Index-Lifecycle-Abweichungen

Detail und SQL: Views.

Reporting über die REST API

Reports (OP-04: Mandats-Wirtschaftlichkeit, Holding-Konsolidierung, Modul-Auslastung, Audit-Reports) werden als dedizierte REST-Endpunkte implementiert.
Der Service-Layer nutzt den Query-Layer für dynamische JSONB-Projektion und gibt typisierte JSON-Responses zurück.
BI-Tools ohne REST-Support können über einen API-Adapter angebunden werden (offen — OP-44).

Zugriff für Audit-Daten

AA_AUDIT_LOG-Auszüge sind über REST-Endpoints mit auditor-Rolle erreichbar.
Direkter SQL-Zugriff auf AA_AUDIT_LOG ist nur für Administrations-/Compliance-Werkzeuge vorgesehen und muss explizit autorisiert werden.

Offen

Aggregation-Layer / BI-Adapter für Tools, die SQL erwarten (OP-44).
Refresh-Strategie für Materialized Views bei Hochlast-Reports (OP-44).
Trennung von operativem und reportingseitigem DB-Replica (NFR-002 / NFR-003).