Datenmodelle richtig dokumentieren: Grain, Beziehungen und Lineage

Eine vollständige Datenmodell-Dokumentation erklärt Zweck, Granularität, Tabellen, Spalten, Schlüssel, Beziehungen, Transformationen und Herkunft eines Modells. Sie verbindet fachlichen Kontext mit technischer Struktur, damit BI-Entwickler, Analytics Engineers und Analysten dasselbe Modell sicher verwenden können.

Ein automatisch erzeugtes ER-Diagramm ist dafür hilfreich, aber nicht ausreichend. Es zeigt Beziehungen, erklärt jedoch selten, warum eine Tabelle existiert, welche Zeile sie repräsentiert oder welche Qualitätsgrenzen gelten.

Die drei Ebenen der Datenmodell-Dokumentation

Modellebene

Beschreibt Zweck, fachlichen Scope, Owner, Aktualisierung, Quellen und bekannte Grenzen des gesamten Modells.

Tabellenebene

Erklärt Grain, Rolle, Schlüssel, Ladeverhalten und Beziehungen einer Tabelle.

Spaltenebene

Dokumentiert fachliche Bedeutung, Datentyp, erlaubte Werte, Null-Verhalten und sensible Inhalte eines Feldes.

Nicht jede Spalte braucht einen langen Text. Besonders wichtig sind Schlüssel, fachlich mehrdeutige Felder, Statuswerte und Spalten, die in KPIs oder Beziehungen verwendet werden.

Pflichtfelder auf Modellebene

Ein Datenmodell sollte mindestens diese Fragen beantworten:

Mit Zweck und Grain beginnen

Der Grain bezeichnet die Zeilenbedeutung einer Tabelle. Dokumentiere ihn für jede Faktentabelle einzeln: Ein Modell kann Rechnungspositionen, Bestellpositionen und monatliche Bestände auf unterschiedlichen Ebenen enthalten.

Schwach:

FactSales enthält Verkäufe.

Belastbar:

Eine Zeile in FactSales repräsentiert eine gebuchte Rechnungs- oder Gutschriftposition. Quellsystem, Belegnummer und Positionsnummer identifizieren den Geschäftsvorfall eindeutig.

Ohne Grain können Nutzer Beträge doppelt zählen, falsche Joins bauen oder Kennzahlen auf einer ungeeigneten Ebene aggregieren.

Dokumentiere auch, ob stornierte, interne oder noch nicht fakturierte Vorgänge enthalten sind. Datum, Produkt und Kunde sind Analysemerkmale; sie identifizieren nicht zwingend eine einzelne Position. Microsoft betont für Faktentabellen einen konsistenten Grain in seiner Einführung in Sternschemas für Power BI.

Tabellen nach ihrer Rolle beschreiben

In einem Sternschema erfüllen Tabellen unterschiedliche Aufgaben:

• Faktentabellen enthalten messbare Geschäftsvorfälle auf einem definierten Grain.
• Dimensionstabellen liefern beschreibende Merkmale für Analyse und Filter.
• Bridge-Tabellen bilden Viele-zu-viele-Beziehungen ab.
• Hilfs- und Mappingtabellen unterstützen technische Regeln oder Harmonisierung.

Die Rollenbezeichnung allein reicht nicht. Ergänze Zweck, Primärschlüssel, Ladeart und zeitliches Verhalten.

Bei Dimensionen ist zum Beispiel wichtig, ob Änderungen überschrieben oder historisiert werden. Bei Fakten sollte klar sein, ob Nachbuchungen vorhandene Zeilen aktualisieren oder neue erzeugen.

Spalten und Schlüssel dokumentieren

Für jede relevante Spalte gehören zusammen:

• Anzeigename und technischer Name,
• fachliche Beschreibung,
• Datentyp,
• erlaubte Werte oder Einheit,
• Null-Verhalten,
• Schlüsselrolle,
• Herkunft oder Transformationsregel,
• Verwendung in KPIs.

Ein Primärschlüssel identifiziert eine Zeile innerhalb der Tabelle. Ein Fremdschlüssel verweist auf eine Zeile in einer anderen Tabelle. In analytischen Modellen können technische Surrogate Keys verwendet werden, die keine fachliche Bedeutung besitzen. Diese Unterscheidung sollte sichtbar sein.

Beziehungen verständlich machen

Zu einer Modellbeziehung gehören die beteiligten Tabellen, Schlüsselspalten, Kardinalität und fachliche Bedeutung. In semantischen Modellen wie Power BI kommen weitere Eigenschaften hinzu:

