Dimensionaal datamodel

De implementatie van een Data Warehouse heeft tot gevolg dat er vanuit een technisch standpunt anders moet nagedacht worden. De architectuur van de database is zo onderhevig aan de concrete behoeften van de business, dat een nieuw datamodel ontstaat: het dimensionaal datamodel.

Dimensionaal

Met de integratie van de data warehouse ontstond een volledig nieuwe manier van denken. Het principe van relationele datamodelering, wat de algemene regel is bij OLTP, bleek niet te voldoen voor analytische evaluaties. Een nieuwe vorm van datamodel ontstond, het dimensionaal datamodel. Het behoort niet tot de scope van dit artikel om een gedetailleerde technische uitleg te verschaffen met betrekking tot de bouw van een data warehouse. Om echter toch de hoofdidee van data warehousing voor ogen te kunnen houden en omdat de indeling van een dergelijke structuur in sterke mate afwijkt van deze binnen een transactionele omgeving, zal er kort ingegaan worden op de algemene principes.

De basisidee achter een dimensionaal datamodel berust in de benadering van de gegevens, die zich niet louter uit in een groepering van detailgegevens, maar waarbij vertrokken wordt vanuit het standpunt van de attributen. Die attributen kregen de toepasselijke benaming dimensies. De dimensionale benadering heeft enkele heel specifieke technische gevolgen. Zo wordt het principe van de master-detail modellering, die op elke relationele database een standaardmodelering is, verdrongen door een samensmelting van gegevens in functie van het laagste niveau. De gegevens van de master worden binnen een data warehouse beschouwd als informatieve attributen van de detailgegevens.

Van relationeel to dimensionaal

Figuur 1 toont hoe de OLTP tabellen met factuurheaders en factuurdetaillijnen van een boekhoudpakket samengesmolten worden tot een globale factuurtabel. We veronderstellen voor de leesbaarheid even dat er geen ODS bestaat en dat de data warehouse rechtstreeks opgeladen wordt vanuit het OLTP systeem.

Fact tabellen en dimensietabellen

Een dergelijke versmelting heeft natuurlijk aanzienlijke gevolgen. Indien er bij de overzetting geen groepering gebeurt, zal de nieuwe tabel hetzelfde niveau van detail bevatten als dat van de detailtabel op het OLTP systeem. Bijgevolg zullen alle gegevens van de master herhaald worden in elk record van de detailtabel. Een dergelijke tabelstructuur wordt een fact tabel genoemd. Heel rudimentair kunnen we stellen dat een fact tabel de tabel is die de cijferinformatie bevat waarop gerapporteerd zal worden. Ze zal benaderd worden vanuit het perspectief van de zogenaamde dimensietabellen.

Zoals vermeld is een dimensie het standpunt van waaruit gerapporteerd wordt. Een voorbeeld van een dimensie is het klantnummer in de bovenstaande illustratie. Behalve een uniek nummer binnen de onderneming heeft een klant natuurlijk nog andere attributen. We denken aan het adres, een of meerdere telefoonnummers, contactpersonen, etc. Nu is het onbegonnen werk om al deze gegevens binnen de fact tabel te gaan opnemen. Een dergelijke tabel zal –afhankelijk van de grootte van de onderneming – honderdduizenden tot miljoenen records bevatten. Aangezien een klant op elk ogenblik van domicilie of van telefoonnummer kan veranderen, of gecontacteerd kan worden via andere contactpersonen, is het een onmogelijke opdracht om deze gegevens telkens bij te werken op het niveau van elke factuurlijn. Vandaar dat men de klantdetails zal afzonderen in een aparte tabel, een dimensietabel. Via een technische sleutel die in de data warehouse bijgehouden wordt, zal deze tabel binnen het dimensionale datamodel gekoppeld worden aan de fact tabel. Om een dergelijke koppeling mogelijk te maken dient de fact tabel vanzelfsprekend diezelfde technische sleutel te bevatten. Vandaar dat deze bij het aanmaken van elk record in de fact tabel opgezocht zal worden in de dimensietabel. Deze techniek wordt een lookup genoemd.

Figuur 2 illustreert de eerder vermelde principes. We merken dat het klantnummer dat we eerder in de fact tabel aantroffen vervangen werd door een technisch sequentieveld. De eigenlijke klantgegevens, inclusief het klantnummer, bevinden zich in een nieuwe dimensietabel. Naast de klantentabel werden ter illustratie ook enkele gelijkaardige dimensietabellen in het model opgenomen, met betrekking tot productcodes en business units.

Snowflaking

Wanneer een dimensietabel binnen hetzelfde model gekoppeld wordt aan een andere dimensietabel, bijvoorbeeld wanneer een klant meerdere telefoonnummers kan hebben en men deze niet als aparte velden wenst te voorzien binnen de klantentabel, dan zal een zogenaamd sneeuwvlokkenmodel – of snowflaking model – ontstaan. Snowflaking is heel interessant voor het genereren van performante queries, maar brengt een gevaarlijk risico met zich mee. Het aanspreken van een dimensietabel via de fact tabel dient in principe te resulteren in 1 record per gevonden dimensie. In het geval van snowflaking zal de link tussen de fact tabel en bijvoorbeeld de klantentabel waar naartoe gerefereerd werd wel slechts 1 record teruggeven, maar de extra join met de tabel die de telefoonnummers bevat zal leiden tot meerdere records. En wanneer we in gedachten nemen dat de fact tabel de cijferinformatie bevat, zullen hierdoor onherroepelijk dubbeltellingen ontstaan. Er dient dus heel gericht mee omgegaan te worden. Een vorm van snowflaking waarbij de extra dimensietabel een 1 op 1 relatie heeft met de principiële dimensietabel vormt geen probleem, al zijn de situaties waar de behoefte ontstaat aan een dergelijke structuur zeldzaam.

Voor elke dimensie waarvan de attributen veel wijzigingen kunnen ondergaan, fast changing dimensions of key dimensions genoemd, zal er dus een dimensietabel aangemaakt worden. De toepassing van deze techniek resulteert in de creatie van een stervormig schema, vandaar dat het dimensionale datamodel vaak eenvoudigweg het sterschema of star model genoemd wordt.

Sommige dimensies, zoals in bovenstaand voorbeeld het factuurnummer of de factuurdatum, zullen slechts sporadisch of zelfs nooit een wijziging ondergaan. Dergelijke dimensies, die de naam slow changing dimensions of degenerate dimensions kregen, blijven deel uitmaken van de fact tabel. Eventuele wijzigingen van deze dimensies zullen een bijwerking van de fact gegevens met zich meebrengen, een proces dat zoveel mogelijk te vermijden is. De keuze tussen het al dan niet degenereren van dimensies is dus een belangrijk gegeven bij de bouw van een data warehouse.