In een eerdere blog introduceerde ik het het 6 lagen model van Malcolm Chisholm. In deze blog gaan we dieper in op de waarde van dit model voor ons vak, data warehousing en business intelligence.
Sterschema's
Een belangrijk onderdeel van het vakgebied is traditioneel het sterschema. Gegevens worden onderverdeeld in feiten (dingen die je wilt meten) en dimensies (de assen waarlangs je wilt analyseren).
In bijvoorbeeld dit sales sterschema zijn de verkopen onze feiten, en de dimensies zijn Klant, Product, Winkel en Status. Land is hier 'ge-snowflaked', dat wil zeggen dat deze niet rechtstreeks aan de feitentabel verbonden is maar via Klant.
Hoe helpt het 6 lagen model ons nu?
Om te beginnen kunnen we data uit het 6 lagen model plotten op het sterschema. Reference Data bevindt zich meestal in flakes (zoals Land), soms in (kleine) dimensies, zoals Status in bovenstaand voorbeeld. Enterprise Structure Data en Transaction Structure Data bevindt zich in de dimensie tabellen. De informatie in feitentabellen komt bijna altijd uit Transaction Activity Data, een enkele keer uit Transaction Audit Data.
Het is dus mogelijk om een sterschema te ontwerpen, enkel door naar de data te kijken en deze in te delen in het 6 lagen model. Daarnaast kunnen we uit de positie van de gegevens in het 6 lagen model afleiden welke ontwerp aandachtspunten we mogen verwachten in de opzet van een datawarehouse.
Metadata
De eerste laag uit het model is de metadata. Normaal gesproken is deze info te vinden in de catalog van het RDBMS: in SQL Server bijvoorbeeld in de system views sysobjects en syscolumns. Ook foreign key constraints horen in deze categorie.
Het belang hiervan is denk ik voor BI-er evident, al was het maar omdat, als je hier geen aandacht aan besteedt, je ETL-proces niet loopt. Je krijgt een tekst-string nou eenmaal niet zomaar in een datum-veld gepropt... Vanuit het oogpunt van datawarehousing geldt dus vooral dat je met deze metadata rekening moet houden als je data naar je datawarehouse overbrengt. Hierbij geldt grofweg dat je datawarehouse de ruimste definitie vanuit je bronapplicaties zal bevatten. Als een omschrijving voor kleur in de eerste bron 10 karakters lang kan zijn en in de tweede 50 karakters, dan zul je je datawarehouse uitgaan van 50 karakters.
In het zeldzame geval dat een bronsysteem nog door de database afgedwongen foreign key constraints bevat, zul je deze daar achterlaten en niet meenemen naar je datawarehouse; dit voorkomt een hoop ellende met volgordes in je laadproces. Bovendien is het de vraag of een volgend bronsysteem diezelfde constraints kent.
Goed omgaan met bron metadata is dus vooral een technische aangelegenheid, en meer zullen we er hier niet over zeggen. In BI land kennen we echter nog twee soorten metadata: de lineage en de definitie.
Met de lineage bedoelen we 'waar komt dit veld vandaan': uit welk(e) kolom(men) uit welk bronsysteem is dit veld afkomstig en welke berekening lag er eventueel aan ten grondslag? Met de definitie bedoelen we de 'business definitie' van het veld. Denk bijvoorbeeld aan de tabel Klant: wanneer is iets of iemand volgens de organisatie een klant? Deze definitie kan zowel op een tabel als een kolom betrekking hebben.
Reference data
Reference data omvat de code-waarde tabellen in een systeem. Denk aan geslacht, status, dat soort codes. Het gaat om kleine tabelletjes, met weinig records. Gelukkig maar, zo zullen we zien...
In klassiek gemodelleerde databases is een groot deel van de tabellen van dit type. Ze zien er meestal ongeveer zo uit:
Om de database overzichtelijk te houden worden deze code-waarde paren tegenwoordig vaak in een enkele tabel samengevoegd, ongeveer als volgt:
Voor de betekenis van de data maakt dit uiteraard niets uit. Over reference data kunnen we oeverloos discussieren - en dat is misschien ook wel verstandig. De hoeveelheid betekenis die een enkel rijtje in een tabel kan hebben mogen we niet onderschatten. Ik heb in de praktijk meegemaakt dat er op CxO niveau verwarring ontstond over wanneer een polis nou eigenlijk actief was: was dat zolang er geld op binnenkwam of zolang er risico op gelopen werd? Is een geschorste polis nog actief? En dit ging dan alleen nog maar over een 0 en een 1 in de kolom Actief...
Komen we nu terug op metadata van het type definitie, dan zien we dat een definitie op kolom niveau niet meer voldoet. Ieder record in een reference data tabel heeft misschien wel zijn eigen uitleg nodig. Aangezien de meeste tabellen in deze categorie een beperkt aantal records bevat en deze statisch zijn, kan het dan ook lonen om (bepaalde) reference data tabellen uit te breiden met een extra kolom:
Een ander aspect aan deze reference data is dat deze vaak in veel verschillende bronsystemen voorkomt, waarbij (met name bij ingekochte systemen) de gebruikte waarde gedicteerd wordt door het systeem. Met andere woorden: een landcode is in het ene systeem NL, terwijl het in een ander systeem NED is - en dit kun je niet wijzigen. Zolang het gaat over een ordersysteem en een CRM systeem is dat nog niet zo'n bezwaar: we wijzen een van de systemen aan als leidend en laten de waarde uit het andere systeem voor wat het is. Zodra het echter gaat om twee naast elkaar draaiende ordersystemen (bijvoorbeeld van dochterbedrijven) wordt dit lastiger. Klanten uit het ene systeem komen niet voor in het andere systeem...
Ook hier kunnen we gelukkig ons voordeel doen met de statische aard en de geringe omvang van deze categorie data. Hier (en waarschijnlijk alleen hier) kunnen we ons namelijk veroorloven om vertaaltabellen aan te leggen, ongeveer als volgt:
Deze vertaaltabellen zijn dusdanig statisch dat het beheer ervan prima bij de business (een afdeling Controlling schiet mij te binnen) neergelegd kan worden - zolang het daadwerkelijk reference data is!
De moraal van vandaag moge duidelijk zijn: Dont't underestimate the importance of reference data.
In een volgend blog gaan we in op laag 3 en 4: Enterprise Structure Data en Transaction Structure Data.
![Bart Linders](https://www.ensior.com/images/employees/Portret/bart-linders-portret.png)