Slowly Changing Dimensions in Delta: wann SCD Typ 2 nötig ist und wann Time Travel reicht
SCD in Delta ist vor allem eine Betriebsfrage rund um MERGE, Dateigrößen und Historisierung.
Die Kernaussagen auf einen Blick.
- Slowly Changing Dimensions sorgen dafür, dass Änderungen an Dimensionsdaten nicht einfach überschrieben werden, sondern nachvollziehbar bleiben.
- Typ 1 überschreibt alte Werte. Typ 2 legt für jede Änderung eine neue Zeile mit , und an. Typ 3 speichert einen Vorher-Wert, Typ 6 kombiniert mehrere Muster.
- Auf Delta entscheidet vor allem der Betrieb: Der Attribut-Hash erkennt Änderungen, Deletion Vectors reduzieren MERGE-Kosten und Time Travel bleibt eher ein Werkzeug für Debugging und Reproduzierbarkeit.
- Mein Vorschlag: Entscheidet pro Dimension, welche Attribute wirklich historisiert werden müssen. Nutzt einen Attribut-Hash für die Change Detection und prüft Deletion Vectors, bevor der nächtliche MERGE zum Engpass wird.
Inhaltsverzeichnis
Warum SCD in Delta anders gebaut werden müssen
Der Customer-360-Report zeigt denselben Kunden doppelt. Einmal mit alter Postleitzahl aus dem Frühjahr, einmal mit neuer aus dem Sommer. Das BI-Team fragt, welche Version die richtige ist. Die Erklärung aus dem Engineering-Ticket: is_current steht bei beiden auf true, und effective_to ist bei einer NULL, bei der anderen 9999-12-31. Monate später fällt auf, dass zwei Umsetzungspfade unterschiedliche Konventionen für effective_to genutzt haben.
Wir sehen dieses Bild häufiger, sobald Dimensionen im Delta-Gold-Layer wachsen und mehrere Teams am gleichen Schema arbeiten. Der Modellierungsüberblick klärt, wann Star Schema, Wide Tables oder Data Vault die richtige Grundstruktur sind. Hier geht es um die Betriebsfragen dahinter:
Vor der Umsetzung sollten vier Fragen beantwortet werden: Welcher SCD-Typ passt zu welcher Dimension? Wie erkennt der nächtliche MERGE fachliche Änderungen zuverlässig? Wann helfen Deletion Vectors beim Kostenprofil? Und wann reicht Delta Time Travel nicht mehr aus?
SCD in Delta ist vor allem eine Betriebsfrage rund um MERGE, Dateigrößen und Historisierung. Delta verändert die klassische Kimball-Rechnung: Deletion Vectors machen den nächtlichen Update-Zyklus tragbar, Attribut-Hashes ersetzen die Spalte-für-Spalte-Change-Detection, und Time Travel bleibt ein Werkzeug für Debugging.
Was sind Slowly Changing Dimensions?
Slowly Changing Dimensions beschreiben Muster, mit denen Änderungen an Dimensionsdaten über die Zeit nachvollziehbar gespeichert werden. Der Begriff stammt von Ralph Kimball und wurde in „The Data Warehouse Toolkit“ als Sammlung nummerierter Muster (Typ 0 bis 7) formalisiert.
Der Grund für SCD ist einfach. Eine Fakt-Zeile in einem Report bezieht sich auf einen fachlichen Zeitpunkt. Wenn sich eine Dimension später ändert, muss trotzdem klar bleiben, welche Version zur ursprünglichen Faktzeile gehört. Ein Umsatz-Report für März 2025, der auf die aktuelle Vertriebsregion des Kunden joint, zeigt einen Umsatz, der März 2025 gar nicht in dieser Region gemacht wurde.
SCD löst dieses Problem, indem die Dimension ihre Historie speichert und der Fakt-Join die passende Version auswählt. Die Kimball-Nummerierung strukturiert vier Antwort-Muster (Typ 1, 2, 3, 6) plus drei Sonderfälle (Typ 0, 4, 7).
Der Nutzen ist immer ähnlich: BI-Reports werden zeitlich korrekt, Compliance-Rückschau wird belegbar, und die Semantik-Schicht (Power BI, Genie Ontology, dbt-Semantic-Layer) kann sauber auf „aktueller Kundenstamm“ und „Kundenstamm zum Faktzeitpunkt“ trennen.
Die Grenze ist die operative Realität. Jede historisierte Dimension bringt zusätzliche Zeilen, zusätzliche Schreiblast im nächtlichen MERGE und zusätzliche Join-Komplexität in Downstream-Queries. SCD Typ 2 sollte nicht automatisch für jede Dimension gewählt werden. Pro Dimension gehört die Wahl explizit entschieden. Wie SCD gegen Wide-Tables und Data-Vault-Muster einzuordnen ist, klären wir im Überblick zur Datenmodellierung im Lakehouse. Was der Begriff selbst neutral bedeutet, steht im Überblick zu Slowly Changing Dimensions.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche SCD-Typen gibt es?
In der Praxis sind vor allem vier Typen relevant, die übrigen sind Sonderfälle. Wir gehen sie in der Reihenfolge durch, in der Teams sie tatsächlich einsetzen.
Typ 1 · Overwrite
Das alte Attribut wird beim Load überschrieben, keine Historie. Speichersparend und günstig im MERGE, passend für Fehler-Korrekturen, Löschanforderungen und fachlich uninteressante Attribute wie Cache-Timestamps.
Typ 2 · Add New Row
Jede Änderung legt eine neue Zeile mit eigenem Surrogatschlüssel an. Effective-Dates und is_current steuern, welche Version ein Fakt-Join trifft, das wichtigste Muster für echte Historisierung im Gold-Layer.
Typ 3 · Add New Attribute
Statt einer neuen Zeile entstehen zwei Attribut-Spalten für aktuellen und vorherigen Wert. Passt nur für eine strukturelle Einmal-Umstellung, nicht für laufenden Fließbetrieb mit fortgesetzter Historie.
Typ 6 · Hybrid 1+2+3
Kombiniert Typ 1, 2 und 3: Typ-2-Zeilen mit Effective-Dates, eine überschriebene aktuelle Spalte und eine vorherige Spalte. Passt, wenn Reports gleichzeitig historisch korrekt und aktuell konsolidiert laufen sollen.
Die Sonderfälle kurz zusammengefasst: Typ 0 friert das Attribut ein (Geburtsdatum, ursprünglicher Vertragsbeginn), Typ 4 lagert die Historie in eine separate Historien-Tabelle aus, Typ 7 legt sowohl Surrogatschlüssel als auch Business-Key in den Fakt und lässt die Analystin per Join entscheiden. In den meisten Delta-Projekten kommt keiner davon vor.
| SCD-Typ | Historisierungs-Grund | Attribute pro Wechsel | BI-Anfrage-Muster | Delta-Kosten-Profil |
|---|---|---|---|---|
| Typ 1 | Keine Historie nötig (Fehler-Korrektur, Löschanforderung) | 0 zusätzliche | Nur „aktuell“ | Sehr niedrig (nur UPDATE) |
| Typ 2 | Fachliche Historie über Zeit | 3–4 zusätzliche (SK, Effective-Dates, Flag) | „Aktuell“ + „zum Faktzeitpunkt“ | Mittel (UPDATE + INSERT) |
| Typ 3 | Genau ein Vorher-Zustand parallel zum Aktuell | 1 zusätzliche pro historisiertem Attribut | „Aktuell“ + „genau ein Vorher“ | Niedrig (UPDATE zwei Spalten) |
| Typ 6 | Aktueller und historischer Stand parallel | 3 pro historisiertem Attribut plus SK | „Aktuell“ + „konsolidiert aktuell“ + „historisch zugeordnet“ | Hoch (mehrere UPDATE-Cluster) |
Wie setzt man SCD Typ 2 mit MERGE INTO in Delta um?
MERGE INTO ist in Delta der zentrale Baustein für SCD Typ 2. Die Databricks-Doku hält drei Klauseln bereit: WHEN MATCHED für Ziel-Zeilen mit Source-Match (UPDATE oder DELETE), WHEN NOT MATCHED für Source-Zeilen ohne Ziel-Match (nur INSERT), und WHEN NOT MATCHED BY SOURCE für Ziel-Zeilen ohne Source-Match. Wichtig: Eine Source-Zeile darf nicht mehrere Zielzeilen treffen, und eine Zielzeile darf nicht von mehreren Source-Zeilen getroffen werden.
WHEN MATCHED
Ziel-Zeile hat einen Source-Match. UPDATE oder DELETE, im SCD-Fall: alte Version schließen, wenn sich der Attribut-Hash geändert hat.
WHEN NOT MATCHED
Source-Zeile hat keinen Ziel-Match. Nur INSERT möglich, im SCD-Fall: neuer Kunde, erste Version einfügen.
WHEN NOT MATCHED BY SOURCE
Ziel-Zeile hat keinen Source-Match mehr, etwa wenn ein Kunde aus dem Quell-System verschwunden ist, aber in der Dimension weiter historisiert werden soll.
Ein vereinfachtes Beispiel für eine dim_customer-Dimension mit historisiertem Namen, E-Mail und PLZ sieht so aus. Der Kern ist der Attribut-Hash. Er ersetzt den Vergleich jeder einzelnen Spalte:
Der Attribut-Hash über sha2(concat_ws('||', ...)) bildet die historisierten Spalten in einen Fingerabdruck ab. Der WHEN MATCHED-Zweig schließt die alte Version, sobald der Hash abweicht. Der Vergleich bleibt ein einzelnes Prädikat, egal ob drei oder dreißig Attribute historisiert werden. Die neue Version wird anschließend in einem zweiten Schritt eingefügt, weil eine einzelne Delta-MERGE-Anweisung derzeit keine kombinierte Update-plus-Insert-Aktion auf denselben Business-Key erlaubt. In der Regel läuft der zweite Schritt als CTE-Union-Muster oder als zweite Anweisung im Job.
Zwei Konventionen sind hierfür nötig: Erstens: sha2(..., 256) gegen Hash-Kollisionen. Zweitens: der Trenner || in concat_ws verhindert, dass zwei Attribute wie "Müller" + "Straße" versus "" + "Müllerstraße" denselben Hash erzeugen. Dieses Muster ist Standard in der Community-Literatur zu SCD-Umsetzungen.
Für Teams, die den MERGE-Code nicht selbst pflegen wollen, bringt Lakeflow Spark Declarative Pipelines eine deklarative Alternative über AUTO CDC INTO mit. Laut Databricks-Dokumentation zu MERGE INTO kommt sie mit nativem SCD-Typ-1- und Typ-2-Support inklusive Out-of-Order-Handling. Der Trade-off: weniger eigene SQL-Logik, aber auch weniger Kontrolle über die genaue Change Detection.
Was ändern Deletion Vectors beim SCD-MERGE?
Ohne Deletion Vectors kann eine kleine Zeilenänderung in Delta dazu führen, dass ganze Dateien neu geschrieben werden. Delta speichert die Tabelle als eine Menge Parquet-Dateien; sobald eine Zeile in Datei A geändert werden muss, wird A gelesen, die Zeile im Speicher modifiziert, und A wird als neue Datei komplett geschrieben. Im ungünstigen Fall muss für eine geänderte Zeile eine ganze 128-MB-Datei neu geschrieben werden.
Deletion Vectors reduzieren diesen Rewrite-Aufwand. Statt die Datei neu zu schreiben, wird die geänderte Zeile in einer separaten Metadaten-Struktur als „gelöscht“ markiert; die neue Version wird als Append geschrieben. Die eigentliche Datei bleibt liegen. Zur Query-Zeit filtert Delta die als „gelöscht“ markierten Zeilen aus. Die Databricks-Dokumentation zu Deletion Vectors beschreibt das als „mark rows as modified in metadata instead“ von Ganz-Datei-Rewrites.
Der Preis: Deletion Vectors verlangen später ein REORG TABLE ... APPLY (PURGE) oder ein OPTIMIZE, um die als „gelöscht“ markierten Zeilen physisch zu entfernen, sonst wächst der Read-Overhead. Ein Teil des Aufwands verschiebt sich vom nächtlichen Load in geplante Wartungsfenster, in der Regel der bessere Trade-off. Wie Deletion Vectors im breiteren Delta-Ökosystem eingeordnet sind, klären wir im Überblick zu Deletion Vectors.
welcher Schlüssel wofür?
Egal ob Star Schema, Data Vault oder Wide Table: Die Schlüsseldefinition muss sauber sein. Bei SCD Typ 2 wird die Antwort besonders explizit.
Der Business Key ist der fachliche Schlüssel aus dem Quellsystem, zum Beispiel eine Kundennummer. KD-04711. Über alle Zeit-Versionen einer Dimensions-Zeile bleibt er konstant. Er ist der Anker, über den der Load erkennt: „diesen Kunden habe ich schon, ich brauche keine neue Dimensions-Zeile, ich muss nur die vorhandene mit einer neuen Version ergänzen“.
Der Surrogatschlüssel ist ein technisch erzeugter Schlüssel, der eindeutig auf eine Version einer Dimensions-Zeile zeigt. Kunde KD-04711 in seiner März-Version bekommt Surrogatschlüssel 47823, in seiner Juni-Version bekommt er 48156. Der Fakt joint über den Surrogatschlüssel und trifft damit automatisch die richtige historische Version.
Delta unterstützt Identity-Spalten (GENERATED ALWAYS AS IDENTITY) für Surrogatschlüssel. Sie sind monoton wachsend, aber nicht garantiert lückenlos. Für BI-Aggregation reicht das; für regulatorische Nummerierung, die eine ununterbrochene Sequenz verlangt, ist ein separater Zähler nötig.
Schwierig wird es bei zusammengesetzten Business Keys. Ein Kunde, dessen Business Key aus country + customer_number besteht, hat drei Kollisions-Risiken auf einmal: unterschiedliche Länder-Codes zwischen Quell-Systemen (DE vs. DEU vs. Germany), Trailing-Whitespace im Customer-Number, und Groß-/Kleinschreibungs-Änderungen. Ohne stabile Normalisierung (Trim, Upper-Case, ISO-Code-Mapping) driftet der Business Key über die Zeit, und der MERGE erkennt einen Kunden als „neu“, der schon vorhanden ist.
Wann reicht Delta Time Travel statt SCD Typ 2?
Delta Time Travel wirkt auf den ersten Blick wie eine einfache Alternative: mit SELECT * FROM dim_customer TIMESTAMP AS OF '2026-06-01T00:00:00Z' sieht die Query den Tabellenzustand vom 1. Juni. Ohne effective_from, effective_to, is_current. Ohne Surrogatschlüssel. Ohne MERGE-Nachtjob. Die Frage ist naheliegend: warum SCD Typ 2 bauen, wenn Delta die Historie eh mitführt?
Time Travel ist als Instrument für Auditing, Debugging und die Reproduktion historischer Analysen gedacht, nicht als Ersatz für fachlich modellierte Historie. Der Grund liegt in der Retention: deletedFileRetentionDuration liegt standardmäßig bei sieben Tagen, logRetentionDuration bei dreißig. Nach einem VACUUM können alte Dateien entfernt sein. Dann ist ein Zugriff auf diese Versionen nicht mehr möglich.
Beide Retention-Werte lassen sich hochziehen. Ein Jahr Retention ist technisch möglich. Der Preis ist direkt: die Delta-Tabelle hält jede Version jeder geänderten Datei für die Retention-Dauer physisch vor. Bei häufig geänderten Dimensionen kann lange Retention schnell zu deutlichem Storage-Overhead führen.
Die Grenze ist damit klar. Time Travel deckt drei Fälle ab:
Debug & Reproducibility
Welchen Trainingsdaten-Snapshot hat ein ML-Modell gestern gesehen, das falsche Vorhersagen produziert hat?
Rückschau im Retention-Fenster
Eine Analystin sieht die letzten vierzehn Tage der Dimension durch, ohne dass jemand SCD Typ 2 gebaut hat.
Rollback nach Fehl-Load
RESTORE TABLE ... TO VERSION AS OF bringt den Zustand vor einem fehlerhaften Job zurück, etwa nach versehentlich auf false gesetzten is_current-Flags.
Fachlich modellierte Historie über Jahre, mit Fakt-Joins auf die passende historische Version und reproduzierbaren BI-Reports für regulatorische Abschlüsse: das gehört in SCD Typ 2 im Gold-Layer. Time Travel ist dafür nicht das richtige Modell. Wie Time Travel als Instrument sauber einzuordnen ist, klären wir im Überblick zu Time Travel im Delta Lake.
Wie geht man mit Late-Arriving Facts und Dimensions um?
Eine Faktzeile kommt an, bevor die passende Dimensionsversion verarbeitet wurde. Der Fakt kennt eine Kunden-Version, die es in der Dimension noch nicht gibt. Umgekehrt: eine Fakt-Zeile für März kommt im Juni an, und der Kunde ist in der Zwischenzeit umgezogen. Die Faktzeile aus März darf nicht mit der Dimensionsversion aus Juni verknüpft werden.
Diese beiden Fälle heißen Late-Arriving Dimensions (verspätete Dimensions-Aktualisierung) und Late-Arriving Facts (verspätete Fakt-Zeile). Kimball hat sie in den Design Tip #91 zu Late-Arriving Facts und einem weiteren Design Tip zu Late-Arriving Dimensions eingeordnet.
Für Late-Arriving Dimensions ist das Muster vergleichsweise klar. Der Fakt-Load schreibt die Faktzeile zunächst mit einem technischen Unknown-Surrogatschlüssel (Konvention: -1). Sobald die Dimensions-Aktualisierung nachträglich kommt, läuft ein Reconciliation-Job, der die Fakt-Zeilen mit customer_sk = -1 gegen die neu erschienene Dimensions-Version updated. Der WHEN MATCHED BY SOURCE-Zweig aus dem Delta-MERGE deckt genau diesen Fall ab.
Late-Arriving Facts sind schwieriger. Die Fakt-Zeile für März muss auf die März-Version des Kunden joinen. Die aktuelle Version wäre falsch, weil sie den Umsatz in eine später gültige Regions-Zuordnung schiebt. Das heißt: der Fakt-Load braucht ein Business-Effective-Date der Faktzeile und ein Prädikat, das gegen effective_from <= business_date AND (effective_to IS NULL OR effective_to > business_date) joint. Das ist der Standard-Range-Join in einem SCD-Typ-2-Schema und der Grund, warum SCD Typ 2 zeitliche Korrektheit bringt und Typ 1 diese Rolle offen lässt.
Der operative Fehler, den wir häufiger sehen: das Fakt-Load-Team schreibt den Fakt mit dem Load-Timestamp anstelle des Business-Effective-Date. Der Range-Join trifft dann die falsche Dimensions-Version. Die Regel: Business-Effective-Date kommt aus dem Quell-System (Bestell-Datum, Vertrags-Startdatum), Load-Timestamp ist Metadaten für Debugging. Beide gehören in die Fakt-Tabelle. Für den SCD-Join zählt das Business-Datum, nicht der Ladezeitpunkt.
künftiger Baustein für SCD-Updates
Ein SCD-Typ-2-Update betrifft oft mehr als eine Tabelle. In vielen Modellen hängen an einer Kunden-Version eine Bridge-Tabelle (Kunde ↔ Kundengruppe), eine Preisliste, eine Vertriebs-Zuordnung. Klassisch laufen diese Updates nacheinander als getrennte MERGE-Anweisungen. Fällt der Job zwischen dim_customer und bridge_customer_group aus, ist die Datenlage inkonsistent, bis der Restart durchläuft.
Delta bringt derzeit als Preview Multi-Statement Transactions, die mehrere Schreib-Anweisungen über mehrere Tabellen atomar zusammenfassen. Perspektivisch kann ein BEGIN TRANSACTION ... COMMIT-Block ein SCD-Typ-2-Update auf dim_customer, ein Anhängen an bridge_customer_group und ein Update von fact_sales_current als eine atomare Einheit ausführen. Der Zwischen-Zustand entfällt, Reconciliation nach Job-Abbruch wird überflüssig.
Zum Zeitpunkt der Veröffentlichung ist das Feature noch in Preview und für kritische Produktionspfade zu früh. Es ist trotzdem der Baustein, der Multi-Table-SCD-Muster von einer Reihe verketteter Jobs zu einer Transaktion macht. Teams, die heute SCD Typ 2 auf mehreren verbundenen Tabellen bauen, sollten die Preview beobachten und das eigene Muster so gestalten, dass eine spätere Umstellung auf BEGIN TRANSACTION möglich ist. Konkret heißt das: Reconciliation-Logik gehört in einen separaten Job, der später vereinfacht werden kann, sobald Multi-Statement Transactions produktiv verfügbar sind.
Typische Fehler bei Slowly Changing Dimensions in Delta
effective_to: NULL + Sentinel gemischt
Zwei Teams nutzen unterschiedliche Konventionen für das Ende der Gültigkeit in derselben Tabelle. Reports auf is_current = true AND effective_to IS NULL oder auf effective_to > current_timestamp() verpassen jeweils die andere Hälfte. Kunden werden doppelt oder gar nicht mehr gezählt. Konvention pro Projekt entscheiden, dokumentieren, Bestandsdaten migrieren.
Change-Detection ohne Attribut-Hash
Eine WHEN MATCHED AND (target.a <> source.a OR ...)-Kette wird bei zwanzig Attributen zum Wartungs-Alptraum, NULL-Handling kippt bei jedem neuen Attribut. Ein Attribut-Hash über sha2(concat_ws(...)) ist eine Zeile Code und robust gegen NULL.
is_current inkonsistent mit effective_to
Wenn is_current = true und effective_to gleichzeitig gesetzt sind, hat der MERGE die alte Version nicht sauber geschlossen. Aggregate über beide Felder liefern dann unterschiedliche Kundenzahlen. Ein Data-Quality-Check am Ende des MERGE-Jobs fängt das früh.
Instabiler zusammengesetzter Business Key
Ländercodes, Nummern-Präfixe oder Whitespace-Konventionen driften unabhängig zwischen Quell-Systemen. Der MERGE erkennt einen bestehenden Kunden als neu und legt eine zweite Historisierungs-Kette an.
SCD Typ 2 als Default für jedes Attribut
Wer Cache-Zeitstempel, Foto-URLs oder Login-Zeiten historisiert, lässt die Dimension pro Nacht um zehntausende Zeilen wachsen, ohne fachlichen Nutzen. Nur Attribute historisieren, die Berichte tatsächlich brauchen.
Zwei Absätze zum Abschluss dieser Grenze. Ein SCD-Muster ist nur so gut wie das Data-Quality-Setup, das es umgibt. Ohne Sanity-Check auf is_current-Konsistenz, ohne Monitoring auf ungewöhnlich große MERGE-Batches (die auf ein Change-Detection-Problem hindeuten), ohne Alarm auf plötzlich schrumpfende oder wachsende Zeilenzahlen, driftet die Dimension unbemerkt. Ein einfacher Data-Quality-Check nach dem MERGE ist günstiger als eine falsche Quartalsanalyse.
Und ein SCD-Muster löst kein Modell-Problem, das im Grunddesign liegt. Wenn der Business Key aus dem Quell-System instabil ist, wenn die Fakt-Semantik unklar ist, wenn die Retention-Anforderung nicht mit dem Fachbereich geklärt ist, hilft kein Typ 2 dieser Welt. SCD funktioniert nur auf einem sauberen Grundmodell. Wo das Grunddesign wackelt, wackelt es mit oder ohne Historisierung.
Fazit
SCD Typ 2 mit Attribut-Hash-Change-Detection, Effective-Dates und aktivierten Deletion Vectors ist der Delta-Standardfall für historisierte Dimensionen.
Slowly Changing Dimensions sind ein bewährtes Kimball-Muster, müssen auf Delta aber bewusst umgesetzt werden. Für jede Dimension braucht es eine bewusste Designentscheidung: Welchen Typ? Welche Attribute? Welche End-Date-Konvention? Welche Change-Detection? Und mit welchem Datei- und Schreibverhalten in Delta im Kalkül?
Typ 1 gehört auf alles, was fachlich keine Historisierung braucht. Typ 3 hat einen sehr engen Anwendungsfall (strukturelle Einmal-Umstellung mit Paralleldarstellung), Typ 6 lohnt sich nur, wenn Reports gleichzeitig historische und aktuelle Sichtweisen brauchen. Time Travel bleibt ein Werkzeug für Debugging, Reproduzierbarkeit und Rollback, aber kein Ersatz für fachliche BI-Historie.
Baut vor der nächsten SCD-Typ-2-Umsetzung eine kleine Entscheidungstabelle: welche Attribute historisiert werden, mit welcher fachlichen Begründung, und welche BI-Anfrage die Historie tatsächlich braucht.
FAQ
Slowly Changing Dimensions sind Muster aus dem Data Warehousing, mit denen Änderungen an Dimensionsdaten über die Zeit nachvollziehbar gespeichert werden. Der Begriff stammt von Ralph Kimball und umfasst die Muster Typ 0 (nie ändern), Typ 1 (überschreiben), Typ 2 (neue Zeile pro Änderung mit Effective-Dates und Surrogatschlüssel), Typ 3 (Vorher-Spalte) sowie Typ 4, 6 und 7 als Sonderfälle. Ziel ist zeitlich korrekte BI-Analyse und belegbare Historie.
