De Data Vault: feiten, fabels en waarheid

De kern van de Data Vault bestaat uit een modelleringstechniek voor een datawarehouse. Deze is bedacht door Dan Lindstedt*. De Data Vault slaat alle binnenkomende transacties op in een sterk genormaliseerde structuur. Ongeacht of deze gegevens integer en juist zijn: “100% of the data 100% of the time”. De Data Vault (DV) maakt onderscheid tussen feiten en de waarheid.

Vanuit compliance soms een must

Dit kan handig zijn om geen enkele transactie te verliezen. En is vanuit het oogpunt van compliance en wetgeving soms een must. Op alle velden hou je in de Data Vault consequent historie bij. Een ingenieuze constructie van hub-, link- en satelliettabellen zorgt voor flexibiliteit bij de opslag.

De wijze van modellering: 3NF vs Data Vault

orders van een bedrijf gemodelleerd volgens de 3de normaalvorm (3NF)
Figuur 1: orders van een bedrijf gemodelleerd volgens de 3de normaalvorm (3NF)

orders van een bedrijf gemodelleerd volgens de Data Vault
Figuur 2: orders van een bedrijf gemodelleerd volgens de Data Vault

Transitie van 3NF naar DV

  • Elke mastertabel (referentietabel zoals customer) splits je in een hub- en een satelliettabel. De sleutels komen in de hubtabel. De beschrijvende velden komen in één of meerdere satelliettabellen.
  • Hierdoor ontstaat de volgende flexibiliteit: aan de hub kun je eenvoudige meerdere satelliettabellen koppelen. Vandaar de naam ‘hub’. Zo koppel je makkelijk klantgegevens uit andere systemen of externe bronnen. Hierdoor blijven bestaande tabellen intact.
  • Joins tussen twee mastertabellen geef je vorm met een linktabel. Hierdoor ontstaat flexibiliteit in het type relatie die gegevens met elkaar hebben.
  • Elke transactietabel splits je in een link- en een satelliettabel. De sleutels komen in de linktabel. De transactiedetails komen in de satelliettabel.

Voorbeeld: stel dat orders opeens niet meer alleen door bedrijven maar ook door consumenten kunnen worden geplaatst? Dan volstaan een paar extra tabellen: Person Order Link (Person RK, Order RK), Person Hub (Person RK, ID (BK)) en Person Satellite (Person RK, first name, last name, etc.). Het huidige datamodel van de Data Vault blijft daarbij intact. Dat wil zeggen: het is niet nodig om bestaande tabellen aan te passen.

De feiten van de Data Vault

  • Meer tabellen voor opslag: dataopslag in een Data Vault vergt meer tabellen. Tenminste twee keer zoveel tabellen zijn nodig.
  • Meer joins voor ophalen data: er zijn meer joins nodig om de juiste data te selecteren.
  • Extra component: de Data Vault vormt een extra component in de volwassen DWH-architectuur. Eindgebruikers mogen de Data Vault niet raadplegen. De reden? Die bevat mogelijk onjuiste of incomplete gegevens.
  • Drie modelleringstechnieken tegelijk: in de complete DWH-architectuur komen met de Data Vault drie modelleringstechnieken voor: 3NF, Data Vault en Dimensioneel (sterschema, sneeuwvlok).
  • Flexibiliteit in dataopslag: de Data Vault geeft op een aantal manieren flexibiliteit in dataopslag:
    • Vrijheid in de type relatie die entiteiten met elkaar kunnen hebben
    • Eenvoudig kunnen toevoegen van nieuwe bronnen en entiteiten. En hiervoor hoef je niet de bestaande structuur aan te passen.
    • Ook fout of incomplete gegevens kunnen worden opgeslagen.
  • Gesloten omgeving: voor eindgebruikers is het niet toegestaan om gegevens uit de Data Vault op te vragen. Deze kunnen immers onjuistheden bevatten.

Definitie: volwassen DWH-architectuur

In een volwassen DWH-architectuur worden een aantal functies uitgevoerd:

  • je toetst de datakwaliteit
  • je bouwt historie op
  • je combineert data
  • je dwingt consistentie af tussen gegevens

