In vorige posts gaf ik al aan dat ik een liefhebber ben van de Data Vault methodiek voor data modellering van het data warehouse. Waarom dit zo is zal ik hieronder uitleggen. Het gaat te ver om de Data Vault methode in deze post uit helemaal uit te leggen, dit is al gedaan in dit artikel, geschreven door godfather Dan Linstedt. In deze post volsta ik met een beknopte schets van de drie bouwstenen van Data Vault.

Bouwstenen van Data Vault

Hub tabellen

Een Hub record representeert het bestaan van een entiteit vanaf een bepaald moment. Hub records zijn uniek identificeerbaar met hun business key.Bijvoorbeeld:

Klant met klantnummer K1234567 is sinds 12-02-2009 bekend in het data warehouse.

De business key is hier: K1234567

Link tabellen

Een Link record representeert een relatie tussen twee of meer Hub (of Link) records. Link tabellen worden doorgaans gebruikt om bepaalde structurele samenhangen tussen entiteiten weer te geven zoals hiërarchische verhoudingen. Bijvoorbeeld:

Sinds 25-03-2009 is in het data warehouse bekend dat de medewerker met personeelsnummer AB321 valt onder de afdeling Verkoop

Dit Link record refereert naar de volgende Hub records:

* Medewerker (business key = AB321)

* Afdeling (business key = Verkoop)

Daarnaast is de Link tabel de aangewezen plek om transactiegegevens in op te slaan. Bijvoorbeeld:

Sinds 25-03-2009 is in het data warehouse bekend dat klant K1234567 op 22-03-2009 order 8887.23 geplaatst heeft voor product met code X342P.

Dit Link record refereert naar de volgende Hub records:

* Klant (business key = K1234567)

* Product (business key = X342P)

* Order (business key=8887.23)

Satellite tabellen

Een Satellite record representeert een of meerdere attributen die behoren bij een Hub of Link record. Bijvoorbeeld:

Van 25-03-2009 tot 01-01-2010 is in het data warehouse bekend dat klant K1234567 de rechtsvorm ‘BV’ heeft.

Met data warehouse gemodelleerd volgens de Data Vault zijn we in staat om:

* data uit operationele systemen op bepaalde momenten in de tijd vast te leggen, zodanig dat we ten allen tijde de data van dat moment exact terug kunnen halen, ook al zijn er na dat bewuste moment wijzigingen aangebracht in de data. Het zogenaamde non volatility principe. Lees voor meer uitleg een van mijn vorige posts over tijd in een datawarehouse.

* data uit verschillende operationele systemen te integreren. Dat wil zeggen: Het inlezen van soortgelijke informatie uit verschillende bronnen in dezelfde Data Vault tabellen en het maken van koppelingen tussen data items uit verschillende gegevensbronnen.

Reference tabellen

De reference tabel wordt gebruikt om beperkte van te voren vaststaande set in onder te brengen.  Reference tables kunnen eventueel historized zijn net zoals Satellites. Deze tables staan op zichzelf en zijn niet geïntegreerd met de rest van de Data Vault. Ze kunnen gebruikt worden als ‘vertaaltabel’.

Merkwaardigerwijs verbiedt de officiële Data Vault leer ons Link tabellen (waarin we relaties tussen Hub records opslaan) te voorzien van een einddatum. Hierover is veel discussie in het “wereldje”. Eerlijk gezegd begrijp ik niet waarom. Ook relaties tussen Hubs kunnen een beperkte houdbaarheid hebben. Daarvoor heb je nou eenmaal een einddatum nodig. Kortom: ik voorzie ook Link tabellen gewoon van een einddatum.

Wat is er nu zo handig aan?

Stabiliteit door de tijd

Een belangrijke spelregel van Data Vault is: Wat eenmaal in de Data Vault staat, wijzigt nooit meer. Als we nu de Data Vault methode uitbreiden met Links met einddatum (zoals hierboven genoemd) zijn we in staat een data warehouse te creëren dat volledig stabiel is in de tijd. We kunnen ten allen tijde oude kengetallen en overzichten exact reproduceren.

Kleine wijzigingen in brondata -> kleine impact op het data warehouse