• Quell- und Zieltabelle,
• verwendete Schlüsselspalten,
• Kardinalität,
• Filterrichtung,
• Aktiv- oder Inaktivstatus,
• fachliche Bedeutung.

Beispiel:

FactSales.customer_key verweist als Viele-zu-eins-Beziehung auf DimCustomer.customer_key. Die Dimension filtert die Faktentabelle; jede Verkaufsposition wird genau einer zum Buchungszeitpunkt gültigen Kundenversion zugeordnet.

Unterscheide dabei eine Datenbankregel von einer Power-BI-Modellbeziehung: Eine Linie im semantischen Modell beweist nicht, dass die Quelldatenbank einen Fremdschlüssel erzwingt. Filterrichtung und Aktivstatus steuern die Auswertung im Modell. Details erläutert Microsoft unter Modellbeziehungen in Power BI Desktop.

Foreign Key und Lineage sind nicht dasselbe

Ein Foreign Key beschreibt eine strukturelle Beziehung zwischen Datensätzen: Welche Zeile referenziert welche andere Zeile?

Lineage beschreibt die Herkunft und Verarbeitung von Daten: Aus welcher Quelle stammt ein Feld, durch welche Transformationen läuft es und welche nachgelagerten Modelle oder KPIs verwenden es?

Beispiel:

• Foreign Key: FactSales.product_key verweist auf DimProduct.product_key.
• Lineage: FactSales.net_revenue stammt aus ERP-Rechnungspositionen, wird um Retouren reduziert und fließt in die KPI Nettoumsatz ein.

Eine Beziehung kann ohne dokumentierte Lineage existieren. Umgekehrt kann ein Feld aus einer Quelle stammen, ohne einen Foreign Key zu dieser Quelle zu besitzen.

Transformationen dokumentieren

Nicht jede technische Zeile im SQL-Modell gehört in die fachliche Dokumentation. Konzentriere dich auf Regeln, die Bedeutung oder Qualität verändern:

• Filter auf Geschäftsstatus,
• Währungsumrechnung,
• Deduplizierung,
• Mapping von Codes,
• Historisierung,
• Ableitung von Zeiträumen,
• Behandlung verspäteter Daten,
• Zusammenführung mehrerer Quellsysteme.

Verlinke bei Bedarf auf den technischen Code, aber fasse die fachliche Wirkung in verständlicher Sprache zusammen.

Source Lineage aufbauen

Dokumentiere die Kette von der Quelle bis zur Nutzung:

1. Quellsystem und Quellobjekt
2. Staging- oder Transformationsmodell
3. analytische Tabelle und Feld
4. semantisches Modell oder Measure
5. KPI und Bericht

Markiere für jede Verbindung, ob sie geprüft, manuell beschrieben oder nur vermutet ist. Eine dokumentierte Abhängigkeitskette ist nur so vollständig wie die erfassten Beziehungen; fehlende Kanten dürfen nicht als Beweis für fehlende Auswirkungen gelten. Wie die Berichte am Ende dieser Kette dokumentiert werden, zeigt der Leitfaden Power-BI-Berichte dokumentieren.

Owner, Refresh und Betriebswissen

Ein Modell braucht mindestens einen technischen Owner. Für kritische fachliche Regeln sollte zusätzlich eine fachliche Rolle benannt sein.

Refresh-Dokumentation umfasst:

• Zeitplan und Zeitzone,
• erwartete Verfügbarkeit der Quellen,
• inkrementelle oder vollständige Ladung,
• typische Laufzeit,
• Fehlerverhalten,
• Ansprechpartner,
• sichtbaren Datenstand.

So kann ein Nutzer unterscheiden, ob ein ungewöhnlicher Wert fachlich auffällig oder lediglich noch nicht aktualisiert ist.

Qualitätsnotizen sichtbar halten

Qualitätsprobleme gehören nicht nur in Tickets. Dokumentiere bekannte Einschränkungen direkt am Modell oder Feld:

• fehlende Historie vor einem Stichtag,
• verspätete Quelle,
• unvollständige Region,
• hoher Null-Anteil,
• manuelles Mapping,
• fachlich ungeklärter Statuswert.

Notiere Auswirkung, Verantwortlichen und geplante Behandlung. Ein Qualitätsvermerk ohne Kontext erzeugt sonst nur Unsicherheit.

Durchgängiges Beispiel: Sales-Sternschema

Modell: Sales Analytics Model

Das folgende Modell ist ein fiktives Beispiel für die Analyse gebuchter Rechnungen und Gutschriften.

