Data Vault 2.0 im Lakehouse: wann es sich lohnt und wann es teuer wird
Data Vault 2.0 zerlegt fachliche Objekte in Hubs, Links und Satellites für eine nachvollziehbare Insert-Only-Historie, mit mehr Tabellen, mehr Joins und mehr Betriebsaufwand.
Die Kernaussagen auf einen Blick.
- Data Vault 2.0 zerlegt fachliche Objekte in Hubs, Links und Satellites. Der Vorteil ist eine nachvollziehbare Insert-Only-Historie. Der Nachteil sind mehr Tabellen, mehr Joins und mehr Betriebsaufwand.
- Der Zielkonflikt liegt im Betrieb: Viele Hubs, Links und Satellites erzeugen viele kleine Dateien. Ohne Automatisierung und passenden -Plan wird Data Vault auf Delta schnell teuer.
- Vor der Einführung sollten drei Dinge klar sein: Welche Audit-Anforderung gibt es wirklich? Welche Automatisierung steht bereit? Und lassen sich Hash-Keys, Namensregeln und Ladelogik dauerhaft konsistent halten?
- Mein Vorschlag: Data Vault nur für auditrelevante Domänen einsetzen. Für viele BI-Domänen reichen Star Schema, SCD 2 und Delta Time Travel. Als Standardmodell für alles ist Data Vault meist zu teuer, wenn es keine klare Audit-Anforderung gibt.
Inhaltsverzeichnis
Warum Data Vault auf Delta anders bewertet werden muss
Im Meeting fordert Compliance Data Vault, weil eine Prüfung bevorsteht. Die BaFin-Prüfung steht in achtzehn Monaten, der Modellierer hat DV noch aus dem Oracle-DWH mitgebracht, und im Data-Bereich steht die Annahme im Raum, dass Data Vault auf Databricks problemlos läuft. Kurz danach gibt es ein Backlog mit zwölf Hubs, siebenundzwanzig Satellites und noch keinen Plan für Dateigrößen, OPTIMIZE und Betrieb.
Wir sehen dieses Bild häufiger, sobald die Modellierungsfrage im Lakehouse auf eine reale Regulierungs-Situation trifft. Der Modellierungsüberblick klärt, wann Data Vault gegenüber Star Schema oder Wide Tables sinnvoll ist. Hier geht es um die Betriebsfrage dahinter.
Vor der Entscheidung sollten vier Fragen beantwortet werden: Was kosten Hubs, Links und Satellites auf Delta wirklich? Wo werden Raw Vault und Business Vault getrennt? Wann braucht es PIT-Tables statt nur Delta Time Travel? Und welche Automatisierung hält das Modell auch nach drei Jahren noch konsistent?
Data Vault auf Delta ist vor allem eine Audit- und Betriebsentscheidung. Auf Delta wird Data Vault oft teurer als im klassischen DWH, weil viele Tabellen und kleine Dateien entstehen. Ohne belegten Regulierungs-Grund und Automatisierungs-Reife wird die Rechnung teuer. Als Default-Antwort für Modellierung im Gold-Layer taugt Data Vault nicht.
Was ist Data Vault 2.0?
Data Vault 2.0 zerlegt fachliche Objekte in drei Bausteine: Hub, Link und Satellite. Änderungen werden dabei nicht überschrieben. Jede Änderung wird als neue Zeile angefügt. Der Rahmen kommt aus den 1990ern von Dan Linstedt, entwickelt in der NSA und seit 2013 als DV 2.0 mit Hash-Keys, Insert-Only-Semantik und Parallel-Load formalisiert (siehe Wikipedia-Eintrag zu Data Vault).
Ein Hub enthält den fachlichen Schlüssel eines Objekts, also die Kundennummer oder die Vertragsnummer, plus einen deterministisch berechneten Hash-Key und Metadaten wie Load-Date und Quell-System. Beschreibende Informationen wie Name, Adresse oder Status gehören nicht in den Hub.
Ein Link verbindet Hubs miteinander, zum Beispiel Kunde und Vertrag. Auch Links tragen einen eigenen Hash-Key und Load-Date. Fachliche Attribute gehören dort ebenfalls nicht hin.
Ein Satellite enthält die beschreibenden Informationen zu einem Hub oder Link, jeweils mit Ladezeitpunkt. Jede Attribut-Änderung erzeugt eine neue Satellite-Zeile mit neuem Load-Date; alte Zeilen bleiben unverändert stehen. Das ist der Kern von Insert-Only: Bestehende Zeilen werden nicht überschrieben. Neue Zustände werden angefügt. Databricks beschreibt in seinem Data-Vault-Modellierungsleitfaden dieses Muster als natürlichen Sitz für den Silver-Layer der Medaillon-Architektur.
| Objekttyp | Beispiele | Inhalt |
|---|---|---|
| Hub | , , | Fachlicher Schlüssel + , , |
| Link | , | Verbindung zwischen Hubs + , , |
| Satellite | , , , , , | Beschreibende Attribute + , , , |
Auf Delta werden Hub, Link und Satellite zu einzelnen Delta-Tables. Der Hash-Key wird aus dem normalisierten fachlichen Schlüssel berechnet, häufig mit SHA-256, in älterer Databricks-Doku noch als sha1(UPPER(TRIM(c_custkey))). Die Normalisierung (Trim, Upper-Case) ist Teil des Hash-Vertrags: sie muss über alle Beladungen und Systeme identisch sein, sonst entstehen unterschiedliche Schlüssel für dasselbe fachliche Objekt.
Data Vault 2.0 unterscheidet sich in vier Punkten von der ursprünglichen 1.0-Fassung. Erstens: Hash-Keys ersetzen sequenzielle Surrogatschlüssel und machen paralleles Laden über alle Hubs und Satellites deterministisch möglich. Zweitens: Raw Vault und Business Vault sind zwei getrennte Schichten. Drittens: die Insert-Only-Semantik wird explizit; Updates auf Satellites sind untersagt und jede Änderung ist ein Append mit neuem Load-Date. Viertens: eine Staging-Zone vor dem Raw Vault ist Bestandteil der Referenz-Architektur. Alle neuen Vault-Projekte starten heute auf 2.0.
Der Unterschied zur klassischen dimensionalen Modellierung ist wichtig. Ein Star-Schema mit Slowly Changing Dimensions historisiert an einer Dimension. Data Vault verteilt die Historisierung über viele Satelliten, dafür bleibt jede Attribut-Gruppe für sich versionierbar. Wie Star-Schema, Wide-Tables und Data Vault in der Modell-Entscheidung gegeneinander abzuwägen sind, klären wir im Überblick zur Datenmodellierung im Lakehouse. Was der Begriff selbst neutral bedeutet, steht im Überblick zu Data Vault.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wann ist Data Vault wirklich nötig?
Data Vault ist nicht automatisch besser als Star Schema, SCD 2 oder Wide Tables. Data Vault lohnt sich vor allem dann, wenn eine nachvollziehbare Historie auf Datenebene gebraucht wird. In vielen Projekten wird diese Reihenfolge vertauscht. Dann wird zuerst das Modell beschlossen, bevor die eigentliche Anforderung klar ist.
Die einfache Auditfrage lautet: Können wir einen alten Datenstand wiederherstellen? Diese Frage beantwortet Delta Time Travel für viele Fälle. Die wichtigere Frage lautet: Können wir später nachweisen, welche Quelle welchen Wert geliefert hat und dass dieser Wert nicht überschrieben wurde?
Wenn diese Frage verbindlich beantwortet werden muss, wird Data Vault relevant. Insert-Only auf der Raw-Ebene, Hash-Keys als deterministische Provenance-Anker, Load-Date als unveränderliche Zeitachse. Genau dafür ist Data Vault gebaut.
Wie Historisierung auf einzelner Dimension mit MERGE, Deletion Vectors und Time Travel funktioniert, ordnen wir im Überblick zu Slowly Changing Dimensions in Delta ein. Wie sich Vault vom 3NF-Muster im Silver-Layer abgrenzt, klären wir im Überblick zur 3NF-Modellierung im Delta-Silver-Layer.
wo liegt der Unterschied?
Ein sauberer Data Vault trennt Raw Vault und Business Vault. Genau diese Trennung geht in vielen Projekten verloren.
Der Raw Vault speichert Quelldaten so unverändert wie möglich. Bereinigung, Umformung und fachliche Regeln gehören nicht in diese Schicht. Der Raw Vault ist Insert-Only, die Hub/Link/Satellite-Struktur bildet exakt das Quell-Schema ab. Er ist die Schicht, die für Nachvollziehbarkeit und Prüfung besonders wichtig ist. Business-Rules gehören ausschließlich in den Business Vault. Nur so bleibt die Rohdaten-Integrität erhalten.
Der Business Vault ergänzt den Raw Vault um fachliche Regeln, Zuordnungen und berechnete Informationen. Same-as-Links konsolidieren doppelt geführte Business Keys aus mehreren Quellen, Computed Satellites berechnen abgeleitete Attribute (etwa den customer_lifetime_value), Effectivity Satellites tragen die fachlichen Gültigkeitszeiträume. Wichtig ist: Der Business Vault ersetzt den Raw Vault nicht. Er liegt als eigene Schicht daneben.
Der häufigste Fehler entsteht aus Pragmatismus: „lass uns die Anschriftsprüfung gleich im Raw-Satellite ablegen, spart eine Tabelle.“ Ab diesem Moment ist die saubere Nachvollziehbarkeit gefährdet. Sobald eine fachliche Regel im Raw Vault landet, ist die Rohdaten-Historie mit Ableitungen vermischt, und die Herkunft eines Werts lässt sich später nicht mehr sauber erklären. Ohne die Disziplin, die Trennung durchzuhalten, ist Vault die falsche Wahl.
Die betriebliche Konsequenz: zwei Modellschichten, mehr Automatisierung und ein klarer Betriebsplan für beide Schichten. Ohne Automatisierung driften Raw und Business Vault auseinander, weil in der Business-Schicht immer öfter „schnell etwas gebogen“ wird.
Wie funktionieren Business Keys und Hash Keys im Data Vault?
Der Hash-Key ist eine der wichtigsten Festlegungen in einem Data Vault. Wenn diese Regel später geändert wird, kann die Historie schwer nutzbar werden.
Ein Hash-Key wird deterministisch aus dem Business Key berechnet. Das klingt einfach, führt aber oft zu drei Problemen.
Normalisierung
Derselbe Business Key kommt aus Quellsystemen unterschiedlich formatiert (etwa „KD-04711 “, „kd-04711“, „KD-04711“). Ohne einheitliche Regel wie sha1(UPPER(TRIM(c_custkey))) entstehen unterschiedliche Hash-Keys für denselben Kunden.
Hash-Algorithmus
MD5 ist für neue Vaults ungeeignet, SHA-1 zeigt bei großen Volumen Kollisions-Risiken. SHA-256 ist der Standard: ein späterer Wechsel bedeutet ein Multi-Monats-Projekt für alle Hubs, Links und Satellites.
Zusammengesetzte Keys
Besteht der Business Key aus mehreren Feldern, braucht es einen deterministischen Separator (z. B. „|~|"), der in den Daten nie vorkommt: sonst kollidieren Kombinationen wie („A", „12") und („A1", „2").
Hash-Kollisionen sind bei SHA-256 in normalen Data-Vault-Volumen meist nicht das Hauptproblem. Das größere Risiko liegt fast immer in uneinheitlicher Normalisierung oder späteren Regeländerungen.
Wozu braucht ein Data Vault Point-in-Time-Tables?
Ein Data Vault erzeugt viele Satellite-Zeilen, weil jede Änderung als neue Zeile gespeichert wird. Sobald mehrere Satellites gemeinsam ausgewertet werden, werden die Abfragen schnell kompliziert: für jeden Satellite muss die zum Ziel-Zeitpunkt gültige Zeile per Load-Date-Range identifiziert und dann gejoint werden.
Point-in-Time-Tables (PIT) bereiten diese Logik vor, bevor die eigentliche Analyse läuft. Eine PIT-Table hält pro Hub-Instanz und pro Zeitpunkt genau eine Zeile mit den Load-Dates der zu diesem Zeitpunkt gültigen Satellites. Analysen verbinden dann die PIT-Table mit den passenden Satellites über den Ladezeitpunkt, das ist eine Standard-Delta-Join-Operation mit Liquid Clustering statt Load-Date-Range-Logik.
PIT-Tables sind wichtig, wenn technische Ladezeit und fachliche Gültigkeit getrennt betrachtet werden müssen. Das Load-Date (unitemporal, „wann kam die Info an“) und das Business-Effective-Date (temporal, „wann galt sie fachlich“) lassen sich in einer PIT-Table getrennt tragen. Delta Time Travel ersetzt diese fachliche Gültigkeitslogik nicht vollständig. Time Travel kennt nur die technische Table-Version; die fachliche Gültigkeit bleibt außen vor.
Der Aufwand kommt in der Materialisierung. Eine PIT-Table muss regelmäßig neu berechnet werden, üblicherweise als tägliches oder wöchentliches Snapshot. Bei fünf Satelliten auf einem Hub mit fünf Millionen Einträgen und einem täglichen PIT-Rebuild reden wir über eine Delta-Table mit rund 1,8 Milliarden Zeilen pro Jahr. Das ist machbar, muss aber geplant und automatisiert werden.
Ohne PIT-Tables schreibt jeder Analyst ad-hoc Load-Date-Range-Joins über die Satelliten. Dann werden Abfragen langsam, Ergebnisse uneinheitlich, und Data Vault wird als Ursache vermutet. Das Problem liegt dann oft nicht am Modell selbst, sondern an der fehlenden PIT-Schicht.
Warum Data Vault auf Delta teuer werden kann
Auf Delta kann Data Vault teurer werden als erwartet. Der Grund ist einfach: Data Vault zerlegt ein fachliches Objekt in viele Delta-Tabellen, und viele Delta-Tables plus Insert-Only-Semantik plus häufige Loads produzieren viele kleine Files.
Ein Beispiel macht das sichtbar. Eine mittelgroße Kunden-Domäne mit fünf fachlichen Schlüsseln (Kunde, Vertrag, Produkt, Standort, Kampagne), zwölf Satelliten je Hub im Schnitt (Grunddaten, Anschrift, Kontakt, Compliance, Segmentierung, Vertriebs-Verantwortung und so weiter) und drei Links zwischen Kunde–Vertrag, Vertrag–Produkt, Kunde–Standort führt schnell zu fünf Hubs, drei Links und rund sechzig Satellites. Auf Delta sind das rund 68 Tabellen statt weniger, stärker zusammengefasster Tabellen.
Deletion Vectors bringen im Raw Vault wenig, weil dort niemand löscht: für Business-Vault-Satellites mit Rebuild-Semantik reduzieren sie die Rewrite-Kosten spürbar. Mehr dazu in den Überblicken zuDeletion Vectors und Liquid Clustering, das auf dem Hash-Key eines Hubs bzw. auf hash_key + load_date bei Satelliten heute der Standard ist und das klassische Z-Ordering ersetzt.
Ob sich der Aufwand rechnet, lässt sich über zwei Fragen prüfen. Wenn die Vault-Betriebs-Rechnung (Storage plus OPTIMIZE-Compute plus PIT-Rebuild) mehr als das Fünffache eines Star-Schema-Betriebs auf derselben Domäne kostet und wenn keine Regulierungs-Anforderung diesen Aufschlag rechtfertigt, ist Vault die falsche Wahl. Diese Zahl ist nur eine Orientierung und muss mit einem echten Pilot-Load geprüft werden.
Wenn zusätzlich keine Data-Vault-Automatisierung eingerichtet ist, kann der Aufwand noch deutlich höher liegen. Der Aufwand für den händischen Modell-Katalog, den händischen Load-Code und den händischen OPTIMIZE-Plan skaliert nicht linear mit den Quellsystemen.
Welche Audit-Anforderungen rechtfertigen Data Vault?
Data Vault ist vor allem dort sinnvoll, wo Regulierung eine nachvollziehbare Herkunft von Daten verlangt, die sich mit Star und SCD 2 alleine oder mit Delta Time Travel plus Unity-Catalog-Lineage nicht sauber abbilden lässt. Für den deutschen und europäischen Markt tauchen vor allem drei Bereiche häufig auf.
BaFin, BAIT, MaRisk
Banken und Finanzorganisationen müssen Änderungen an Daten, Systemen und Berechtigungen nachvollziehbar machen. Wenn spätere Herkunfts-Nachweise pflichtig sind, spielt Data Vault seine Stärke aus: IT-Reporting und Nutzer-Berechtigungen sind typische Prüf-Fokusse.
MDR (EU 2017/745)
Hersteller von Medizinprodukten müssen technische Dokumentation über den gesamten Produktlebenszyklus vorhalten, inklusive Herkunftsnachweisen aus klinischer Bewertung und Post-Market Surveillance. Die Raw-Vault-Historie ist dafür ein sauberer Baustein.
EU AI Act
Bei Hochrisiko-KI-Systemen werden Dokumentation, Logging und Datenherkunft der Trainingsdaten relevant. Data Vault kann ein Baustein sein, wenn Trainingsdaten und Herkunftsnachweise ohnehin im Lakehouse verwaltet werden, der Katalog-Bezug läuft dann über Unity Catalog Lineage.
Die Frage vor der Vault-Entscheidung lautet in jedem der drei Kontexte: reicht die Kombination aus SCD 2 im Star-Gold-Layer, Delta Time Travel für Version-Rebuild und Unity-Catalog-Lineage für die Herkunfts-Nachweise? Wenn diese Kombination reicht, braucht es keinen Data Vault. Wenn sie nicht reicht, sollte Data Vault gezielt für die auditrelevanten Domänen eingesetzt werden.
Ein zweiter Governance-Vorteil entsteht durch die Zerlegung: sensitive Attribute (Preise, PII, Compliance-Klassifikationen) landen in eigenen Satelliten, während öffentliche Attribute in einem anderen Satellite bleiben. Auf Delta lassen sich diese Satelliten dann über Unity Catalog Access Control unterschiedlich berechtigen. Für DSGVO- und AI-Act-Kontexte ist das ein natürliches Muster, das die Vault-Modellierung frei mitbringt. Das allein ist kein ausreichender Grund für die Einführung, aber ein Nebeneffekt, der gegen einen denormalisierten Wide-Table-Gold-Layer spricht, sobald PII über die Domäne verteilt liegen.
Welche Automatisierung braucht Data Vault auf Delta?
Data Vault ohne Automatisierung skaliert kaum. Das zeigt sich spätestens in produktiven Projekten. Ab mehreren Quellsystemen wird ein manuell gepflegter Modellkatalog schnell unzuverlässig, die Namens-Konventionen brechen, der Hash-Vertrag wird von zwei Data-Engineers unterschiedlich implementiert, und drei Jahre später ist niemand mehr sicher, welcher Hash-Key mit welcher Normalisierungs-Regel entstanden ist.
Vier Werkzeuge prägen die Landschaft. Sie ersetzen kein Data-Vault-Wissen in der Organisation, machen größere Modelle aber erst praktikabel.
VaultSpeed
Kommerzielles Tool, erzeugt DDL, Ladeprozesse und Metadaten aus einem zentralen Modell. Unterstützt Databricks, Snowflake und Azure, sinnvoll für größere Vaults mit mehreren Quellsystemen und klaren Governance-Anforderungen.
WhereScape
Klassisches Enterprise-Tool für DWH-Automatisierung, deckt Data-Vault-Generierung, Deployment und Metadaten-Katalog ab. Preis und Lizenzmodell passen vor allem in Unternehmen, in denen WhereScape ohnehin schon läuft.
datavault4dbt
Open-Source-Ansatz für Organisationen, die dbt-Core bereits einsetzen. Community-Weiterentwicklung des früheren dbtvault (bzw. AutomateDV), gepflegt von Scalefree. Erzeugt den Load-Code, ist aber kein Deployment-Tool.
Datavault Builder
Visuelles Modellierungs-Tool mit angebundenem Katalog (xax.de). Passt für Organisationen ohne dbt-Erfahrung, die aus der klassischen BI-Modellierung kommen, am stärksten im deutschsprachigen Markt verbreitet.
Die Tool-Entscheidung ist zweitrangig gegenüber der Personalfrage. Aus unserer Erfahrung braucht ein produktiver Vault auf Delta für fünf bis zehn Quellsysteme mindestens zwei dedizierte Data Engineers plus einen Modell-Architekten. Darunter wird der Betrieb schnell knapp. Ohne diese Aufstellung hilft auch die Tool-Auswahl wenig, und die Adoption sollte gestoppt werden.
Wann ist Data Vault nicht die richtige Wahl?
Data Vault ist nicht für jedes Lakehouse-Modell sinnvoll. In einigen Fällen ist der zusätzliche Aufwand größer als der Nutzen.
BI-Reporting als Hauptzweck
Für klassische Dashboards, etwa in Sales oder Controlling, reicht oft ein sauberes Star-Schema mit SCD 2. Data Vault bringt hier meist wenig Zusatznutzen, macht Modellierung, Betrieb und Abfragen aber deutlich aufwendiger.
Fehlende Data-Vault-Erfahrung
Ohne klare Modellierungsregeln und Automatisierung entstehen schnell viele Tabellen, die technisch korrekt wirken, fachlich aber schwer verständlich sind. Kein gutes erstes Modellierungsprojekt für kleine Data-Organisationen.
Time Travel und Lineage reichen bereits
In vielen Fällen lassen sich Herkunft und historische Stände bereits über Unity Catalog Lineage, Delta Time Travel und einen gut aufgebauten Gold Layer nachvollziehen. Data Vault wird erst interessant, wenn diese Mittel nicht mehr ausreichen.
ML oder Feature Serving als Hauptzweck
ML-Workloads brauchen meist breite, fertig vorbereitete Tabellen. Ein Vault ist dann nur ein zusätzlicher Zwischenschritt: Wide Tables liegen näher am Bedarf, wenn ML der wichtigste Konsument ist.
Reiner Engine-Wechsel
Ob Delta oder Iceberg: Die Modellierungsfrage bleibt ähnlich. Dieselben Fragen zu Datei-Anzahl, Joins und Betrieb bleiben. Ein Engine-Wechsel macht Data Vault nicht automatisch einfacher.
Eigentlich ist Ownership gemeint
Data Vault ersetzt kein Data Mesh. Data Vault beantwortet, wie Daten modelliert werden: Data Mesh beantwortet, wer für Datenprodukte verantwortlich ist. Beides kann zusammenpassen, löst aber unterschiedliche Probleme.
Der häufigste Fehler ist, Data Vault einzuführen, bevor der eigentliche Bedarf klar ist. Wenn keine starke Audit-, Historisierungs- oder Integrationsanforderung dahintersteht, bindet Data Vault dauerhaft viel Engineering-Aufwand, ohne dass der Nutzen sauber belegbar ist.
Fazit
Data Vault 2.0 lohnt sich nur, wenn Audit- oder Historisierungspflichten es verlangen: für alles andere reichen Star Schema, SCD 2 oder Delta Time Travel.
Es passt dort, wo Herkunft, Historie und Nachvollziehbarkeit wirklich nachweisbar sein müssen und wo Star Schema, SCD 2 und Delta Time Travel nicht mehr ausreichen.
In solchen Fällen bringt Data Vault klare Vorteile: Insert-Only-Historie, stabile Hash-Keys, nachvollziehbare Herkunft und eine saubere Trennung zwischen Rohdaten und abgeleiteter Business-Logik.
Für viele andere Domänen ist Data Vault dagegen oft zu schwer. Die Zerlegung in Hubs, Links und Satelliten erzeugt viele Tabellen und Dateien, braucht regelmäßige Optimierung, eigene PIT-Logik und ein hohes Maß an Automatisierung. Ohne entsprechende Erfahrung wird daraus schnell ein Modell, das technisch sauber wirkt, aber im Betrieb teuer und schwer verständlich wird.
Besonders sinnvoll ist Data Vault in regulierten Bereichen, etwa Finance, Medizintechnik oder bei datenintensiven KI-Systemen mit hohen Nachweispflichten. Für klassische BI ohne klare Audit-Anforderung ist ein Star Schema meist einfacher, günstiger und näher an den Analysewerkzeugen.
Vor dem ersten Hub sollten Kosten, Automatisierung, vorhandene Erfahrung und Betriebsaufwand sauber geklärt sein. Ein flächiger Data-Vault-Rollout lohnt sich nur, wenn diese Grundlagen wirklich stehen.
Vor dem ersten Hub sollten Kosten, Automatisierung, vorhandene Erfahrung und Betriebsaufwand sauber geklärt sein: ein flächiger Rollout lohnt sich nur, wenn diese Grundlagen wirklich stehen.
FAQ
Data Vault 2.0 ist eine Modellierungsmethode, die fachliche Objekte in Hub, Link und Satellite zerlegt. Änderungen werden dabei nicht überschrieben. Jede Änderung wird als neue Zeile angefügt. Auf Delta werden Hub, Link und Satellite zu einzelnen Delta-Tables, der Hash-Key wird üblicherweise als SHA-256 über den normalisierten Business Key berechnet, und jede Attribut-Änderung erzeugt eine neue Satellite-Zeile mit Load-Date.