Voor het laatste denk je aan consistentie tussen aggregaties en de details maar ook over de aggregatietabellen heen.

Data Vault architectuur

Een Data Vault kan worden toegepast als Central Datawarehouse (CDW), maar ook als pre-CDW of Persistant Staging Area (PSA). Pas je de Data Vault als CDW toe dan is er geen sprake van een volwassen DWH-architectuur. Vanuit de Data Vault bouw je immers datamarts op en deze kennen een dimensionele structuur.

Voor de detaildata moet je dan terug naar de Data Vault. Die kent een andere structuur en kent geen of andere transformaties. Bovendien kan die ook nog eens onjuiste data bevatten. Een drilldown op een Data Vault is dus ook gevaarlijk. Een Data Vault kan daarom nooit het CDW vervangen in een volwassen DWH-architectuur. Je wilt één versie van de waarheid en die kan dan niet meer worden afgedwongen. Of je kan dat alleen tegen heel veel meer kosten. Want, de datawarehousebus, die dat afdwingt, is er niet meer.

Voor één specifieke indicator zijn soms wel meerdere aggregatietabellen nodig. Elke datamart kan in theorie daarmee een geheel eigen waarheid creëren. Zo kan een Data Vault gemakkelijk ontaarden in een verzameling losse data-silootjes. Net als in het pré-datawarehousetijdperk.

De belangrijkste voordelen van de Data Vault

  1. Datamodel van de Data Vault staat los van het datamodel van de bronnen. Wijzigingen daarin hebben minder vaak impact op het datamodel van de Data Vault.
  2. Flexibiliteit in gegevensopslag en gemakkelijk uitbreidbaar. Eenvoudig bronnen kunnen toevoegen, zonder dat de huidige tabellen van de Data Vault qua structuur moeten wijzigen. Is die flexibiliteit ook op een andere wijze te realiseren? Een Data Vault is bij uitstek de manier om deze vorm van flexibiliteit te realiseren.
  3. Herlaadbaarheid: gegevens vanuit de Data Vault kun je altijd gebruiken om het CDW/datamarts te herladen, tot ver terug in de tijd. Ook in het geval bronsystemen inmiddels een andere structuur kennen.
  4. Compliance: altijd terug kunnen herleiden van de data, ongeacht structuurwijzigingen in bronsystemen.
  5. Snelheid van laden: wanneer er veel satelliettabellen zijn per hub, dan kun je deze parallel laden. Wanneer de hardware parallelle verwerking ondersteunt, gaat het laden van gegevens veel sneller.

De Data Vault route en de traditionele route van Business Analytics
Figuur 3: De Data Vault route en de traditionele route van Business Analytics

De belangrijkste nadelen van de Data Vault

  1. Meer werk: de Data Vault is complexer om te maken. Daarnaast heb je nu een extra component die je ook moet onderhouden.
  2. Meer transformaties: in de Data Vault normaliseer je entiteiten verder dan de bron. Nadien moet er ‘terug worden gewerkt’ naar een dimensioneel datamodel. Zie de afbeelding hierboven.
  3. Meer kennis nodig: met de Data Vault komt er een 3e modelleringstechniek bij. Medewerkers moeten die technieken stuk voor stuk beheersen.
  4. Geen integriteit: de gegevens zijn in de Data Vault niet integer en niet altijd juist.

Wat gebeurt er na de Data Vault in het laadproces?

Het belangrijkste voordeel van de Data Vault is de flexibiliteit van dataopslag. In een volwassen DWH-architectuur heb je naast een Data Vault ook een CDW en mogelijk ook een of meerdere datamarts / kubussen nodig. Het is natuurlijk prachtig wanneer bij structuurwijzigingen in de bron de Data Vault niet hoeft te worden aangepast. Maar dat geldt niet voor het CDW en de Datamarts, want deze zijn dimensioneel (voorkeur) of 3NF.

Voorbeeld 1

Een klant heeft niet langer slechts één accountmanager maar kan vanaf vandaag meerdere accountmanagers hebben.

