Artikel

Een eenvoudig alternatief voor de Data Vault

DWH-architectuur op basis van de historische data (staging) area

De data warehouse-methode en datamodelleringswijze Data Vault van Daniel Linstedt staat momenteel enorm in de belangstelling in Nederland. Er verschijnen veel artikelen over de Data Vault in de vakbladen, op ieder business intelligence seminar wordt erover gesproken en veel kundige data warehouse consultants zijn er enthousiast over. Waarom deze warme belangstelling? Omdat de Data Vault een aantal problemen van de traditionele data warehouse-architecturen van Ralph Kimball en Bill Inmon oplost. En toch deel ik het enthousiasme over de Data Vault niet. De problemen van de architecturen van Kimball en Inmon worden weliswaar opgelost, maar deze kunnen ook op een veel eenvoudigere en efficiëntere manier worden opgelost. Dit artikel beschrijft deze alternatieve oplossing.

Data warehouse-architecturen

Data warehouse-architecturen kunnen vanuit verschillende perspectieven beschreven en vergeleken worden. In dit artikel wordt uitgegaan van de data-architectuur. Daarbij spelen dataopslag en datamodellering een belangrijke rol. Andere aspecten, zoals metadata, foutafhandeling, ongestructureerde data, archivering, big data en autorisatie zijn niet relevant in het kader van dit artikel en laat ik daarom buiten beschouwing.

De drie dominante data warehouse-architecturen

Eind jaren ‘80 werd het normaliseren van gegevens gemeengoed. Normalisatie van gegevens voorkomt redundantie (dezelfde gegevens meerdere malen opslaan). De grondlegger van het begrip data warehouse, Bill Inmon, schreef voor om de gegevens in het (enterprise) data warehouse te normaliseren. De data marts (een verzameling van gegevens met een kleinere hoeveelheid aan gegevens dan het gehele data warehouse en vaak ingericht voor een specifiek doel) zijn ook onderdeel van de data warehouse-architectuur van Inmon. Inmon gaf meerdere redenen voor het opnemen van data marts, bijvoorbeeld om ten behoeve van performance de gegevens te aggregeren, of vanwege beveiliging maar een deel van de gegevens ter beschikking te stellen. De data warehouse-architectuur van Inmon (Corporate information factory) bestaat daarmee in basis uit de volgende opslaglagen:

  • Een data staging area voor de ontkoppeling van de bronsystemen en het verzamelen van alle gewijzigde gegevens op één platform.
  • Een data warehouse op basis van een genormaliseerd geïntegreerd datamodel inclusief historie en inclusief de resultaten van business rules (een business rule, ook wel transformatieregel genoemd, is bijvoorbeeld de berekening van de omzet).
  • Data marts t.b.v. het eenvoudig en met hoge performance beschikbaar stellen van gegevens aan gebruikers.

Halverwege de jaren ‘90 groeide, onder aanvoering van Ralph Kimball, de populariteit van het dimensioneel modelleren [1] (sterschema’s). Het achterliggende principe van deze wijze van modelleren is dat bij data warehouses eenvoud en hoge performance belangrijker zijn dan het voorkomen van redundantie. Ofwel, Kimball staat redundantie toe in een dimensioneel model (overigens alleen in dimensies, juist niet in de omvangrijke feitentabellen). Kimball introduceerde met deze wijze van modelleren ook een andere architectuur dan Bill Inmon, namelijk de Kimball bus architecture. Deze architectuur bestaat uit de volgende opslaglagen:

  • Een verzameling van fysieke data marts die logisch geïntegreerd zijn op basis van geconformeerde dimensies (dus geconformeerde data marts). Een geconformeerde dimensie is bijvoorbeeld de klantdimensie die wordt gebruikt in het sterschema ‘verkoop’ en tevens in het sterschema ‘verkoopfacturen’, waarbij een data mart bestaat uit één of meerdere sterschema’s. Zodoende kan men logisch gezien spreken over één data warehouse, fysiek kan het data warehouse echter bestaan uit meerdere databases (of andere technologieën, zoals MDB OLAP).
  • De data staging area voor de ontkoppeling van de bronsystemen en het (tijdelijk) verzamelen van alle gewijzigde gegevens op één platform. Formeel gezien maken de geconformeerde dimensies ook deel uit van de data staging area, zodat deze maar eenmalig samengesteld hoeven te worden en vervolgens kunnen worden gedistribueerd naar de data marts.

De afgelopen jaren krijgt een derde stroming veel aandacht: de Data Vault. Daniel Linstedt is de grondlegger van de Data Vault, een methode van modelleren en een beschrijving van de bijbehorende architectuur [2]. De Data Vault is een hybride vorm van modelleren, met zowel eigenschappen van normaliseren als van een dimensioneel model [3]. De architectuur van de Data Vault bestaat uit de volgende opslaglagen:

  • De data staging area voor de ontkoppeling met de bronsystemen en het verzamelen van alle gewijzigde gegevens op één platform.
  • De Raw Data Vault, waarin de historische brongegevens zonder de resultaten van business rules worden vastgelegd, met een lichte integratie op business keys (bijv. het klantnummer voor de identificatie van een klant).
  • De Business Data Vault, waarin ook de resultaten van de business rules (berekeningen, transformaties etc.) worden vastgelegd.
  • Data marts t.b.v. het eenvoudig en met hoge performance beschikbaar stellen van gegevens aan gebruikers.

Dan Linstedt brengt hierbij de nuance aan [4] dat van deze vier fysieke opslaglagen drie opslaglagen optioneel zijn:

  • de data staging area. De gegevens zouden ook rechtstreeks in de Raw Data Vault kunnen worden geladen.
  • de Business Data Vault. De business rules (transformaties) zouden ook verwerkt kunnen worden in het proces van de Raw Data Vault naar de data marts.
  • de fysieke data marts. De data marts zouden ook virtueel kunnen zijn, bijvoorbeeld via SQL Views op de Data Vault-structuur.

Het is belangrijk om vast te stellen dat zowel Inmon als Lindstedt in hun architectuur ook plaats bieden aan een dimensioneel model. De data marts binnen deze architecturen kunnen namelijk een dimensionele structuur hebben. Inmon, Linstedt en Kimball zijn het er derhalve over eens dat dimensionele modellen goed geschikt zijn voor de analyse van gegevens. Hierbij moet de nuance worden aangebracht dat voor specifieke functionaliteit (denk bijvoorbeeld aan data mining) andere datastructuren beter geschikt zijn.

Samengevat zijn er dus drie manieren om het data warehouse te modelleren: normaliseren (3NV), dimensioneel modelleren of de Data Vault. De wijze van modelleren gaat samen met een data warehouse-architectuur. In figuur 1 zijn de verschillende architecturen gevisualiseerd.
 

Figuur 1: Data warehouse architecturen van Inmon, Kimball en Linstedt. Hoofdletter ‘T’ betekent in dit schema dat business rules en structuurwijzigingen worden toegepast en de kleine letter ‘t’ betekent dat alleen structuurwijzigingen worden aangebracht in de data. Let op, Inmon biedt ook allerlei uitbreidingen op deze architectuur, maar deze zijn niet relevant in dit kader. Linstedt benadrukt dat niet alle lagen verplicht zijn.

De problemen van de architecturen van Inmon en Kimball

De grote vraag is waarom Dan Linstedt deze derde modelleringswijze en architectuur heeft geïntroduceerd? Het antwoord daarop is dat hij een aantal problemen in de architecturen van Inmon en Kimball op heeft willen lossen. Deze problemen hebben betrekking op de volgende aspecten:

  • De architecturen van Inmon en Kimball hebben geen opslaglaag waarin alle (mogelijk relevante) brongegevens historisch zijn opgeslagen zonder enige vorm van selectie, aggregatie en (business rule-) transformaties. De Data Vault biedt wel een opslaglaag, de Raw Data Vault, waarin deze historische gegevens zonder transformaties zijn opgeslagen. Deze opslaglaag (‘the system of records’) is noodzakelijk voor een auditable en compliant data warehouse. Een auditable data warehouse maakt het mogelijk te reconstrueren hoe een cijfer op een rapport tot stand is gekomen. In de architecturen van Kimball en Inmon worden de gegevens na de (vluchtige) data staging area (DSA) direct bewerkt waardoor de audittrail van bron naar rapport wordt doorbroken.
  • Doordat de architecturen van Inmon en Kimball de gegevens al direct na de DSA interpreteren en integreren, zal deze interpretatie en integratie bij elke bronwijziging moeten plaatsvinden. Daarmee wordt de architectuur meer afhankelijk van bronwijzigingen. Indien deze interpretatie en integratie niet (direct) plaatsvindt, zoals bij de Data Vault, ontstaat er hogere mate van brononafhankelijkheid. Bronwijzigingen kunnen bovendien eenvoudiger en gestandaardiseerd worden verwerkt, resulterend in een kortere time-to-market.

Vanzelfsprekend kan men discussiëren of deze eisen voor ieder data warehouse belangrijk zijn. Een data warehouse hoeft bijvoorbeeld niet altijd auditable te zijn. In dit artikel wordt er vanuit gegaan dat deze eisen worden gesteld aan het data warehouse.

De Data Vault oplossing

De Data Vault-architectuur lost deze problemen op door de introductie van de Raw Data Vault. Deze opslaglaag is een kopie van de brongegevens, maar in een andere structuur (hubs, links en satellites) waarbij ‘licht geïntegreerd’ wordt op de business key. Deze opslaglaag legt de complete historie vast, de gegevens zijn een afspiegeling van de bron en de gegevens kunnen in deze laag eenvoudig geladen worden. De Data Vault lost dus een aantal essentiële problemen van de architecturen van Kimball en Inmon op.

De nadelen van de Data Vault

Vaak hebben oplossingen voor een probleem nadelige bijeffecten, zo ook bij de Data Vault. De Data Vault heeft twee nadelen: extra opslaglagen en de introductie van een extra modelleringstechniek, de Data Vault zelf. Dat vergt een toelichting.

Extra opslaglagen binnen het data warehouse

