Data Vault Modellierung: So baust du eine skalierbare Datenbasis

Definition

Data Vault Modellierung ist ein Ansatz zur Datenmodellierung für Warehouses, der Daten in Hubs, Links und Satellites strukturiert und Änderungen konsequent historisiert. Es ist nicht das Reporting-Modell (z. B. Star Schema), sondern eine Integrations- und Historisierungsschicht für viele Datenquellen.

Einleitung

Wenn Quellsysteme wachsen, sich Felder ändern und Excel-Logik überall anders aussieht, wird ein klassisches Datenmodell schnell zur Dauerbaustelle. Data Vault Modellierung setzt genau hier an: Sie trennt stabile Schlüssel von beschreibenden Attributen und Beziehungen, damit dein Datenmodell Änderungen besser aushält und Analysen verlässlich bleiben.

Kernbausteine: Hubs, Links, Satellites

Data Vault wurde maßgeblich von Dan Linstedt geprägt. Der Ansatz basiert auf drei Hauptkomponenten, die bewusst unterschiedliche Aufgaben haben und dadurch Skalierbarkeit und Nachvollziehbarkeit verbessern.

• Hub (Data Vault): Enthält den stabilen Business Key (z. B. Kundennummer) plus technische Metadaten. Optional wird ein Surrogate Key genutzt, oft als Hash Key / Hashing.

• Link (Data Vault): Bildet Beziehungen zwischen Hubs ab (z. B. Kunde–Vertrag, Auftrag–Position). Links sind der Ort für viele-zu-viele-Beziehungen und helfen, komplexe Beziehungsnetze sauber zu speichern.

• Satellite (Data Vault): Speichert beschreibende Attribute und deren Historisierung (z. B. Name, Status, Adresse, Preise). Satelliten speichern, was sich ändert, ohne den Hub instabil zu machen.

Diese klare Trennung ist der praktische Hebel: Neue Attribute landen in Satelliten, neue Beziehungen in Links, neue Objekte als Hubs. Das reduziert Umbauten an bestehenden Strukturen, wenn Anforderungen sich verändern.

Raw Vault vs. Business Vault: klare Trennung

Ein häufiger Fehler ist, fachliche Regeln zu früh in die Integration zu drücken. Data Vault trennt deshalb bewusst:

• Raw Vault: Abbildung der Quelle so nah wie möglich an der technischen Wahrheit, inklusive Historisierung und Auditierbarkeit. Hier wird nicht „schön gerechnet“, sondern sauber gespeichert, was geliefert wurde.

• Business Vault: Ableitungen, Harmonisierung, Regelwerke und fachliche Interpretationen (z. B. Klassifikationen, abgeleitete Kennzeichnungen, Regel-Links). Das ist die Schicht, aus der später Data Mart / Information Mart und Analysen gebaut werden.

Für Anwender bedeutet das: Die „Diskussion über die Zahl“ wird kleiner, weil Rohdaten, Korrekturen und fachliche Logik transparent getrennt sind.

Bi-temporale Historisierung und zeitliche Konsistenz

Bi-temporale Historisierung bedeutet, dass zwei Zeitachsen getrennt geführt werden: fachliche Gültigkeit (wann galt etwas in der Geschäftswelt?) und technische Erfassung (wann wurde es im Warehouse geladen oder korrigiert?).

Das ist entscheidungsrelevant, wenn Zahlen rückwirkend korrigiert werden (z. B. Stornos, Nachträge, Datenqualitätsthemen). Statt „Vergangenheit umzuschreiben“ bleibt nachvollziehbar, welche Version zu welchem Zeitpunkt bekannt war. Das erhöht zeitliche Konsistenz und schützt vor Überraschungen in Monatsabschluss- oder Audit-Situationen.

Delta-Load-Strategien: Delta-Only Load und Hash Keys

Data Vault wird typischerweise delta-basiert geladen: Es werden nur neue oder geänderte Datensätze verarbeitet (Delta‑Only Load / Änderungsflankengetriebene Beladung), statt Tabellen immer komplett zu replizieren. Das ist bei großen Datenmengen und vielen Quellen oft der Unterschied zwischen „läuft stabil“ und „läuft nur nachts mit Glück“.

