Een datamodel volgens de praktijk

1. Het normaliseren van tabellen

Normalisatie

Normaliseren is een methode voor het organiseren van gegevens in een relationele database. Stel: Een tabel heeft een kolom met (unieke) waarden, bijvoorbeeld de kolomproductsleutel. Elke productsleutel heeft zijn omschrijvende waarden in bijbehorende kolommen, zoals bijvoorbeeld kleur, grootte en categorie. Alle data in één tabel kan voor onoverzichtelijkheid en overtollige data zorgen.

Het modificeren en/of splitsen van een tabel zodat deze alleen sleutelkolommen overhoudt en hierdoor de omschrijvende waarden als nieuwe tabellen aan het model toevoegen heet normaliseren. Overtollige data is hierbij geminimaliseerd en het semantic-model zal overzichtelijker en makkelijker te begrijpen zijn.

3. Het leggen van relaties

In het proces van normalisatie worden grote gedenormaliseerde tabellen opgeknipt in meerdere kleinere tabellen. Er ontstaat een splitsing tussen feitentabel en dimensietabel. Ze communiceren met elkaar door relaties. Om relaties goed te kunnen begrijpen, kan onderscheid worden gemaakt in twee onderdelen: kardinaliteit en filterrichting.

Kardinaliteit

Met kardinaliteit wordt bedoeld: het aantal waarden in een tabel dat kan matchen met het aantal waarden in een andere tabel. In Power BI-begrippen zijn de volgende kardinaliteiten te onderscheiden:

Veel-op-één (*:1)

Veel-op-één betekent dat in de veel-kolom (feitentabel) een waarde meerdere keren kan voorkomen. In de één-kolom (vaak de dimensie) komt de waarde maar één keer voor. Dit is de meest voorkomende relatie en zal de beste prestaties opleveren. Power BI hoeft immers maar één waarde op te zoeken en matchen. Deze relatie wordt in beginsel altijd geadviseerd.

Één-op-één (1:1)

Één-op-één betekent dat in de veel-kolom (feitentabel) een waarde maar één keer voorkomt. In de één kolom (vaak de dimensie) komt de waarde ook maar één keer voor. Deze relatie komt zelden voor en áls ze voorkomt, kun je je afvragen of normalisering echt nodig is. Het toevoegen van een extra datatabel kost immers ook opslag.

Veel-op-Veel (*:*)

Veel-op-Veel betekent dat in de veel-kolom (feitentabel) een waarde meerdere voorkomt. In de één kolom ( vaak de dimensie ) komt de waarde ook meerdere keer voor. Al valt deze vorm van relatie niet altijd te voorkomen, wordt aangeraden ze waar mogelijk te vermijden. Bij deze vorm van relatie zal Power BI alles met alles vergelijken en hierdoor het aantal query’s op de achtergrond vermenigvuldigen. Deze relatie kan voor prestatieproblemen zorgen.

Als deze relatie niet valt te vermijden, omwille van vereisten en data, probeer dan een tussentabel te creëren. Een tussentabel is een tabel met unieke waarden die tussen de feitentabel en de dimensietabel staat. De tussentabel heeft een veel-op-één relatie met filter richting – beide met de dimensie abel en een veel-op-één relatie met de filterrichting – single met de feitentabel.

Filterrichting

Een relatie verbindt twee tabellen met elkaar. Door deze relatie kunnen ze met elkaar communiceren. Met filterrichting kan men bepalen of deze communicatie vanuit een tabel komt of vanuit beide tabellen. Filterrichting kun je wel vergeleken met een deur. Op basis van de richting wordt bepaald welke tabel door de deur mag om te kunnen communiceren.

Single

Met de filterrichting ‘single’ staat de deur open voor de één-kolom ( vaak de dimensie). Dit betekent dat de veel-kolom (de feitentabel) niet kan communiceren met de één-kolom (vaak de dimensie). In deze situatie hebben andere dimensietabellen, die ook de feitentabel beïnvloeden, geen invloed op de huidige dimensietabel.

Beide-relatie

Met een beide-relatie kan zowel de veel-kolom (feitentabel) als de één-kolom (dimensietabel) met elkaar communiceren. Er wordt geadviseerd om deze vorm van relatie zoveel mogelijk te vermijden.

