Fachliche Modellierung (Teil 4) – Data Vault und des Kaisers neue Kleider?
Modellierung dient dazu, Zusammenhänge möglichst einfach und zweckdienlich darzustellen. Gute Modellierung schafft Klarheit, Data Vault hingegen erzeugt Komplexität.
Data Vault zerlegt die Welt in technokratische Bausteine: Hubs, Links, Satelliten. Es trennt Dinge von ihren Beschreibungen und verteilt selbst eng zusammenhängende Informationen auf viele Tabellen. Diese Konstruktion erschwert das Verständnis erheblich – ohne erkennbaren fachlichen oder technischen Nutzen.
Im Vergleich zum Star Schema vervielfacht sich die Anzahl der Tabellen drastisch: Während ein Star Schema für einen Geschäftsprozess typischerweise aus einer Faktentabelle und wenigen Dimensionen besteht (oft unter zehn Tabellen), kann ein entsprechendes Data Vault-Modell leicht auf 30, 50 oder mehr Tabellen anwachsen. Diese Vervielfachung resultiert aus der Grundstruktur des Modells: Jede Entität wird als Hub modelliert, Beziehungen als Links und jede beschreibende Eigenschaft als eigener Satellit. Bereits für vier Dimensionen können so über 15 Tabellen entstehen – und das ist nur ein Minimalbeispiel.
Mehr Tabellen bedeuten mehr Entwicklungs- und Wartungsaufwand, komplexere ETL-Prozesse, schlechtere Performance und ein unverständliches Modell für Fachanwender. Diese Herausforderungen betreffen nicht nur den Entwicklungsaufwand, sondern wirken sich auch negativ auf Fehlersuche, Releasezyklen und Data Governance aus.
Ein weiterer Aspekt: Die Zahl der Architekturschichten steigt oft deutlich an. Klassische Architekturen bestehen meist aus drei Schichten: Stage, konsolidierter Core (z. B. 3NF), Star Schema. In Data Vault-Projekten hingegen finden sich oft vier oder mehr Layer: Stage, Raw Data Vault, Business Data Vault und danach erst das Star Schema. Hinzu kommen in einigen Architekturen noch PIT- oder Bridge-Tabellen.
Diese Schichtung ist nicht per se falsch, doch in der Praxis bedeutet sie mehr Komplexität, mehr Abhängigkeiten, mehr Deployment-Pfade. Der Stage-Layer entfällt meist nicht, da im Raw Vault bereits Transformationslogik einfließt (z. B. Hash Keys). Der Business Vault bringt eine eigene Logikschicht mit sich, die oft schwer nachvollziehbar ist. Das Ergebnis: ein Datenfluss, der sich nur mit hohem technischen Aufwand überblicken lässt.
Befürworter behaupten, Data Vault sei dort sinnvoll, wo große Mengen historischer Daten flexibel integrierbar sein müssen – etwa in hochregulierten Branchen. Auf danlinstedt.com wird Data Vault als evolutionärer Standard beschrieben, der Transparenz, Auditierbarkeit und Flexibilität vereinen soll. Doch selbst in diesem Kontext fehlt mir die Vorstellung, wie diese Modellierung echten Mehrwert schaffen soll. Die versprochene Flexibilität führt in der Praxis oft zu einem starren Gefüge voller Abhängigkeiten.
Ein beliebtes Argument für Data Vault ist sein Einsatz in Projekten wie denen der NASA. Dort soll es geholfen haben, große Mengen historisierter Daten systematisch zu erfassen, ohne bestehende Strukturen zu verändern. Ob Data Vault dafür wirklich das richtige Modell war, kann ich nicht beurteilen. Und vielleicht gibt es sogar Spezialfälle, in denen es funktioniert. Aber für den klassischen Einsatz in Business Intelligence und Data Warehousing halte ich es für ungeeignet. Dort geht es um Verständlichkeit, Agilität und Zusammenarbeit mit dem Fachbereich. Dafür ist Data Vault schlicht das falsche Werkzeug.
Selbst spezialisierte Automatisierungstools können den Aufwand nicht wirklich abfedern: Sobald Data Vault nicht streng regelkonform umgesetzt wird – was in vielen Projekten der Fall ist – stoßen diese Tools an ihre Grenzen. Wartung und Pflege werden dann extrem aufwändig und fehleranfällig. Diese Erfahrung mache nicht nur ich: In zahlreichen Erfahrungsberichten, Foren und Fachartikeln wird ähnlich berichtet. Zum Beispiel zeigt Kyvos Insights, wie schwer nachvollziehbar der Pfad von Data Vault zur Berichtsstruktur sein kann. Data Vault führt in der Praxis häufig zu hoher Komplexität, geringem Nutzen und sinkender Agilität.
Warum ist Data Vault dennoch so weit verbreitet?
Ich glaube nicht, dass es an einer Beratungsindustrie liegt, die an der Komplexität verdient. Ich glaube, wir führen Data Vault ein, weil wir es können. Weil es neu ist, anspruchsvoll, elegant wirkt. Weil wir hoffen, damit auf der Höhe der Zeit zu sein.
Wir unterschätzen, wie schwer es zu betreiben ist. Und wir überschätzen, wie sehr sich die zugrundeliegenden Ideen in echte Vorteile für das Business übersetzen lassen. Wir greifen zu Data Vault, weil es professionell aussieht, technisch sauber wirkt – und weil wir hoffen, damit auf der sicheren Seite zu sein. Doch genau das macht es so schwer, sich davon zu lösen.
Für mich ist Data Vault ein Beispiel für „des Kaisers neue Kleider“: Ein System, das durch Komplexität Autorität ausstrahlt – ohne dass jemand den fehlenden Erkenntnisgewinn hinterfragt.
Weiterlesen in meiner Modellierungsreihe:
- Wer ist verantwortlich für Begriffe im Datenmodell?
- Warum das BI-Team für das fachliche Datenmodell verantwortlich ist?
Über die Autorin:
Dr. Katharina Wirtz ist Beraterin mit dem Fokus auf BI, Datenmodellierung und Team-Enablement. Mit ihrer Firma SKET22 hilft sie Unternehmen, datengetriebene Entscheidungen auf ein solides Fundament zu stellen.
Mehr zu ihren Workshops: sket22.de
Vernetzen auf LinkedIn: linkedin.com/in/katharina-wirtz