Ik ben Richard Steijn en datawarehousing/BI specialist. Bij vele organisaties in diverse branches heb ik een kijkje in de keuken mogen nemen. Verscheidene technologieën hebben mijn pad gekruist. Data en alle vraagstukken daaromheen vormen een rode draad in mijn werkzame leven. In deze blog schrijf ik over de dingen die mij zoal bezighouden.
Bij de kreet Data Vault wordt al vrij snel gedacht aan data warehousing. Dit is echter niet het enige domein waarvoor deze modelleringtechniek/architectuur nuttig is. In deze post wil ik eens aandacht besteden aan de toepasbaarheid van Data Vault in een datamigratiestraat. Een typisch data migratie traject houdt in ieder geval in dat:
Belangrijk is dat iedere iteratie in het migratietraject herhaalbaar en traceerbaar is. De data in de bronsystemen is echter doorgaans in beweging tijdens dit traject. Al is het maar vanwege het verbeteren van datakwaliteit in de bronsystemen naar aanleiding van een proefmigratie. Om herhaalbaarheid van iedere iteratie te garanderen is het noodzakelijk dat er “foto’s” genomen worden van de bronsystemen. Voor dit doel kan per bronsysteem een Source Data Vault (sDV) worden aangelegd (of liever nog: genereren). De sDV bevat enkel de volledige (inhoudelijk) ongewijzigde data op verschillende peilmomenten in het betreffende bronsysteem.
Voor data-integratie en datatransformaties zijn soms vertaaltabellen nodig. Deze kunnen worden ondergebracht in een Helper Database. Als we streng in de leer zijn en we willen gaan voor 100% reproduceerbaarheid van iedere iteratie in het migratietraject dan zouden we ook van deze vertaalinformatie de historie moeten gaan bijhouden.
Niet iedere opschoonactie of transformatie is volledig te automatiseren. Menselijke tussenkomst is dan noodzakelijk. Onze migratie architectuur moet ruimte bieden voor handmatige ingrepen die niet plaats vinden in de bronsystemen maar ergens verderop in de migratiestraat. Om hier herhaalbaarheid te kunnen garanderen is het noodzakelijk dat het handmatig ingrijpen op gestructureerde wijze gebeurt. Dit kan door handmatige wijzigingen te zien als zijnde afkomstig uit een correctiesysteem dat we behandelen als bronsysteem. En net als voor alle andere bronsystemen wordt ook voor dit systeem een sDV aangelegd. Deze speciale sDV noem ik Correctie Data Vault (cDV). Hier wordt de historie van de correcties bewaard. Voor de duidelijkheid, het correctiesysteem is geen echt systeem, het is in feite een set correctiebestanden volgens een vast stramien. Dit kunnen bijvoorbeeld Excel bestanden zijn met in iedere rij een te vervangen data-item, gecombineerd met vervangende data. Of Excel bestanden met de sleutels van de entiteiten (of relaties) die niet meegaan in de migratie. Om maar eens wat te noemen. Deze correctiebestanden worden ingelezen in de cDV.
De bouwstenen voor de migratie zijn dus sDV’s, de cDV en de Helper DB. Als we een proefconversie voorbereiden, zullen deze allereerst gevuld moeten worden. Alle gegevens in deze bouwstenen worden vervolgens op een bepaalde wijze opgeschoond, bewerkt en gecombineerd zodat nieuwe data ontstaat, die geschikt is om te importeren in het doelsysteem. De wijze waarop dit gebeurd, is sterk onderhevig aan voortschrijdende inzichten. Om 100% reproduceerbaarheid van deze stap te garanderen is het natuurlijk noodzakelijk om alle versiebeheer toe te passen op de gebruikte bewerkingen (programmacode dus). Daarnaast is het handig (maar niet strikt noodzakelijk) om de uitkomst van deze bewerkingen historisch op te slaan in een speciaal hiervoor bestemde Migratie Data Vault (mDV). Dit maakt het vergelijken van de uitkomsten van verschillende iteraties eenvoudiger. Ook kan hierin voor ieder data-item worden vastgelegd uit welke bewerking het precies afkomstig is. Dit is met name handig naarmate de betreffende bewerking complexer is. Daar waar het simpele bewerkingen betreft, zou eventueel kunnen worden volstaan met een view op de betreffende sDV.
De mDV vormt uiteindelijk de bron van waaruit het doelsysteem wordt geladen.
In onderstaande afbeelding is het hierboven beschrevene nog eens schematisch weergegeven. De letters A, B en C geven aan waar na iedere iteratie verbeteringen kunnen worden aangebracht.