Rethinking the Integration Layer: Beyond Hubs, Links, and Satellites
For years, data architects have debated how to structure the integration layer of a data platform.
Two common patterns dominate:
- Wide historized tables — easy to query, but they suffer from version explosion. A single attribute change (say, a phone number update) forces a new version of the entire row.
- Data Vault (DV) — hubs, links, satellites. DV solves versioning and late binding elegantly, but its grammar is abstract. Try explaining “link–satellite split” to a business user — they glaze over fast.
So we asked: what if we could keep the decomposition benefits of Data Vault, but align the physical model directly with the business logical data model (LDM)?
The Core Idea: A Business-Shaped 3NF
Instead of hubs/links/satellites, we implement the entity types from the business LDM in 3NF:
- Core entities → stable business objects (Party, Product, Order).
- Associative entities → relationships that deserve their own table (OrderLine, CustomerAddress).
- Characteristic entities → attribute sets with distinct change cadences (ContactDetail, ProductPrice).
- Reference entities → code lists and domains (Country, Currency).
This makes the integration layer business-readable. The tables carry the same semantics as the logical model.
Why Split into Characteristics?
Because change happens unevenly.
If every attribute of PARTY sits in one giant historized table, then a change in a single field — like marital status — triggers a new version of the entire row. Multiply that by hundreds of attributes, and you have version explosion.
By placing volatile attributes in Characteristic entities:
- You historize only the small sets of columns that actually change.
- Versioning becomes cheaper, tables stay lean, and lineage remains clear.
Example:
party_core (stable identifiers)
party_name_characteristic (dual SCD2 historized)
party_gender_characteristic (dual SCD2 historized)
Only the affected Characteristic versions when an attribute changes.
A Different Kind of Decomposition
This approach:
- Keeps the discipline of decomposition (like DV).
- Preserves business semantics (like 3NF).
- Minimizes unnecessary duplication.
In other words: decomposed inside, composed at the edges.
What’s Next
In the next article, we’ll look at two essential patterns for making this work in practice:
- Supertypes & subtypes → how we implement PARTY with PERSON and ORGANIZATION.
- Source subtypes → how we unify multiple systems (Salesforce, SAP, CRM) without duplicating raw data.