In een ideale wereld maak je rapporten en analyses rechtstreeks op de brongegevens en hoef je de gegevens niet te kopiëren naar een aparte omgeving (het data warehouse). Immers, deze kopieslag moet ontwikkeld, onderhouden en beheerd worden. Bovendien vergt de kopieslag doorlooptijd, zijn de gegevens niet actueel en neemt de kopie schijfruimte in beslag. Toch zijn er vaak goede redenen om de gegevens wel te kopiëren naar een data warehouse, denk hierbij aan performance, integratie en eenvoud.

Bij een data warehouse(-architectuur) moet dezelfde redenering worden gehanteerd, een extra opslaglaag binnen een data warehouse moet voldoende toegevoegde waarde hebben. De architectuur van de Data Vault bestaat uit een DSA, een Raw Data Vault, een Business Data Vault en data marts. Dus mogelijkerwijs uit maar liefst vier opslaglagen om uiteindelijk de informatie te kunnen rapporteren. Soms worden zelf nog meer opslaglagen gesuggereerd (pre-staging, post-Data Vault, cubes, in-memory etc.). Al deze lagen vergen inspanning en kosten in termen van ontwikkeling, onderhoud en beheer. Bovendien gaan deze extra lagen juist door alle benodigde inspanning ten koste van een korte time-to-market bij wijzigingen. Daarnaast zijn impactanalyses lastiger uit te voeren, omdat de logica van elke laag moet worden begrepen. Ergo, het nadeel van de Data Vault is dat deze leidt tot een architectuur met extra opslaglagen en deze extra lagen leiden tot meer inspanning en kosten dan noodzakelijk.

De nuance van Linstedt op deze kritiek is dat, zoals hierboven genoemd, drie lagen (DSA, Business Data Vault en fysieke data marts) optioneel zijn. Daar plaats ik echter twee kanttekeningen bij: de Business Data Vault is naar mijn mening altijd noodzakelijk om te voorkomen dat business rules op meerdere plaatsen moet worden onderhouden, namelijk in ieder Extraction, Transformation and Load (ETL) proces naar een data mart waarin het resultaat van deze business rule wordt gebruikt. Daarnaast zijn virtuele data marts (database views) wellicht mogelijk in bepaalde situaties, maar de datastructuur van de Data Vault leidt tot een slechtere performance dan een dimensioneel model. De Data Vault vereist namelijk meer joins tussen (grote) tabellen en in het algemeen kan worden gesteld dat het koppelen van tabellen ten koste gaan van de performance.

De Data Vault als modelleringstechniek

In de Kimball-architectuur wordt maar één datamodelleringstechniek toegepast: dimensioneel modelleren. Bij de Data Vault-architectuur wordt deze modelleringswijze ook toegepast (fysiek en/of virtueel), maar daarnaast is de Data Vault als modelleringswijze ook vereist. De gegevens worden dus niet alleen meerdere keren opgeslagen, maar ook in meerdere structuren. Betrokkenen moeten kennis van zowel de Data Vault als dimensioneel modelleren vergaren en hiermee ervaring opdoen. De hiervoor benodigde inspanning (en doorlooptijd) moet niet onderschat worden. Daarnaast zijn er inhoudelijk ook kritische opmerkingen [5] te maken over de Data Vault als modelleringswijze, maar deze worden buiten beschouwing van dit artikel gelaten, omdat dit niet de kern van de kritiek is.

De opslaglagen van een data warehouse

Het is duidelijk dat extra opslaglagen met een extra wijze van modellering leiden tot extra inspanning, hogere kosten, langer durende laadprocessen en langere doorlooptijd van aanpassingen. Dus een belangrijk architectuurprincipe is dat een opslaglaag alleen gerechtvaardigd is wanneer deze voldoende toegevoegde waarde heeft. Dat brengt ons bij de vraag: wanneer heeft een opslaglaag voldoende toegevoegde waarde? Deze vraag blijkt verrassend eenvoudig te beantwoorden. Een data warehouse moet bestaan uit een achterkant (backroom) en voorkant (frontroom) omdat deze twee onderdelen verschillende doelstellingen hebben die niet te verenigen zijn in één opslaglaag:

  • De achterkant van het data warehouse moet gegevens volledig historisch vastleggen, zonder enige wijze van interpretatie, zodat het data warehouse auditable en compliant is. Daarnaast moet deze laag eenvoudig zijn (in termen van ontwikkeling, onderhoud, beheer en laden) zodat wijzigingen in de bron snel kunnen worden opgevangen.
  • De voorkant van het data warehouse moet de gegevens op een eenvoudige wijze aan de gebruikers beschikbaar stellen met de best mogelijke performance.

Een data warehouse bestaat dus in principe uit twee fysieke opslaglagen. Mochten de eisen van de achterkant niet worden gesteld aan het data warehouse, dan zijn er vaak nog technische redenen om deze achterkant zo in te richten, bijvoorbeeld t.b.v. herstelbaarheid of het beschikbaar hebben van alle data op één platform in één formaat.

Het eenvoudige alternatief voor de Data Vault

De volgende vraag is op welke manier de gegevens in deze twee lagen gemodelleerd moeten worden. Daarbij komen we op het alternatief voor de Data Vault. Het alternatief voor de Data Vault aan de achterkant van het data warehouse is verrassend eenvoudig en niet uniek.

Deze achterkant bestaat uit de data staging area waarbij alle gegevens in een RDBMS historisch worden opgeslagen in de datastructuur van de bron. Ofwel, de gegevens worden vanuit de bron 1:1 geladen in de historische data staging area, waarbij elke tabel twee extra attributen krijgt, datum_tijdstip_geldig_van en datum_tijdstip_geldig_tot, gebaseerd op datum/tijdstip op het moment van extractie (of mutatiedatumtijdstip in de bron). Het laadproces naar de historische data staging area voert dus geen transformaties, aggregaties, schoning of selecties uit. Alleen indien de bron niet relationeel is, bijv. XML of Cobol, vindt een technische vertaalslag naar relationeel formaat plaats. De historische data staging area is een exacte kopie van de brongegevens, waarbij de historie wordt vastgelegd. In de historische data staging area wordt alleen de primary key benoemd (om vast te stellen of gegevens zijn gewijzigd), maar geen foreign keys. Deze oplossing stelt derhalve minimale eisen aan de datakwaliteit. Figuur 2 toont de werking van de historische data staging area.
 

Figuur 2: De werking van de historische data staging area. Voor de leesbaarheid is het tijdstip niet opgenomen in dit voorbeeld.

Deze achterkant van het data warehouse voldoet aan alle gestelde eisen: volledige historie, een kopie van de bron zonder transformaties en bovendien is deze achterkant eenvoudig vanuit allerlei aspecten. En omdat de structuur en het proces zo eenvoudig zijn, kunnen de ETL-processen van bron naar de historische data staging area volledig gegenereerd worden. In tegenstelling tot de (Raw) Data Vault kunnen de gegevens van nieuwe bronsystemen zonder inhoudelijke kennis van de data worden toegevoegd aan de achterkant van het data warehouse. Dat is een belangrijk voordeel. Gegevens uit nieuwe bronsystemen kunnen dus met minimale inspanning in zeer korte doorlooptijd worden opgenomen in de historische data staging area. Bij het gebruik van de Raw Data Vault als achterkant van het data warehouse moet men de gegevens altijd eerst modelleren en dat vergt dus meer inspanning.

Aan de voorkant van het data warehouse is het alternatief voor de Data Vault een geïntegreerd dimensioneel datamodel waarin de gegevens op het laagste detailniveau worden vastgelegd en de resultaten van de business rules zijn verwerkt. Deze voorkant voldoet daarmee aan de doelstellingen: eenvoud en hoge (of optimale) performance. Hierbij wordt dus aangesloten op de architectuur van Kimball. Een belangrijk principe hierbij is dat bij de fysieke implementatie zo veel mogelijk wordt gestreefd naar één fysieke database zonder fysieke aggregaten om daarmee het beheer en onderhoud zo eenvoudig mogelijk te houden. Het gebruik van nieuwe technologie (appliances, column based databases, in-memory technologie etc.) maakt dit prima mogelijk, omdat hiermee gegevens zeer snel te laden en op te vragen zijn. De inzet van bijvoorbeeld een data warehouse appliance maakt het dus mogelijk de architectuur te vereenvoudigen (of eenvoudig te houden). Rick van der Lans verwoordt dit uitstekend in het artikel “The advantages of the data warehouse appliance revisited” [6].

De alternatieve architectuur bestaat derhalve uit een historische data staging area aan de achterkant en een geïntegreerd dimensioneel model aan de voorkant, zie figuur 3. Deze alternatieve architectuur wordt in de praktijk al jaren toegepast bij een groot aantal organisaties in verschillende marktsegmenten met een grote variëteit aan bronsystemen met terabytes aan data. Deze architectuur voldoet daarbij prima.
 

Figuur 3: Data warehouse-architectuur met de historische data staging area

Hierbij geldt het architectuurprincipe dat data marts (extra opslaglagen!) alleen worden geïmplementeerd indien nodig, bijvoorbeeld omdat specifieke functionaliteit of een andere datastructuur vereist is. Performance is geen reden om een data mart in te richten. Een voorbeeld is een situatie waarin data mining moet plaatsvinden o.b.v. klantgegevens. Veel data mining algoritmes vereisen dat alle relevante klantgegevens in één record beschikbaar zijn, terwijl in een dimensioneel model de aankopen, klachten, betaalgedrag en kenmerken van de klant verspreid zijn opgeslagen. In dat geval volstaat het dimensionele data warehouse dus niet en is een data mart nodig. Een ander voorbeeld zijn KPI-toepassingen. In dat geval worden Key Performance Indicatoren (meetwaarden) verzameld vanuit verschillende sterschema’s en worden deze opgeslagen in één apart KPI-sterschema. In dat geval ontstaat ook een data mart die overigens fysiek onderdeel uitmaakt van de data warehouse database.

Deze voorbeelden blijven echter uitzonderingen. Het overgrote deel van gewenste rapportages en analyses zijn direct gebaseerd op een dimensioneel model. Voor alle duidelijkheid, performance is geen valide reden meer om (geaggregeerde) data marts te maken. Met de huidige technologie is het mogelijk om grote hoeveelheden data snel te analyseren.

