Data Vault 2.0

Introductie

Het vorige hoofdstuk sloot af met een belofte: waar het star schema optimaliseert voor query-eenvoud en leessnelheid, kiest Data Vault 2.0 een compleet andere afweging — geoptimaliseerd voor traceerbaarheid, parallel laadbaarheid, en flexibiliteit wanneer bronsystemen wijzigen, ten koste van directe bevraagbaarheid. Data Vault is geen vervanging voor het star schema; het is een aanvullende laag die er meestal voor zit, met het star schema (of een vergelijkbare gedenormaliseerde vorm) er weer bovenop gebouwd als presentatielaag.

Dit is bewust het laatste modelleerhoofdstuk in dit deel van het handbook, en het meest geavanceerd — Data Vault lost een specifiek probleem op dat vooral speelt bij grote, complexe organisaties met meerdere overlappende bronsystemen, strenge auditvereisten, of een historie van dure "big bang"-herontwerpen van hun warehouse. Als je bij een klein of middelgroot team werkt met een handvol bronnen, is een goed opgezet star schema vaak ruim voldoende — begrijpen wanneer je Data Vault niet nodig hebt, is minstens zo waardevol als begrijpen hoe het werkt.

Het Probleem dat Data Vault Oplost

Stel je voor: een grote organisatie heeft een CRM voor sales, een apart ERP voor facturatie, en na een overname een tweede CRM van het overgenomen bedrijf — alle drie met een eigen, net iets andere definitie van "klant". In een traditioneel star schema-ontwerp zou je deze drie bronnen tijdens het laden al moeten samenvoegen tot één dim_customer, wat betekent dat je vooraf moet beslissen hoe conflicten worden opgelost (welke bron "wint" als namen verschillen?) — een beslissing die vaak nog niet definitief te nemen is, en die je bovendien dwingt te wachten tot alle drie de bronnen geladen zijn voordat je de dimensie kunt bouwen.

Data Vault lost dit op door de identiteit van een klant (de business key) volledig te scheiden van de beschrijving van die klant per bronsysteem. Elke bron krijgt zijn eigen, onafhankelijk te laden tabel met beschrijvende data; het samenvoegen tot één klantbeeld gebeurt pas later, in een aparte laag, met alle historie van alle bronnen nog intact en herleidbaar naar waar elk gegeven vandaan kwam. Dat is de kern van waar de rest van dit hoofdstuk om draait.

De Drie Bouwstenen: Hubs, Links, Satellites

Elk Data Vault-model is opgebouwd uit precies drie soorten tabellen, elk met een strikt afgebakende verantwoordelijkheid — vergelijkbaar in geest met de striktheid van fact/dimension tables in het vorige hoofdstuk, maar met een andere verdeling.

Hubs bevatten uitsluitend unieke business keys — geen beschrijvende attributen, geen namen, geen adressen. Een hub_customer bevat simpelweg elke unieke klant-identifier die ooit is gezien, uit welke bron dan ook, samen met een hash key en metadata over wanneer en waar die voor het eerst opdook. Een hub verandert bijna nooit van vorm en groeit alleen door nieuwe rijen toe te voegen — nooit door bestaande rijen te wijzigen.

Links leggen relaties tussen hubs vast — vergelijkbaar met een bridging table voor veel-op-veel-relaties, maar hier het standaardmechanisme voor élke relatie, ook één-op-veel. Een link_customer_order legt vast dat een specifieke klant bij een specifieke order hoort, zonder zelf iets over die klant of order te zeggen.

Satellites bevatten alle beschrijvende, veranderende attributen, gekoppeld aan een hub of link, met volledige historie — functioneel vergelijkbaar met een SCD Type 2-dimensie uit het vorige hoofdstuk, maar hier de standaardvorm voor élk attribuut, niet een uitzonderingsgeval. Cruciaal: elke bron krijgt zijn eigen satellite op dezelfde hub. sat_customer_crm_sales en sat_customer_crm_acquired kunnen beide aan hub_customer hangen, elk met hun eigen attributen, hun eigen laadschema, en zonder dat het laden van de ene satellite ooit hoeft te wachten op de andere.

Waarom Deze Scheiding? Load-onafhankelijkheid

Dit is de architectonische kern van Data Vault, en het antwoord op de vraag "waarom niet gewoon een dimensie": elke tabel in een Data Vault-model kan volledig onafhankelijk en parallel geladen worden, zonder te wachten op enige andere tabel.