In der Implementierung helfen Hash Key / Hashing und Hash-Diffs, Änderungen effizient zu erkennen. Der Nutzen ist pragmatisch: weniger ETL / ELT-Last, klarere Delta-Logik, reproduzierbare Läufe und bessere Skalierbarkeit.

Data Vault 1.0 vs. Data Vault 2.0

Data Vault 1.0 beschreibt primär das Modellkonzept (Hubs, Links, Satellites). Data Vault 2.0 erweitert das Ganze um klarere Methodik für Implementierung, Automatisierung, Governance und moderne Plattformen.

In der Praxis ist Data Vault 2.0 meist die relevantere Wahl, weil es Standards für wiederholbare Muster liefert (z. B. Lade-Templates, Hashing-Strategien, Audit-Spalten) und damit die Umsetzung planbarer macht.

Vergleich: Kimball, Inmon, Data Mesh

Data Vault ersetzt nicht alles, sondern sitzt an einer anderen Stelle:

• Star Schema / Kimball‑Methodik: stark für konsumierbare Data Marts, schnelle Fachbereichsanalysen und „breites“ Reporting. Data Vault ist oft davor als Integrationsschicht sinnvoll.

• Inmon: fokussiert ein zentral normalisiertes Enterprise Warehouse. Data Vault erreicht ähnliche Ziele (Integration, Historie), bleibt aber in Änderungen oft flexibler.

• Data Mesh: organisatorischer Ansatz. Data Vault kann darin als Modellierungsstandard dienen, um domänenspezifische Datenprodukte konsistent und auditierbar bereitzustellen.

Architektur im Lakehouse/Cloud: vom Vault zum Gold-Layer

In Lakehouse-Setups passt die Schichtung gut zusammen: Raw Vault entspricht oft dem belastbaren Integrationskern, Business Vault liefert fachlich nutzbare Ableitungen, und daraus entstehen Gold-Sichten bzw. Data Marts für Power BI und Excel.

Der Anwendernutzen ist klar: Auch Nicht-IT-affine Nutzer greifen auf saubere, konsistente „Gold“-Daten zu, statt sich durch Tabellen, Schlüssel und Workarounds zu kämpfen. Das macht Self-Service realistischer, ohne Governance zu verlieren.

Praxisleitfaden mit Mini-Beispiel

Ein Unternehmen konsolidiert Kunden- und Umsatzdaten aus ERP, CRM und Excel-Listen. Im Data Vault entstehen ein Kunden-Hub (Business Key), Links zwischen Kunde–Vertrag–Auftrag und Satelliten für Attribute wie Status, Region und Zahlungsbedingungen. Korrekturen aus dem ERP werden bi-temporal historisiert, sodass Monatsberichte rückwirkend erklärbar bleiben. Aus dem Business Vault werden danach stabile Data Marts gebaut, auf denen Power-BI-Dashboards ohne ständige Modellumbauten laufen.

Best Practices: Modellierungstechniken, die sich bewähren

• Business Keys sauber definieren: Wenn der Schlüssel wackelt, wackelt das ganze Modell (inkl. Links und Historisierung).

• Satelliten bewusst schneiden: Attribute nach Änderungsfrequenz und fachlicher Zugehörigkeit gruppieren, statt alles in einen „Monster“-Satelliten zu pressen.

• Governance und Naming von Anfang an: Tabellen, Schlüssel, Ladezeitpunkte und Metadaten müssen einheitlich sein, sonst wird die Wartung teuer.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung wird sinnvoll, wenn du mehr als ein oder zwei Datenquellen integrierst, Historisierung und Auditierbarkeit wirklich ernst meinst oder zeitliche Konsistenz geschäftskritisch ist. Besonders knifflig sind die richtigen Delta-Load-Strategien, Hashing-Konventionen, die Abgrenzung Raw Vault vs. Business Vault und die Frage, wie schnell daraus Data Marts entstehen sollen.

Gute Hilfe reduziert Projektrisiko: weniger Umwege in der Implementierung, klarere Architekturentscheidungen und ein Datenmodell, das auch in zwei Jahren noch wartbar ist.