“The Data Vault Model is a detail oriented, historical tracking and uniquely linked set of normalized tables that support one or more functional areas of business.”Dan Linstedt · Data Vault Series 1 — Data Vault Overview · 2002 · Dan Linstedt, Data Vault Series 1 — Data Vault Overview (2002), definiția modelului
Hub, link, satellite: keys, relations, attributes with history — three kinds of tables, one auditable warehouse.
The star schema is fast to read and easy to understand, but rigid: a new source or a new column means rewriting the dimension. The snowflake normalises the dimensions — fewer duplicates, more joins — and is usually not worth it. Data Vault answers a different problem: how to integrate twenty sources that change often, without rewriting anything and with a full audit trail. Three kinds of tables: hubs (business keys — a customer, a product), links (relations between keys — the customer bought the product) and satellites (descriptive attributes, with load date and source, hence full history). The cost is that a vault is not read directly: it has too many tables. The typical architecture is staging, then vault (raw and business), then star-shaped marts on top for reporting. The choice is not ideological. Few, stable sources: star directly. Many, changing sources with audit requirements: vault underneath, star on top.
This passage looks at what happens when sources don't just change, but contradict each other. Two systems can describe the same customer with differently spelled names. In Data Vault, the hub keeps a single key for the customer, while satellites keep both versions, each with its source. Nothing gets deleted to resolve the conflict. Truth becomes a choice made late, at reporting time, not early, at load time. Think of two bills from the same address with differently spelled names: you keep both and decide later which one is right. That moves the decision to where context exists. But how do keys actually get tied together across sources, when none of them is the source of truth? That opens the next step.
This passage answers the earlier question: who links the keys when no system is the source of truth. The answer is that nobody owns them. The hub is a neutral anchor: it recognizes a customer regardless of which system sent it. The link records the relationship each time a source asserts it, along with that source. So the connection is not one system's opinion, but a collection of claims. Think of a contact list where you note that Ana knows Ion because three friends told you, each with their name beside it. No source dictates, but all leave a trace. This keeps the keys stable even when systems change. But if keys are stable, the attributes around them are not. How do those change without losing history? That is the next step.
Why it matters A warehouse that gets rewritten for every new source never reaches the tenth source. The choice of model decides how cheap change is.