Dit werkt omdat hubs, links en satellites gebruikmaken van hash keys in plaats van sequentiële surrogate keys. Een sequentiële surrogate key (zoals in het star schema-hoofdstuk) vereist een centrale sequence-generator — je kunt niet twee laadprocessen tegelijk nieuwe surrogate keys laten uitgeven zonder coördinatie. Een hash key wordt berekend uit de business key zelf (bijvoorbeeld MD5(customer_id)), volledig deterministisch en zonder enige centrale coördinatie nodig:

-- Hash key: deterministisch, geen sequence-generator nodig,
-- dus veilig parallel te berekenen door elk laadproces afzonderlijk
SELECT MD5(UPPER(TRIM(customer_id))) AS customer_hash_key
FROM staging.customers;

Omdat elk laadproces onafhankelijk dezelfde hash key berekent voor dezelfde business key, kunnen de CRM-sales-load, de ERP-load en de overgenomen-CRM-load tegelijkertijd draaien, elk zijn eigen hub-rijen en satellite-rijen wegschrijven, zonder ooit op elkaar te hoeven wachten of elkaars data te overschrijven. Dit is precies het probleem dat in het traditionele star schema-ontwerp een probleem was: je hoeft niet meer te wachten tot alle bronnen binnen zijn voordat je kunt beginnen met laden.

Concreet Voorbeeld: Hub, Link en Satellite voor Customer & Order

-- HUB: alleen de business key, nooit gewijzigd na invoegen
CREATE TABLE hub_customer (
    customer_hash_key   CHAR(32) PRIMARY KEY,   -- MD5 van de business key
    customer_id         VARCHAR(20),             -- de business key zelf
    load_date            TIMESTAMP,
    record_source         VARCHAR(50)              -- welk bronsysteem leverde dit aan
);

CREATE TABLE hub_order (
    order_hash_key       CHAR(32) PRIMARY KEY,
    order_id             VARCHAR(20),
    load_date            TIMESTAMP,
    record_source         VARCHAR(50)
);

-- LINK: legt de relatie vast, zonder zelf attributen te bevatten
CREATE TABLE link_customer_order (
    link_hash_key         CHAR(32) PRIMARY KEY,   -- MD5 van beide hash keys samen
    customer_hash_key    CHAR(32) REFERENCES hub_customer(customer_hash_key),
    order_hash_key       CHAR(32) REFERENCES hub_order(order_hash_key),
    load_date            TIMESTAMP,
    record_source         VARCHAR(50)
);

-- SATELLITE: beschrijvende data MET historie, per bronsysteem apart
CREATE TABLE sat_customer_crm_sales (
    customer_hash_key    CHAR(32) REFERENCES hub_customer(customer_hash_key),
    load_date            TIMESTAMP,
    customer_name         VARCHAR(100),
    segment               VARCHAR(50),
    hash_diff             CHAR(32),                -- MD5 van alle attributen samen
    record_source         VARCHAR(50),
    PRIMARY KEY (customer_hash_key, load_date)
);

De hash_diff-kolom verdient uitleg: het is een MD5-hash van alle beschrijvende attributen in de satellite samen. Bij elke nieuwe load bereken je de hash-diff van de binnenkomende rij en vergelijk je die met de laatst bekende hash-diff voor die business key — zijn ze gelijk, dan is er niets veranderd en sla je een nieuwe rij simpelweg over; verschillen ze, dan voeg je een nieuwe satellite-rij toe met een nieuwe load_date. Dit is het Data Vault-equivalent van SCD Type 2, maar dan zonder MERGE-statements of UPDATE-logica — puur INSERT, wat het laadproces aanzienlijk eenvoudiger en veiliger maakt om parallel uit te voeren.

-- Nieuwe satellite-rij alleen invoegen als de hash-diff daadwerkelijk verschilt
INSERT INTO sat_customer_crm_sales (customer_hash_key, load_date, customer_name, segment, hash_diff, record_source)
SELECT
    s.customer_hash_key,
    CURRENT_TIMESTAMP(),
    s.customer_name,
    s.segment,
    MD5(CONCAT(s.customer_name, '|', s.segment)) AS hash_diff,
    'crm_sales'
FROM staging.customer_updates s
LEFT JOIN (
    SELECT customer_hash_key, hash_diff
    FROM sat_customer_crm_sales
    QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_hash_key ORDER BY load_date DESC) = 1
) latest ON latest.customer_hash_key = s.customer_hash_key
WHERE latest.hash_diff IS NULL
   OR latest.hash_diff <> MD5(CONCAT(s.customer_name, '|', s.segment));

Insert-Only: Waarom Dit Betrouwbaarheid Oplevert

