The Separation Rule
The entire mechanics of the Data Vault rest on one idea: the three components of a piece of business data don't change at the same pace. A customer's identifier rarely changes. Their relationships with contracts, branches or orders change regularly. Their descriptive attributes change constantly.
Mixing these three paces in a single table means letting the most volatile one impose its rate of rework on the most stable one. The Data Vault separates them into three distinct object types.
The hub: the list of business identifiers
A hub contains only one thing: the unique list of business keys for a concept — a customer number, a contract identifier, a product code. It also carries the source of origin and the date of first appearance.
No descriptive attribute, no relationship. This stripped-down nature is precisely what makes the hub the stable anchor point of the whole model: as long as the business identifies its customers the same way, the hub doesn't move, whatever changes occur in the source systems.
The link: the relationship, and nothing else
A link materializes the association between two or more hubs: this customer holds this contract, this order concerns this product delivered to this address. It only stores the keys involved and load metadata.
Key point: a link is always many-to-many by design. If the business decides tomorrow that a contract can have two holders, no table needs to be modified — cardinality was never fixed in the structure.
The satellite: all context, historized
Satellites attach descriptive data to a hub or a link: name, address, status, amounts, business dates. Each change creates a new timestamped row instead of overwriting the previous one.
Satellites are generally separated by source and by rate of change. One satellite for civil status data that changes once a year, another for statuses that change daily: volumes stay under control and loads remain independent.
- Hash key: deterministic technical identifier derived from the business key.
- Hash diff: content fingerprint, used to load only true changes.
- Load date and record source: native traceability of each record.
Raw Vault and Business Vault
The Raw Vault receives data exactly as delivered by the source, with no business transformation. This is what makes auditing possible: you can always demonstrate what the source system sent, and when.
The Business Vault, built on top, carries the business rules: calculated aggregates, views, bridge tables, master data repositories. It can be rebuilt at will without ever touching the Raw Vault.
Why these mechanics automate so well
The loading patterns for a hub, a link or a satellite are identical regardless of the business domain. What varies is the mapping; what repeats is the code — 90% of the time.
This is where automation makes all the difference: beVault generates the structures and loads from the model, applies the same controls everywhere, and eliminates drift between pipelines written by different developers.