datamodel voordat de wijziging in de bron wordt gemaakt (1 accountmanager per klant)
Figuur 4: datamodel voordat de wijziging in de bron wordt gemaakt (1 accountmanager per klant)

datamodel nadat de bron is gewijzigd (meerdere accountmanagers per klant)
Figuur 5: datamodel nadat de bron is gewijzigd (meerdere accountmanagers per klant)

Zoals zichtbaar wordt hierboven is er geen 1:1 relatie meer tussen klant en accountmanager. Daarom koppel je de AccountManager-dimensie rechtstreeks aan de feittabel.

Voorbeeld 2

Het bedrijf levert niet langer alleen aan bedrijven maar ook aan consumenten.

datamodel voordat de wijziging in de bron optreedt (alleen bedrijven)
Figuur 6: datamodel voordat de wijziging in de bron optreedt (alleen bedrijven)

datamodel nadat de bron is gewijzigd (ook consumenten)
Figuur 7: datamodel nadat de bron is gewijzigd (ook consumenten)

De CustomerKey wordt gevuld wanneer er aan een bedrijf is geleverd (ConsumerKey blijft leeg). De ConsumerKey wordt gevuld wanneer er rechtstreeks aan de consument is geleverd (CustomerKey blijft leeg).

Bronwijzigingen leiden altijd tot aanpassing van datamarts

Uit beide voorbeelden blijkt dat ook met een Data Vault het noodzakelijk is om het datamodel van het CDW/datamarts aan te passen wanneer de structuur van de bronnen wijzigt. Wat betekent dit voor de bestaande gegevens in het CDW/datamarts? Het CDW kan dan of compleet opnieuw worden opgebouwd uit de Data Vault (ETL/scriptaanpassingen zijn noodzakelijk). Of er dient een conversie-ETL geschreven te worden die bestaande data uit het CDW converteert naar de nieuwe structuur en inhoud.

Het voordeel van herlaadbaarheid?

Het voordeel van herlaadbaarheid lijkt er dus niet te zijn. Immers in veel, maar niet alle, gevallen kan een conversie volstaan. Daarnaast kan een conversie de feitenrecords markeren van voor de conversie. Zodat je ook (achteraf) vast kan stellen wanneer de wijziging is ingegaan.

Situaties waarin een Data Vault wel meerwaarde heeft

  1. Vanuit het oogpunt van compliance en traceerbaarheid kan een Data Vault meerwaarde bieden. Immers, er vindt een nauwkeurige registratie plaats van het tijdstip dat een data-element uit welk bronsysteem de DWH-omgeving binnenkomt.
  2. Wanneer bronsystemen frequent tot zeer frequent wijzigen, of de organisatie in een zeer dynamische omgeving opereert, kan een Data Vault meerwaarde bieden.
  3. Wanneer er veel verantwoordingsinformatie gegenereerd moet worden met vaste rapportages. Er kan dan worden volstaan met een Business Data Vault (als CDW), zonder datamarts, waarin alleen juiste/correcte gegevens worden geladen. De BI tool haalt die rechtstreeks uit de BDV.

