Goede datamodelleringspraktijken zijn erg belangrijk voor het bouwen van Power BI‑rapporten die zijn geoptimaliseerd voor prestaties en kunnen schalen wanneer dat nodig is.
Deze tutorial gebruikt een voorbeelddataset van Microsoft, aangepast aan de best practices voor datamodellering die we in dit artikel bespreken. Je kunt de dataset hier downloaden.
Wat is datamodellering?
Datamodellering is het proces van het maken van visuele weergaven van de verbanden tussen datastructuren, met informatie over de individuele attributen binnen die datastructuren.
Als we het in het algemeen over datamodellering hebben, hoor je het vaakst de term stermodel. Dit is een breed toegepaste aanpak voor het ontwerpen van datawarehouses en relationele databases, en is ook de aanbevolen aanpak in Power BI.
Er zijn twee belangrijke voordelen van een stermodel:
- Gebruiksgemak: Een stermodel maakt je datamodel schoner en overzichtelijker, en je rapport wordt makkelijker te gebruiken.
- Prestaties: Stermodellen laten je rapport eenvoudig opschalen naar zeer grote datavolumes. DAX‑measures worden ook sneller berekend en het Power BI‑rapport vernieuwt in het algemeen sneller.
Hoe werkt een stermodel?
Een stermodel bestaat uit een centrale feittabel met meerdere dimensietabellen die van deze feittabel aftakken, vergelijkbaar met de vorm van een ster. Idealiter is het goede praktijk om slechts één feittabel in een datamodel te hebben. Het is echter mogelijk om meerdere feittabellen in Power BI op te nemen.
Power BI‑stermodel. Afbeelding door auteur
Een feittabel bestaat uit waarden die kunnen worden samengevat en geaggregeerd, plus een of meer sleutels die naar de dimensietabellen verwijzen. Het doel van de sleutel is om verbindingen tussen tabellen te maken. Als je complexe datamodellen of grote datavolumes hebt, is het aan te raden de sleutels numeriek te maken in plaats van tekst, omdat dit de prestaties van het model kan verbeteren.
Feittabellen moeten smal zijn en zo weinig mogelijk kolommen bevatten. Kolommen die kenmerken van een dataset beschrijven, zoals Productnaam of Productcategorie, moeten uit de feittabel worden gehaald (als dat niet al in het datawarehouse is gebeurd) en naar hun respectieve dimensietabellen worden verplaatst. Dit proces heet normalisatie van de data en heeft als doel herhaling te vermijden.
Dimensietabellen beschrijven de kenmerken van de dataset, waarbij kenmerken logisch worden gegroepeerd in afzonderlijke tabellen om te voorkomen dat één tabel opzwelt of het lastig wordt om relaties te maken. De dimensietabellen moeten unieke waarden bevatten voor de kenmerken die ze beschrijven, en hun kolommen zorgen voor het filteren of groeperen van de data in het Power BI‑rapport.
Een uitbreiding op het stermodel is het sneeuwvlokschema. In deze aanpak worden dimensietabellen verder onderverdeeld als een kenmerk nog categorieën of subcategorieën heeft. In ons geval hebben we een Products‑tabel met Product‑ID, Productnaam en Productcategorie. In een sneeuwvlokschema bevat deze Products‑tabel alleen de Product‑ID en de Productnaam, terwijl de Productcategorie verder wordt opgesplitst in een eigen tabel met een Productcategorie‑ID en Productcategorie.
Power BI‑sneeuwvlokschema. Afbeelding door auteur
Het gebruik van een sneeuwvlokschema kan echter onnodig de complexiteit van je datamodel vergroten; deze extra tabellen kunnen de prestaties verminderen en het maken van relaties lastig en verwarrend maken.
Relaties maken in Power BI
Er zijn twee manieren om een relatie in Power BI te maken:
- Selecteer een veld uit de ene tabel en sleep het naar het veld in de tweede tabel waarmee je de relatie wilt vormen.
- Selecteer Manage Relationships op het lint en kies "New" om een relatie toe te voegen via hetzelfde venster dat we zo bespreken (maar dan leeg).
Standaard probeert Power BI een relatie tussen tabellen af te leiden; dat gaat niet altijd goed, dus je kunt deze functie uitschakelen in de instellingen of automatisch gemaakte relaties verwijderen. Om de relatie te bewerken, klik je met de rechtermuisknop op de verbindingslijn en kies je "Properties".
Dit venster heeft twee interessante opties bij het definiëren van een relatie: kardinaliteit en kruislifilterrichting. De keuzes voor deze opties kunnen grote impact hebben op het uiteindelijke rapport, dus kies zorgvuldig. Laten we beide opties doornemen.
Relaties maken in Power BI. Afbeelding door auteur
Kardinaliteit
Er zijn vier keuzes voor kardinaliteit: many‑to‑one, one‑to‑one, one‑to‑many of many‑to‑many.
Bij het maken van relaties is het aan te raden dat het koppelveld in minstens één van de tabellen unieke waarden bevat. Hierdoor kun je in je datamodel de opties one‑to‑many of many‑to‑one gebruiken.
In onze data hebben we een relatie tussen de tabel Financials en de tabel Products via het veld Product‑ID. De tabel Products heeft unieke waarden voor het productveld (elk product komt maar één keer voor). De tabel Financials kan elk product echter meerdere keren bevatten per datum, land, segment, enzovoort.
De optie many‑to‑many is het meest problematisch; hoewel die in complexe modellen erg nuttig kan zijn, moet je deze alleen selecteren als je de gevolgen van zo’n relatie volledig begrijpt.
Om te laten zien waar many‑to‑many‑relaties problemen kunnen geven, maken we in het datamodel een jaarlijkse Sales Target‑tabel per productcategorie. We moeten verkoopcijfers en deze targets naast elkaar kunnen rapporteren in dezelfde visual. Dit kan door een many‑to‑many‑relatie te maken tussen de Sales Target‑tabel en de Product‑tabel.
Many‑to‑many‑relaties in Power BI. Afbeelding door auteur
In de onderstaande tabelvisual zie je onze verkoopwaarden en de targets naast elkaar voor elke productcategorie.
Productcategorie, verkoop en bedrag. Afbeelding door auteur
Als we deze tabel echter op productniveau zouden bekijken, zouden de waarden voor de target volledig onjuist zijn. Dit komt door verschillende granulariteitsniveaus in de data; omdat er alleen verkoopdoelen op het niveau van productcategorie zijn, kan Power BI deze targets niet redelijkerwijs op productniveau tonen en worden de targets daarom simpelweg gedupliceerd voor elk product binnen de productcategorie. Als je niet wist dat dit een gevolg kan zijn van een many‑to‑many‑relatie, kan dat zeer problematisch zijn voor bedrijfsrapportages.
Productcategorie, verkoop en bedrag. Afbeelding door auteur
Richting
De optie voor kruislifilterrichting biedt de keuze tussen single of both. Relaties lopen van de tabel met unieke waarden naar de tabel met meerdere waarden. In ons geval loopt de relatie van de tabel Products naar de tabel Financials. Dit betekent dat als de kruislifilterrichting op single staat, de tabel Financials kan worden gefilterd met de velden product en productcategorie in de tabel Products. De tabel Products kan echter niet worden gefilterd met het product‑ID‑veld in de tabel Financials of met een ander kenmerk uit andere dimensietabellen.
Single direction wordt in de meeste gevallen aanbevolen. Bi‑directionele relaties (de optie ‘both’) verlagen niet alleen de prestaties van het model, maar kunnen ook ambiguïteit introduceren bij het filteren van de data.
Neem in ons geval de relaties tussen de tabellen Product, Countries en Financials. Het zijn beide enkelvoudige one‑to‑many‑relaties. Dit betekent dat het filteren van het rapport op land niet automatisch ook de tabel Product filtert. Ter illustratie, bekijk de slicers hieronder. Als je een land selecteert (zoals de VS), past de productslicer zich niet aan naar alleen de producten die relevant zijn voor dat land.
Slicers in Power BI. Afbeelding door auteur
Door de relatie tussen de tabel Products en de tabel Financials te wijzigen naar bi‑directioneel, kunnen we het filter laten doorstromen naar de tabel Products. In dit geval zien we dat het product Carretera niet in de productslicer verschijnt, omdat er geen verkopen zijn voor dat product in de Verenigde Staten van Amerika.
Slicers in Power BI. Afbeelding door auteur
Als alternatief, om bi‑directionele relaties te vermijden, kun je een filter toevoegen aan de slicer‑visual om items die leeg zijn uit te sluiten. Let wel: dit moet je doen voor elke visual die velden uit verschillende dimensietabellen gebruikt.
Filters en slicers in Power BI. Afbeelding door auteur
Je Power BI‑model optimaliseren
De belangrijkste factor bij het optimaliseren van je Power BI‑model is het toepassen van goede datamodelleringspraktijken, zoals in deze tutorial beschreven. Vaker wel dan niet kan een goed datamodel er in z’n eentje voor zorgen dat een Power BI‑rapport opschaalt naar miljoenen en miljarden rijen, terwijl het toch een degelijk prestatieniveau behoudt.
Er zijn daarnaast nog een paar dingen die je kunt doen om je Power BI‑model te optimaliseren, bovenop goede datamodelleringspraktijken, zoals:
- Tijdintelligentie uitschakelen – Deze functie in Power BI maakt automatisch datum/tijd‑hiërarchieën aan telkens wanneer een datumveld aan een visual wordt toegevoegd. Elke keer dat zo’n hiërarchie wordt gemaakt, wordt in feite een extra tabel aan het datamodel toegevoegd. Zoals je je kunt voorstellen kan dit het Power BI‑rapport flink laten opzwellen, waardoor visuals trager renderen en de ververstijd toeneemt. Het is een goed idee om deze functie uit te schakelen en in plaats daarvan één speciale datatabel te gebruiken voor alle datum/tijd‑hiërarchieën.
- Alleen de kolommen laden die je echt nodig hebt – Gebruik de Power Query‑editor om kolommen te verwijderen die je niet nodig hebt of niet gebruikt in je rapport. Een van de meest voorkomende velden die vaak ‘voor de zekerheid’ behouden blijft, is een Row ID‑veld. Dit veld is uniek voor je dataset, bijvoorbeeld een Order‑ID voor elke transactie in een Orders‑tabel. Vaak wordt dit ID‑veld ook als tekst opgeslagen, wat het model nog verder laat opzwellen. Als het ID‑veld niet expliciet in een relatie wordt gebruikt, is het meestal niet nodig om het in je model te laden.
- Alleen de rijen laden die je nodig hebt – Trap niet in de valkuil om te denken dat je al je bedrijfsdata in je Power BI‑rapport moet importeren. Zeker als je bedrijf al lang bestaat, kan dit betekenen dat je rapport veel data bevat waar niemand echt naar kijkt. De sleutel is om met de zakelijke gebruikers van het rapport te praten en precies te achterhalen hoeveel historische data ze willen zien. Als ze oudere data nodig hebben, overweeg dan om daarvan alleen een samengevatte versie te importeren in plaats van elke afzonderlijke transactie.