De conclusie is dat er een eenvoudiger alternatief is voor de Data Vault. De Data Vault als modelleringswijze biedt geen toegevoegde waarde ten opzichte van deze architectuur met het oog op de doelstellingen van de voorkant en achterkant van het data warehouse. Daarmee heeft ook de Data Vault-architectuur geen toegevoegde waarde.

De mystiek van de Data Vault ontrafeld

De theorie van de Data Vault beschrijft nog aantal andere voordelen van de Data Vault. De Data Vault lijkt daarmee welhaast magische krachten toebedeeld te krijgen. Hieronder worden deze argumenten en aanverwante onderwerpen ontrafeld en wordt daarmee aangetoond dat deze argumenten niet geldig of relevant zijn.

Eenvoudig realiseren van dimensionele data marts

Een veel gehoord argument voor de Data Vault is dat vanuit de Data Vault eenvoudig een dimensioneel model kan worden gerealiseerd (of zelfs gegenereerd). Immers, de Data Vault heeft qua structuur veel weg van een dimensioneel model. Dit argument is ontegenzeggelijk waar. Echter, dat is daarmee nog geen valide argument, want al het werk is in de voorgaande (drie) lagen uitgevoerd. De vergelijking van inspanning moet plaatsvinden over de inspanning van de complete gegevenslogistiek van bron tot en met rapport. En dan leidt de Data Vault tot meer inspanning, vanwege de extra modelleringswijze en meerdere opslaglagen.

Het principe van ‘verdeel en heers’

Dan Linstedt beschrijft dat de Data Vault is gebaseerd op het principe van divide and conquer (verdeel en heers). Het achterliggende idee is dat de gegevenslogistiek van bron naar rapport complex is en een complex probleem los je op door deze in kleinere eenheden (verschillende stappen en opslaglagen) op te delen. De verwijzing naar dit principe is terecht, daarom bestaat een data warehouse uit een voor- en achterkant. Echter, de theorie van de Data Vault geeft geen valide argumenten waarom de gegevenslogistiek van het data warehouse altijd in nog meer stappen opgedeeld moet worden. Ik vind dat alleen in specifieke situaties een extra stap en opslaglaag gerechtvaardigd is. Ofwel, wij hanteren hierbij het architectuurprincipe “Niet meer dan twee opslaglagen, tenzij er in een specifieke situatie een goede reden voor is”.

Een dimensioneel model kent ook een aantal nadelen

Een dimensioneel model heeft ook nadelen. Een voorbeeld is het redundant opslaan van gegevens. Een ander nadeel is het effect van ‘cascading change impact’ van historische hiërarchische (snowflake) dimensies. Indien een parent tabel (bijv. productgroep) verandert, dan moet deze wijziging in alle onderliggende child tabellen (bijv. product) ook worden doorgevoerd. Nog een ander nadeel is de complexiteit van het maken van berekeningen met meetwaarden uit verschillende feitentabellen. Dit zijn allemaal nadelen die niet gebagatelliseerd moeten worden. Echter, ook in de Data Vault-architectuur is er een plaats voor het dimensionele model, namelijk in de data marts. De theorie van de Data Vault suggereert dat deze problemen zijn opgelost, maar dat klopt niet. De problemen zijn alleen verschoven naar een andere plaats in de gegevenslogistiek. Dus hoe dan ook, deze uitdagingen gelden voor elke architectuur.

Daarnaast zou men nog kunnen stellen dat het dimensionele model niet volstaat als ‘centraal data warehouse’. Maar dan ontstaat er een definitiekwestie, wat is het centrale data warehouse? Dit artikel spreekt over een achterkant en een voorkant, ‘centraal’ speelt hier geen rol. Wat een rol speelt zijn de eisen aan de achterkant en voorkant en de wijze van modelleren moet aan deze eisen voldoen. De voorkant moet gegevens eenvoudig en met hoge performance beschikbaar stellen, vanuit deze eisen is het dimensionele model de beste keuze voor rapportage en analyse. En zoals hierboven toegelicht, mocht voor bepaalde functionaliteit het dimensionele model niet volstaan, dan pas wordt een data mart geïmplementeerd met een andere opslagstructuur.

Oplossing voor realtime-analyses

Veel data warehouse-omgevingen worden dagelijks geactualiseerd. Operationele analyses kunnen echter actuelere gegevens vereisen. De gegevens in de analyse-omgeving moeten zodoende vaker worden geactualiseerd, bijvoorbeeld per uur, per minuut of zelfs per split second. Deze eis heeft veelal impact op het laadmechanisme, gegevens laden via batches is vaak niet meer mogelijk. Gegevens moeten dan bijvoorbeeld realtime geladen worden vanaf een service-bus of op basis van database-triggers. Het is echter niet zo dat de ene architectuur zich beter leent voor realtime laden van gegevens dan de andere architectuur. Immers, alle architecturen hebben een data staging area waarin de gewijzigde gegevens snel kunnen worden geladen, zonder zware transformaties en afhankelijkheden tussen bronnen.

Ook bij het analyseren van realtime-gegevens zijn de genoemde architecturen niet onderscheidend. Voordat geanalyseerd kan worden, moet (praktisch gezien) altijd geïntegreerd en getransformeerd worden. Geen enkele architectuur is hierin sneller. De vraag is zelfs of de geschetste data warehouse-architecturen wel geschikt zijn voor realtime analyses. Zou de operational data store een aparte omgeving moeten zijn naast het data warehouse, waarbij de operational data store de (benodigde) gegevens snel laadt en integreert, wellicht zelfs op basis van andere technologie? De operational data store zou dan een bron voor het data warehouse zijn. Een uitgebreide analyse van de plaats en werking van de operational data store binnen de data warehouse-architectuur valt echter buiten beschouwing van dit artikel.

De Data Vault biedt flexibiliteit in de relaties (cardinality) tussen tabellen

Tussen tabellen bestaan relaties. Een eigenschap van deze relatie (link) is de cardinality, denk hierbij aan many-to-many, many-to-one (of one-to-many) of one-to-one relaties. Het modelleringsprincipe van de Data Vault is dat tussen twee entiteiten (hubs) een link-tabel wordt geplaatst. Indien de cardinaliteit in de bron tussen twee entiteiten wijzigt, heeft dit geen impact op de structuur van de Data Vault. Dit is ontegenzeggelijk een voordeel van de Data Vault, het model is vanuit dit oogpunt flexibel. Echter, hierop zijn twee nuances te maken. De historische data staging area legt geen relaties vast in het datamodel en biedt daarmee ook deze flexibiliteit. En ondanks dat dit flexibiliteit biedt in de Data Vault, moet dit probleem nog steeds aan de voorkant (in de dimensionele data marts) worden opgelost. Ook hier geldt, de theorie van de Data Vault suggereert dat deze problemen zijn opgelost, maar dat klopt niet. De problemen zijn alleen verschoven naar een andere plaats in de gegevenslogistiek. Dit probleem moet nog steeds in de (dimensionele) data marts worden opgelost en dat geldt daarom voor alle architecturen.

Deze constatering kan ook breder worden getrokken. Bronwijzigingen hebben impact, welke modelleringswijze ook wordt toegepast. De uitdaging is om deze bronwijzigingen zo eenvoudig mogelijk te kunnen verwerken. Daarbij is niet alleen het datamodel aan de achterkant belangrijk, maar nog veel meer om de gegevenslogistiek eenvoudig te houden, zodat de wijziging op zo min mogelijk plaatsen wordt doorgevoerd.

Samenvatting

De Data Vault is populair. Enerzijds is dat goed te begrijpen, de Data Vault lost een aantal problemen op van de architecturen van Kimball en Inmon. Echter, deze problemen zijn eenvoudiger (met minder inspanning en kosten) op te lossen met een historische data staging area aan de achterkant van de data warehouse-architectuur en een geïntegreerd dimensioneel model aan de voorkant van de data warehouse-architectuur. Deze alternatieve architectuur voorkomt de implementatie van een extra datamodelleringswijze (de Data Vault) en voorkomt de implementatie van extra opslaglagen die extra inspanning en kosten vergen en leiden tot een langere time-to-market.

Afsluitend

René Veldwijk heeft in een column [7] prachtig, en met treffende voorbeelden, verwoord dat op het vakgebied van database-ontwerp bepaalde ideeën tijdelijk hoogst populair kunnen zijn, maar naderhand schadelijk blijken te zijn als leidraad voor (database-)ontwerp. Hoe verder je in het verleden kijkt, hoe eenvoudiger deze ideeën te herkennen zijn en omgekeerd geldt, hoe recenter de ideeën, hoe lastiger deze te herkennen zijn. Toch kun je deze schadelijke ideeën nu al herkennen door op twee aspecten te letten: wordt er onderscheid gemaakt tussen een patch en een structurele oplossing en treedt er een mate van ideologische verblinding op waarbij courante ideeën niet meer op nuttigheid worden getoetst?

Ik adviseer dan ook de Data Vault te toetsen op basis van deze twee vragen, zodat duidelijk wordt of de Data Vault toegevoegde waarde heeft. Mijn mening laat zich eenvoudig raden. Hoe dan ook, de toekomst zal uitwijzen of de Data Vault een structurele oplossing is of een patch met te veel overhead.

Categorie:   
Auteur(s)
afbeelding van frankhabers
Frank Habers
Inergy Analytical Solutions B.V. - business developer

Drs. Frank Habers is business developer bij Inergy Analytical Solutions B.V.

 
Reacties
Martijn Evers op maandag 26 september 2011 15:32

Hoi Frank,

