DATA ARCHITECTUREEnterprise

Data Vault 2.0

How data engineers design data that lasts — pick a topic on the left and its full breakdown loads here: the mental model, ERDs and worked schemas, trade-offs, edge cases, and the decisions that separate a durable model from a fragile one.

⏱ 18 min readTopics chapter readerLevel · Dimensional & Warehouse
01 · Orientation

What You'll Master Here

Separate keys (hubs), relationships (links), and context (satellites) so each loads independently, insert-only, fully audited, and never needs rewriting when a source changes.

⏱ 4 min · Topic 1 of 10

Chapter 12 placed Data Vault beside Inmon and Kimball. This chapter is about how it actually works, because the mechanics are exact and most of what goes wrong with a vault is a mechanical mistake rather than a strategic one.

Step the walkthrough below through one row of an aircraft maintenance feed. Three business keys become hubs, then a link, then satellites — and the last step shows what it costs to put them back together again.

Core mental model

Separate keys (hubs), relationships (links), and context (satellites) so each loads independently, insert-only, fully audited, and never needs rewriting when a source changes.

Why it matters

Data Vault is increasingly common in regulated, multi-source enterprises and in modern ELT stacks. Knowing its mechanics lets you build, query, or evaluate one instead of treating it as a black box.

hub
A table of unique business keys plus a hash key, load date, and source.
link
A table recording a relationship/association between hubs.
satellite
A table of descriptive attributes and their history, attached to a hub or link.
hash key
A hash of the business key used as the surrogate, enabling parallel, lookup-free loads.
One source row, walked through the vaultHalewood Aviation fits a fuel pump to airframe MSN-31842. Follow that single row in, and back out.
One flat row from maint_core
  • maint_core.fitment_exportsourcesource extract — one row
    msnpart_serialpart_descconditioncycles_ovhwo_nofitted_on
    MSN-31842SN-77-04412Fuel pump, LHSVC1204WO-2026-11882026-06-12
0 · The source rowSeven columns with four different lifetimes in them. The airframe outlives everything on the row. The part serial is stamped into metal and never changes. The condition changes at every inspection. The fitment itself ends the day the pump is pulled. Keep them in one row and the slowest-changing column gets rewritten every time the fastest one moves.
Common mistake

Using Data Vault as the layer business users query directly. It has many tables and joins; it is an integration core, not a consumption model, serve marts on top.

Better habit

Separate keys, relationships, and context into hubs/links/satellites.

Keep every table insert-only and source-stamped.

Build dimensional marts on top for consumption.

Where this chapter starts

Whether Data Vault is the right architecture at all is Chapter 12's question. This chapter assumes the decision is made and teaches the mechanics: what each object holds, what a real source change touches, and what it takes to get an answer back out.

Compare the three architectures (Ch. 12)
Remember this

Data Vault splits a model into hubs (keys), links (relationships), and satellites (history), loaded insert-only and source-stamped, for auditability and resilience to source change.