Data Vault Cheat Sheet

Updated 2026-04-21

Next Topic: Data Warehousing Cheat Sheet

🧠Study flashcards on this topic113 cards · spaced repetition→

Data Vault is a data modeling methodology designed for building scalable, flexible, and auditable enterprise data warehouses. Created by Dan Linstedt in the 1990s and formalized as Data Vault 2.0 in 2013, the methodology separates business keys, relationships, and descriptive attributes into distinct table types—Hubs, Links, and Satellites—enabling parallel loading, incremental development, and minimal impact from source system changes. Data Vault 2.1 extends the methodology with enhanced support for semi-structured data, ontologies and taxonomies, and alignment with modern architectures like Data Mesh and Data Lakehouse. Unlike traditional dimensional modeling, Data Vault prioritizes adaptability, compliance, and auditability, making it ideal for environments requiring strict lineage tracking, regulatory compliance, and continuous integration of new data sources.

What This Cheat Sheet Covers

This topic spans 18 focused tables and 128 indexed concepts, 113 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Entity TypesTable 2: Specialized Link TypesTable 3: Satellite VariationsTable 4: Business Vault StructuresTable 5: Hash Key PatternsTable 6: Metadata and Audit ColumnsTable 7: Loading PatternsTable 8: Architecture LayersTable 9: Naming ConventionsTable 10: Data Vault vs. Other ApproachesTable 11: Benefits and Use CasesTable 12: Performance OptimizationTable 13: Common ChallengesTable 14: Implementation ToolsTable 15: Best PracticesTable 16: Advanced PatternsTable 17: Testing and ValidationTable 18: Cloud Platform Considerations

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Entity Types

The whole methodology rests on three building blocks—Hubs hold business keys, Links capture the relationships between them, and Satellites carry the descriptive detail and its history. Keeping these concerns in separate tables is what gives Data Vault its parallel loading and resilience to source changes. The Link Satellite and Reference Hub here are natural extensions of that same idea.

Entity	Example	Description
Hub	`HUB_CUSTOMER` `customer_hk (PK)` `customer_id (BK)` `load_date` `record_source`	• Stores unique business keys for core business concepts (e.g., Customer, Product, Order) • contains no descriptive attributes, only identifiers and metadata.
Link	`LINK_ORDER_CUSTOMER` `order_customer_hk (PK)` `customer_hk (FK)` `order_hk (FK)` `load_date` `record_source`	• Captures relationships between Hubs • represents associations or transactions (many-to-many by default) • hash key derived from related Hub business keys.
Satellite	`SAT_CUSTOMER_DETAILS` `customer_hk (FK)` `load_date (PK)` `first_name` `last_name` `email` `hashdiff`	• Stores descriptive attributes and full history for Hubs or Links • every change creates a new record • includes load timestamp and hashdiff for change detection.
Link Satellite	`LSAT_ORDER_CUSTOMER` `order_customer_hk (FK)` `load_date (PK)` `order_total` `order_status` `hashdiff`	• Satellite attached to a Link rather than a Hub • tracks context attributes of the relationship (e.g., order total, discount percentage applied to a customer-order association).
Reference Hub	`REF_HUB_COUNTRY` `country_hk (PK)` `country_code (BK)` `load_date` `record_source`	• Lightweight Hub for reference or lookup data (e.g., country codes, currencies) • follows Hub pattern but typically has fewer satellites and lower audit requirements than core Hubs.

Table 2: Specialized Link Types

A plain Link models a many-to-many relationship, but real data has stranger shapes—self-referencing hierarchies, event streams that never change, duplicate identities that need merging, and derived associations that exist only in the Business Vault. These variants tailor the basic Link to each of those situations.

Type	Example	Description
Non-Historized Link	`NHL_TRANSACTION` `transaction_hk (PK)` `customer_hk (FK)` `product_hk (FK)` `transaction_date` `load_date`	• Records event-based relationships without time-slice history • optimized for insert-only use cases where each occurrence is unique and immutable.

