Het afgelopen jaar is de BI-community opgeschud door een nieuwe aanpak, Data Vault. Data Vault kenmerkt zich door de volgende kernwoorden: traceerbaarheid, uitbreidbaarheid, flexibiliteit (van de IT-afdeling) en herhaalbaarheid. Voor mij zijn de voordelen van het gebruik van Data Vault voor een Centraal Data Warehouse evident. Echter, hoe groot zijn de verschillen tussen Data Vault en sterschema nou daadwerkelijk?
Laten we Data Vault modellering eens nader beschouwen. De kracht van de modelleertechniek ligt in de harde scheiding tussen business keys, associaties en details. De business keys komen voort uit de entiteiten die daadwerkelijk betekenis hebben voor de business (de hubs), alle associaties tussen entiteiten worden opgeslagen in link-tabellen. De details van een link of een hub komen inclusief volledige historie terecht in de satellites.
Deze scheiding biedt optimale flexibiliteit, alle associaties tussen entiteiten hebben een kardinaliteit van n:m, alle data uit de operationele systemen kan geladen worden, onafhankelijk van de integriteit.
Als we op dezelfde manier kijken naar het sterschema dan zie je opvallend veel overeenkomsten. De business keys komen terecht in de verschillende dimensies, inclusief historie van de attributen. De belangrijke associaties (gebeurtenissen uit de business) worden gevormd door de verschillende feitentabellen. Ook het dimensionale model slaat alle relaties tussen entiteiten (dimensies) op met een kardinaliteit van n:m middels de feitentabellen.
De grootste verschillen tussen Data Vault en het dimensionale model zitten in de scheiding tussen business keys en details en de hiërarchie in de dimensiestructuur. Data Vault legt een harde scheiding op tussen business keys en details, het sterschema niet. Daarnaast worden hiërarchieën in een Data Vault model altijd expliciet gemaakt middels een aantal hubs en links, in het sterschema wordt deze hiërarchie in principe platgeslagen in een dimensietabel.
Op de keper beschouwt zijn de verschillen dus misschien wel kleiner dan gedacht. Kort door de bocht kan je de hierboven genoemde verschillen categoriseren onder het kopje redundantie.
Waarom wordt het sterschema dan toch zo verguisd als modelleertechniek voor een CDW? Ik denk dat we hiervoor beter naar de architectuur moeten kijken. In een omgeving waar zowel een CDW als Data Marts voorkomen is een duidelijke scheiding aan te brengen op het gebied van verantwoordelijkheden. Het CDW zorgt voor integratie, historie en traceerbaarheid en de Data Marts zijn verantwoordelijk voor interpretatie (business rules) en eenduidige rapportage richting de business.
Dit onderscheid legt precies de vinger op de zere plek. De hiervoor genoemde verantwoordelijkheden zijn per definitie strijdig met elkaar. Traceerbaarheid en interpretatie kunnen onmogelijk worden gecombineerd in één omgeving. De meeste data warehouses die volgens Kimball-principes zijn gebouwd ontberen een CDW en doen dus toch een (vaak halfslachtige) poging om volledig strijdige verantwoordelijkheden te combineren in één component.
Door toepassing van een aantal designprincipes kan het sterschema uitstekend functioneren als CDW. Zonder op de details in te gaan zijn kernwoorden hierbij: granulariteit, conforme slowly changing dimensies en de juiste keuze van de feiten (een feit is een kortdurende gebeurtenis)
Stelling: wanneer een heldere scheiding wordt aangebracht tussen CDW en Data Marts en de juiste designprincipes worden toegepast dan worden de functionele verschillen tussen Data Vault en sterschema een stuk kleiner.
Dit is een mooie uiteenzetting van de verschillen tussen datavault en datamarts. Deze uiteenzetting gaat vnl in op de modelleertechniek, het uiteindelijke resultaat lijkt nie zo veel te verschillen.
Zelf heb ik jarenlang gewerkt met een datawarehouse volgens het banking model, dat veel overeenkomsten vertoont met datavault. In de praktijk blijken zaken als flexibiliteit en traceerbaarheid behoorlijk tegen te vallen.
De kortste weg van bron naar datamart/sterschema blijkt uiteindelijk de meest flexibele te zijn met een goede traceerbaarheid, mits vanaf het begin goed rekening gehouden is met de eis van traceerbaarheid.
Mooi uiteenzetting Kasper,
Wat ik echter begrepen heb van het modelleren van een Data Vault is een strikte(re) scheiding tussen harde businessrules bij het laden van data naar het CDW en de zachte business rules bij het laden naar de datamarts (of in de views). Juist deze scheiding is een van de krachtige kenmerken van een Data Vault. Daarnaast heeft een Data Vault als groot pluspunt het parallel kunnen laden van data waardoor grotere datavolumes mogelijk zijn. Hoewel de scheiding van harde en zachte business rules bij het modelleren in een ster best mogelijk zijn (wenselijk wellicht?) is het laden van een ster minder flexibel dan het laden bij een Data Vault.
Zoals wel vaker het geval is het vooral belangrijk om de juiste modelleringstechniek of technieken te hanteren die het beste aansluiten bij de vraag van de organisatie en de daar aanwezige/benodigde/gewenste architectuur. Ik vindt het wel goed dat het stermodelleren weer uit het vergetelheidshoekje wordt gehaald en we niet standaard uit moeten gaan van Data Vault als modelleringstechniek voor het CDW.
Remco,
Dank voor je reactie.
Ik ga helemaal met je mee dat Data Vault aanvullende voordelen heeft voor het modelleren van een EDW, boven het dimensionele model.
Er zijn echter organisaties waar het (politiek of qua volwassenheid) niet handig of haalbaar is om een nieuwe modelleertechniek te introduceren.
Wat ik veel zie is dat in die situatie het dimensionele model wordt ingezet op de verkeerde manier, puur als verzameling data marts. Hier probeer ik een lans te breken om ook in die situatie na te denken over zaken als traceerbaarheid.