How to apply the best ideas of Data Vault while staying grounded in a business-oriented, 3NF bi-temporal model
Summary
Data Vault has strong ideas about historization, traceability, and scalability — but it’s not always the right fit if your core is a business-oriented LDM with 3NF and bi-temporality.
In this article, I show how to selectively borrow the best concepts (hubs, links, satellites) and integrate them into a methodology that remains business-first and model-driven.
What Data Vault Gets Right
Data Vault was designed with a focus on integration, historization, and auditability. Some of its concepts are extremely useful when applied thoughtfully:
- Business keys in hubs: Clear anchor points for integration.
- Links for relationships: Explicit modeling of associations between entities.
- Satellites for history: Flexible historization of attributes.
- Auditability: Full lineage back to the source, which is critical for compliance.
These strengths explain why Data Vault remains influential in modern data architecture.
The Pitfalls of Literal DV
Despite its value, a literal implementation of DV doesn’t always serve business needs. Some of the challenges I’ve observed:
- It can become source-centric rather than business-centric.
- Managing large numbers of hubs, links, and satellites introduces overhead.
- Retrieval can be cumbersome if a business-shaped integration layer is missing.
👉 I reflected on this balance in How Hans Hultgren and Ensemble Modeling Influenced My Data Architecture Philosophy, where I discussed how ensemble modeling ideas inspired my approach without dictating the entire methodology.
Borrowing the Good, Skipping the Baggage
In practice, we don’t “do DV.” Instead, we borrow selectively:
- Hubs → map naturally to the business entities already defined in the LDM (e.g., Customer, Product, Agreement).
- Links → represent relationships that are explicit in the enterprise ontology (e.g., Customer–Agreement, Product–Event).
- Satellites → align directly with bi-temporal SCD2 historization, which I explained in From Historization to Exposure: Building a Usable Data Platform with Dual SCD2.
- Metadata-driven mapping → supports automation, in line with Metadata-Driven Data Architecture: Leveraging draw.io and VSCode for Scalable Design.
This way, we integrate the useful patterns of DV without taking on unnecessary baggage.
DV in the Four Pillars Framework
Selective borrowing fits neatly into the four pillars methodology:
- Business-Oriented LDM (Pillar 1) ensures we stay anchored in business meaning rather than sources.
- Model-Driven Engineering (Pillar 2) automates DV-inspired mappings, reducing manual work.
- Business-Friendly Mapping (Pillar 3) ensures lineage and historization remain transparent to business users.
- UDMs (Pillar 4) provide the universal content that hubs and links can connect back to.
This approach transforms DV ideas into practical tools that complement — rather than compete with — a business-oriented architecture.
Where We’re Headed
In the next article, we’ll move from concepts into practice: showing how Model-Driven Engineering with draw.io, VSCode, and metadata automation makes these ideas executable.
Key Takeaways
- Data Vault provides valuable design ideas: hubs, links, satellites, and auditability.
- Literal DV can create overhead and source-centricity if not balanced with business meaning.
- By borrowing selectively, we keep DV’s strengths while anchoring everything in a 3NF, bi-temporal, business-oriented model.
- This selective approach integrates directly into the four pillars methodology.
✍️ This article is Part 4 of the series “Why Elephants Matter in Data Modeling”, where I explore how John Giles’ ideas, Len Silverston’s Universal Data Models, and my own methodology come together in a business-first, model-driven approach.
Series overview
- Part 1: Why Elephants Matter in Data Modeling
- Part 2: Patterns + Universals: The Foundations of Reuse
- Part 3: From Ontology to Enterprise View
- Part 4: Borrowing from Data Vault Without Building One
- Part 5: Model-Driven Engineering in Practice
- Part 6: Business-Friendly Mapping as a Collaboration Tool
- Part 7: The Four Pillars of Business-Centered Data Architecture