* Meer informatie over Dan Linstedt vind je hier.

 

  1. Beste Daan,

    Aardig stuk, en een prima inleiding op DV voor mensen die er nog niet veel van weten. Hier en daar heb ik nog wel wat aanmerkingen, met name op de opmerking “Pas je de Data Vault als CDW toe dan is er geen sprake van een volwassen DWH-architectuur.”

    Een volwassen architectuur is naar mijn mening iets wat niet wordt bepaald door de vraag of je DV als CDW toepast. Eerder zie ik zaken als “loose coupling”, “resilience to change” en “privacy by design” als belangrijk in een DWH. Iedereen kent inmiddels de onderzoeken die aangeven dat onderhoudskosten 80% van de DWH-kosten uitmaken. Resilience to change, ondersteund door loose coupling, is daarmee zo’n beetje de belangrijkste overweging voor een DWH architect. Eentje die dus door het Data Vault model wordt geadresseerd.

    Verder is een DV wat mij betreft geen component maar een architectuurlaag, met een eigen stel concerns: namelijk een robuuste opslag van temporeel consistente en onveranderlijke gegevens. Dat is vervelend voor clubs die maar wat aanklooien in de bronnen, en waarbij het DWH alle ellende mag oplossen. Dat gaat niet meer. En dan krijg je dus discussie over “de waarheid” versus “de feiten”. Dat is een discussie die een architect meteen bij de business neer moet leggen en niet in het DWH. Het is geen afvoerput.

    Wat betreft “de belangrijkste nadelen van de Data Vault” kan ik deze als volgt adresseren:
    “Meer werk: de Data Vault is complexer om te maken. Daarnaast heb je nu een extra component die je ook moet onderhouden.”
    De “separation of concerns” die we toepassen bij een Data Vault vermindert de hoeveelheid werk per laag en maakt het werk per laag veel eenvoudiger. Weinig zaken zijn lastiger dan een groot dimensioneel model aanpassen waar alles van elkaar afhangt.

    2) Meer transformaties: in de Data Vault normaliseer je entiteiten verder dan de bron. Nadien moet er ‘terug worden gewerkt’ naar een dimensioneel datamodel. Zie de afbeelding hierboven.
    Dat geldt alleen als je een dimensioneel model als belangrijk beschouwt. Persoonlijk beschouw ik het als een query-optimalisatie model en een stukje caching. Bij een sterke database is deze nauwelijks nodig, en vaak als een stel views uit te voeren.

    3) Meer kennis nodig: met de Data Vault komt er een derde modelleringstechniek bij. Medewerkers moeten die technieken stuk voor stuk beheersen.
    Medewerkers moeten leren modelleren, en doorhebben dat een DV, of Anchor model, of Kimball model allemaal variaties op hetzelfde thema zijn. Dat vereist meer kennis. Mensen die dat niet kunnen voegen echter weinig toe aan een DWH team en lopen voornamelijk in de weg. Mijn ervaring is dat ik met 1 iemand, desnoods 2-3 mensen, een DWH kan bouwen. Meer mensen zijn zelden nodig. De plekken waar ik meer mensen zie rondhangen zijn plekken die flink kunnen afbouwen als ze betere mensen aannemen.

    4) Geen integriteit: de gegevens zijn in de Data Vault niet integer en niet altijd juist.
    Ze zijn integer met wat er is vastgelegd. En bij integratie op de hubs (het centrale thema van Data Vault!) zijn ze zeker ook onderling integer. Ze zijn daarmee dus ook juist ten opzichte van de bron. Maar ze zijn niet gemasseerd richting “de waarheid”. Een waarheid die er vaak ook niet is, maar met veel moeite wordt afgedwongen door bepaalde stakeholders. Dat is een politiek probleem, geen technisch issue. Door gebruik van business rule satellieten kan overigens prima een waarheid worden aangewezen. Maar die is dan wel volledig auditeerbaar en achteraf ook repareerbaar. Dat laatste is bij een CDW toch echt lastiger.

    Kortom: ik denk dat een puur dimensioneel model leuk is voor DWH’s waarbij je rapporten bouwt voor één afnemer die “de waarheid” bepaalt, en als je weinig veranderingen tegenkomt en dus weinig bronnen ontsluit. Maar dat is in feite mijn definitie van een datamart. Zodra je een groot dataplatform opzet met veel stakeholders en bronnen, heb je echter een probleem met die methodiek. Data Vault kan een aantal problemen die dan ontstaan goed oplossen.

Reageer ook op dit artikel van Daan van Beek

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Een selectie van onze klanten

Word nu ook klant

Wil je ook klant bij ons worden? Wij helpen je maar wat graag verder met data vault (5 voordelen) of andere zaken waar je slimmer van wordt.

Daan van Beek, Eindbaas Passionned Group

DAAN VAN BEEK MSc

Eindbaas Passionned Group

neem contact met mij op

Fact sheet

Aantal organisaties geholpen
2034
Aantal trainingen & workshops
2035
Aantal deelnemers opgeleid
2036
Gemiddelde klantervaring
8,9
Aantal consultants & docenten
2037
Aantal kantoren
3
Aantal jaren actief
14