▣ dataarchitect.studio

Pattern

Data Vault

Model the integration layer as hubs (business keys), links (relationships), and satellites (history), so the warehouse absorbs change without remodelling.

Intent

Build a warehouse integration layer that survives constant source-system change and regulatory audit: every business key, relationship, and attribute history is stored separately, append-only, with full lineage of where and when each fact arrived.

Context

Many volatile source systems feed one warehouse; auditability is a hard requirement; and the cost of remodelling downstream marts every time a source changes has become unbearable. Data vault deliberately splits integration (the vault) from presentation (usually star schemas built on top).

Structure

hub_customer business key only hub_order business key only link_places relationship sat_customer_details attributes + history sat_order_status attributes + history hubs = keys · links = relationships · satellites = descriptive history

New sources or attributes mean adding tables — a new satellite, a new link — never altering existing ones. Everything is append-only and stamped with load time and record source.

Trade-offs

Gains: insulation from source churn; complete, auditable history by construction; highly parallel loads; new sources integrate without remodelling.

Costs: table count explodes (one entity becomes three-plus tables); queries need many joins, so you must build a presentation layer on top — the vault is not queryable by humans in practice; and the methodology demands real training and discipline. It’s an integration-layer pattern for large, regulated, multi-source estates — not a default.

When not to use it

Few sources, moderate change rate, no audit mandate, or a small team: go straight to dimensional. A vault whose discipline lapses is the worst of both worlds — all the joins, none of the guarantees.

Common questions

What are hubs, links, and satellites in data vault?

Hubs store just the business keys of entities (customer, order). Links store relationships between hubs. Satellites store the descriptive attributes and their full history, attached to a hub or link. Everything is append-only and stamped with load time and source.

When should I use data vault instead of dimensional modeling?

When you have many volatile sources, hard audit requirements, and the cost of remodelling marts on every source change has become unbearable — data vault absorbs change by adding tables. With few sources and no audit mandate, dimensional modeling alone is simpler and sufficient.

Can you query a data vault directly?

In practice, no — the hub/link/satellite split means even simple questions need many joins. A data vault is an integration layer; you build a presentation layer, usually star schemas, on top of it for analysts and BI tools.