Waarom nou DV? Ik zie het voordeel niet want als het gaat om het bijhouden van historische informatie kun je toch net zo goed de tabellen uit je bronsysteem inladen en daar een fromdate en tilldate aan toevoegen? Natuurlijk sla je dan de (business) key dubbel op, maar je hebt een mooi platform waarop je zonder extra joins heel makkelijk ENT en PIT functies kunt bouwen, net zoals het doel is bij de DV methode. (Of is dit niet het doel?)
Als een business key wijzigt… Er komt een extra kolom bij de BK. Wat dan? Bij DV kun je kiezen voor een nieuwe hub, maar beter lijkt me om de hub te wijzigen met de nieuwe BK. Maar als je dat doet, wat zeggen de SAT tuples dan nog over de HUB? Niks meer. Dus je moet het hele ding opnieuw inladen, wat een flinke migratie gaat worden.
Nieuwe databronnen. Een nieuw systeem wordt aangesloten. Stel, ik heb allemaal rijen uit Exact in mijn DV. Exact kent een klant op basis van een aantal kolommen, key en not key. Dat is in DV dus HUB en SAT. Nu komt systeem ProjectX erbij. Dit kent diezelfde klant op basis van een technisch ID, bijvoorbeeld een identity kolom. Dit willen we natuurlijk niet in onze DV, dus je gaat daar op business key modelleren en je komt met een ETL proces waarbij de Exact klant in dezelfde hub past als de ProjectX klant. Nu heb je een modelleerstap gedaan waardoor je in een Kimball model minder hoeft na te denken over je conformed Klant dimension.
Maar.. Het alternatief voor de DV approach is om alle regels uit je bronsystemen in te laden in tabellen met een fromdate en todate. Dit is heel eenvoudig, meer straightforward. Als je dat doet voor Exact en ProjectX dan zul je eindigen met twee verschillende tabellen: de Exact klant en de ProjectX klant. Je moet dus nog extra logica toevoegen in een laag hierna om de twee soorten klanten te matchen, zodat je 1 perspectief van dezelfde klant krijgt.
Hier zie ik wel een voordeel voor DV, omdat je in DV een klant bepaalt aan de hand van een business key die (hopelijk) overeenkomt tussen de verschillende systemen. In DV zul je dan een HUB_Klant krijgen met een mooie business key die je bij het toevoegen van een nieuw bronsysteem weer kunt hergebruiken en waar je links aan kunt knopen. Heel fijn. Je hebt hier dus een modelleerslag op gedaan, zodat je niet later in de ETL naar verschillende data marts hetzelfde hoeft te doen. Je hebt in feite de modelleerslag naar voren gehaald, om het maken van de Kimball “Conformed Dimensions” eenvoudiger te maken.
Maar.. Dit is een boel werk. Je DV moet net zo hard worden uitgedacht als je uiteindelijke Conformed Dimension zou moeten worden uitgedacht. Die integratiestap moet sowieso worden gedaan. Mijn vraag is dus niet of die integratie moet worden gedaan, maar of DV de meest makkelijke en snelle oplossing hiervoor zou zijn. Immers, in de Kimball methodologie heb je voor je Data Marts een EDW dat ook volgens Kimball is gebouwd, en waar die integratie dus ook al is gedaan. De mensen die de Data Marts bouwen hoeven alleen maar deze data in te laden.
Ik denk aan een persisted staging area waar alle bronsystemen worden opgeslagen met geldigheidsdatums, en waar vervolgens dezelfde gedachte op wordt losgelaten om van Exact_Klant en ProjectX_Klant dezelfde klant Dimensie te maken. Dit is immers het uiteindelijke doel, want de business wil Facts en Dimensions.
Nogmaals: ik ben heel hard op zoek naar de meerwaarde van de Data Vault methodologie, en ik wil hem echt kunnen pakken. Helaas is het enige wat ik op internet tegenkom, zelfs op de site van Inmon/Linstedt een set vaagheden over de voordelen. En daarnaast een heleboel religieuze discussies waarin mensen elkaar afmaken omdat ze niet de juiste theologie aanhangen. Ik begrijp dat je, wanneer je net begint met het onderwerp, een leidraad wilt hebben over de do’s en don’t’s, maar wanneer je meer dan 10 jaar in het vak zit, zoals ik, dan heb je zo veel dingen geleerd dat je heel goed kunt onderbouwen wanneer je wilt afwijken van een best practice.
Terug naar de persisted staging area. Hier staan al onze tabellen, gevuld en wel, met geldigheidsdatums. Het is voor ons database professionals heel makkelijk om hier bovenop ENT en PIT functies te bouwen, en hierin dezelfde logica te programmeren als we zouden hebben gedaan bij een DV oplossing. Het team dat vervolgens de Facts en Dimensions bouwt zou het niet uitmaken omdat de output exact hetzelfde zou zijn. Ik denk alleen dat we bij deze laatste oplossing een stuk minder tijd aan ontwikkeling kwijt zouden zijn dan wanneer we de tussenstap van een Data Vault zouden hebben gekozen.
Ik heb hier een boel dingen geschreven, en ik heb nu even geen inspiratie meer. Ik nodig jullie allemaal van harte uit om commentaar toe te voegen hieronder, en mij het grote voordeel van Data Vault te laten begrijpen. Ik meen het, laat je commentaar achter, of stuur me een mail, met telefoonnummer zodat we een keer kunnen praten want ik wil het echt begrijpen. Maar tot nu toe, zie ik het gewoon niet.
Reacties zijn gesloten.