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:
- data van een of meer brondatabases naar een nieuwe doeldatabase wordt overgezet. In het geval van meerdere bronnen is vaak data-integratie nodig.
- data uit het bronsysteem moet waar nodig worden opgeschoond. Als het bewaken van datakwaliteit in het bronsysteem gebrekkig is, levert dit eigenlijk gegarandeerd vervuiling op. Een ander bekend fenomeen is het gegeven dat bepaalde velden in bronsystemen zijn gebruikt voor andere doeleinden dan waarvoor ze oorspronkelijk bedoeld zijn.
- entiteiten in de bronsystemen moeten worden getransformeerd naar entiteiten in de doeldatabase. Dit is soms kinderlijk eenvoudig maar in andere gevallen is dit een pittige opgave.
- er doorgaans meerdere iteraties nodig zijn om tot uiteindelijk resultaat te komen. Vaak moet er zoveel worden verspijkerd aan de oude data alvorens deze naar het doelsysteem kan worden overgezet dat dit onmogelijk in een enkele conversieslag kan worden gedaan. Voortschrijdend inzicht is eerder regel dan uitzondering. Er vindt dan een proefmigratie plaats, die vervolgens wordt geëvalueerd door mensen die inhoudelijk op de hoogte zijn van de over te zetten data. De uitkomsten van de evaluatie worden vervolgens verwerkt in een nieuwe proefmigratie, etc. Ook kan deze evaluatie leiden tot het verbeteren van de datakwaliteit in de bronsystemen.
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 hun 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.
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.
