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.
Answers before you ask.
Hubs, which hold distinct business keys; links, which capture relationships between those keys; and satellites, which hold the descriptive, historised attributes. Separating keys, relationships, and attributes into distinct tables is the defining structure of Data Vault, giving it a very different shape from a Kimball star schema.
Strong auditability, full historical tracking, and scalability for complex, multi-source environments. Its structure records where and when data arrived and preserves history by design, and it accommodates new sources by adding hubs, links, and satellites without reworking existing structures. These qualities suit enterprise raw-integration layers more than direct BI consumption.
They often coexist: Data Vault serves as the auditable, integrated raw-data layer, and dimensional star schemas are derived from it downstream for BI consumption. Data Vault is not usually queried directly by BI tools; it feeds the marts that are. The two are complementary layers, not competing choices, in many enterprise architectures.
For complex, multi-source enterprise warehouses where auditability, historisation, and adaptability to changing sources are priorities — common in large, regulated GCC organisations. Its added structural complexity is justified where those needs are real. For simpler environments, a dimensional approach alone may suffice; Data Vault is a deliberate choice for enterprise integration complexity.