Why banks and other complex organizations should preserve Inmon-style modeling while adopting the best concepts from Data Vault.
Introduction
Data Vault has left an undeniable mark on modern data architecture. Its ideas around auditability, insert-only loading, and query assistance have reshaped how many practitioners think about scalable data warehouses.
Yet, as I have argued in earlier articles, its implementations can easily become overly complicated — introducing new terminology, conflicting schools of thought, and steep learning curves that make delivery harder rather than faster.
So where do we go from here?
In this article, I propose an alternative path: one that builds on the strengths of Data Vault concepts but anchors them firmly in the clarity of 3NF modeling and bi-temporal SCD2 structures. This approach retains the governance and scalability required in complex enterprises (like banks), while keeping models understandable, business-oriented, and technically efficient.
Keeping the Core: 3NF as the Integration Layer
At the heart of this approach lies the logical data model (LDM). The LDM defines entity types — core entities, characteristic entities, associative entities, and reference entities. In a 3NF integration layer, these logical distinctions map directly to physical tables:
- Core entity → Core table (similar to a Hub, but without introducing new language)
- Characteristic entity → Attribute table (like Satellites, but modeled with clarity)
- Associative entity → Relationship table (similar to Links, representing many-to-many or complex relations)
- Reference entity → Lookup table
Unlike Data Vault, we do not create new constructs or invent a separate terminology. Instead, we remain in the familiar Inmon 3NF world while ensuring that inheritance, historization, and auditability are properly handled.
Handling Supertypes and Subtypes the Classic Way
One of the thorniest challenges in Data Vault implementations is the inheritance problem — when to model a Hub, when something is a core concept, and how to deal with subtype hierarchies (e.g. parties, agreements, collateral).
In 3NF, the solution is simple and elegant:
- Physical table at supertype level: one table stores all subtype columns as nullable fields.
- Views at subtype level: business users see clean subtype-specific views, derived from the supertype table.
This avoids the confusion of distributing subtype attributes across multiple satellites or introducing “inheritance hubs,” which mixes modeling styles and creates unnecessary complexity.
Bi-Temporal SCD2 as the Foundation
The integration layer must handle change over time — and this is where dual (bi-temporal) SCD2 comes in. Each core and attribute table tracks:
- Valid-from / valid-to (business effective dates)
- Load timestamp (system insertion moment)
This dual tracking allows both business history and system lineage to be reconstructed at any point in time. It is simple, governed, and powerful.
Borrowing the Best from Data Vault
Even though we simplify, we do not throw out Data Vault entirely. Instead, we integrate its most valuable ideas:
- PIT (Point-in-Time) tables: Query assistance to simplify temporal joins and deliver snapshot views without scanning validity ranges on every query. Essential for monthly reporting or regulatory views.
- Bridge tables: Simplify multi-hop joins across complex associative entities, improving performance for consumption layers.
- Insert-only loading: Preserves the audit trail and ensures we can always replay history.
In short, we keep what works and leave behind the dogma.
Why This Matters
For highly governed environments such as banks, the trade-off is clear:
- Data Vault implementations often descend into complexity, accessible only to a handful of certified experts.
- 3NF with bi-temporal SCD2, supported by selective Data Vault concepts, ensures transparency, clarity, and maintainability.
- Business users, modelers, and engineers can work from a shared logical model without navigating an artificial new language of hubs, links, and satellites.
Conclusion
Data Vault taught us much about auditability, parallelization, and agility. But its greatest gift might be the concepts we can reuse in simpler, more transparent architectures.
By combining classic 3NF integration modeling with bi-temporal SCD2 and borrowing helper concepts like PIT and bridges, we can deliver data platforms that are:
- Governed and auditable
- Scalable in the cloud
- Understandable to both business and IT
This hybrid approach offers the best of both worlds: the discipline of Inmon, the clarity of logical modeling, and the practical patterns of Data Vault — without the burden of unnecessary complexity.
✍️ This article is Part 5 of the Data Vault Reconsidered series.
- Part 1: Still Relevant in the Cloud Era?
- Part 2: The Complexity of a Data Vault Implementation
- Part 3: The Data Vault Practitioner’s Glossary
- Part 4: Dan Linstedt and the Origins of Data Vault
- Part 6 (next): From Complexity to Clarity — Migrating from DV to Simplified Bi-Temporal SCD2
- Part 7: Migrating from Data Vault to Bi-Temporal 3NF: A Controlled Metadata-Driven Approach