The rest of this section is part of the full cheat sheet

Table 3: Satellite Variations

Satellites are where most of the design choices actually live, because they decide how change and time are recorded. The variations here differ mainly in how they treat history—some keep every version, some hold only the current state, some track validity windows, and others record whether a key was even present in the source. Picking the right one per attribute group is one of the highest-leverage decisions in a vault.

Type	Example	Description
Standard Satellite	`SAT_CUSTOMER_PROFILE` `customer_hk (FK)` `load_date (PK)` `first_name` `address` `phone` `hashdiff`	• Tracks descriptive attributes that change together • new record inserted only when hashdiff changes • most common satellite pattern.

The rest of this section is part of the full cheat sheet

Table 4: Business Vault Structures

The Raw Vault is faithful but slow to query, so the Business Vault adds structures that pre-compute the hard parts. PIT and Bridge tables flatten expensive time-based joins ahead of time, while Computed Links and Reference Tables hold derived relationships and lookup values that don't belong in the immutable record of source data.

Structure	Example	Description
Point-In-Time (PIT) Table	`PIT_CUSTOMER` `customer_hk (FK)` `snapshot_date (PK)` `sat_profile_ldts` `sat_address_ldts` `sat_phone_ldts`	• Pre-joins multiple satellites around a Hub • stores snapshot timestamps for each satellite • dramatically improves query performance by avoiding complex time-based joins.

The rest of this section is part of the full cheat sheet

Table 1: Core Entity Types

Entity	Example	Description
Hub	`HUB_CUSTOMER` `customer_hk (PK)` `customer_id (BK)` `load_date` `record_source`	• Stores unique business keys for core business concepts (e.g., Customer, Product, Order) • contains no descriptive attributes, only identifiers and metadata.
Link	`LINK_ORDER_CUSTOMER` `order_customer_hk (PK)` `customer_hk (FK)` `order_hk (FK)` `load_date` `record_source`	• Captures relationships between Hubs • represents associations or transactions (many-to-many by default) • hash key derived from related Hub business keys.
Satellite	`SAT_CUSTOMER_DETAILS` `customer_hk (FK)` `load_date (PK)` `first_name` `last_name` `email` `hashdiff`	• Stores descriptive attributes and full history for Hubs or Links • every change creates a new record • includes load timestamp and hashdiff for change detection.
Link Satellite	`LSAT_ORDER_CUSTOMER` `order_customer_hk (FK)` `load_date (PK)` `order_total` `order_status` `hashdiff`	• Satellite attached to a Link rather than a Hub • tracks context attributes of the relationship (e.g., order total, discount percentage applied to a customer-order association).
Reference Hub	`REF_HUB_COUNTRY` `country_hk (PK)` `country_code (BK)` `load_date` `record_source`	• Lightweight Hub for reference or lookup data (e.g., country codes, currencies) • follows Hub pattern but typically has fewer satellites and lower audit requirements than core Hubs.

Table 2: Specialized Link Types

Type	Example	Description
Non-Historized Link	`NHL_TRANSACTION` `transaction_hk (PK)` `customer_hk (FK)` `product_hk (FK)` `transaction_date` `load_date`	• Records event-based relationships without time-slice history • optimized for insert-only use cases where each occurrence is unique and immutable.

Table 3: Satellite Variations

Type	Example	Description
Standard Satellite	`SAT_CUSTOMER_PROFILE` `customer_hk (FK)` `load_date (PK)` `first_name` `address` `phone` `hashdiff`	• Tracks descriptive attributes that change together • new record inserted only when hashdiff changes • most common satellite pattern.

Table 4: Business Vault Structures

Structure	Example	Description
Point-In-Time (PIT) Table	`PIT_CUSTOMER` `customer_hk (FK)` `snapshot_date (PK)` `sat_profile_ldts` `sat_address_ldts` `sat_phone_ldts`	• Pre-joins multiple satellites around a Hub • stores snapshot timestamps for each satellite • dramatically improves query performance by avoiding complex time-based joins.