Door de fysieke scheiding tussen business keys en attributen van entiteiten en onderlinge relaties tussen entiteiten ontstaat een zeer flexibel datamodel. Een wijziging in een attribuut van een entiteit heeft hier alleen maar gevolgen voor het betreffende Satellite record waarin dit attribuut staat. We geven het “verouderde” satellite record een einddatum en maken daarnaast een nieuwe aan met de nieuwe attribuut waarde. We hoeven in tegenstelling tot bijvoorbeeld een star scheme of een 3NF gemodelleerd data model geen nieuwe versie van de volledige entiteit te maken en daar achteraan een nieuwe versie van alle entiteiten die op dat moment een relatie hebben met de bewuste entiteit. Hetzelfde geldt bij wijzigingen in relaties tussen entiteiten. In de Data Vault hoeven we enkel het betreffende Link record dat de “verouderde” relatie representeert van een einddatum te voorzien en een nieuwe Link record aan te maken die de nieuwe relatie representeert.

Flexibiliteit

Als in de loop der tijd er meer attributen van een entiteit moeten worden bewaard in het data warehouse dan aanvankelijk het geval was, dan hoeven we alleen maar een extra satellite tabel toe te voegen die we vanaf dat moment ook gaan vullen. We hoeven niet aan de bestaande tabelstructuur te zitten om dit te faciliteren. Hetzelfde gaat op voor het geval dat er tijdens het leven van het data warehouse nieuwe relaties willen gaan bewaren tussen reeds langer bestaande Hub tabellen.

Mogelijkheid tot parallel laden van data

De opsplitsing in Hubs, Links en Satellites en de manier waarop deze met elkaar samenhangen heeft als groot voordeel dat we veel data parallel kunnen laden. In wezen kan dit in 3 stappen gebeuren:

Stap1: Het parallel laden van de Hub tabellen

Stap 2: Het parallel laden van de Satellite tabellen behorend bij de Hub tabellen en alle Link tabellen.

Stap 3: Het parallel laden van de Satellite tabellen behorend bij de Link tabellen.

Compacte wijze van historie bewaren

Data Vault bewaart alleen de verschillen in de brondata ten opzichte van het vorige laadmoment. Dit in combinatie met het uiteenrafelen van entiteiten in Hubs, Links en Satellites zorgt voor een zeer compacte wijze van opslag van het de historie van data items.

Er wordt (bijna) niets weggegooid

In Data Vault lezen we de bron data ongewijzigd in. We doen niet aan data cleansing. Pas als we de data in het data warehouse vrijgeven eindgebruikers bijvoorbeeld d.m.v. een data mart, passen we allerhande business logic toe om foute data achter te houden of te “verbeteren”. Het mooie van deze werkwijze is dat wanneer we bijvoorbeeld door voortschrijdend inzicht in de loop der tijd betere logica ontwikkelen voor het schonen van data deze kan worden toegepast op de oorspronkelijke, niet reeds opgeschoonde en gefilterde brondata.

In combinatie met Change Data Capture op bronsystemen zouden we zelfs een Data Vault kunnen creëren die real time meebeweegt met de operationele systemen die de bron data leveren. Men is hier al druk doende. Bijvoorbeeld hier.

Auditability

Een andere Data Vault regel is dat ieder record moet worden voorzien van een bron verwijzing. We kunnen op basis hiervan een mechanisme maken waarmee we zeer gedetailleerd ieder item in ons data warehouse kunnen terug traceren naar de bron. Problemen opsporen in de brondata wordt hiermee vergemakkelijkt.

Zeer geschikt voor code generatie

Door de beperkte hoeveelheid bouwstenen en duidelijke regels waaraan een Data Vault moet voldoen is deze bij uitstek geschikt voor het genereren van allerhande programma code. Denk hierbij aan het vanuit een genormaliseerd datamodel van een bronsysteem een Data Vault database genereren die alle informatie kan bevatten die zich in het betreffende bronsysteem bevindt. Denk hierbij ook aan het genereren van ETL om data vanuit het bronsysteem in te lezen in de Data Vault database.

Dit is zo een greep uit alle voordelen van de Data Vault die bij mij op komt. Als u er meer weet, reageer vooral. Ziet u nadelen, vooral ook reageren.