Langsam veränderliche Dimensionen: überschreiben, eine Zeile hinzufügen oder eine Spalte hinzufügen

Worum es geht

Dimensionsattribute ändern sich langsam und unregelmässig, und ein Data Warehouse muss entscheiden, ob ein letztes Jahr erfasster Fakt unter dem damaligen oder dem heutigen Attributwert ausgewiesen werden soll. Die (zitierten) Kimball-Group-Technikseiten definieren die grundlegenden Antworten darauf. Typ 1: Der alte Attributwert in der Dimensionszeile wird durch den neuen überschrieben, sodass das Attribut stets die aktuellste Zuordnung widerspiegelt und die Historie zerstört wird; auf dem alten Wert aufgebaute Aggregate müssen neu berechnet werden. Typ 2: Eine neue Dimensionszeile mit den aktualisierten Werten und einem neuen Surrogat-Primärschlüssel wird hinzugefügt, auf den Faktenzeilen ab dem Zeitpunkt der Änderung verweisen; die Seite verlangt mindestens drei zusätzliche Spalten: ein Gültig-ab-Datum der Zeile, ein Gültig-bis-Datum der Zeile und einen Indikator für die aktuelle Zeile. Typ 3 fügt ein Attribut hinzu, das den alten Wert bewahrt, während das Hauptattribut überschrieben wird, sodass Berichte entweder nach dem aktuellen oder dem alten Wert gruppieren können; die Seite beschreibt diese Technik als vergleichsweise selten eingesetzt. dbt-Snapshots (zitiert) setzen Typ 2 über veränderliche Quelltabellen um und fügen jeder Version dbt_valid_from und dbt_valid_to hinzu; eine Timestamp-Strategie erkennt Änderungen über eine Spalte updated_at, eine Check-Strategie durch den Vergleich einer Liste von Spalten, und eine Konfiguration legt fest, ob an der Quelle gelöschte Zeilen ignoriert, für ungültig erklärt oder als neue Version erfasst werden.

Warum es wichtig ist

Ohne eine Richtlinie liefert derselbe Bericht je nach Ausführungszeitpunkt unterschiedliche Antworten, und niemand kann sagen, ob „Umsatz nach Region" die Region der Kundin zum Kaufzeitpunkt oder die heutige verwendet. Typ 2 beantwortet beide Fragen, vervielfacht aber die Dimensionszeilen und erfordert, dass jeder Faktenladelauf den zum Ereigniszeitpunkt gültigen Surrogatschlüssel nachschlägt.

So wird es angewendet

• Pro Attribut entscheiden, nicht pro Tabelle: Korrekturen von Erfassungsfehlern sind Typ 1; reale Änderungen, die Berichte historisch zuordnen müssen, sind Typ 2.
• Den natürlichen Schlüssel in jeder Typ-2-Zeile behalten und (natürlicher Schlüssel, valid_from) indexieren für Stichtags-Abfragen; für die aktuelle Zeile durchgängig einen offenen Sentinel-Wert oder NULL verwenden und dokumentieren, welchen.
• Snapshots mindestens so oft ausführen wie die feinste Berichtsperiode; Änderungen zwischen zwei Snapshots fallen sonst zu einer Version zusammen.
• Fakten laden, indem über den natürlichen Schlüssel mit dem Gültigkeitsbereich verknüpft wird, der den Ereigniszeitstempel enthält, nicht über die aktuelle Zeile.

Stolpersteine

Verspätet eintreffende Dimensionsänderungen erfordern ein Rekeying bereits geladener Fakten. Typ 2 auf stark wechselnden Attributen (letzte Anmeldung) macht die Dimension grösser als die Fakten; solche Attribute besser in die Faktentabelle oder eine separate Mini-Dimension verschieben.