In een ster-, sneeuwvlok- of stervlokmodel wordt een feitentabel beïnvloed door meerdere dimensietabellen. Als de optie om de feitentabel met de dimensietabel te laten communiceren openstaat, ontstaat de kans dat andere dimensietabellen via de feitentabel de huidige dimensie tabel zal beïnvloeden. Op zijn beurt kan de huidige dimensietabel ook de feitentabel beïnvloeden en hierdoor wordt de kans op onduidelijke of foutieve data ernstig vergroot.

De uitzondering waarin een filterrichting ‘beide’ kan worden gebruikt, is als een van de twee tabellen, betroken in de relatie, geen andere relaties heeft of gaat krijgen. Of in het geval van het gebruik van een tussentabel waarbij de tussentabel zowel een beide-directie heeft met de feitentabel als een single-directie met de dimensie. De tussentabel kan niet communiceren met de dimensietabel en hierdoor eindigt de invloed van de beide-relatie.

Single met filterrichting

In het geval van een veel-op-veel relatie ontbreekt het Power BI aan unieke waarden. In dit geval zal Power BI automatisch voor een beide-relatie kiezen. In dit geval kan handmatig worden gekozen voor de filterrichting. Hier kan worden aangegeven welke tabel mag communiceren met de andere tabel. In het geval van veel-op-veel relaties wordt altijd aangeraden om de filterrichting te bepalen om beide-relaties te voorkomen.

4. De definitie van de architectuur van het semantic model in ster, sneeuwvlok of combinatie

In het proces van normalisatie worden grote gedenormaliseerde tabellen opgeknipt in meerdere kleinere tabellen. De mate van normaliseren, bepaalt uiteindelijk de architectuur van het semantic-model.  

In relatie tot Power BI herkennen we drie model-architecturen. Het stermodel, het snowflakemodel en het stervlokmodel. Elk model heeft zijn eigen voor- en nadelen en is sterk afhankelijk van de mate waarin normalisatie mogelijk is.

Stermodel

In het stermodel is de feitentabel genormaliseerd en zijn de dimensietabellen gedenormaliseerd. Deze feitentabel heeft een relatie met verschillende dimensietabellen, vaak via de relatie één-op-veel. In tegenstelling tot een snowflakemodel staan de dimensietabellen los van elkaar. Zij hebben dus geen relatie met elkaar.

De voordelen van een stermodel zijn:

Ontwerp:

• Het stermodel heeft een simpel en makkelijk te begrijpen ontwerp.

Query:

• Een snelle prestatie wegens de veel-op-één relaties.

Data:

• Geschikt voor grote hoeveelheden data.

De nadelen van een ster model zijn:

Overtollige data:

• De dimensietabellen in een stermodel zijn vaak gedenormaliseerd. Dit betekent dat de dimensietabellen in een stermodel zijn overtollige data opslaat in zijn dimensietabellen. Dit kan bij een groot datamodel onoverzichtelijk zijn.

Geen complexe relaties:

• Het sterschema heeft een beperkt vermogen om complexe relaties tussen feit en dimensie weer te geven.

Snowflakemodel

Een snowflakemodel is bijna volledig genormaliseerd. Alle overtollige data (inclusief de overtollige data in dimensietabellen) zijn verspreid over meerdere dimensietabellen. In tegenstelling tot een stermodel kunnen de dimensietabellen in een snowflakemodel wel een relatie met elkaar hebben.

De voordelen van een snowflakemodel zijn:

Overtollige data:

• Een genormaliseerde datastructuur vermindert de overtollige gegevens.

Complexe relaties:

• Maakt complexere relaties tussen gegevens mogelijk.

Zoekopdrachten:

• Goed voor meer gestructureerde, voorspelbare zoekopdrachten.

De nadelen van een snowflakemodel zijn:

Ontwerp:

• De complexere datastructuur kan moeilijker te begrijpen en gebruiken zijn.

Query:

• Meerdere relaties tussen tabellen kunnen resulteren in langzamere queryprestaties.
   

Opslag:

• Vereist meer opslag vanwege het grotere aantal tabellen.

Starflakemodel

Een starflakemodel is een combinatie van een stermodel en een snowflakemodel. In een starflakemodel zijn maar een aantal dimensietabellen gedenormaliseerd. Een starflakemodel probeert de voordelen van stermodel en snowflake te combineren.