Data Vault is a data warehouse modelling methodology developed by Dan Linstedt that structures the data warehouse into three distinct table types: Hubs (containing business keys — the natural identifiers used by the business, such as account codes, entity identifiers, and vendor numbers), Links (containing the relationships between hubs — connecting a GL journal to its account, entity, and period without storing any attributes), and Satellites (containing the descriptive attributes of hub or link records, with full change history through timestamp-based historisation). Data Vault’s separation of keys, relationships, and attributes enables the data warehouse to record every version of every record as it changes over time — providing a complete audit trail of how data looked at any point in history — and to add new source systems or new attributes to the warehouse without restructuring existing tables, because each source system loads its data into satellite tables associated with the existing hubs and links.
Data Vault Table Types
| Table Type | Contents | Finance Example |
|---|---|---|
| Hub | Business key + load date + record source; no descriptive attributes | HUB_ACCOUNT: AccountCode, LoadDate, RecordSource (EBS, FCCS, Manual) |
| Link | Foreign keys to multiple hubs + load date + record source; represents a business relationship | LINK_GL_POSTING: AccountHashKey, EntityHashKey, PeriodHashKey, LoadDate |
| Satellite | Hash key to parent hub/link + descriptive attributes + load date + end date for historisation | SAT_ACCOUNT_EBS: AccountHashKey, AccountName, AccountCategory, ValidFrom, ValidTo, RecordSource |
Data Vault vs Kimball Star Schema
Data Vault and Kimball (star schema) are not competing alternatives for all use cases — they are appropriate for different layers of the data warehouse architecture. Data Vault is well-suited to the raw vault layer — where data from multiple heterogeneous source systems (Oracle EBS, SAP, external bank feeds, ZATCA API data) is loaded without transformation, with full historical tracking and source system attribution. Kimball star schema is well-suited to the business vault / information mart layer — where cleansed, conformed, and business-ready dimensional models are presented for BI tool consumption. Many enterprise data warehouse architectures combine both: Data Vault at the raw and integration layer (for auditability and multi-source resilience), Kimball dimensional models at the presentation layer (for Power BI and Oracle Analytics Cloud query performance).
Data Vault for GCC Regulatory Compliance
Data Vault’s complete historical tracking makes it particularly valuable for GCC enterprises with regulatory data retention requirements. ZATCA’s ten-year e-invoice retention requirement, Egypt’s ETA data retention mandate, and SAMA’s financial records retention policy all require that historical financial data be preserved with evidence of when it was loaded and from which source. Data Vault’s satellite tables, with their load date and end date columns, provide a technically complete answer to the question “what did this account’s balance show on this specific date, as loaded from this specific source system?” — an audit-grade historical view that a current-state data warehouse (which overwrites prior values on each refresh) cannot provide.
What Goes Wrong in Practice
The most common Data Vault implementation failure is building a Data Vault architecture for an environment that does not require its complexity — a single-source, stable environment where full historical tracking and multi-source reconciliation are not business requirements. Data Vault’s development and maintenance overhead (more tables, more complex loading patterns, more joins in the presentation layer) is justified by the auditability and scalability benefits in complex multi-source environments, but adds cost and latency in simple environments where a direct Kimball dimensional model would provide the same analytical capability with lower overhead. The Data Vault vs Kimball decision should be driven by the source system complexity and the regulatory requirements, not by architectural preference.
How Loop Wise Solutions Applies Data Vault
We apply Data Vault methodology in GCC enterprise data warehouse engagements where: the data warehouse must integrate more than three heterogeneous source systems, regulatory retention requirements mandate full historical tracking at the source-record level, or the data warehouse scope is expected to grow significantly over time through new source system additions. For simpler environments, we implement Kimball dimensional models that provide equivalent BI capability with lower implementation and maintenance cost.
