Data Vault Modelling
A modelling approach separating business keys, relationships and descriptive attributes into hubs, links and satellites, optimised for auditability and change absorption.
Data Vault is built for a specific environment: many source systems, frequently changing, with a regulatory requirement to show exactly what arrived and when. Hubs hold business keys, links hold relationships between them, and satellites hold time-stamped descriptive attributes from each source.
Its strengths follow from that split. Adding a source system means adding satellites without restructuring anything. Relationships change without rewriting history. And the load is fully auditable and insert-only, which is why it appears so often in banking and insurance where lineage must be demonstrable to a regulator.
Its cost is equally structural: the model has many more tables than a dimensional one, queries require many joins, and it is genuinely unpleasant to consume directly. That is by design — Data Vault is an integration layer, not a serving layer, and it is normally followed by dimensional marts built on top of it.
The failure this creates in practice is teams adopting it for the integration properties and then exposing it to analysts, who find the join complexity impossible. If the marts are not built, the project is usually judged a failure regardless of how correct the vault is.