Helaas moet ik je wijzen op een wezenlijke fout in je hele redenatie. Een Business Data Vault is zuiver beschouwd een semantische laag en niet standaard een fysieke laag/repository/databse (kan wel, hoeft niet). In feite zijn veel data vaults opgezet met een CDW+ oftwel Business Rules (results) Vault met daarop meestal geen aparte Business Data Vault als complete semantische laag op de DV+BRRV (gemiste kans naar mijn smaak, maar strict genomen niet altijd nodig). Een Business Rule Vault hergebruikt op een eenvoudige manier de fysieke Data Vault objecten maximaal en dat kan volstrekt niet elegant met een HSA. Een BRRV is een repository met afgeleide DV objecten. Deze architectuur met een BRRV dupliceert **MINIMAAL** (nl alleen nieuwe gegevens die door de BR's gegenereerd worden) en alleen als er een functionele vraag is. Vanwege de strcutuur kun je heel makkelijk HUBS&LINKS hergebruiken. Daarom zie ik een DV arch als meer volwassen als een HSA georienteerdee architectuur zonder dat er meer lagen onstaan (waar sla jij je herbruikbare BR's auditeerbaar op in een 2 laags architectuur?)

Ronald Damhof op maandag 26 september 2011 18:35

Dit is een artikel in de trand van: 'ik ben leverancier van X en ik doe een vergelijking van X met Y. Y ken ik niet en heb ik geen ervaring mee. Wel is het mijn mening dat Y zus en zo werkt (geen referenties, geen peer review). Y is niet goed (wederom nauwelijks/geen/1 zeer selectieve referentie(s) of peer reviews) en X wel. En o ja - ik verkoop alleen X.'

Dit is geen artikel, dit is hoogstens een opinie, misschien een blogpost, maar ik denk vooral een luxe advertentie onder het masker van een vakblad. Ik verwijt met name XR magazine e.e.a.; als je als vakblad jezelf niet meer serieus neemt en enige mate van commerciële onafhankelijkheid niet nastreeft, ben je wat mij betreft gediskwalificeerd als vakblad. Bij deze dus.

Het cynische nu is dat XR magazine het volgende heeft staan in haar disclaimer bij het invoeren van comments:
'Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving'

Misschien had er duidelijk moeten staan in het artikel dat Inergy een leverancier is van X oplossingen - dat is namelijk transparant voor de lezer.

Ik heb Inergy heel hoog zitten en heb veel waardering voor hun business model en hun medewerkers, maar bovenstaand zeer gekleurd artikel doet geen enkele contributie aan ons vakgebied en aan de bestaande Body Of Knowledge (geen enkele verwijzing naar de Data Vault BOK in de referenties van dit artikel) en helpt ons dus niet verder. Laat staan de klant.

Ongetwijfeld krijg ik nu het verwijt dat ik inhoudelijk niet in ga op het artikel. Dat klopt - dat doe ik niet. Als ik moet reageren op alle advertenties van leveranciers in de data management en Business Intelligence heb ik een dagtaak. Als Inergy een review had willen hebben op dit artikel dan hadden ze het lef moeten hebben om voor publicatie een review proces in te gaan met hoor en wederhoor. Waarbij er volledige transparantie en openheid is in dit reviewproces is (eventueel zelfs naar buiten toe). Ja - dat proces heeft meer tijd nodig en past ongetwijfeld niet in de marketing campagne.....Maar had wel degelijk van waarde kunnen zijn voor ons vakgebied.

Als ik inhoudelijks toch nog iets kwijt wil, is het dat architectuurkeuzes ALTIJD afhankelijk zijn van de context van de klant. Het idee dat altijd X of altijd Y bij iedere klant past is idioot en doet geen recht aan diezelfde context, doet geen recht aan de klant.

Ronald Damhof
Onafhankelijk Adviseur in A,B,C,D,E,F, (..), X, Y, Z

Erik-Jan Koning op donderdag 29 september 2011 13:11

Ronald, ik vind je reactie niet bepaald chique.

Dit is wel degelijk een artikel. Er zitten uitgebreide uitleggen van de verschillende methodieken in, er worden referenties aangehaald, er is een duidelijke lijn en opbouw, er wordt een uitgebreide redenatie en formulering gebruikt en het standpunt van de schrijver wordt beargumenteerd neergezet. Natuurlijk is elk stuk een opinie van een schrijver, natuurlijk hoef je het niet eens te zijn met de zienswijze van de schrijver, maar dit is wel degelijk een goed artikel.

Wanneer iemand zijn best doet om op deze wijze een 9 pagina's tellend geheel (althans op mijn scherm) te schrijven, dan kun je dat niet simpel afserveren als zijnde een "luxe advertentie". Dat is te simpel en gewoon niet correct.

Ik vind dat we dit soort stukken moeten toejuichen, zeker omdat de schrijver een ander geluid durft te laten horen, althans een zienswijze heeft die niet strookt met datgene dat op dit moment hot is. Wellicht ontbreken er zaken in het artikel en wellicht worden er onjuiste redenaties gedaan, prima. Laten we dat bediscussieren, dat verdient dit artikel.

Frank, ik ga datgene dat je hebt geschreven eerst eens goed overdenken in plaats van dat ik gelijk in de pen klim om dit af te serveren.

Marius de With op maandag 26 september 2011 20:22

Beste Frank,

bedankt dat je je mening en ideeen over DWH/BI weer met ons wilt delen, want tenslotte zijn we allemaal altijd weer op zoek om DWH/BI oplossingen sneller en tegen minder kosten te realiseren. En als het met een laag minder kan: Chapeau! Maar ik vraag me het volgende af bij de door jou voorgestelde oplossing, zoals in figuur 3 ook naar voren komt. Ik kan er, met respect, niets meer van maken dan een Kimball+, met dit verschil dat er nu een historische staging achter zit om het dimensioneel model te voeden, zoals je zelf aangeeft: "Hierbij wordt dus aangesloten op de architectuur van Kimball". In figuur 3 mis ik de kleine t alsnog. Van de historische staging naar dimensioneel betekent ook wel degelijk een structuurwijziging, omdat over het algemeen de structuur van een source-system, behoorlijk afwijkt van niet alleen een DataVault, maar ook van een relationeel of dimensioneel model. En ik verwacht dat de hoofdletter T in figuur 3 er wel een is met de omvang en gewicht van een chocoladeletter: van rauwe, in historische toestanden opgeslagen, niet-geintegreerde en gecleansde data "in 1 keer" naar een nette voorkant vergt wel heel veel van je transformatie. En ja, appliances kunnen je daar deels in tegemoet komen.

Sander Robijns op maandag 26 september 2011 20:47

Beste Frank,

Aardig artikel, maar mist inderdaad toch een en ander zoals door zowel Martijn Evers als Ronald Damhof is aangehaald in hun commentaar.

Een van de zaken die ik daarin nog wil aanhalen is de volgende uitspraak die je doet in het artikel: "Daarnaast zijn virtuele data marts (database views) wellicht mogelijk in bepaalde situaties, maar de datastructuur van de Data Vault leidt tot een slechtere performance dan een dimensioneel model."

