# Data Vault

Data Vault is een datamodelleringsmethode die voornamelijk in gebruik is bij datawarehousing. Het is bedacht door Dan Linstedt en is speciaal bedoeld voor het opslaan van gegevens uit verschillende bronnen, met verschillende definities en betrouwbaarheid.
Bij het ontwerpen van een datawarehouse wordt gewoonlijk uitgegaan van het bedrijfsmodel. Om alle data erin te krijgen wordt een set definities opgesteld waar de data aan moet voldoen. Alles wat niet aan deze definities voldoet wordt ofwel aangepast ofwel uit het datawarehouse geweerd. Daarnaast gaat men uit van één versie van de waarheid. Er worden dus keuzes gemaakt m.b.t. de betrouwbaarheid van de data. Dit wordt een probleem wanneer het bedrijf of de processen binnen het bedrijf veranderen.
Bij een database volgens Data Vault werkt men andersom. Men gaat uit van de bronnen. In principe wordt elk feit opgeslagen maar wel met een aantal extra parameters. Zo wordt altijd bijgehouden waar de betreffende data vandaan komt en wanneer deze is vastgelegd. Het is makkelijk om met filtering eerdere versies van de database in te zien waardoor het bruikbaar is voor Basel II en Sarbanes-Oxley. Ook leent het zich als operational data store en is het geschikt voor parallelle laadprocessen waardoor men deze flexibeler kan plannen.

## Uitgangspunten

* Alle data van alle bronnen worden ingeladen in het datawarehouse. Er vindt geen filtering op fouten plaats. Dit betekent dat de verantwoordelijkheid voor datakwaliteit bij de bronnen wordt neergelegd.
* Toepassing van business rules, het hanteren van definities en schoning van de data wordt bij de datamarts ingebouwd.
* Er worden alleen data toegevoegd in het datawarehouse. Er vinden geen deletes of updates plaats. Uitzondering is de update van de geldigheid (invullen van de einddatum) in een Satelliet-tabel. Hierdoor is het laadproces het meest efficiënt.

## Modelleren

In een Data Vault-model worden de volgende tabellen onderscheiden.

### HUB

    De HUB-tabellen bevatten de business keys waarvan verwacht wordt dat deze niet veranderen. Bijvoorbeeld klantnummers, productnummers enz. Alles met dezelfde business key (dus ook uit verschillende bronnen) komt in dezelfde HUB terecht. Gegevens worden niet gemerged. De geldigheid van een regel in een HUB heeft alleen een begindatum en geen einddatum.

### SAT (Satelliet)

    Deze bevat de attributen die wel aan verandering onderhevig zijn. Bijvoorbeeld de naam of het adres van een klant. In de Satellieten wordt historietype 2 gehanteerd. Wanneer de verwachting is dat het ene attribuut vaker verandert dan het andere kan besloten worden om twee aparte satellieten aan een hub te hangen. Ook data uit verschillende bronnen kunnen in één satelliet terechtkomen, maar vaak wordt gekozen voor aparte satellieten voor elke bron.

### Link

    Met de linktabellen worden de relatie tussen de verschillende HUBs gelegd. De links bevatten feiten zoals orders, transacties en processen. Voor het linken wordt gebruikgemaakt van surrogaatsleutels. Ook een linktabel kan weer zijn eigen satellieten hebben.

### Reference-table

    Hierin wordt informatie opgeslagen die geen rechtstreekse relatie met de Hubs, Satellieten of linktabellen heeft.
Bij een Data Vault-model worden de entiteiten uit de bronnen ingeladen in HUB- en satelliettabellen. Als de bedrijfsprocessen veranderen maar de bronnen hetzelfde blijven, blijven deze tabellen in dezelfde vorm bestaan. De bedrijfsprocessen worden hieromheen gemodelleerd door middel van Link-tabellen. Als het bedrijfsproces verandert of er komt een proces bij, dan worden er extra links aangemaakt. Komt er een bron(tabel) bij dan wordt de data in een bestaande of nieuwe HUB geladen. Wordt de bron(tabel) uitgebreid dan komt er een nieuwe Satelliet bij. Hierdoor is Data Vault min of meer resistent tegen veranderingen in het bedrijf.
* Artikel van Dan Linstedt op Tdan.com, gepubliceerd op 1 juli 2002