Vorige week zijn we dieper in het concept achter Data Vault gedoken. Samen met een aantal collega’s en Kasper de Graaf hebben we gekeken wat de toepasbaarheid van Data Vault is binnen software ontwikkeling.
Data Vault is een modelleerstijl ontstaan in de datawarehousing wereld. Dan Linstedt heeft de basis voor deze stijl gelegd en inmiddels meerdere keren succesvol toegepast. Het is een modelleerstijl waarin data zo wordt vastgelegd dat:
- deze uitgebreid kan worden zonder de bestaande structuur aan te passen;
- op een zeer eenvoudige manier mutaties en herkomst van de data vastgelegd kan worden;
- geen complexe structeren bedacht hoeven te worden om de betekenis van een enititeit duidelijk vast te leggen;
Om dit te bereiken zijn een aantal eenvoudige regels opgesteld. Zo wordt een enititeit gemodelleerd als een HUB. Een hub bevat slechts een business ID en een technische ID voor de entiteit. Stel een hub beschrijft een klant dan beschrijft het slechts een klantnummer en een technische ID. Vanuit datawarehouse perspectief zou nog metainformatie, zoals het bronsysteem waaruit de data komt, kunnen worden toegevoegd.
Hubs worden aan elkaar geknoopt via Links. Een link is een tabel die een N op M relatie legt tussen hubs. Ook een link is een eenvoudige entiteit die slechts beperkt metadata bevat.
Van de hubs kunnen natuurlijk meerdere attributen vastgelegd worden. Deze attributen worden in Satelliet-entiteiten ondergebracht. Een hub kan meerdere satellieten hebben en is daarmee flexibel uit te breiden.
Het mooie van Data Vault is dat het slechts deze drie entiteitsoorten kent. Daarmee is het eenvoudig inzichtelijk te maken.
Tijdens onze discussie konden we al snel een verband leggen met een object georienteerd domeinmodel. Deze zou je makelijk middels Data Vault kunnen persisteren. Het is zelfs relatief eenvoudig om hier een frameworkje voor te schrijven. Stel je voor dat je een .NET LinkToDataVault provider hebt. Deze provider kan op basis van annotaties (attributen in .NET) makelijk de mapping tussen het objectmodel en de relationele database maken. Het voordeel van deze aanpak is dan dat je minder database aanpassingen hoeft door te voeren wanneer je objectmodel wijzigd. Je zult namelijk slechts database uitbreidingen hebben en beperkt tot geen wijzigingen.
Een mooi punt om in een POC te bewijzen. Mocht je dus nog een leuke informatica afstudeeropdracht zoeken 🙂 …. Neem gerust contact op