Data Vault: Definition, Hub-Link-Satellite, Abgrenzung

Data Vault ist eine Methode, um Daten aus verschiedenen Quellsystemen so im Data Warehouse zu speichern, dass jede Änderung nachvollziehbar bleibt und neue Datenquellen ohne Umbau bestehender Tabellen hinzukommen. Die Methode teilt jede fachliche Sache (Kunde, Vertrag, Produkt) auf drei Tabellenarten auf: einen Schlüssel-Speicher (Hub), einen Beziehungs-Speicher (Link) und einen Attribut-Speicher (Satellite).

Was ist Data Vault?

Data Vault sitzt zwischen den Rohdaten aus den Quellsystemen und den Reports der Fachbereiche, also im mittleren Layer eines Data Warehouse oder Data Lakehouse. Der Ansatz ist auf zwei Dinge optimiert. Erstens: Jede Änderung an einem Attribut wird nicht überschrieben, sondern als neue Zeile mit Ladezeitstempel und Herkunftssystem festgehalten. Der frühere Wert bleibt lesbar. Zweitens: Kommt eine neue Datenquelle oder ein zusätzliches Feld dazu, entsteht eine neue Tabelle, ohne dass die bestehenden Ladepfade migriert werden müssen.

Der Ansatz geht auf Dan Linstedt zurück, der die Methode Ende der 1990er Jahre bei US-Behörden und Lockheed Martin entwickelt und im Jahr 2000 veröffentlicht hat. Die 2013 mit Michael Olschimke publizierte Nachfolge-Fassung Data Vault 2.0 ergänzt Hash-Keys statt aufsteigender Sequenz-IDs (parallele Ladbarkeit ohne Reihenfolge-Abhängigkeit), Insert-only-Loads, einen abgetrennten Business-Vault für berechnete Metriken sowie Point-in-Time- und Bridge-Tabellen als Query-Assist-Strukturen. Die kanonische Referenz ist das Buch [„Building a Scalable Data Warehouse with Data Vault 2.0"](https://www.sciencedirect.com/book/9780128025109/building-a-scalable-data-warehouse-with-data-vault-20) (Linstedt & Olschimke, Morgan Kaufmann 2016).

Die drei Bausteine tragen jeweils eine klar abgegrenzte Verantwortung. Ein Hub ist ein Schlüssel-Verzeichnis für eine fachliche Sache. Er hält nur den Business-Key (Kunden-Nummer, Vertrags-Nummer) plus technische Metadaten wie Ladezeitstempel und Herkunft, aber keine beschreibenden Attribute. Ein Link speichert die Beziehung zwischen zwei oder mehr Hubs (Kunde-Vertrag, Vertrag-Deckung), ebenfalls ohne Attribute. Ein Satellite hängt an einem Hub oder an einem Link und trägt die eigentlichen Attribute; typischerweise ein eigener Satellite pro Quellsystem und Änderungs-Rate, damit langsam veränderliche Stammdaten und schnell wechselnde Zustände getrennt gepflegt werden. Alle Ladungen sind Insert-only, Änderungen werden per Hash-Vergleich erkannt.

Architektonisch besetzt Data Vault die Integrations-Schicht zwischen Rohdaten und Konsum-Layer, in einer Medaillon-Architektur also den Silber-Layer. Der Konsum-Layer für Business Intelligence wird daraus als dimensionales Modell (Star-Schema) oder als denormalisierte Wide-Table (One Big Table) abgeleitet. Compliance-Regime wie BCBS 239, SOX oder die DSGVO sind ein häufiger Treiber für Data Vault, weil die insert-only-Historisierung jede Attribut-Änderung mit Ladezeitstempel und Quelle nachweist.

Abgrenzung zu Star Schema, 3NF und One Big Table

Data Vault wird häufig mit anderen Modellierungs-Mustern gleichgesetzt oder gegen sie ausgespielt, obwohl die Muster unterschiedliche Architektur-Schichten besetzen. Die folgende Tabelle sortiert die Beziehungen.

Begriff	Architektur-Schicht	Kernunterschied zu Data Vault
Star Schema (Kimball)	Konsum-Layer (Gold)	Star Schema ist ein dimensionales Konsum-Muster mit Fakten-Tabelle und Dimensionen für BI-Abfragen. Data Vault ist ein Integrations-Muster im Silver-Layer. Beide Muster werden häufig kombiniert: Data Vault historisiert, das Star darüber liefert die BI-Sicht.
3NF-Warehouse (Inmon)	Integrations-Layer (Silver)	3NF und Data Vault besetzen dieselbe Schicht. Data Vault ist auf Änderungs-Toleranz (neues Attribut leitet zu neuem Satellite) und Parallel-Ladbarkeit optimiert. Der 3NF-Ansatz erzwingt referenzielle Integrität und ist bei Struktur-Änderungen migrations-anfälliger.
One Big Table (OBT)	Konsum-Layer (Gold)	OBT bündelt alle Attribute einer Domäne in einer breiten, denormalisierten Tabelle für Column-Store-Engines. Data Vault splittet Attribute maximal nach Änderungs-Grund und Herkunft.
Data Mesh	Organisations-Modell	Data Mesh ist ein Organisations-Ansatz mit dezentralen Datendomänen und Data Products; Data Vault ist ein Modellierungs-Muster. Eine Domäne im Mesh kann Data Vault als internes Silver-Modell verwenden.

Zwei Trennlinien sind für die Einordnung besonders relevant. Die erste verläuft zwischen Schicht und Muster: Data Vault und Star Schema bezeichnen keine konkurrierenden Ansätze, weil sie unterschiedliche Layer beliefern (Silver-Integration vs. Gold-Konsum). Die zweite verläuft zwischen zwei Silver-Mustern: 3NF und Data Vault. Beide integrieren Rohdaten mit Historie; Data Vault erkauft die höhere Änderungs-Toleranz mit deutlich mehr Tabellen und einem höheren Modellierungs-Aufwand, der Konsum-Layer muss die zerlegten Tabellen wieder joinen. Diese Kosten sind der wichtigste Grund, warum Data Vault in kleineren Kontexten oft überdimensioniert ist.

Beispiel: Vertrags-Domäne bei einem Versicherer

Ein DACH-Versicherer modelliert die Vertrags-Domäne im Silber-Layer eines Delta-Lakehouse mit Data Vault. Die drei Bausteine erscheinen als eigenständige Delta-Tabellen mit Hash-Keys und Insert-only-Merge.

Auf Hub-Ebene entstehen HUB_KUNDE, HUB_VERTRAG und HUB_DECKUNG mit dem jeweiligen fachlichen Business-Key, einem SHA-256-Hash-Key, dem Ladezeitstempel und dem Herkunftssystem. Beziehungen liegen in LINK_KUNDE_VERTRAG und LINK_VERTRAG_DECKUNG; sie tragen die Hash-Keys der verbundenen Hubs plus Ladezeitstempel und Herkunft. Die eigentlichen Attribute stehen in Satellites, aufgeteilt nach Änderungs-Rate und Quelle: SAT_KUNDE_STAMM enthält Kern-Attribute wie Namen und Geburtsdatum, SAT_KUNDE_ADRESSE führt die Adress-Historie getrennt, SAT_VERTRAG_STATUS speichert die schnell wechselnden Vertrags-Zustände.

Wird ein zweites CRM-System als Quelle angebunden, entsteht kein Umbau: An HUB_KUNDE hängt ein zusätzlicher Satellite SAT_KUNDE_CRM_B mit den ergänzenden Attributen aus der neuen Quelle, die vorhandenen Tabellen bleiben unberührt. Historische Ladungen behalten ihren Zustand.

Aus dem Silver-Vault wird per SQL-View oder materialisiert der Gold-Star gebaut. DIM_KUNDE entsteht als Join über HUB_KUNDE und die aktiven Satelliten-Sätze zum Query-Zeitpunkt, FAKT_SCHADEN als zentrale Fakten-Tabelle mit den Dimensions-Keys. Der Data Vault bleibt die auditierbare Historie für Compliance-Nachweise, das Star darüber liefert die abfrage-optimierte BI-Sicht für [Data Marts](/insights/glossar/data-mart/) im Berichtswesen. Auf dem [Data Lakehouse](/insights/glossar/data-lakehouse/) übernehmen Deletion Vectors die zeilengenaue DSGVO-Löschung einzelner Datensätze, ohne die Insert-only-Semantik zu brechen.