Ik mis volledig de onderbouwing waarom dit zo is. Overigens is dat niet noodzakelijk het geval, iets dat in diverse artikelen op internet reeds onderbouwd is aangegeven, zowel door Dan Linstedt, maar ook door bijvoorbeeld Johannes van den Bosch in diverse blogposts (http://johannesvdb.blogspot.com) en nog vele anderen. En dat is jammer. Ik ben zelf onafhankelijk consultant op het gebied van data warehousing en heb veel ervaring met Kimball's aanpak. Met betrekking tot Data Vault ben ik nog in een leerproces, maar met al het materiaal dat ik tot nu toe daarover heb gelezen, wordt bovenstaande uitspraak in ieder geval weerlegt, maar wel in een bepaalde context.

Nu is deze uitspraak analoog aan de volgende: "Een Ferrari is sneller dan een Lelijke Eend". Is dat zo? Op papier wel ja. En op het circuit ook. Maar als ze door een weiland rijden, durf ik dat sterk te betwijfelen. Met de juiste context had je opmerking veel meer waarde gehad.

Maar de strekking van het artikel begrijp ik volkomen. Ook ik sta momenteel nog kritisch tegenover Data Vault. Maar dat komt vooral om twee redenen:
- ik weet er nog niet genoeg van
- ik heb geen praktische ervaring ermee

Daarom ga ik, zolang ik niet meer geleerd heb en de Certified Data Vault Modeler nog niet met succes heb afgerond, altijd eerst te rade bij personen die duidelijk wel die kennis en ervaring hebben, zoals de personen eerder genoemd. Misschien had je dat ook beter gedaan. Of toch in ieder geval beter verwoord in je artikel.

Nogmaals, ik waardeer de kritische houding ten aanzien van Data Vault, maar helaas biedt het artikel niet afdoende onderbouwing om dit hard te maken.

Met vriendelijke groeten,
Sander Robijns
Zelfstandig DWH/BI consultant

Martijn Suurd op dinsdag 27 september 2011 12:23

Frank,

Ik vind, dat je nog al een eenzijdig beeld schetst, toewerkend naar een conclusie die je al in je hoofd had volgens mij. De opmerking van Rene Veldijk in de conclusie is misschien dan ook wel op jezelf van toepassing.

In je artikel zeg je dat door Data Vault er weer een extra modellerings techniek wordt geintroduceerd waar wel weer kennis van opgedaan moet worden, hetgeen volgens jou niet onderschat moet worden. Door het introduceren van een historische staging laag echter, is dit juist wel het geval. Bronsystemen kunnen een veelheid aan modelleringstechnieken(al dan niet goed toegepast) bevatten. Je kan het zo gek niet verzinnen. Door deze brontabellen in de historische staging te zetten heb je veel kennis nodig om dit te interpreteren. De transformatie naar de volgende laag blijft dan ook complex.

Deze transformatie kan mbv Data Vault ook wel complex zijn, maar de data vault standaard maakt het wat dat betreft simpel. In de hubs vind je de sleutels. In de sats alle beschrijvende data en de links bevatten de relaties tussen de hubs.

Een belangrijk kenmerk van data vault is bovendien het scheiden van sleutels en beschrijvende data. Dit biedt de mogelijkheid om attributen te verspreiden over verschillende sats. In een historische staging zal elke wijziging van een attribuut een nieuw record opleveren. Voor tabellen met veel attributen kan dit aardig gaan exploderen.

In kleine datawarehouses met een klein aantal bronsystemen kan ik me trouwens nog wel voorstellen dat een historische staging laag een goede oplossing is.

Wat dat betreft sluit ik me ook aan bij Ronald dat een architectuurkeuze afhankelijk is van de context van de klant.

met vriendelijke groeten,

Martijn Suurd
BI consultant bij Capgemini

Hennie de Nooijer op dinsdag 27 september 2011 12:44

Beste Frank,

Met interesse heb ik het eerste gedeelte met plezier gelezen en vind het een aardig overzicht van de diverse architecturen. Met de "nadelen van de datavault" begint het een beetje te kriebelen. Het lijkt wel of je het artikel in verschillende tijdsperiodes hebt geschreven want in het eerste gedeelte geef je duidelijk aan dat er in principe (waarvan afgeweken kan worden) maar 1 fysieke opslagstructuur hebt bij Datavault om vervolgens bij de nadelen aan te geven dat "er zelfs nog meer opslaglagen gesuggereerd worden (pre staging, post-Datavault, cubes, in memory, etc". Enigzins storende argumentatie. Bovenstaande is een van mijn kritiekpunten maar dit hadden er makkelijk meer kunnen zijn.

Ik vind het wel goed om kritische geluiden te horen, ook al is dit een met leveranciers specifieke bril maar ik ben bang dat ik niet vatbaar ben voor je argumenten.

Hennie de Nooijer

Evelien van Veen op dinsdag 27 september 2011 20:24

Hallo Frank,

Ziet er mooi en lean uit, maar waar beleg je in deze opzet de single point of definition in verband met complexe busiess rules? Die wil je niet voor iedere datamart opnieuw bepalen.

Evelien van Veen.

Rob Mol op dinsdag 27 september 2011 21:57

Beste Frank,

Het streven naar veenvoudiging van de opslag in data warehouses onderschrijf ik.
De meeste inspanning zit echter in het ontwikkelen van de transformaties.
Door eenmalig te transformeren naar een data vault model beschik je als het ware over een blokkendoos, waarmee je eenvoudig allerlei dimensionele modellen kunnen samenstellen. Vaak is een directe vertaling mogelijk van HUB naar dimensie en van HUB of LINK naar feit.

Dit vereist wel dat de data vault een afspiegeling is van het bedrijfsmodel en niet van de gegevensopslag in de bron. Als je de gegevensopslag in de bron vertaalt naar een datavault opslag waarbij je de tabelstructuur van de bron volgt, dan is er inderdaad niet veel toegevoegde waarde tov een historische staging.

Rob Mol

Roland Bouman op dinsdag 27 september 2011 23:17

Frank,

ik persoonlijk vond dit een helder en inzichtelijk artikel, en eerlijk gezegd ben ik nogal verbaasd door de toon en heftigheid van de vooral negatieve - commentaren.

Ik moet er uitdrukkelijk bijzeggen dat ik mijzelf niet als data warehouse architectuur expert beschouw, dus het kan zijn dat ik allerlei zaken in Frank's betoog heb gemist.
Wel heb ik alvorens dit antwoord te plaatsen mijzelf zoveel mogelijk ingelezen; ik hoop dat ik hetgeen ik ben tegengekomen goed genoeg begrepen heb om een zinvolle bijdrage te leveren aan deze thread.

Ik heb tot dusver deze lijnen van inhoudelijke kritiek kunnen ontdekken:

1) In de door Frank voorgestelde 2-laags architectuur is er geen aparte plaats voor het toepassen van de "business rules". Als ik het goed begrijp wordt hier voornamelijk mee bedoeld: de regels om tot afgeleide gegevens te komen ("transformatieregels"), zoals in het "berekening van de omzet" voorbeeld uit het artikel. Behalve over de plaats van de business rules is ook er zorg over de herbruikbaarheid van dezelfde business rules voor meerdere datamarts.

Deze kritiek wordt - als ik hem goed begrijp tenminste -, door Martijn Evers naar voren gebracht, terwijl Evelien van Veen zich afvraagt hoe dit in een 2-laags architectuur zijn beslag krijgt.

2) Er wordt de suggestie gewekt dat dit artikel eenzijdig/gekleurd is, en dat Frank zelf niet onafhankelijk en niet objectief zou zijn, omdat hij "leverancier" is van de door hem voorgestelde 2-laags architectuur (en niet van data vault).

Deze kritiek wordt Ronald Damhof, Hennie de Nooijer, en in mindere mate ook door Martijn Suurd te berde gebracht.

3) Martijn Suurd, Marius de With en Rob Mol noemen het bezwaar dat de transformatie van historische staging area naar data marts in de door Frank voorgestelde 2-laags architectuur veel complexer is dan wanneer deze via een data vault architectuur zou verlopen.

4) Martijn Suurd noemt twee nadelen van de historische staging area ten opzichte van een (raw) data vault: door de bron modellen zomaar over te nemen wordt de diversiteit aan modellerings methoden juist groter dan wanneer er eest een DV zou zijn toegepast. Daarnaast noemt hij toename van het data volume als risico, hetgeen bij een data vault ondervangen zou kunnen worden door groepen van snel en minder snelwijzigende attributen in hun eigen satellieten onder te brengen.

Voor wat betreft #1:
In het artikel staat: "...de voorkant van het data warehouse is ... een geïntegreerd dimensioneel datamodel waarin ... de resultaten van de business rules zijn verwerkt". Ik had hieruit begrepen dat de afgeleide gegevens gedurende de transformatie van de historical staging area naar de data marts worden berekend, om in de data marts te worden opgeslagen.

Als ik het goed begrijp resulteert minimale toepassing van de data vault methodologie ook in een 2-laags architectuur, bestaande uit een "Raw data vault" en een data presentatielaag bestaande uit klassieke datamarts en/of een business data vault. In de "Raw data vault" zouden dan de brongegevens alleen op business key geintegreerd worden zonder verdere transformaties. Het lijkt dus dat ook hier de toepassing van business rules in de transformatie naar de data presentatielaag toe zou moeten plaatsvinden. Kortom, voor wat betreft de plaats lijkt mij nauwelijks een verschil met een 2-laags architectuur bestaande uit historical staging area + data presentatielaag. Ook voor wat betreft de herbruikbaarheid van business rules lijken hier precies dezelfde uitdagingen te liggen als bij de door Frank voorgestelde 2-laags architectuur.

(Overigens denk ik dat het ook in deze 2-laags architecturen in de praktijk nog niet zo slecht gesteld hoeft te zijn met de kansen op herbruikbaarheid: Als het puur gaat om het herhaald toepassen van bepaalde algoritmes, dan zou je met een behoorlijk ETL product gewoon je ETL job geparameteriseerd kunnen opzetten en deze herhaald aanroepen. Anderzijds zie ik geen probleem om afgeleide data die je in de presentatielaag hebt opgeslagen in een later stadium van je ETL terug te lezen als dat betekent dat je dezelfde berekening minder vaak hoeft uit te voeren.)

Voor wat betreft #2:
Ik vind deze kritiek eerlijk gezegd een beetje flauw. Inergy is vooral leverancier van BI diensten. Als zij dat op deze manier doen, en daar success mee hebben, dan maakt dat het verhaal toch juist des te meer waardevol? Zolang de oplossing maar voldoet aan de requirements van de klant, zie ik eerlijk gezegd niet in waarom deze zich druk zou moeten maken op de wijze waarop dat gebeurt.

Misschien dat sommigen vinden dat bepaalde requirements niet of onvoldoende met de voorgestelde 2-laags architectuur kunnen worden gerealiseerd, maar in de comments heb ik dat nou niet zo snel teruggevonden.

Bij dit punt wil ik ook nog opmerken dat ik juist wel prima bronverwijzingen heb gevonden aan het einde van Franks artikel. Hij linkt zelfs door naar de learndatavault site; als dat geen referentie naar het "data vault body of knowledge" is, wat dan wel?

Voor wat betreft #3:
De redenatie van Frank lijkt hier te zijn dat toepassen van de Data Vault methodologie het werk voor de transformaties niet zozeer versimpelt, maar dat alleen de locatie en verdeling van het werk verandert. Aangezien er telkens benadrukt wordt dat er voor de Raw Data Vault alleen door "lichte integratie" op business keys plaatsvindt, is mijn (wellicht wat snelle) conclusie dat het meeste werk 'm nog steeds zit in de transformatie naar de presentatie laag toe (hetgeen in de praktijk vooral zal neerkomen op het genereren van dimensioneel gemodelleerde datamarts). Kortom, ik zie niet zo snel waarom Franks redenering hier scheef zou gaan.

Voor wat betreft #4:
Het lijkt mij dat de complexiteit van whatever modellerings methoden je in de bronsystemen vindt altijd van invloed zijn op de realisatie van de data warehouse architectuur. Ook bij data vault zul je daarmee geconfronteerd worden, alleen de plek waar je dat probleem aanvalt verschilt. Tot slot hoeft het data volume op zichzelf geen probleem te zijn indien er gebruik gemaakt wordt van een column-oriented RDBMS (of ten minste kolom compressie). En als dat data volume echt een probleem is, zou het dan niet nog meer voor de hand liggen om in plaats van een data vault gebruik te maken van anchor modeling?

vriendelijke groet van

@rolandbouman
http://rpbouman.blogspot.com/

Ronald Damhof op woensdag 28 september 2011 8:33

Wat mij erg doet fascineren is dat er velen zijn die zeggen dat dit debat religieus is - alsof je voor de een en tegen de ander bent. Wat opvallend is, is dat dit met name komt uit de hoek van mensen ‘die er niks mee te maken willen hebben’ en met een zeker dédain op zo’n debat neerkijken, maar intussen wel diezelfde spanning steeds voeden. Ook in DWH land is men aan het polariseren. Polarisatie leidt niet tot inzichten.

Als dit religieus is, dan ben ik van alle geloven of (en dat is semantisch hetzelfde) een enorme atheïst ;-)

Zoals ik in mijn comment al zei; alle architecturen hebben hun context. Een context van de klant bedoel ik daarmee en nee die context hebben wij niet. Je hoort mij dan ook niet roepen dat X > Y. Iets wat het artikel van Inergy wel doet. X >Y impliceert een kwaliteits oordeel, en dat oordeel kan alleen maar door de klant worden gegeven (Ref. Deming, Weinberg, Juran). Dat is mijn belangrijkste kritiek. En nee, dit kan niemand afdoen als ‘flauw’. Dit is de kern van vele idiote discussies die ik tegenkom.