Merk op dat geen van de bovenstaande statements een UPDATE of DELETE bevat — Data Vault-tabellen zijn in de kern insert-only. Dit heeft een directe consequentie die veel waard is in enterprise-omgevingen: elke rij die ooit is geladen, blijft voor altijd bestaan, precies zoals hij binnenkwam, met record_source en load_date die exact vastleggen waar en wanneer. Voor auditdoeleinden ("toon aan dat dit cijfer op 3 maart correct was volgens de data die we toen hadden") is dit vaak niet optioneel maar een compliance-vereiste — en het is precies waarom Data Vault populair is in de financiële sector en andere zwaar gereguleerde omgevingen.

Data Vault versus Star Schema versus 3NF

Business Vault en de Information Mart-laag

Een cruciaal punt dat vaak wordt gemist: een Data Vault-model is niet bedoeld om rechtstreeks door analisten of BI-tools bevraagd te worden. De drie-tabellen-per-relatie-structuur, met attributen verspreid over meerdere satellites per bron, maakt zelfs simpele vragen omslachtig om direct te schrijven. Data Vault is een integratie- en opslaglaag — de "raw vault" — waar bovenop je een business vault (afgeleide, business-logica-verrijkte structuren, nog steeds in Data Vault-stijl) en uiteindelijk een information mart-laag bouwt, die er in de praktijk vaak precies uitziet als het star schema uit het vorige hoofdstuk.

Met andere woorden: Data Vault en dimensioneel modelleren zijn in de praktijk vaak geen alternatieven voor elkaar, maar complementair — Data Vault als robuuste, parallel-laadbare, volledig traceerbare basislaag, en een star schema als presentatielaag erbovenop, specifiek gebouwd voor de rapportagebehoeften die op dat moment relevant zijn. Dit sluit direct aan op de bronze/silver/gold-indeling uit Medallion Architecture: een raw vault past goed in de rol van een uitgebreide silver-laag, met information marts als gold.

Point-in-Time (PIT) en Bridge-tabellen zijn de gebruikelijke hulpmiddel om de overgang van raw vault naar information mart behapbaar te maken. Een hub met vijf satellites uit vijf verschillende bronnen vereist normaliter vijf aparte joins, elk met zijn eigen "wat was de laatst geldige rij op tijdstip X"-logica — omslachtig en foutgevoelig om telkens opnieuw te schrijven. Een PIT-tabel berekent dit één keer vooraf: voor elke combinatie van business key en relevant tijdstip legt hij vast welke load_date in elke satellite op dat moment de meest recente was, zodat de information mart-laag daarna simpele, voorspelbare joins tegen de PIT-tabel kan doen in plaats van tegen elke satellite los. Een bridge-tabel doet hetzelfde voor links: het lost meerdere-hops-relaties (klant → link → order → link → factuur) vooraf op tot directe, plat te bevragen paden.

Best Practices

• Gebruik Data Vault alleen als het probleem het rechtvaardigt — meerdere overlappende bronsystemen, strenge auditvereisten, of een organisatie die regelmatig bronsystemen ziet komen en gaan. Voor een enkel bronsysteem is de overhead zelden de moeite waard.
• Bouw altijd een presentatielaag erbovenop. Verwacht niet dat analisten rechtstreeks tegen hubs, links en satellites queryen — een business vault of information mart is geen optioneel extraatje, het is waar Data Vault pas bruikbaar wordt.
• Eén satellite per bron per hub, nooit attributen van meerdere bronnen in één satellite mengen — dat is precies de load-onafhankelijkheid die Data Vault zijn kracht geeft.
• Bereken hash keys consistent (dezelfde normalisatie — hoofdletters, trimmen van spaties — in elk laadproces), anders berekent hetzelfde business key-record in twee verschillende bronnen per ongeluk twee verschillende hash keys.
• Behandel hubs, links en satellites als insert-only. Zodra je een UPDATE op een van deze tabellen overweegt, is dat een signaal dat je het patroon verkeerd toepast.

Veelgemaakte Fouten

• Data Vault toepassen bij een klein team met één of twee bronnen — de overhead van drie tabellen per relatie levert dan geen enkel voordeel op ten opzichte van een direct star schema, en kost aanzienlijk meer ontwikkeltijd.
• Attributen van meerdere bronnen in één satellite mengen, waardoor je alsnog moet wachten tot alle bronnen binnen zijn voordat je kunt laden — precies het probleem dat Data Vault had moeten oplossen.
• Vergeten een business vault/information mart-laag te bouwen, waardoor analisten worden losgelaten op de ruwe hub/link/satellite-structuur en compleet vastlopen op de complexiteit.
• Hash keys inconsistent berekenen tussen laadprocessen (bijvoorbeeld wel of niet trimmen van whitespace), waardoor dezelfde entiteit meerdere hub-rijen krijgt.
• Sequentiële surrogate keys gebruiken in plaats van hash keys "omdat het vertrouwder aanvoelt" — dit ondermijnt direct de parallel-laadbaarheid die de hele reden is om voor Data Vault te kiezen.

