AI Glossary / Data engineering and architecture / Intermediate

Data vault modeling

Definition

Data vault modeling is a data-modeling approach commonly used to integrate and retain historical data from multiple sources. It separates business identifiers, relationships and descriptive history into structures called hubs, links and satellites. This separation supports traceability and change over time, while downstream structures present data for particular reporting or analytical needs.

What it means

The word “vault” does not mean an encryption product or a password manager. Here it describes an approach to organizing enterprise data. The central idea is to avoid placing identity, relationships and frequently changing descriptions into one structure with competing responsibilities.

Data Vault 2.0 is broader than the modeling pattern alone: its creator describes methodology, architecture and implementation as additional components. Renaming tables as hubs, links and satellites therefore does not automatically produce a well-governed platform, correct integration or a useful analytical service. Business meaning and operational discipline remain necessary.

How it works

A hub records distinct business keys for a concept, such as customer numbers. A link records relationships at a defined grain, such as an association between a customer and an order. Satellites hold descriptive context and history associated with a hub or link.

Load information and record-source metadata help explain when and from where information entered the system. Changes can be captured as historical satellite records rather than simply overwriting earlier descriptions. Detailed patterns vary, including how validity periods, multiple active values and relationship changes are represented.

An architecture may distinguish a Raw Vault that preserves source-oriented information from a Business Vault that adds derived rules or supporting structures. Reporting marts can then expose information in forms convenient for consumers. The layers must not obscure meaning: load time is not automatically the time a fact became true in the business, and matching key strings do not automatically identify the same entity.

Three practical examples

1. Customer integration: a company combines records from several operational systems while retaining source attribution. It resolves what each system's customer identifier means before treating similar identifiers as shared business keys.

2. Product history: descriptive changes such as classification or packaging details are retained separately from product identity. Analysts can investigate which source supplied a recorded description and when it arrived.

3. AI dataset preparation: a team derives features from historical integrated data. It checks which information was available at the relevant prediction time so later corrections do not silently leak into earlier training examples.

Think of it this way

Think of a museum catalog with three connected parts: identifiers for objects, records of relationships between them and dated descriptions from different curators. A new description does not require inventing a new identity for the object.

The analogy helps explain separation and history. A real data vault uses precise keys, table grains and loading rules; a tidy catalog alone does not solve conflicting identifiers, missing history or inconsistent source definitions.

Worked example

Suppose a simplified design contains customer C17 and order O88. A customer hub records C17, an order hub records O88, and a link records the customer-order association. A customer satellite records the segment “Standard” loaded on 1 March.

On 10 March, the source reports “Premium.” The design adds a new descriptive history record rather than creating a second customer identity. The simplified counts remain one customer hub row, one order hub row and one association, while the customer satellite has two history rows.

If the source says the change actually took effect on 8 March, that effective date is different from the 10 March load date. A question about what the warehouse knew on 9 March differs from a question about the customer's retrospectively reported status on 9 March. The model and queries must preserve and interpret the required timelines explicitly.

Illustrative case study

Fictional case: HistoryDock integrates two service systems. Both contain customer number 120, but the numbers were allocated independently and refer to different organizations. An early prototype hashes the number alone and incorrectly merges their records.

The team revisits the business-key definition, incorporates the appropriate identity context and documents how cross-system matching is established. It also adds tests using overlapping identifiers and confirms that downstream marts retain the intended distinctions.

The lesson is that hashing does not discover business identity. HistoryDock is fictional, and the example is not a universal instruction to prefix every key with its source; the correct key design depends on the domain.

Common misconceptions and mistakes

Do not assume a hash key fixes inconsistent business keys. It can transform a chosen representation, but the representation must first identify the intended concept correctly.

Do not equate load timestamps with real-world effective dates. Different historical questions may require both.

Do not assume the raw structure is automatically convenient for every dashboard. Downstream views or marts can simplify access, while the underlying history and source traceability remain available for their purpose.

Business use

Data vault modeling can be useful when sources evolve, historical traceability matters and integration must grow incrementally. It also introduces additional tables, joins, loading conventions and skills requirements.

Evaluate the approach against the organization's actual complexity rather than treating it as a universal replacement for dimensional or other models. Establish key definitions, table grain, history rules and quality checks before automating loads. For AI work, document how training datasets are reconstructed from the vault, including temporal cutoffs and transformations. Historical storage provides evidence only when the extraction logic uses that history correctly.

People also ask

Does a hub hold every attribute of an entity?

No. Its focus is business identity; descriptive context generally belongs in satellites.

Does Data Vault remove the need for data-quality work?

No. Source interpretation, profiling, validation and governance remain necessary.

Can a star schema coexist with a data vault?

Yes. A downstream analytical mart can use a star schema while drawing on integrated vault data.

Check your understanding

Why does the customer's segment change create another satellite record rather than another customer identity in the worked example?

Answer: The customer's business identity remains C17. The change concerns descriptive history, which the satellite records separately.

Related terms

• Hub
• Surrogate key
• Data mart
• Temporal data
• link
• satellite
• business key
• historization
• Raw Vault
• Business Vault
• dimensional modeling
• data lineage

Learn next

Learn about business keys and temporal modeling next. Model two sources with overlapping identifiers, then write separate questions for business-effective time and warehouse-load time. Confirm that the proposed structure can answer both without silently conflating them.

More in Data engineering and architecture

• Data auditing - Data auditing is a systematic examination of data and, where relevant, the processes that handle it against stated criteria.
• Data binding - Data binding is a mechanism that connects data values to another representation so that values can be displayed, transferred or updated according to defined...
• Data blending - Data blending combines information from separate sources for an analysis or view, using agreed links and compatible levels of detail.
• Data-centric computing - Data-centric computing is an approach to computer-system design that treats the location, movement and access patterns of data as central concerns.
• Data-centric programming language - A data-centric programming language emphasizes describing, querying and transforming collections of data.
• Data-centric security - Data-centric security is an approach that organizes protection around the information itself: what it contains, how sensitive it is, who may use it and...

Sources

Giebler and colleagues, Data Vault research paper, structures and practical modeling challenges: https://www.ipvs.uni-stuttgart.de/departments/as/downloadgallery_as/groegech/Giebler2019_DataVault_ER.pdf

Daniel Linstedt, Data Vault 2.0 scope and implementation responsibilities: https://datavaultalliance.com/architecture-data/faq-about-data-vault-2-0/

Datavault Builder, satellite structure and descriptive history: https://datavault-builder.com/data-vault/satellite/

Primary research and practitioner documentation consulted. The customer example and fictional case simplify modeling details and are not a complete implementation specification.

Previous: Data validation according to a list Next: Data verification