Slowly Changing Dimensions

Slowly Changing Dimensions (SCD, langsam veränderliche Dimensionen) sind Regeln dafür, wie ein Data Warehouse (die zentrale Auswertungs-Datenbank eines Unternehmens) mit selten wechselnden Stammdaten umgeht, etwa einer neuen Kundenadresse, einem umbenannten Produkt oder einem neu zugeschnittenen Vertriebsgebiet. Vier Grund-Optionen stehen zur Wahl: den alten Wert überschreiben, ihn als eigene Zeile historisieren, die Änderung verwerfen oder mehrere Ansätze mischen. Die von Ralph Kimball nummerierten Typen 0 bis 6 sind der De-facto-Standard für diese Entscheidung.

Was sind Slowly Changing Dimensions?

Der Begriff stammt aus der klassischen dimensionalen Modellierung nach Kimball (der Standard-Bauart für Auswertungs-Datenbanken) und beschreibt eine Design-Entscheidung: Wie soll eine Dimensionstabelle (die Tabelle mit Stammdaten wie Kunde, Produkt oder Region) mit Änderungen umgehen, die selten passieren, aber betriebswirtschaftlich relevant sind? Ein Kunde zieht in eine andere Stadt, eine Produktkategorie wird umbenannt, ein Vertriebsgebiet wird neu zugeschnitten. Jede Bewegungsdaten-Zeile (etwa eine Bestellung oder Buchung) verweist auf die passende Stammdaten-Zeile über einen Surrogate Key (einen technischen Schlüssel wie 4711, der die fachliche Kundennummer ersetzt) und erwartet, dass dieser Verweis stabil bleibt.

Die Antwort auf diese Frage ist eine fachliche Design-Entscheidung: Sollen historische Fakten dem alten Zustand der Dimension zugeordnet bleiben (der Umsatz mit der Kundennummer 4711 in Essen), oder sollen sie mit dem aktuellen Zustand angezeigt werden (derselbe Kunde, jetzt in Bochum)? Beide Sichten sind legitim, führen aber zu unterschiedlichen Reports. SCD ordnet jeder Dimension und häufig sogar jedem einzelnen Attribut einer Dimension eine der Kimball-Strategien zu.

Kimball nummeriert sechs kanonische Typen. Type 0 friert das Attribut ein, Änderungen werden ignoriert (typisch für den ursprünglichen Vertragsbeginn oder eine Kundennummer). Type 1 überschreibt den alten Wert, es gibt keine Historie (schnell und einfach, aber Reports auf alte Fakten zeigen den neuen Wert). Type 2 ist die klassische Historisierung: Bei einer Änderung wird eine neue Zeile mit neuem Surrogate Key eingefügt, die alte Zeile wird über valid_from und valid_to geschlossen. Alte Fakten behalten ihren Verweis auf die alte Zeile, neue Fakten zeigen auf die neue. Type 3 legt zusätzlich zur aktuellen eine previous_value-Spalte an, um genau eine Vorgänger-Version je Attribut vorzuhalten (begrenzte Historie ohne Zeilen-Explosion). Type 4 lagert die Historie in eine parallele History-Tabelle aus und hält die Haupt-Dimension schmal. Type 6 kombiniert Type 1, 2 und 3 in einer Dimension (aktueller Wert, historisierte Zeile, letzter Vorgänger-Wert), um Reports auf beide Sichten in einer Query zu erlauben.

Im Lakehouse hat sich die Umsetzung verlagert. Statt SQL-Stored-Procedures in einem klassischen Warehouse-Server wird SCD auf Delta-Tabellen mit MERGE INTO implementiert, in Databricks Lakeflow Declarative Pipelines deklarativ über APPLY CHANGES INTO, und der Downstream-Konsum der Historie erfolgt über Change Data Feed. Die Muster selbst sind unverändert Kimball.

Abgrenzung: Change Data Capture, Change Data Feed und Snapshots

SCD wird häufig mit benachbarten Begriffen verwechselt, die aber auf einer anderen Ebene liegen: SCD ist ein Zielmodell im Warehouse, CDC und CDF sind Transportmuster, ein Snapshot ist eine Alternative.

Der wichtigste Unterschied liegt zwischen CDC und SCD. CDC ist die Ingest-Seite (wie kommen die Änderungen aus dem Quellsystem ins Lakehouse), SCD ist die Modellierungs-Seite (wie werden sie in der Dimension abgelegt). Beide gehören zusammen, sind aber getrennte Entscheidungen: Eine CDC-Pipeline speist eine Bronze-Änderungstabelle, ein MERGE INTO-Schritt formt daraus die SCD-2-Dimension im Silver- oder Gold-Layer.

Beispiel: Kunden-Umzug in einer SCD-2-Dimension

Ein Retail-Data-Warehouse führt die Kunden-Dimension dim_customer mit SCD Type 2 auf einer Delta-Tabelle. Der Kunde mit der Business-Key-ID C-4711 zieht am 1. Juli 2026 von Essen nach Bochum. Die operative Datenbank meldet die Adressänderung, eine CDC-Pipeline schreibt sie in eine Bronze-Änderungstabelle. Ein Batch-Job führt den MERGE INTO-Schritt auf dim_customer aus und produziert diesen Zustand:

Die alte Zeile bleibt erhalten, valid_to wird auf den Vortag der Änderung gesetzt und is_current auf false. Für den Kunden entsteht eine neue Zeile mit neuem Surrogate Key 4712, offenem Gültigkeits-Ende und is_current = true. Bestellungen aus Juni verweisen weiterhin auf customer_sk = 4711 (Essen), Bestellungen ab Juli auf customer_sk = 4712 (Bochum). Der Umsatzreport nach Stadt zeigt damit die tatsächliche geografische Verteilung zum Zeitpunkt der Bestellung; die heutige Adresse überschreibt die Historie nicht rückwirkend.

Die SQL-Umsetzung nutzt einen Attribut-Hash, um Änderungen effizient zu erkennen:

MERGE INTO dim_customer AS tgt
USING (
  SELECT
    src.customer_id,
    src.ort,
    src.plz,
    src.name,
    md5(concat_ws('|', src.ort, src.plz, src.name)) AS attr_hash
  FROM bronze_customer_changes src
) AS chg
ON tgt.customer_id = chg.customer_id AND tgt.is_current = true
WHEN MATCHED AND tgt.attr_hash <> chg.attr_hash THEN
  UPDATE SET valid_to = current_date() - INTERVAL 1 DAY, is_current = false
WHEN NOT MATCHED THEN
  INSERT (customer_id, ort, plz, name, attr_hash, valid_from, valid_to, is_current)
  VALUES (chg.customer_id, chg.ort, chg.plz, chg.name, chg.attr_hash,
          current_date(), DATE'9999-12-31', true);

In Databricks Lakeflow Declarative Pipelines fasst APPLY CHANGES INTO ... STORED AS SCD TYPE 2 diese Logik in einen deklarativen Aufruf zusammen. Downstream-Konsumenten lesen die Änderungen der Dimension über Change Data Feed und aktualisieren dimensionale Marts oder Feature Stores inkrementell.