Ik adviseer en implementeer ook HSA constructies zoals Inergy die doet, ik implementeer echter ook DV constructies, zoals Inergy volgens mij nog nooit heeft gedaan (?). Eigenlijk kun je veilig stellen dat de (inmiddels) vele Data Vault consultants allemaal komen uit de hoek van klassieke Kimball oplossingen. Zij hebben dus redelijk goed vergelijkingsmateriaal. Ook dat is kern van mijn kritiek; diegenen die erover praten en diegenen die het moeten doen - dat gat wordt zo langzamerhand gapend groot. Dat zie je ook terug in de comments en op twitter; het zijn met name de comments en de tweets van de ‘do-ers’ die zich tegen dit artikel keren en van de ‘praters’ die dat niet doen. 


Is dat dan een diskwalificatie van wat er geschreven is op die gronden? Dat zou flauw zijn, maar het brengt wel de plicht met zich mee dat er forse due diligence is verricht. En verwijzen naar learndatavault.com is dan wel erg flauw - ik verwijs ook niet naar wikipedia.com in zijn algemeenheid in mijn artikelen. Dan Linstedt heeft gewoon een boek geschreven en er zijn intussen veel artikelen in DB/M verschenen door vele auteurs. Ook zijn er inmiddels redelijjk wat internationale aktiviteiten en zijn er presentaties op slideshare. Die zie ik allemaal niet in de referenties terug. En helemaal flauw is dan dat er een referentie wordt bijgepakt van ‘iemand’ die 3 jaar geleden een blogje heeft geschreven die vol met fouten staat, maar ‘toevallig’ wel kritiek heeft op data vault......Dat komt bij mij over als ‘ik heb een stelling, en ik zoek de argumenten er bij’.

In dit kader is het misschien ook van belang uit te leggen waarom ik niet inhoudelijk reageer. Zoals ik al zei is er inmiddels een redelijke Body of Knowledge (al mag die nog veel beter worden) over Data Vault, hier niet naar refereren (en dan ontkrachten op basis van argumenten) betekent een constante herhaling van diezelfde Body of Knowledge. Dat zie ik ook veel in fora - waar een kritische erin wordt gegooid en niet meer wordt geaccepteerd als je gewoon verwijst naar de bekende referenties. Van een vak community (dit artikel is ook geschreven in een vakblad) mag je verwachten dat - als er kritiek is - je je in gaat lezen in de achtergronden of - nog beter - experimenten doet. En op basis daarvan de community verrijkt met je inzichten.

[Zo zou ik dolgraag een experiment doen hoe Data Vault kan functioneren op Netezza). En vanuit een dergelijk experiment een artikel schrijven met de bevindingen.....maar dat is een andere verhaal ;-)]

Tenslotte nog een aspect die van belang is in dit specifieke geval waar Inergy dit artikel schrijft. Inergy is een leverancier van oplossingen die geleverd worden met name in architectuur X. Die transparantie mis ik in het artikel, iets wat een ziekte aan het worden is op het Internet en in vakbladen; men schrijft X, maar vertelt er niet bij dat er een afhankelijkheid is (financieel of anders). Tegen deze achtergrond zou het Inergy hebben betaamd om de due diligence van dit artikel nog zwaarder aan te zetten. Zo had ik - als ik in hun schoenen stond - sterk overwogen om hoor en wederhoor toe te passen.

[Sidenote: Vlak voor mijn vakantie heeft Inergy mij gevraagd om te ‘discussiëren’ - wat iets anders is dan ‘reviewen’ trouwens (Inergy heeft het artikel mij nooit toegestuurd)- na mijn vakantie was echter ‘te laat’ voor Inergy. Het artikel had echter ook naar vele anderen gestuurd kunnen worden en laten reviewen - maar ja - ook dat proces kost wel veel tijd. Ook van Dan Linstedt weet ik dat hij dergelijke zaken graag van commentaar zou willen voorzien.]

Het beste wat we kunnen doen - in mijn opinie - is typologieën enigszins vergelijken op kwaliteits- en context attributen die we vaak bij klanten zien of door klanten worden gevraagd. Nogmaals, sommige kwaliteits- context attributen hoeven niet van toepassing te zijn of minder van toepassing te zijn bij een klant. Het is dus zaak een lijst te krijgen van kwaliteits- en context attributen en daar de verschillende typologieën eens naast te zetten (er zijn er trouwens nogal wat meer dan het artikel doet geloven) en te wegen. We krijgen dan geen dogma’s, geen zwart/wit, geen polarisaties, maar een spectrum aan grijstinten waar we met behulp van heuristieken respect geven aan context.

Ik blijf dan ook bij mijn standpunt dat dit artikel geen contributie is aan de verhoging van kennis.

Deze comment begon met het begrip ‘polarisatie’ en dat het niet kan leiden tot betere inzichten. Over Data Vault is inmiddels veel geschreven, maar ook het shrift heft die polarisatie niet op. We moeten praten, discussiëren en vooral leren van elkaar. Op deze manier werkt het niet.

Naar mijn stellige overtuiging kan dit alleen door de rijkste vorm van informatie overdracht; face 2 face.

Ik stel dan ook voor dat we bijeenkomsten gaan houden en elkaar uitdagen om zelf scherper te worden en het vakgebied te verrijken. Zoiets als de SQLzaterdag of hoe de Agile community dat doet.

Wie is met mij?

Peter Bais op woensdag 28 september 2011 10:07

Inhoudelijk is deze discussie, als je drie stappen achterwaarts doet om het van de juiste afstand te bekijken, niet echt interessant.

Inderdaad, de keuze voor een bepaalde architectuur afhankelijk van de context van de klant.
Nog een stapje verder: omdat er geen 100% zuivere 'DataVault' klantcontexten, of 'Inmon'- of 'Kimball' klantcontexten bestaan in de echte wereld, zul je ook bij de implementatie van een architectuur geregeld concessies doen.

Wat wel interessant is, is de dynamiek van de discussie. Hier geeft iemand die zijn mening over DataVault. Dat is mogelijk of waarschijnlijk gedaan vanuit zijn eigen invalshoek. Dat is logisch en dat kan ook eigenlijk niet anders. De antwoorden zijn vervolgens ook gegeven vanuit de eigen invalshoek van de desbetreffende schrijver.

Ja, misschien is de auteur leverancier van product X, en wordt de kritiek op product Y daardoor gedreven.
Het voorgestelde alternatief kan echter worden overgenomen zonder dat daarvoor produkt X of bijbehorende diensten moeten worden afgenomen.

Dan blijft het toch aan de aanhangers van Y om op basis van de inhoud te reageren op de auteur, anders wordt deze hele discussie tijdverspilling.

En ik? Ik vind het gezond om kritisch te blijven kijken naar welke methodologie of architectuur dan ook. Ik heb ook wel wat krtische noten bij Data Vault en het geautomatiseerd genereren van Data Vaults.

Het voorgestelde alternatief vind ik zelf wel elegant eigenlijk: Historie in het data warehouse domein opslaan in de structuur van de bron, en integreren in de volgende laag.
Dimensioneel, zoals Frank Habers zegt? Waarom niet? Ik hoor op dit punt graag waarom er in deze laag een DataVault structuur nodig is.

Ik weet ook niet of de kritiek, dat het overnemen van het datamodel van de bron leidt tot het exploderen van de opslag in de historische laag echt zo zwaar weegt. Met een goede archiveringsstrategie is dit makkelijk af te vangen.

Misschien was de boodschap beter overgekomen, als de kritiek op de DataVault methodiek wat gematigder was gehouden. De ene benadering sluit de andere namelijk niet uit. "Whatever works for you", zoals Dan Linstedt al zegt.

Frank Habers op woensdag 28 september 2011 12:47

Allereerst bedankt voor alle reacties. Gezien alle (snelle) reacties, views en tweets blijkt in ieder geval dat dit onderwerp leeft binnen ons vakgebied. Dat vind ik leuk om te zien en toont tevens aan dat we het als BI-community continue beter willen doen. Ik probeer hieronder zoveel mogelijk reactie te geven op de opmerkingen en vragen. Allereerst twee niet-inhoudelijke reacties, daarna ga ik weer snel over op de inhoud.

* Inergy is niet onafhankelijkheid, het artikel is een advertentie
Inergy verkoopt geen DWH-architecturen, we verzorgen geen DWH-architectuur-opleidingen, we zijn niet afhankelijk van DWH-architecturen. Als de data vault (DV) beter geschikt zou zijn, stappen we als Inergy vandaag nog over op de DV. Dus het artikel is geen advertentie. Het artikel is mijn/onze mening op basis van veel ervaring en onderzoek. Ja, we zijn een commerciële BI-dienstverlener, maar ik geloof dat bijna alle personen die gereageerd hebben ook commerciële BI-diensten (advies, implementatie, etc.) aanbieden. Dat is dus niet onderscheidend.

* Inergy heeft geen DV-ervaring en geen due dilligence verricht
In een aantal reacties wordt gesteld dat wij (Inergy)geen implementatie-ervaring hebben met de data vault en (als ik het goed begrijp) daarom niet een dergelijk artikel mogen schrijven. Of anders gezegd, ik ben niet voldoende zorgvuldig geweest (due dilligence). Ik ben van mening dat ik wel zorgvuldig genoeg ben geweest. Een paar wapenfeiten. Sinds 2005 heb ik mij verdiept in de data vault, ik heb de boeken, artikelen en blogs van Linstedt en anderen gelezen over dit onderwerp. In het kader van dit artikel heb ik discussies gevoerd met drie DV-architecten. Daarnaast heb ik online en telefonisch met Dan Linstedt gediscussieerd over de DV. Bovendien heb ik in 2009 een paneldiscussie over dit onderwerp georganiseerd. Tenslotte, wetenschap kan plaatsvinden op basis van observaties (ervaring!), maar ook op basis van logisch redeneren. Mijn artikel is geen wetenschap, ik wil hiermee alleen maar zeggen dat implementatie-ervaring niet noodzakelijk is. Natuurlijk is DWH-ervaring wel belangrijk en die bezitten wij zeker, wij zijn bij Inergy ook doeners i.p.v. praters. Samengevat, ik ben niet over één nacht ijs gegaan bij het schrijven van dit artikel en heb dus de benodigde zorgvuldigheid in acht genomen. Los daarvan, ik sta (oprecht) open voor nieuwe inzichten.

