Ik ben Lidwine van As, sinds 1994 werkzaam in de IT, en actief als 
In juni van dit jaar publiceerde DB/M een artikel van Karien Verhagen en Bart Vrijkorte, waarin Data Vault als techniek voor het modelleren van centrale datawarehouses wordt vergeleken met “relationele” (bedoeld wordt: 3NF) modellering. Naast voordelen benoemen de auteurs ook enkele bezwaren van de methodiek.
De opgeworpen bezwaren snijden echter naar mijn mening geen hout in een datawarehouse-context. Om een modellering voor datawarehouses te beoordelen, zul je daar op z’n minst met een datawarehouse-bril naar moeten kijken. Dat lijkt een open deur, maar in dit geval lijken de auteurs eerder een OLTP-bril op te hebben. Het resultaat is een vertekend beeld van de sterktes en zwaktes van Data Vault.
Datawarehouse != OLTP
Het datamodel van een datawarehouse heeft een totaal andere rol dan dat van een OLTP-systeem.
Een datawarehouse doet niets anders dan elders gecreëerde gegevens ontvangen, opslaan en weer afstaan – en dat in grote hoeveelheden. Daarbij speelt verwerkingssnelheid een belangrijke rol, want de totale verwerking moet meestal binnen een beperkt batchwindow plaatsvinden. Verder weten we inmiddels dat het ETL-proces 70% van de totale ontwikkel- en onderhoudsinspanning en -kosten in beslag neemt; hoe beheer(s)baarder het proces is, hoe meer dat scheelt in de kosten.
Deze factoren bepalen de inrichting van het datawarehouseproces. Dat vertaalt zich in uitgangspunten als:
- liever vele simpele, gestandaardiseerde ETL-procedures dan een klein(er) aantal complexere, customized procedures
- inserts hebben de voorkeur boven updates
- eventuele datakwaliteitscontroles op de invoer doe je niet met database constraints, maar in het ETL-proces (aangezien dat meestal beter performt)
- zo min mogelijk onderlinge afhankelijkheden tussen laadprocedures: enerzijds om het proces overzichtelijk en onderhoudbaar te houden; anderzijds om maximaal te kunnen parallelliseren, wat bijdraagt aan de schaalbaarheid van het proces
Het datawarehouse-model is sterk bepalend voor de mate waarin deze uitgangspunten gerealiseerd kunnen worden. (Data Vault is speciaal ontworpen om maximale ondersteuning te bieden). Niets in het artikel wijst er echter op dat de auteurs deze rol van het datamodel hebben laten meewegen in hun beoordeling.
Laten we eens enkele van hun bezwaren onder de loep nemen.
Geen constraints
Verhagen en Vrijkorte zien het als een risico dat Data Vault relaties tussen entiteiten altijd weggeneraliseert naar n:m-cardinaliteit: daarmee valt immers de controle in de database op invoer van de juiste cardinaliteit weg.
Zoals gezegd: als je die controle al wilt uitoefenen, dan doe je dat in je ETL-proces, niet in de database (in tegenstelling tot wat de auteurs suggereren, is dat geen Data Vault-bedenksel, maar een geaccepteerde best practice in datawarehouseland).
De Data Vault-filosofie gaat echter nog verder: het centrale datawarehouse wordt beschouwd als een system of fact, dat *alle* aangeleverde gegevens moet kunnen verwerken – het oordeel “deugdelijk of niet” wordt pas onderweg naar de datamart geveld, op basis van de criteria van de eindgebruiker. Aan de poort worden dus überhaupt geen controles uitgevoerd (behalve om gegevens uit te filteren waar het systeem technisch niet mee uit de voeten kan, bijv. vanwege verkeerde gegevensformaten).
Een Data Vault-model moet dus kunnen omgaan met gegevens die eigenlijk een verkeerde cardinaliteit hebben. En dan is het juist heel verstandig – zo niet noodzakelijk – om a) zo min mogelijk constraints in het model op te nemen, en b) deze daar waar ze onvermijdelijk zijn zo ruim mogelijk te definiëren. Het gebruik van linktabellen, waardoor iedere relatie per definitie de ruimste cardinaliteit krijgt, is dan de meest logische maatregel.
Linktabellen vs foreign keys
Verder stellen Verhagen en Vrijkorte dat in sommige situaties1 het gebruik van een linktabel “weinig toegevoegde waarde lijkt te hebben” (waarom dat zo zou zijn, wordt niet nader onderbouwd), en zijn van mening dat het “het beste lijkt” om maar gewoon een foreign key te gebruiken.
Ook nu wordt niet de impact meegewogen die modelkeuzes hebben op het ETL-proces. De meerwaarde van de linktabel zit hem nl. in de modelmatige ontkoppeling van de hubs, en daarmee van de bijbehorende laadprocedures. Hierdoor wordt het aantal synchronization points in het proces geminimaliseerd: eerst worden alle hubs parallel geladen, daarna alle links parallel, daarna alle satellites parallel. (Als er voldoende processing power voorhanden is, is het zelfs mogelijk om de hub-satellites gelijktijdig met de links te laden.)
Doordat de onderlinge wachttijd tussen jobs minimaal is, worden het batchwindow en de beschikbare resources optimaal benut; dit komt de schaalbaarheid van het proces ten goede.
Verder is het voor ontwikkeling en onderhoud van ETL-processen een voordeel als laadprocedures zo min mogelijk onderling afhankelijk zijn: de processen worden er flexibeler en minder complex van.
Door de hubs aan elkaar te knopen via foreign keys loop je al die voordelen mis, omdat de hubs nu noodgedwongen serieel moeten worden geladen. Het beslag op het batchwindow wordt daarmee groter dan nodig, en de schaalbaarheid van het proces loopt eveneens terug. Bovendien maakt de onderlinge afhankelijkheid het ETL-proces complexer, en dus slechter onderhoudbaar.
End user access?
Tenslotte noemen de auteurs nog als bezwaar dat Data Vault-modellen lastig bevraagbaar zijn door eindgebruikers. De observatie klopt - maar is het ook een probleem? De modellering is specifiek bedoeld voor het centrale datawarehouse, en daar heeft de eindgebruiker sowieso niets te zoeken. Is het een nadeel als in een restaurant de keuken niet even sfeervol is ingericht als de eetzaal?
Conclusie
Data Vault heeft zijn sterke en zwakke kanten; omdat het concept nog maar net in opkomst is, zijn met name over de zwaktes nog weinig ervaringsfeiten voorhanden.
Bij afwezigheid daarvan, kan discussie een uitstekend middel zijn om onze beeldvorming aan te scherpen - maar dan moeten we die wel voeren met geldige argumenten.
- de auteurs doelen hier op zgn. “zwakke entiteiten”: entiteiten die (deels) gedefinieerd c.q. geïdentificeerd worden door hun relatie met een andere entiteit, waardoor die relatie de facto onveranderlijk is. Een voorbeeld is de relatie van een factuurregel met de factuur waarop hij voorkomt. ↩
Back to home page
« Data Vault en brononafhankelijkheid BI: to ROI or not to ROI »
