Wat is een stermodel in Power BI?
Een stermodel is een manier om analytische gegevens te organiseren rondom een centrale feitentabel en daaromheen gekoppelde dimensietabellen. De feitentabel bevat meetbare gebeurtenissen, bijvoorbeeld verkoopregels, facturen of urenregistraties. Dimensietabellen beschrijven de kenmerken waarmee deze feiten worden gegroepeerd en gefilterd, zoals product, klant, datum en regio. In een eenvoudig diagram lijken de relaties op de punten van een ster.
Het voordeel van deze opzet is niet de tekening, maar het heldere onderscheid tussen wat wordt gemeten en waarover wordt gerapporteerd. Wanneer een verkoopregel een bedrag van 250 euro bevat, is dat een feit. Het product waartoe de regel behoort en de regio van de klant zijn dimensiekenmerken. Door dit onderscheid consequent vast te leggen, worden DAX-measures, filtering en onderhoud begrijpelijker.
Eerst de korrel van de feitentabel vastleggen
De korrel beschrijft precies wat één rij in een feitentabel vertegenwoordigt. Bij FactVerkoop kan één rij een orderregel zijn, niet een volledige bestelling of een totaal per dag. Dat klinkt vanzelfsprekend, maar in de praktijk worden datasets vaak samengesteld uit exports met verschillende detailniveaus. Als een totaalregel naast individuele orderregels wordt meegenomen, kan omzet dubbel worden geteld.
Een modelleur schrijft daarom eerst een zin op: ‘Elke rij in FactVerkoop beschrijft één verkochte productregel op één order.’ Daarmee wordt duidelijk welke sleutels nodig zijn en hoe bedragen mogen worden geaggregeerd. Een andere analyse, bijvoorbeeld voorraadstanden aan het einde van iedere dag, vraagt een andere korrel en mogelijk andere rekenregels. Een voorraadstand mag niet zonder meer over alle dagen worden opgeteld.
Het verschil tussen feiten en dimensies
FactVerkoop bevat bijvoorbeeld OrderregelID, ProductID, KlantID, DatumID, Aantal en Nettobedrag. DimProduct bevat voor iedere ProductID de productnaam, categorie en artikelgroep. DimKlant bevat kenmerken van klanten. DimDatum bevat opeenvolgende datums en eigenschappen als maand, kwartaal en jaar. Dimensies geven betekenis aan de sleutels in de feitentabel.
De dimensiezijde van een gewone één-op-veelrelatie hoort voor de gekozen sleutel unieke waarden te bevatten. Als DimProduct twee regels met dezelfde ProductID heeft, is niet meer vanzelfsprekend welke rij het juiste filter vormt. Een meervoudige sleutel kan soms een teken zijn dat de dimensie op een verkeerd detailniveau is ingericht. Controle op sleutels is daarom een fundamenteel onderdeel van de modelvoorbereiding.
Relaties en filterrichting
In een gebruikelijk stermodel loopt filtering van de dimensie naar de feitentabel. Een selectie van de categorie ‘Kantoorartikelen’ in DimProduct beperkt dan de betrokken verkoopregels in FactVerkoop. Wanneer meerdere dimensies dezelfde feitentabel filteren, kan Power BI een omzetbedrag berekenen voor bijvoorbeeld Kantoorartikelen in Regio Noord gedurende het derde kwartaal.
Het is verleidelijk om overal bidirectionele filtering toe te staan, omdat sommige visuals dan onmiddellijk het gewenste lijken te doen. Maar dubbele filterpaden en onduidelijke relatie-routes kunnen juist verrassende resultaten geven. Maak de modelstructuur daarom zo eenvoudig mogelijk. Als een situatie om bidirectionele filtering vraagt, moet worden aangetoond waarom dat nodig is en welke gevolgfilters optreden.
Measures gebruiken voor zakelijke berekeningen
In Power BI wordt de omzet vaak als measure gedefinieerd, bijvoorbeeld Omzet = SUM(FactVerkoop[Nettobedrag]). Deze measure wordt beoordeeld binnen de actuele filtercontext. Een slicer voor Jaar 2026 selecteert andere verkoopregels dan een slicer voor Jaar 2025. De measure hoeft daarom niet voor iedere productgroep als afzonderlijke formule te worden opgeslagen.
Measures vormen de plek om bedrijfsdefinities te beheren. Een netto-omzetmeasure kan andere regels vragen dan een brutoverkoopmeasure. Als retouren apart worden geregistreerd, moet worden vastgelegd hoe die in de berekening meetellen. Zonder deze afspraken gebruiken verschillende rapporten mogelijk dezelfde naam voor een ander begrip. Dat is een inhoudelijk probleem dat niet wordt opgelost door alleen de relatiepijlen te wijzigen.
Praktijkvoorbeeld: omzetanalyse bij een groothandel
Een groothandel heeft drie exports: orderregels, producten en klanten. In het oude rapport wordt alles samengevoegd tot één brede tabel. Productnamen en klantsegmenten worden daardoor duizenden keren herhaald. Wanneer een product van categorie verandert, verschijnen soms verschillende categorieën voor dezelfde code. Het team wil omzet per maand, productgroep en klantsegment analyseren.
De BI-ontwikkelaar begint met één schone feitentabel, waarbij een rij één orderregel representeert. Daarna worden DimProduct en DimKlant ingericht met unieke sleutels. Een datumdimensie beschrijft het volledige analysevenster. De relaties verbinden de dimensies met de feitentabel. Vervolgens wordt één centrale omzetmeasure gemaakt en wordt de betekenis van retouren vastgelegd.
De eerste controle vergelijkt het totaalbedrag uit FactVerkoop met het gezaghebbende brontotaal. Daarna wordt één productcategorie gefilterd en worden de onderliggende orderregels steekproefsgewijs gecontroleerd. Vervolgens wordt een klantsegment geselecteerd. De BI-ontwikkelaar controleert dat dezelfde orderregel niet dubbel meetelt wanneer kenmerken uit twee dimensies tegelijk worden gebruikt. Pas daarna worden dashboards gebouwd.
Datakwaliteit vóór modellering
Een stermodel maakt een slechte gegevensbron niet vanzelf betrouwbaar. ProductID kan in het ene bestand tekst en in het andere bestand getal zijn. Klantcodes kunnen leidende nullen bevatten. Als een factregel geen passende dimensiesleutel heeft, kan deze in rapportages onder een onbekende categorie terechtkomen of verwarrende resultaten veroorzaken. Daarom verdient gegevensvoorbereiding in Power Query of de bronlaag voldoende aandacht.
Controleer op ontbrekende sleutels, dubbele dimensiewaarden en datums buiten het verwachte bereik. Leg vast of onbekende waarden moeten worden afgewezen of als afzonderlijke categorie zichtbaar blijven. Een stilzwijgende verwijdering van fouten kan het financiële totaal veranderen. De correctieprocedure moet daarom ook voor de bedrijfseigenaar begrijpelijk zijn.
De rol van een datumdimensie
Een datumdimensie ondersteunt rapportages waarin tijdvakken consequent worden gedefinieerd. Naast de datum kunnen kalenderjaar, maandnummer, kwartaal en eventueel boekjaar worden vastgelegd. Een aaneengesloten datumreeks is belangrijk wanneer geavanceerde time-intelligenceberekeningen worden gebruikt. Daarmee kunnen onder voorwaarden vergelijkingen met voorgaande jaren en cumulatieve perioden worden uitgevoerd.
Een maandnaam zonder jaartal is onvoldoende voor analyses over meerdere jaren. Januari 2025 en januari 2026 zouden dan onbedoeld worden samengevoegd. Ook moet het verschil tussen kalenderjaar en boekjaar expliciet zijn. Een organisatie met een gebroken boekjaar kan andere vergelijkingen nodig hebben dan een standaardkalender. De datumdimensie legt zulke afspraken op één plaats vast.
Wanneer zijn meerdere feitentabellen nodig?
Een organisatie kan omzet, voorraad en budget in één rapportageomgeving willen combineren. Deze gegevens hebben niet noodzakelijk dezelfde korrel. Omzet bestaat uit transacties; voorraad kan een periodieke momentopname zijn; budget is mogelijk per maand en afdeling beschikbaar. Ze zonder onderscheid in één grote tabel plaatsen veroorzaakt herhaling en lastige berekeningen.
Een beter ontwerp gebruikt waar passend afzonderlijke feitentabellen en gedeelde, eenduidige dimensies. Dezelfde DimDatum en DimProduct kunnen afhankelijk van de situatie meerdere feiten beschrijven. Daarbij moet worden gecontroleerd of alle sleutels en tijdsdefinities echt overeenkomen. Niet iedere dimensie past bij iedere feitentabel. Een verkeerde gemeenschappelijke relatie kan nog steeds misleidende filters opleveren.
Een veelvoorkomend probleem: veel-op-veelrelaties
Soms bevat een sleutel aan beide kanten van een relatie meerdere keren dezelfde waarde. Power BI ondersteunt meerdere relatiepatronen, maar een onbedoelde veel-op-veelrelatie is vaak een signaal dat het datamodel onvoldoende is afgebakend. Bijvoorbeeld: een klant kan bij meerdere accountmanagers horen en een accountmanager heeft meerdere klanten. Deze relatie kan een brugtabel of een expliciet zakelijk model vereisen.
Het is onverstandig een waarschuwing weg te werken door willekeurig de filterrichting of cardinaliteit aan te passen. Bepaal eerst welke entiteit de gegevens vertegenwoordigt en of een koppeltabel nodig is. Test daarna met enkele klanten waarvan de verwachte uitkomst bekend is. Alleen zo wordt zichtbaar of de relatie de zakelijke betekenis correct representeert.
Beveiliging en row-level security
Een stermodel kan bijdragen aan overzichtelijke filterlogica voor row-level security, maar beveiligingsregels vragen een afzonderlijk ontwerp. Als regiomanagers alleen hun eigen verkopen mogen bekijken, moet worden onderzocht hoe de regio aan de feitentabel gekoppeld is en of dezelfde beperking via andere rapporten en modellen standhoudt. Het verbergen van een visual is geen beveiligingsmaatregel.
Gebruik testaccounts met de rechten van echte eindgebruikers. Controleer niet alleen het standaardrapport, maar ook mogelijke andere toegangspaden, exports en gedeelde semantische modellen. Rollen moeten aansluiten op organisatorische verantwoordelijkheden en worden herzien bij functiewijzigingen.
Controleplan voor een nieuw stermodel
Een acceptatiecontrole bevat minstens het brontotaal, het aantal factregels, de uniciteit van dimensiesleutels en de werking van filters. Maak een klein testoverzicht met bekende productcodes, klantsegmenten en datums. Controleer hoe de maat zich gedraagt als een filter wordt toegevoegd, verwijderd of gecombineerd met een tweede dimensie.
Let vooral op totalen die plausibel lijken maar een verkeerde betekenis hebben. Een nette grafiek kan verkeerde bedragen laten zien wanneer dubbele relaties bestaan. Bewaar daarom één gevalideerde controlequery of rapportagetabel naast het semantische model. Herhaal de test na schemawijzigingen of een nieuwe dimensie.
AI, Copilot en de juiste cursus
AI en Copilot kunnen helpen bij het verkennen van DAX-formules en modelvragen, maar een gegenereerd voorstel kan de korrel of filtercontext verkeerd begrijpen. De inhoudelijke controle van relaties, sleutels en measures blijft essentieel. De waarde van AI is groter wanneer het datamodel begrijpelijk en goed gedocumenteerd is.
Voor verdieping is een Power BI-training over datamodellering en DAX passender dan een algemene Copilot-training. Een AI-training kan aanvullend zijn wanneer generatieve hulpmiddelen bewust in het analyseproces worden gebruikt. Bekijk de cursus Power BI Gevorderd →
Conclusie
Een stermodel brengt structuur aan door gebeurtenissen en beschrijvende kenmerken van elkaar te scheiden. Dat maakt rapportages onderhoudbaarder en helpt gebruikers om dezelfde bedrijfsdefinities te gebruiken. De kwaliteit hangt vooral af van de korrel van de feitentabel, unieke dimensiesleutels, juiste relaties en controleerbare measures. Een kleine gevalideerde dataset laat snel zien of het model de gewenste betekenis heeft voordat er uitgebreide dashboards op worden gebouwd.