En dan gaan we het nu weer over de inhoud hebben, dat vind ik veel belangrijker.

* Business Data Vault is geen fysieke opslagplaats.
Martijn Evers stelt dat de Business DV geen fysieke opslagplaats is. In mijn artikel baseer ik mij op de boeken en artikelen van Dan Linstedt. In het artikel ‘defining the business data vault’ beschrijft Dan de business Data Vault als een fysieke aparte omgeving en adviseert Linstedt het gebruik van een raw data vault en een business data vault. Ik vind dus niet dat ik een fout heb gemaakt in mijn redenering. Ik hoop dat je begrijpt dat ik uitga van de boeken/artikelen van uitvinder/grondlegger Linstedt.

Echter, de opmerking van Martijn intrigeert mij wel. Ik weet het niet, maar is de verklaring hiervoor dat er verschillende stromingen zijn binnen de DV-community? Als voorbeeld, de term BRRV komt volgens mij ook niet in de boeken van Linstedt voor.

Uitgaande dat de business vault wel semantisch is, dan trek ik de conclusie dat de DV ook streeft naar een minimaal aantal lagen, wat dat betreft zijn we het eens. En dat is misschien wel de belangrijkste boodschap van mijn artikel: niet klakkeloos nieuwe opslaglagen introduceren, als je dat met DV (grotendeels) ook in twee stappen kan doen, prima! Ik maak dat echter dus niet op uit de literatuur over de DV.

* Waar sla jij je herbruikbare BR's auditeerbaar op in een 2 laags architectuur?
Business Rules zijn opgeslagen in de ETL (of ELT) van DSA naar dimensioneel model (van achterkant naar voorkant). In basis worden zodoende alle BR’s op één plek opgeslagen. Echter, ik denk dat met de vraag wordt bedoeld dat er situaties zijn waarin een BR op meerdere plekken in het dimensioneel model wordt gebruikt. In dat geval, dus niet voor die 80%, maken wij gebruik van een extra opslagplaats (intermediate laag), zodat je maar op één plek de BR’s onderhoud. Ja, inderdaad een extra opslaglaag. Hierbij geldt het architectuurprincipe: “geen extra opslagplaats, tenzij…”. Het nuanceverschil, maar wel belangrijk: niet per definitie een extra opslagplaats.

* Beheersbaarheid van de chocoladeletter ‘T’
Allereerst een correctie van mijn kant: in figuur 3 bedoel ik de grote T inderdaad structuurwijzingen EN transformaties (daarom noem ik dat de grote T). @Marius, bedankt voor je oplettendheid, ik zal dit laten corrigeren in het artikel.

Dan de inhoudelijk reactie: ik vind dat Marius een mooie omschrijving geeft van de grote T: ‘een met de omvang en gewicht van een chocoladeletter’. Ik kan mij deze perceptie geheel voorstellen, het lijkt een te grote en complexe stap die ten koste gaat van onderhoudbaarheid en beheerbaarheid. Ik hoop dat ik in paar zinnen kan uitleggen hoe ik hier tegenaan kijk:
Mijn ervaring is dat grofweg 80% van de ETL-processen van HDA naar dimensioneel model vrij eenvoudig zijn: een tabel selecteren, wellicht een paar joins naar andere tabellen, paar berekeningen op attribuutniveau, vervolgens historie-afhandeling en klaar is kees. Ik vind dus dat je voor die 80% ook in minimaal aantal stappen richting dimensioneel model moet gaan, houd het simpel.
Dan houden we de overige 20% nog over, dat zijn inderdaad complexe ETL-processen. De grote T houden wij op twee manieren onderhoudbaar en beheersbaar. Enerzijds standaardiseren en genereren we, zodat bijv. tijdstrookintegratie en historieafhandeling eenvoudig en beheersbaar blijven. Dat is (ook) niets uniek, juist de DV-community is actief met genereren bezig. Dat kan ik alleen maar toejuichen en ik kijk daarom uit naar de datavault automation congres van volgende week. Anderzijds lossen we dit op door een tussenstap te nemen indien het te complex wordt. Het moet beheersbaar blijven. Ja, dus extra opslag, maar dus wederom gebaseerd op het architectuurprincipe: Geen extra opslagplaats, tenzij.

* Eigenlijk beschrijf je een Kimball+ architectuur
Dat is het ook, ik pretendeer ook helemaal niet een unieke architectuur te bieden. Met het artikel wil ik aantonen dat de kracht in de eenvoud zit.

* Waarom leidt het DV-datamodel tot slechtere performance dan een dimensioneel model?
Sander constateert terecht dat ik in mijn artikel niet onderbouw dat de performance van een DV-datamodel slechter is dan een dimensioneel model. @Sander, ook jij bedankt voor je oplettendheid. Ik zal dat alsnog aanpassen.

De onderbouwing van de stelling is eenvoudig: De DV leidt tot meer tabellen (vanwege de satellites) en dus meer joins dan een dimensioneel model. In het algemeen kun je stellen dat joins de performance nadelig beïnvloeden. Zeker v.w.b. de vereiste joins tussen grote tabellen, bijv. een link (bijv. miljarden kassabonregels) met de bijbehorende satellites (hetzelfde aantal records met daarin de prijs en aantal van een kassabon). Impliciet bevestigt Linstedt dit nadeel ook door de introductie van specifieke tabellen voor performance, zogenaamde Query assistance tables (zie blz 140 van het boek ‘supercharge your data warehouse’ van Dan Linstedt).

Natuurlijk staat de technologie niet stil en zijn er situaties te bedenken dat dat joins niet nadelig voor de performance zijn. Indien iemand kan bewijzen dat joins ‘onder de streep’ wel bevorderlijk zijn voor de performance, dan hoor ik dat graag. Ik geloof niet dat dit het geval is.

* De HDA is juist complexer dan de DV
Gesteld wordt dat in bronsystemen op verschillende manieren wordt gemodelleerd en dat je dus met onze architectuur juist méér modelleringskennis nodig hebt. Ik ben het eens dat bronsystemen op verschillende manieren worden gemodelleerd. Maar ongeacht de architectuur zal je het bronmodel moeten doorgronden en extraheren, met of zonder data vault. Ergens moet je die pijn pakken. Dus de gevolgtrekking deel ik niet.

* De HDA leidt tot extra opslag
Martijn Suurd merkt terecht op dat een HDA tot meer opslag kan leiden dan in een data vault. Ik heb overwogen om dit nadeel te beschrijven. Ik heb dat echter niet gedaan, omdat ik het nadeel een detail vind en dat zou ten koste gaan van de kern van het betoog. Mede omdat ik dan ook de nadelen van de DV-modelleringswijze van zou moeten gaan benoemen. Een voorbeeld van zo’n nadeel: Satellites kunnen worden opgedeeld per bronsysteem, per wijzigingsfrequentie, per classificatie of per type (H6. ‘supercharge your DWH’ van Dan Linstedt). Hoe kom je tot die keuze die bovendien strijdig kunnen zijn? En wat doe je als je kiest voor het criterium ‘wijzigingsfrequentie’ en deze wijzigingsfrequentie wijzigt in de tijd? Dan moet je de satellites gaan herindelen, een intensief proces (zie paragraaf 6.10 en 6.11). Voor alle duidelijkheid, dit is maar een voorbeeld, ook dit voorbeeld vind ik niet tot de kern van mijn betoog behoren.

* De keuze voor DWH-architectuur is context-gedreven
De keuze voor een BI-oplossing vind óók ik context-gedreven. Soms adviseer ik klanten helemaal geen DWH te implementeren, wellicht volstaat een BI-tool op de bron of volstaat een virtueel DWH. Daar zijn we het over eens. Echter, ik zou niet weten wat de criteria zijn wanneer wél de data vault in te zetten. Maar ik zeg niet dat ik de absolute waarheid in pacht heb, het artikel is wat betreft inderdaad een mening, maar wel een onderbouwde mening. Ik ben erg benieuwd wat de criteria zijn voor de keuze van een bepaalde architectuur en welke argumenten daarvoor gelden. Ik heb daarover in de literatuur, blogs, artikelen nog niet een constructief verhaal gelezen. @Ronald, gezien je opmerking dat je een architectuur-atheïst bent ;), wellicht kan jij die handschoen oppakken? Dat zou ik super vinden!

In een interessante reactie verwijst Peter naar de uitspraak van Dan Linstedt: "Whatever works for you". Ook in mijn telefonische contact met Dan zegt hij: “Als je geen problemen ondervindt met jouw architectuur, dan moet je geen DV gebruiken”. Dat vind ik echter een te makkelijk antwoord. Architectuurkeuzes maak je vooraf, dus moet je ook vooraf de voor- en nadelen kunnen afwegen. Nogmaals, ik ben erg benieuwd hoe deze beslisboom voor de keuze van de juiste DWH-architectuur eruit gaat zien.

Martijn Suurd op woensdag 28 september 2011 14:59

Frank,

Een interessante discussie is er gaande en hoe meer reacties hoe meer we het eens zijn volgens mij.

Dus daarom nog maar even een inhoudelijke reactie op je reactie:

Je zegt: "Ongeacht de architectuur zul je bronmodel moeten doorgronden en extraheren". Hier ben ik het helemaal mee eens. En aangezien je dit toch moet doen waarom zou je het resultaat van dit analyse en denkwerk niet expliciet maken door je data meteen in een data vault te gieten. In de opdrachten die ik gedaan heb vind ik data vault juist een goed hulpmiddel om je bronsysteem te doorgronden. Bovendien behoudt je nog steeds alle detail en is alle data traceable.
Hoe groter je omgeving wordt en hoe meer mensen er mee werken hoe meer er mijns inziens de behoefte is aan een enterprise data warehouse met een standaard modelleerwijze die als databron dient voor de verschillende gebruikersgroepen.

