Star-Schema-Grundlagen: Fakten, Dimensionen und die Granularität festlegen

Worum es geht

Die dimensionale Modellierung teilt Daten in Messungen von Geschäftsereignissen und den beschreibenden Kontext dieser Ereignisse: wer, was, wo, wann, warum und wie. In einer relationalen Datenbank wird daraus ein Star-Schema: Faktentabellen im Zentrum, jeweils über Fremdschlüssel mit den sie umgebenden Dimensionstabellen verknüpft. Die Power-BI-Anleitung (zitiert) formuliert es operativ: Eine Faktentabelle enthält Dimensionsschlüsselspalten, die sich auf Dimensionstabellen beziehen, sowie numerische Kennzahlenspalten; die Schlüsselspalten bestimmen die Dimensionalität der Faktentabelle und die Schlüsselwerte ihre Granularität; Dimensionstabellen sind vergleichsweise klein, Faktentabellen gross und wachsend. Die Grain-Seite der Kimball Group (zitiert) macht den ersten Entwurfsschritt explizit: Die Festlegung der Granularität legt genau fest, was eine einzelne Faktentabellenzeile darstellt, wird zu einem verbindlichen Vertrag und muss der Wahl von Dimensionen und Fakten vorausgehen; eine atomare Granularität, die niedrigste vom Prozess erfasste Ebene, wird empfohlen, weil sie unvorhersehbaren Abfragen standhält. Die Facts-Seite (zitiert) klassifiziert Kennzahlen: Additive Kennzahlen lassen sich über jede Dimension summieren; halbadditive, etwa Saldi, über alle Dimensionen ausser der Zeit; nicht-additive, etwa Verhältniswerte, gar nicht, weshalb ihre additiven Bestandteile gespeichert und das Verhältnis erst nach der Aggregation berechnet werden sollte.

Warum es wichtig ist

Analystinnen und Analysten sowie BI-Werkzeuge können ein Star-Schema aggregieren, ohne die Quellsysteme zu kennen: nach Dimensionsattributen filtern, Kennzahlen summieren, nach beliebiger Dimension gruppieren. Ein normalisiertes operatives Schema erzwingt Mehrfach-Joins, deren Semantik sich je Abfrage unterscheidet, und eine Tabelle, die Granularitäten mischt (Bestellpositionen und Bestellköpfe), zählt doppelt, sobald sie jemand summiert.

So wird es angewendet

• Die Granularität als Satz formulieren („eine Zeile pro Bestellposition pro Tag") und jede Kennzahl oder Dimension zurückweisen, die nicht dazu passt; eine abweichende Granularität in eine eigene Faktentabelle legen.
• Jeder Dimension einen ganzzahligen Ersatzschlüssel geben, den natürlichen Schlüssel der Quelle als Attribut behalten, und eine Datumsdimension mit Kalenderattributen einbeziehen, statt sie in jeder Abfrage neu abzuleiten.
• Degenerierte Dimensionen (Bestellnummer) direkt am Fakt speichern; Dimensionstabellen für Entitäten mit beschreibenden Attributen reservieren.
• Konforme Dimensionen einmal definieren und über Faktentabellen hinweg wiederverwenden, damit Ergebnisse verschiedener Prozesse auf denselben Zeilen übereinstimmen.

Stolpersteine

Dimensionen per Snowflaking in normalisierte Untertabellen aufzuspalten, spart kaum Speicherplatz und kostet Joins. NULL-Fremdschlüssel brechen Filter; ein explizites „unbekannt"-Dimensionselement verwenden. Als Fakten gespeicherte Durchschnitte und Prozentsätze lassen sich nicht korrekt neu aggregieren.

Ersatzschlüssel in wiederholbar ausführbaren Pipelines

Ein aus einer Sequenz gezogener Schlüssel wird in Ladereihenfolge vergeben, sodass ein Neuausführen oder nachträgliches Befüllen einer Dimension ausser der Reihe Schlüssel ändert und die dazwischen geladenen Fakten verwaist zurücklässt. In für idempotente Wiederholungen gebauten Pipelines den Ersatzschlüssel deterministisch aus dem natürlichen Schlüssel ableiten (und aus valid_from bei Typ-2-Zeilen), meist als Hash; dbt_utils.generate_surrogate_key ist die gängige Implementierung. Dimensions- und Faktenladungen bleiben dann unabhängig voneinander wiederholbar, und Fakten lassen sich beim Laden ohne Lookup verschlüsseln. Ganzzahlige Sequenzschlüssel dort beibehalten, wo Ladevorgänge serialisiert ablaufen und die Join-Performance auf einer schmalen Ganzzahl wichtig ist, und die beiden Schemata nie innerhalb einer Dimension mischen.