Zweck: Analyse von fakturiertem Umsatz und Marge nach Kunde, Produkt, Region und Zeit

Zentrale Faktentabelle: FactSales

Grain: Eine gebuchte Rechnungs- oder Gutschriftposition; eindeutiger Geschäftsschlüssel aus Quellsystem, Belegnummer und Positionsnummer

Dimensionen: DimDate, DimCustomer, DimProduct, DimRegion, DimSalesOrganization

Primärschlüssel der Faktentabelle: Technischer sales_line_key

Fremdschlüssel: date_key, customer_key, product_key, region_key, sales_org_key

Quellen: ERP-Aufträge und Rechnungen; CRM-Kundenzuordnung; Product Master

Wesentliche Transformationen: Retouren mindern Nettoumsatz am Buchungsdatum; Währungsumrechnung in EUR mit Monatsdurchschnittskurs; interne Verkaufsorganisationen werden ausgeschlossen.

Refresh: Werktags nach Abschluss der ERP-Replikation

Qualitätsnotiz: Historische Regionszuordnung ist vor Januar 2024 nur auf Länderebene verfügbar.

Verknüpfte KPIs: Nettoumsatz und Bruttomarge

Grenze: Auftragseingang lässt sich aus Rechnungspositionen allein nicht vollständig ermitteln. Dafür wird eine eigene Bestellfaktentabelle mit Bestelldatum und separat definiertem Grain benötigt.

Mit drei Prüfungen die Dokumentation abnehmen

1. Eindeutigkeit: Prüfe, ob der dokumentierte Geschäftsschlüssel tatsächlich eine Zeile identifiziert. Wenn nicht, fehlt im Grain beispielsweise eine Belegversion oder Teilposition.
2. Join-Verhalten: Vergleiche Zeilenzahl und Umsatzsumme vor und nach einer Dimensionszuordnung. Eine unerwartete Vervielfachung deutet etwa auf mehrere passende Dimensionsversionen hin.
3. Zeitverhalten: Verfolge eine Gutschrift zu einer älteren Rechnung. Aus der Dokumentation muss hervorgehen, in welchem Monat sie wirkt und ob historische Auswertungen verändert werden.

Diese Prüfungen erfolgen im Daten- oder BI-System. In der Dokumentation hältst du Prüfergebnis, Datum und bekannte Einschränkungen fest; Beispieldaten sollten fiktiv sein.

Review-Checkliste

• Zweck und fachlicher Scope sind verständlich.
• Der Grain jeder Faktentabelle ist eindeutig.
• Tabellenrollen und Schlüssel sind dokumentiert.
• Kardinalität und Filterrichtung der Beziehungen sind korrekt.
• Wichtige Spalten besitzen fachliche Beschreibungen.
• Transformationen erklären ihre fachliche Wirkung.
• Foreign Keys und Lineage werden nicht verwechselt.
• Quellen und nachgelagerte KPIs sind verknüpft.
• Owner, Refresh und Fehlerverhalten sind benannt.
• Qualitätsnotizen enthalten Auswirkung und Verantwortlichen.

Häufige Fehler

Nur ein Diagramm bereitstellen

Ein ERD zeigt Struktur, aber selten Grain, Transformationen oder fachliche Grenzen.

Grain implizit lassen

Ohne eindeutige Zeilenbedeutung entstehen Doppelzählungen und falsche Joins.

Jede Spalte gleich ausführlich dokumentieren

Priorisiere Schlüssel, fachlich wichtige Attribute, Statuswerte und KPI-relevante Felder. Vollständigkeit ohne Nutzwert wird schnell nicht mehr gepflegt.

Foreign Keys als vollständige Lineage behandeln

Schlüsselbeziehungen zeigen keine Quellsysteme, Transformationen oder nachgelagerte Nutzung.

Qualitätsprobleme nur im Backlog führen

Nutzer müssen bekannte Einschränkungen dort sehen, wo sie das Modell auswählen und interpretieren.

Technische Namen ohne fachliche Übersetzung

Ein Feldname wie net_rev_adj_amt ist keine Definition. Ergänze eine verständliche Beschreibung und Einheit.

Häufige Fragen

Fazit

Gute Datenmodell-Dokumentation beginnt mit Zweck und Grain und reicht bis zu Schlüsseln, Transformationen, Lineage und Qualitätsgrenzen. Sie verbindet technische Präzision mit fachlicher Verständlichkeit und macht Modelle sicher wiederverwendbar.

Passende Blogartikel

• Power-BI-Berichte richtig dokumentieren