groeten,

Martijn Suurd

Peter Bais op donderdag 29 september 2011 15:06

"... In de opdrachten die ik gedaan heb vind ik data vault juist een goed hulpmiddel om je bronsysteem te doorgronden ...".

In zijn reactie op Franks argumenten draagt Dan Linstedt dit ook aan als een van de sterke eigenschappen van DataVault.

Daar valt wel wat over te zeggen:
DataVault is een modelleer-methodiek. Het doorgronden van een bronsysteem (hetgeen normaal gesproken volgt op een inventarisatie van business requirements) is een activiteit die valt onder informatie-analyse. Ik denk zelf dat het prettiger is om die activiteit uit te voeren zonder hinder van alle modelleringsvereisten, en de resultaten vast te leggen in een logisch (ER) gegevensmodel zonder meteen te moeten denken aan HUBs, LINKs en SATs.
Vervolgens kan het logische model worden uitgewerkt naar een DataVault model. Dat is even zweten - of je laat dit doen door een tool (bv Quipu, maar er zijn er meer).

En oh ja, ik ben zeker wel een (kritisch) voorstander van de toepassing van DataVault - op het juiste moment en op de juiste plek.

Sander Robijns op donderdag 29 september 2011 16:30

Beste Peter,

Data Vault is meer dan alleen een modelleringstechniek. Het is ook een methodologie, iets wat Dan toch vrij duidelijk maakt. Kimball's aanpak is ook meer dan alleen dimensioneel modelleren.

Als je echter de modellering onder de knie hebt, denk ik dat een Data Vault model ook best geschikt is om een logisch model mee te beschrijven, maar misschien heb ik het daarin mis. Het belangrijkste is dat alle stakeholders het model snappen.

Of tools als quipu ideaal zijn om je Data Vault model (dus niet de ETL) te laten genereren, heb ik zo mijn twijfels over, maar daar hoor ik ongetwijfeld meer over op de Data Vault Automation conference op 6 oktober.

Peter de Leeuw van Weenen op vrijdag 30 september 2011 17:39

Hoi Peter,

Helemaal eens!

Inplaats van ERD grijp graag naar UML om het logische of conceptuele model in te modelleren. Dat is denk ik omdat ik daar goed in thuis ben en dat ik het rijk vind aan uitdrukkingsmogelijkheden. De soort relatie en de cardinaliteit wordt hierin gedocumenteerd.

Het logische gegevensmodel in UML zet ik daarna makkelijk om in het technische Datavalault model (als het een datavault wordt).

Henk Scholten op maandag 3 oktober 2011 16:15

Met interesse en enige verbazing heb ik het artikel en deze discussie gelezen. Uiteindelijk heb ik besloten om te reageren. In de eerste plaats valt het me moeilijk om alle verschillende elementen te combineren. De inhoud van het artikel is technisch, maar er worden ook normatieve sociologische beweringen gedaan. Het is tegen een specifieke architectuur en presenteert een eigen architectuur.

Het sociologische aspect komt op mij vooral over als een variant op het thema conspiracy theory waarbij in dit geval een ‘DV-community’ de klant bedreigt. Verder wil ik dit graag buiten beschouwing laten. Het positioneren van een eigen architectuur (of toch ook weer niet?) tegenover een bepaalde andere architectuur, in dit geval de Data Vault, in plaats van het te positioneren te midden van alle beschikbare architecturen of als aanvulling op bepaalde architecturen, wil ik zoveel mogelijk buiten beschouwing laten.

Waar ik op in wil gaan is dat naar mijn mening de essentie van Data Vault niet voldoende wordt gezien. Alhoewel de reacties van o.a. Martijn Evers, Rob Mol, Martijn Suurd, Peter Bais ook in deze richting gaan, wil het volgende benadrukken.

Er vindt wel degelijk een belangrijke en grote transformatie en integratie van de data plaats op weg van bron naar de Data Vault, namelijk een semantische transformatie en integratie. De data uit de verschillende bronsystemen wordt in lijn gebracht met de zogenaamde business keys. Verder worden bij een Data Vault de relaties tussen de domein-objecten nadrukkelijk vastgelegd en van attributen voorzien. In het artikel wordt gesteld dat de foreign keys weg worden gelaten en dat dan alles simpel is, dat zal wel. Maar de relaties in een Data Vault hebben in principe niets met de relaties van database objecten, keys of foreign keys uit te staan. In de praktijk zal een relatie tussen business objecten natuurlijk zijn afbeelding vinden in relaties in de database, maar daar gaat het niet om.

Het artikel begint met te stellen dat o.a. metadata en ongestructureerde data buiten beschouwing worden gelaten. En in de aanvulling/reactie van 28 september wordt gesteld dat 80% van al het werk (of wordt bedoeld van alle code?) gaat zitten in simpele transformaties. Natuurlijk kan je nooit iemand anders zijn ervaring betwisten, maar de vraag doemt op of we het over hetzelfde werk hebben. Het ook buiten beschouwing laten van big data doet vermoeden dat dit niet het geval is. Maar hoe dan ook, als metadata juist niet buiten beschouwing wordt gelaten ontstaat een heel andere waardering voor de Data Vault en de belangrijke positie in de ‘big chocolate T’. In het artikel en de reactie wordt simpelweg gedaan alsof de architectuur geen invloed op de big T heeft, een fatalisme dat ik niet deel. In het gepresenteerde model zit de big T tussen achterkant en voorkant, daarbij verder niet geholpen door de structuren. De semantische transformatie van de Data Vault maakt het vullen van de Data Marts veel eenvoudiger en ook transparanter voor de gebruikers, dan wanneer een 1:1 kopie als bron moet dienen.

Het hele gedoe over de extra lagen en het wijzen naar wat de guru zelf heeft gezegd, gezegd zou hebben, of toch ook weer niet heeft gezegd, draagt wat mij betreft niet bij aan het vinden van de beste architectuur. Dat ik conceptueel ook een tweelaags architectuur onderschrijf mag blijken uit de door mij geschreven artikelen die vorig jaar in DB/M zijn gepubliceerd. Maar hoe dat in de praktijk wordt ingevuld zal de situatie moeten bepalen.

Wat de query-efficiency betreft is het zeer waarschijnlijk dat Data Vault binnen korte tijd in het voordeel zal zijn ten opzichte van klassieke tabel gebaseerde architecturen. Bijvoorbeeld het werk dat aan de Systems Group van de ETH Zurich wordt gedaan met betrekking tot het toepassen van field programmable array gebaseerde co-processoren, o.a. voor het versnellen van joins is zeer relevant. Zoek op: Avalanche ETH Zurich. Het recent door IBM gekochte Netezza is maar een voorbeeld van wat er nu al mogelijk is en van wat ons nog te wachten staat. Dan Linstedt heeft kortgeleden aan goed artikel over dit onderwerp gepubliceerd. Het AIDA project van Amdocs-Franz technologies, waarbij de Allegrograph RDF triple store als DW wordt ingezet, gaat nog verder. Ook dan is DV als concpet nog steeds heel bruikbaar.

Het is naar mijn mening zo dat de Data Vault visie door het centraal stellen van een semantische transformatie van bron-data naar het business domein, waarbij de auditability niet in het gedrang komt, staat als een huis en wel degelijk zowel specifiek is als een meerwaarde heeft. Het beweerde nadeel van de vele lagen komt op mij gezocht over en de nadelen van de architectuur voor wat betreft performance zal binnenkort een voordeel blijken te zijn. Nog steeds is het natuurlijk zo dat niet elke klant die om BI vraagt, met een Data Vault is geholpen. Voor een simpel rapportage systeem met relatief weinig data en waarbij maar een paar en eenvoudige transformaties nodig zijn is het waarschijnlijk te veel van het goede.

Voor de duidelijkheid; ik ben gecertificeerd Data Vault specialist.

Groeten,
Henk Scholten

Dan Linstedt op dinsdag 4 oktober 2011 18:10

Let me just point out a few things:

1) the business data vault is a concept, not a physical layer - so the architecture that Frank points out is flat-out-wrong. Incorrect.
2) Claiming there is "no value" to the Data Vault model is also incorrect - see my blog post for corrective statements on this.
3) The claims about performance here are completely unjustified - there are no numbers listed to back this opinion up, there is no "bake-off" by an independently judged panel to test performance and to publicly state which is better or worse. Furthermore, there are no statements about hardware/software/os/database engine, etc... on which to compare performance or to generate numbers from
4) the comparative analysis in this article switches from comparing the Data Vault (with raw data) to an HSDA - to comparing the Data Vault with raw data to a business driven data mart. Well? Which is it? What comparison do you really want to make? By the way, comparing it to business driven conformed dimensional models is not possible, the Data Vault model (as I've defined it) does not contain business driven data. For a comparison to a RAW populated conformed dimensional model, you need to see my numerous blog entries on the subject. For a comparison to the HSDA, you need to see my rebuttal to the arguments that you have put forward.
5) If you are quoting Dejan Sarka, you really need to check your sources - he's got zero interest, and zero clue about the Data Vault. Please check my posting on Dejan Sarka for more information.
7) To understand the nature of simplicity and complexity, you would be better served by studying and referencing the mathematical formulas that attempt to measure such metrics. The Data Vault is NOT more complex than any other model simply because it has more tables. Again, see my blog post on normalization and denormalization and performance of joins for more information. To simply claim the DV is more complex because it has more tables is an argument that holds no water.

Finally, to attack something that a) you have no need for, b) you've admitted openly you've never built c) you have no certification on is simply blatant misrepresentation. You've openly declared that you don't see the value, and that you don't feel the pain. You've openly declared that you've never dealt with "large systems" or even medium sized systems (or any system at 50TB or more). You've openly told me that you don't cross lines of business with your solution.

Again, I say: until you run in to these situations, or you feel these pains, you will not understand the benefits of the Data Vault.

Furthermore: if what you have is working for you, then don't fix it...

Respectfully,
Dan Linstedt

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.