Datenmodellierung steht im Zentrum jedes modernen Enterprise Data Warehouse (EDW), wird jedoch oft vernachlässigt. Dies führt bei steigenden Datenmengen und höheren Aktualisierungsfrequenzen zu Skalierungsengpässen und erheblichen Wartungsproblemen.
Data Vault bietet eine einzigartige Architektur, die Skalierbarkeit, vollständige Nachvollziehbarkeit sowie eine widerstandsfähige, historisierte Änderungsverfolgung vereint. Viele Anwender unterschätzen jedoch die Reichweite und das Potenzial dieser Methode. Während die ursprüngliche Data-Vault-Methodik den Schwerpunkt auf das Modellieren legte, geht Data Vault 2.0 weit darüber hinaus. In ihrem wegweisenden Buch präsentieren Daniel Linstedt und Michael Olschimke Data Vault 2.0 als ein umfassendes „System of Business Intelligence“, das nicht nur Modellierung, sondern auch vollständige, praxisnahe Workflows für das unternehmensweite Datenmanagement bereitstellt.
Einer der Hauptpfeiler von Data Vault ist seine Methodik, die bewährte Unternehmenspraktiken kombiniert. So nutzt Data Vault das Capability Maturity Model Integration (CMMI), um Organisationen dabei zu unterstützen, Schritt für Schritt Reife in ihrem Datenmanagement aufzubauen und die richtigen Fähigkeiten in der richtigen Reihenfolge zu entwickeln. PMP-Prinzipien (Project Management Professional) sorgen dafür, dass Projekte im Zeitplan bleiben und einen klaren Geschäftswert liefern. Der System Development Life Cycle (SDLC) stellt eine strukturierte, wiederholbare Vorgehensweise für die Entwicklung sicher.
Darüber hinaus integriert Data Vault 2.0 Six Sigma und Total Quality Management (TQM), um eine Kultur der Qualität und kontinuierlichen Verbesserung über den gesamten Lebenszyklus hinweg – von der Konzeption bis zum Betrieb – zu etablieren. Schließlich bringt die Scrum-Methodik Agilität in die Umsetzung, sodass Teams durch kurze Sprints, enge Zusammenarbeit mit Stakeholdern und iterative Releases flexibel auf sich ändernde Geschäftsanforderungen reagieren können. Eine ausführlichere Diskussion zur Methodik findet sich im Data-Vault-2.0-Buch.
Grundlagen der Data-Vault-Modellierung
Data Vault 2.0 basiert auf drei fundamentalen Modellierungselementen, die das Rückgrat seiner Architektur bilden. Das Verständnis dieser Komponenten ist entscheidend, um nachzuvollziehen, wie Data Vault die Balance zwischen Flexibilität und Performance erreicht. Diese Hauptbausteine sind: Hubs, Links und Satellites.
Hubs repräsentieren die zentralen Geschäftskonzepte einer Organisation. Was genau verfolgt ein Unternehmen? Diese Elemente bilden die Hubs. Ein Hub enthält lediglich den Geschäftsschlüssel sowie Metadaten wie Ladezeitstempel und Quellinformationen. Man kann sich Hubs als stabile Ankerpunkte im Datenmodell vorstellen. Beispiele: Kunden-Hub, Produkt-Hub, Bestell-Hub usw. Diese Entitäten ändern ihre Identität kaum, weshalb sie sich hervorragend als Hubs eignen. Der große Vorteil liegt in der Einfachheit und Stabilität: Auch wenn sich Kundenattribute im Laufe der Zeit verändern, bleibt der Geschäftsschlüssel konstant.
Das nächste zentrale Konzept sind die Links, die Beziehungen und Geschäftsvorfälle zwischen Hubs abbilden. Anders als traditionelle Ansätze (z. B. 3NF), bei denen Fremdschlüssel innerhalb von Entitäten eingebettet sind, lagert Data Vault diese Beziehungen in dedizierte Link-Tabellen aus. Ein Beispiel: Ein „Kunde–Bestellung“-Link verbindet Kunden mit ihren Bestellungen, ohne die Hubs mit Beziehungsdaten zu belasten. Diese Trennung ermöglicht maximale Flexibilität, wenn sich Geschäftsbeziehungen ändern oder neue Beziehungstypen entstehen. Links können beliebig viele Hubs miteinander verbinden, wodurch sich komplexe n:m-Beziehungen leicht modellieren und pflegen lassen.
Satellites speichern alle beschreibenden Attribute und Kontextinformationen, die sich im Zeitverlauf ändern. Jeder Hub und jeder Link kann mehrere Satellites haben, die jeweils unterschiedliche Aspekte einer Entität zu verschiedenen Zeitpunkten erfassen. Ein Kunden-Hub könnte beispielsweise Satellites für demografische Daten, Präferenzen oder Bonitätsinformationen besitzen, die jeweils ihre eigene Änderungshistorie und Ladezyklen aufweisen. Diese feingranulare Trennung erlaubt eine präzise Historisierung und ermöglicht es Teams, unterschiedliche Attributgruppen unabhängig voneinander zu laden und zu aktualisieren.
Neben diesen Kernelementen gibt es im Data Vault auch sogenannte abgeleitete Entitäten, die spezifischere Geschäftsanforderungen adressieren – z. B. Point-in-Time-Tabellen (PIT) oder Bridge-Tabellen. Da diese fortgeschrittener sind, werden sie in diesem Blog nicht behandelt. Bei Fragen zu spezifischeren Entitäten können Sie sich jedoch jederzeit melden.
Die Schichtenarchitektur
Data Vault 2.0 organisiert diese Modellierungskomponenten in einer dreischichtigen Architektur. Auch wenn Schichtenarchitekturen seit Bill Inmon ein Grundprinzip des Data Warehousing darstellen, ist die Data-Vault-2.0-Umsetzung insofern einzigartig, als dass sie in allen Schichten eine strukturelle Konsistenz beibehält. Andere Ansätze hingegen kombinieren oft verschiedene Modellierungsmethoden in den einzelnen Schichten (z. B. relational im Staging, normalisiert im Warehouse, dimensional in Marts).
In der Staging-Schicht landen alle eingehenden Rohdaten in ihrer ursprünglichen Form – mit minimalen Transformationen. Nur eine grundlegende Standardisierung sorgt dafür, dass das Laden ins Raw Vault konsistent möglich ist. Die Staging-Schicht dient als Puffer zwischen den Quellsystemen und den komplexeren Transformationsprozessen downstream. Zudem ermöglicht sie eine vollständige Nachvollziehbarkeit darüber, wann welche Daten aus welcher Quelle eingetroffen sind.
Das Raw Vault ist die markanteste Innovation von Data Vault. Anstatt Daten beim Laden zu normalisieren oder zu denormalisieren, speichert es die reinen, unveränderten Geschäftsdaten nach dem Hub-Link-Satellite-Prinzip. Diese Schicht dient als „Single Source of Truth“ für sämtliche historischen Daten. Sie gewährleistet vollständige Nachvollziehbarkeit und bewahrt die Daten so, wie die Quellsysteme sie erfasst haben – strukturiert für maximale Flexibilität und langfristige Historisierung. Geschäftsregeln oder Transformationen finden hier nicht statt.
Das Business Vault ergänzt das Raw Vault um berechnete Felder, Geschäftsregeln und abgeleitete Daten – jedoch unter Beibehaltung derselben Hub-Link-Satellite-Struktur. Damit bietet es dieselbe strenge Historisierung wie das Raw Vault, erweitert aber die Daten um Business-Logik für analytische Zwecke. Zusammen bilden Raw Vault und Business Vault die Kernschicht des Data-Vault-Warehouse, wobei die Unterscheidung eher funktional als architektonisch ist.
Information Marts bilden die letzte Schicht. Hier werden die Daten für spezifische analytische Anforderungen in optimierten Formaten bereitgestellt. Das können klassische dimensionale Modelle, spezialisierte Analysemodelle oder operative Datenspeicher sein. Sie basieren jedoch stets auf einem Fundament, das vollständige Datenherkunft und historischen Kontext garantiert.
Nachdem wir nun die wichtigsten Konzepte von Data Vault 2.0 behandelt haben, werden wir im nächsten Beitrag ein Beispiel-Warehouse implementieren, um zu sehen, wie alles in der Praxis zusammenpasst. Bleiben Sie dran für den nächsten Blog – und zögern Sie nicht, bei Fragen oder Kommentaren Kontakt aufzunehmen.
Quellen:
- Scalefree (o. D.) Data Vault 2.0 definition. Verfügbar unter: https://www.scalefree.com/consulting/data-vault-2-0/ (Zugriff am: 28. August 2025).
- Linstedt, D. und Olschimke, M. (2015) Building a scalable data warehouse with Data Vault 2.0. Waltham, MA: Morgan Kaufmann.
Introduction to Data Vault 2.0 - Part I
Data modeling sits at the heart of every modern Enterprise Data Warehouse (EDW), yet it is often neglected, leading to scalability bottlenecks and maintenance headaches as data volumes and update frequencies grow.
Data Vault delivers a unique architecture that combines scalability, full auditability, and resilient historical tracking of changes. Many practitioners, however, misunderstand its scope and underappreciate its true potential. Although the original Data Vault methodology emphasized modeling, Data Vault 2.0 extends far beyond that single layer. In their landmark book, Daniel Linstedt and Michael Olschimke present Data Vault 2.0 as a comprehensive “system of business intelligence,” complete with practical, enterprise-scale workflows for implementing not just the model but an end-to-end data management framework.
One of the main pillars of Data Vault is its methodology, which combines well-established enterprise practices. It uses the Capability Maturity Integration (CMMI) to help organizations gradually build maturity in their data management processes, ensuring they develop the right capabilities in the right order. Project Management Professional (PMP) principles ensure projects stay on track and deliver business value, while Systems Development Life Cycle (SDLC) provides a structured, repeatable approach to development.
Data Vault 2.0 also integrates Six Sigma and Total Quality Management (TQM) to embed a culture of quality and continuous improvement throughout the lifecycle, from design to operations. Last but not least, Scrum methodology brings agility to delivery, enabling teams to respond to changing business needs through short sprints, stakeholder collaboration, and iterative releases. A much more detailed discussion of the methodology can be found in the Data Vault 2.0 book.
Fundamentals of Data Vault Modeling
Data Vault 2.0 builds upon three fundamental modeling constructs that form the backbone of its architecture. Understanding these components is crucial for appreciating how Data Vault achieves its balance of flexibility and performance. These main building blocks are: Hubs, Links, and Satellites.
Hubs represent the core business concepts within an organization. Fundamentally, what is it that a business tracks? Those will be the Hubs in a data vault. A Hub contains only the business key and metadata such as load timestamps and record sources. Think of Hubs as the stable anchors in the data model. Examples of a Hub might be: a customer Hub, product Hub, order Hub, etc. These entities rarely change their fundamental identity, making them perfect candidates for the Hub structure. The beauty of this design lies in its simplicity and stability. Regardless of how customer attributes evolve over time, the customer's business key remains constant.
The next core concept, Links, captures the relationships and business events between Hubs. Unlike traditional approaches, such as 3NF, that might embed foreign keys within entities, Data Vault isolates these relationships into dedicated Link tables. For example, a Customer-Order Link connects customers to their orders without cluttering either the Customer or Order Hub with relationship data. It might seem trivial at first sight, but this separation provides tremendous flexibility when business relationships change or when new relationship types emerge. Links can connect any number of Hubs, making complex many-to-many relationships straightforward to model and maintain.
Satellites house all the descriptive attributes and context that change over time. Every Hub and Link can have multiple Satellites attached, each capturing different aspects of the entity at different points in time. A Customer Hub might have separate Satellites for demographic information, preferences, credit ratings, and these Satellites could have their own change history and load patterns. This granular separation allows for precise historical tracking and enables team to load and update different attribute sets independently.
In addition to the core entities in Data Vault, there are also so-called derived entities that are used to address more specific business needs. These include, but are not limited to, Point-in-Time (PIT) tables and Bridge tables. We will not discuss these as they are more advanced entities and outside the scope of this blog. Please reach out if you require clarification on other more specific data vault entities.
The Layered Architecture
Data Vault 2.0 organizes these modeling components within a three-layer architecture, and while layered architectures have been fundamental to data warehousing since Bill Inmon, Data Vault 2.0 implementation is unique in that it maintains structural consistency across the different layers. This is as opposed to other methodologies that might, for example, use relational modeling in staging, normalized in the warehouse layer, and dimensional in marts.
In the Staging Layer, we have a landing zone for all incoming data. Raw data arrives here in its original form with minimal transformation. We have just enough standardization to ensure consistent loading into the Raw Vault. The Staging Layer acts as a buffer between the source systems and any sort complex transformation process that happens downstream. This way, we also have a complete audit trail of what arrived when and from where.
The Raw Vault represents Data Vault's most distinctive innovation. Instead of normalizing or denormalizing data upon entry to the warehouse, the Raw Vault preserves pure, untransformed business data organized into the Hub, Link, and Satellite structure. This layer serves as the single source of truth for all historical data, maintaining complete auditability while organizing information according to Data Vault modeling principles. No business rules or transformations are applied at this layer and it represents exactly what the business systems recorded, when they recorded it, but structured for maximum flexibility and historical preservation.
The Business Vault introduces calculated fields, business rules, and derived data while maintaining the same Hub, Link, Satellite. structure as the Raw Vault. It maintains the same rigorous historical tracking as the Raw Vault while adding the business intelligence needed for analytical workloads. The Raw Vault and Business Vault together form the core Data Vault warehouse layer, both using identical modeling structures. The distinction is functional rather than architectural.
Information Marts provide the final layer, delivering data in formats optimized for specific analytical use cases. These marts can be traditional dimensional models, specialized analytical structures, or operational data stores, but they draw from a foundation that preserves complete data lineage and historical context.
Now that we've covered the main concepts of Data Vault 2.0, we'll implement an example warehouse to see how everything fits together in practice. Stay tuned for the next blog, and don't hesitate to reach out with any questions or comments.
Sources:
- Scalefree (no date) *Data Vault 2.0 definition*. Available at: https://www.scalefree.com/consulting/data-vault-2-0/ (Accessed: 28 August 2025).
- Linstedt, D. and Olschimke, M. (2015) *Building a scalable data warehouse with Data Vault 2.0*. Waltham, MA: Morgan Kaufmann.
Kommentar schreiben