Performance Tips

• Indexeer hash keys consequent op elke hub, link en satellite — dit zijn de kolommen waarop vrijwel elke join in het model draait.
• Gebruik de hash-diff-vergelijking om onnodige satellite-rijen te vermijden. Zonder deze check groeit een satellite met elke load, ook als er niets veranderd is, wat de information mart-laag onnodig traag maakt om op te bouwen.
• Beperk het aantal satellites per hub tot wat praktisch nodig is — te veel granulaire satellites (één per los attribuut) maakt het samenvoegen in de presentatielaag onnodig complex zonder een navenant voordeel.
• Bouw information marts als aparte, materialiseerde tabellen, niet als views direct over de raw vault heen — anders betaal je bij elke dashboardquery opnieuw de kosten van het samenvoegen van meerdere satellites.

Interviewvragen

"Wat zijn de drie bouwstenen van Data Vault, en wat is de verantwoordelijkheid van elk?" Let op: hubs (unieke business keys), links (relaties tussen hubs), satellites (beschrijvende, historische attributen) — en het besef dat elk een strikt afgebakende, niet-overlappende rol heeft.

"Waarom gebruikt Data Vault hash keys in plaats van sequentiële surrogate keys?" Let op: hash keys zijn deterministisch en vereisen geen centrale sequence-generator, waardoor meerdere laadprocessen volledig parallel en onafhankelijk kunnen draaien.

"Wanneer zou je Data Vault kiezen boven een star schema, en wanneer juist niet?" Let op: Data Vault bij meerdere overlappende bronsystemen, strenge auditvereisten, of frequent wisselende bronnen; een star schema (of zelfs direct 3NF) bij een enkel of klein aantal bronnen waar de extra complexiteit geen voordeel oplevert.

"Wat is een hash-diff, en waar wordt die voor gebruikt?" Let op: een hash van alle attributen in een satellite-rij samen, gebruikt om te detecteren of een nieuwe rij daadwerkelijk gewijzigde data bevat vóórdat je een nieuwe satellite-rij toevoegt — voorkomt onnodige rijgroei.

"Waarom is een Data Vault-model niet geschikt om direct door BI-tools bevraagd te worden?" Let op: het besef dat attributen verspreid zijn over meerdere satellites per hub, wat zelfs simpele queries omslachtig maakt, en dat een business vault/information mart-laag daarom altijd nodig is.

"Hoe verhoudt Data Vault zich tot medallion architecture (bronze/silver/gold)?" Let op: een raw vault functioneert vaak als een uitgebreide, sterk gestructureerde silver-laag, met information marts (vaak star schemas) als gold — complementair, niet concurrerend.

Relevante Documentatie

• dbt Labs: Data Vault Modeling — hoe Data Vault-patronen zich vertalen naar dbt-projecten.
• Snowflake: Data Vault Architecture — platformspecifieke overwegingen voor hash keys en insert-only laadpatronen.
• Databricks: Building a Data Vault on the Lakehouse — hoe Delta Lake's ACID-garanties Data Vault-laadpatronen ondersteunen.

Samenvatting

Data Vault 2.0 lost een specifiek, herkenbaar probleem op: hoe integreer je data uit meerdere, mogelijk conflicterende bronsystemen, volledig traceerbaar en parallel laadbaar, zonder vooraf te hoeven beslissen hoe conflicten worden opgelost? De drie bouwstenen — hubs voor identiteit, links voor relaties, satellites voor beschrijvende historie — scheiden precies wat zelden verandert (business keys) van wat vaak verandert (attributen), elk per bron apart, gekoppeld via deterministische hash keys die elke centrale coördinatie tussen laadprocessen overbodig maken. De prijs voor deze flexibiliteit is bevraagbaarheid: een raw Data Vault is niet bedoeld voor directe rapportage, en vereist altijd een business vault of information mart-laag erbovenop — vaak weer een star schema, wat laat zien dat de modelleeraanpakken uit dit en het vorige hoofdstuk elkaar aanvullen in plaats van uitsluiten. Met deze fundamenten (data modeling, star schema, Data Vault) op zak is het tijd om te kijken naar hoe data daadwerkelijk van bron naar deze modellen beweegt — het onderwerp van het volgende hoofdstuk, ETL vs ELT.