Sterschema of platte tabel: waarom uw datamodel belangrijker is dan uw dashboard

Laatst bijgewerkt op 4 augustus 2026

Bij een sterschema staan de gebeurtenissen die u wilt meten in feitentabellen, zoals verkopen, boekingen, voorraadbewegingen of productieorders. De invalshoeken waarmee u die gebeurtenissen analyseert, staan in afzonderlijke dimensietabellen, zoals klanten, producten, vestigingen en periodes. Een platte tabel kan voor een kleine en overzichtelijke analyse prima volstaan. Zodra een rapport regelmatig wordt gebruikt, meerdere onderwerpen combineert of verder moet groeien, biedt een sterschema doorgaans een stevigere basis.

Sterschema of platte tabel: van ERP-export naar onbeheersbaar rapport

Veel Power BI-rapporten beginnen met één brede export of query uit het ERP-systeem. Elke orderlijn bevat naast aantallen en bedragen ook de klantnaam, productgroep, verkoper, vestiging en andere beschrijvende gegevens. U bouwt er een eerste rapport op, de cijfers kloppen en de directie krijgt snel het gevraagde inzicht.

Daarna groeit het rapport. Er komen budgetcijfers bij, voorraadgegevens, een tweede vestiging en een aangepaste margeberekening. Nieuwe measures moeten rekening houden met uitzonderingen en gegevens die op een ander detailniveau beschikbaar zijn. De verversing duurt langer en een wijziging in één onderdeel heeft onverwachte gevolgen elders.

Het probleem zit dan niet noodzakelijk in het dashboard of in één verkeerde formule. Vaak is de oorspronkelijke gegevensstructuur niet langer geschikt voor wat het rapport intussen moet doen. Wat voor de eerste analyse efficiënt was, wordt bij verdere uitbreiding een beperking.

Wat is een sterschema?

Een sterschema scheidt twee soorten informatie die in een platte tabel door elkaar staan.

Feitentabellen bevatten wat er gebeurt: orderlijnen, facturen, boekingen, voorraadbewegingen of productieorders. Ze bestaan meestal uit veel rijen en bevatten vooral bedragen, aantallen, datums en sleutels naar andere tabellen.

Dimensietabellen bevatten de kenmerken waarmee u die gebeurtenissen analyseert. Denk aan klanten, producten, verkopers, vestigingen en periodes. Ze bevatten doorgaans minder rijen, maar meer beschrijvende informatie.

De dimensietabellen worden verbonden met één of meer feitentabellen. In een schematische voorstelling staat de feitentabel centraal en liggen de dimensies errond. Dat verklaart de naam sterschema.

Die structuur sluit goed aan bij de manier waarop Power BI gegevens filtert, groepeert en berekent. Niet toevallig is het sterschema het door Microsoft Learn aanbevolen modelontwerp voor Power BI. Een selectie van een klant, productgroep of periode filtert de relevante transacties in de feitentabel. Daardoor worden relaties duidelijker en blijven measures meestal eenvoudiger en beter voorspelbaar.

Het voordeel wordt nog groter wanneer verschillende onderwerpen samenkomen. Verkoop, budget en voorraad kunnen elk een afzonderlijke feitentabel vormen, terwijl ze dezelfde product-, klant- en kalendertabellen gebruiken. Werkelijke verkoop naast budget per productgroep en maand wordt dan een logische analyse, zonder dat alle gegevens eerst kunstmatig naar één detailniveau moeten worden gebracht.

Waarom een platte tabel aanvankelijk aantrekkelijk is

Een platte tabel is snel opgebouwd. U hebt één query, hoeft weinig relaties te beheren en kunt meteen met de visualisaties beginnen. Voor een eerste, afgebakende analyse is dat vaak een rationele keuze.

De beperkingen worden pas zichtbaar wanneer het model groeit. Ze doen zich vooral voor bij verschillende detailniveaus, toenemende omvang en complexere bedrijfslogica.

Verschillende detailniveaus veroorzaken foutgevoelige berekeningen

Een platte tabel vertrekt doorgaans van één detailniveau. Dat kan bijvoorbeeld één rij per orderlijn zijn. Niet alle informatie uit een bedrijf is echter op datzelfde niveau beschikbaar.

Staat een transportkost één keer per order geregistreerd, maar wordt ze bij elke orderlijn herhaald, dan mag u die kolom niet zonder meer optellen. Een order met drie lijnen zou de transportkost anders drie keer meetellen. Het rapport blijft een geloofwaardig getal tonen, maar het totaal is verkeerd.

Hetzelfde probleem ontstaat wanneer u een maandbudget per productgroep wilt vergelijken met dagelijkse verkopen per artikel en orderlijn. Beide gegevens hebben een ander detailniveau. Ze in één platte tabel samenbrengen vraagt al snel om verdelingen, duplicaten of andere technische constructies die moeilijk te controleren zijn.

Een sterschema lost niet elke berekening automatisch op, maar maakt het verschil in detailniveau zichtbaar. Verkoop en budget krijgen elk hun eigen feitentabel en worden via gedeelde dimensies met elkaar vergeleken. Daardoor blijft duidelijk welke cijfers rechtstreeks uit de bron komen en welke berekeningen of verdeelsleutels nodig zijn.

Een afzonderlijke kalendertabel speelt daarbij een belangrijke rol. Ze zorgt ervoor dat boekjaren, maanden, weken en vergelijkingen met vorige periodes overal op dezelfde manier worden toegepast. Power BI biedt ook automatische datumfunctionaliteit, maar voor rapporten die structureel worden gebruikt, geeft een expliciete kalender meer controle en transparantie.

Een breed model kan onnodig zwaar worden

In een platte tabel worden klantnamen, adressen, productomschrijvingen en andere kenmerken bij iedere transactie herhaald. Power BI kan zulke herhaling gedeeltelijk efficiënt comprimeren, waardoor een platte tabel niet automatisch traag is. Toch kan een zeer brede tabel met veel unieke tekstwaarden meer geheugen vragen en langer verversen.

In een sterschema staan beschrijvende gegevens één keer in een dimensietabel. De grote feitentabel bevat vooral sleutels en meetwaarden. Dat kan het model compacter maken en zorgt er vooral voor dat filters en groeperingen op een overzichtelijke manier worden toegepast.

De prestaties van een rapport hangen daarnaast af van de kwaliteit van de measures, het aantal visualisaties, de opslagmodus, de databron en de gebruikte interacties. Een sterschema is dus geen garantie op een snel rapport, maar het vormt wel een betere basis om prestaties systematisch te beheren.

Het model wordt moeilijker te begrijpen en over te dragen

Naarmate een rapport groeit, komt de logica vaak op verschillende plaatsen terecht. Een deel zit in de bronquery, een deel in Power Query en een deel in de measures. Daardoor wordt het steeds moeilijker om te achterhalen hoe een cijfer precies tot stand komt. Vaak weet na verloop van tijd alleen de oorspronkelijke bouwer nog welke uitzonderingen en afspraken in het model verwerkt zijn.

Ook een model met te veel tabellen en onduidelijke relaties wordt snel moeilijk beheersbaar. Een kleine wijziging kan dan gevolgen hebben op andere plaatsen in het rapport, zonder dat meteen duidelijk is waarom.

Een goed opgebouwd sterschema brengt meer structuur. Het maakt duidelijk welke tabellen transacties bevatten, welke tabellen gebruikt worden om te filteren en op welk niveau cijfers worden berekend. Daardoor kan een andere Power BI-bouwer het model sneller begrijpen, controleren en verder onderhouden.

Wanneer kan een platte tabel wel volstaan?

Niet ieder rapport heeft een uitgebreid datamodel nodig. Een platte tabel kan een goede keuze zijn voor een eenmalige of verkennende analyse, waarbij snelheid belangrijker is dan herbruikbaarheid. Ze kan ook volstaan wanneer het model klein blijft, slechts één onderwerp en één duidelijk detailniveau bevat en er geen bijkomende databronnen of vergelijkingen gepland zijn.

Ook eenvoudige kenmerken, zoals een status of categorie, hoeven niet automatisch een afzonderlijke dimensietabel te krijgen. Een sterschema is geen doel op zich. De structuur moet in verhouding staan tot de complexiteit en verwachte levensduur van het rapport.

Een bruikbare vuistregel is dat u de structuur opnieuw moet beoordelen zodra het rapport regelmatig in beslissingen wordt gebruikt, verschillende processen of databronnen combineert, of door meerdere medewerkers moet kunnen worden onderhouden. Op dat moment is het rapport geen tijdelijke analyse meer, maar een bedrijfsmiddel dat een degelijke basis nodig heeft.

Dat kantelpunt komt vaak vroeger dan verwacht. Een voorlopig rapport van een controller kan jarenlang in gebruik blijven. Wanneer de beperkingen uiteindelijk zichtbaar worden, zijn er meestal al veel measures, pagina’s en gebruikers van afhankelijk.

Een duidelijk model helpt ook AI

De kwaliteit van het datamodel wordt nog belangrijker nu Power BI steeds meer AI-functionaliteit bevat. Copilot en vergelijkbare hulpmiddelen gebruiken niet alleen de cijfers, maar ook de structuur, relaties, veldnamen, omschrijvingen en bijkomende instructies van het semantische model om vragen te interpreteren.

Een sterschema helpt omdat de betekenis van de tabellen en hun onderlinge relaties duidelijker is. Dat volstaat echter niet. Measures moeten eenduidige namen hebben, technische velden die gebruikers niet nodig hebben kunnen beter worden verborgen en belangrijke begrippen moeten correct worden omschreven. Waar nodig moet ook bijkomende context worden toegevoegd over de manier waarop het bedrijf bijvoorbeeld omzet, marge of actieve klanten definieert.

Een AI-toepassing formuleert een antwoord vlot, ook wanneer ze de onderliggende gegevens verkeerd interpreteert. Een verzorgd model verkleint dat risico en maakt het eenvoudiger om de antwoorden te controleren. De kwaliteit van AI-analyse begint daarom niet bij de prompt, maar bij de betekenis en structuur van de gegevens.

Van een platte tabel naar een sterschema

Een bestaand model hoeft niet altijd volledig opnieuw te worden gebouwd. In veel gevallen kan de structuur gefaseerd worden verbeterd.

Begin met vast te leggen wat één rij in de huidige tabel precies voorstelt. Is dat een order, een orderlijn, een factuurregel of een voorraadbeweging? Dat detailniveau bepaalt welke gegevens in de feitentabel thuishoren en voorkomt dat bedragen van verschillende niveaus onbedoeld worden samengevoegd.

Vervolgens kunt u terugkerende beschrijvende informatie, zoals klanten, producten en vestigingen, onderbrengen in afzonderlijke dimensietabellen. Daarbij volstaat het niet altijd om alleen dubbels te verwijderen. Ook de gebruikte sleutels, ontbrekende waarden en wijzigingen in klant- of productkenmerken moeten correct worden behandeld.

Voeg daarnaast een volwaardige kalendertabel toe en verbind die consequent met de relevante datumvelden. Begin met de dimensies die in bijna ieder rapport terugkomen, meestal periode, klant en product. Andere onderdelen kunnen volgen wanneer ze werkelijk iets toevoegen.

Bestaande measures en visualisaties kunnen vervolgens stapsgewijs worden aangepast. Hoeveel werk dat vraagt, hangt af van de huidige structuur en van de mate waarin kolommen rechtstreeks in rapporten en berekeningen worden gebruikt. Een gefaseerde ombouw is vaak mogelijk, maar verdient vooraf een goede impactanalyse.

Wacht daarmee bij voorkeur niet tot het model vastloopt. Iedere uitbreiding op een ongeschikte structuur maakt de latere aanpassing complexer. Een gerichte review van het datamodel kan vroeg zichtbaar maken waar risico’s zitten, welke onderdelen kunnen blijven en welke ingrepen eerst nodig zijn.

Is uw datamodel nog geschikt voor wat uw rapport intussen moet doen?

Een rapport kan er verzorgd uitzien en toch steunen op een structuur die verdere groei moeilijk maakt. Een diagnosescan van uw datamodel brengt in kaart waar foutieve totalen, onduidelijke relaties, prestatieproblemen of afhankelijkheden kunnen ontstaan. U krijgt daarbij geen theoretisch ideaalmodel, maar een praktische prioriteitenlijst: wat goed zit, wat eerst moet worden aangepakt en wat voorlopig kan blijven. Dat sluit aan bij wat een sterschema voor uw stuurinformatie belooft. Wilt u het datamodel meteen laten bouwen of herstructureren? Bekijk dan Power BI-implementatie.

Veelgestelde vragen

Wat is het verschil tussen een feitentabel en een dimensietabel?

Een feitentabel bevat de gebeurtenissen die u wilt meten, zoals orderlijnen, boekingen of voorraadbewegingen. Een dimensietabel bevat de invalshoeken waarmee u die gebeurtenissen analyseert, zoals klanten, producten, periodes en vestigingen.

Feitentabellen bevatten doorgaans veel rijen en vooral sleutels en meetwaarden. Dimensietabellen bevatten minder rijen en meer beschrijvende gegevens. In een klassiek sterschema lopen filters doorgaans van de dimensies naar de feiten.

Is een sterschema niet overdreven voor een kmo?

Dat hangt minder af van de bedrijfsgrootte dan van het gebruik van het rapport. Een eenmalige analyse heeft andere eisen dan een rapport dat iedere maand wordt gebruikt om prijzen, marges, voorraad of capaciteit te bespreken.

Wanneer een model langere tijd moet meegaan, verschillende gegevensbronnen combineert of door meerdere mensen wordt beheerd, betaalt een heldere structuur zich ook binnen een kleinere onderneming terug.

Mijn rapport op een platte tabel werkt goed. Waarom zou ik het veranderen?

Wanneer het rapport klein, overzichtelijk en betrouwbaar blijft, is er geen reden om het uitsluitend om principiële redenen om te bouwen.

Het is wel verstandig om de structuur opnieuw te bekijken zodra er andere detailniveaus, databronnen of bedrijfsprocessen bijkomen. Problemen zoals dubbele tellingen en moeilijk controleerbare measures ontstaan vaak pas nadat het model verschillende keren werd uitgebreid.

Moet ik mijn bestaande model volledig herbouwen?

Niet noodzakelijk. Vaak kunnen dimensies, een kalendertabel en duidelijkere relaties gefaseerd worden ingevoerd. Hoeveel van het bestaande rapport kan blijven, hangt af van de huidige queries, measures, visuals en veldnamen.

Een korte analyse vooraf voorkomt dat u tijdens de ombouw onverwacht berekeningen of rapportpagina’s breekt.

Werkt Copilot beter met een sterschema?

Een duidelijk sterschema kan Copilot helpen om de gegevens en relaties beter te interpreteren. De kwaliteit van de antwoorden hangt echter ook af van duidelijke veldnamen, betrouwbare measures, omschrijvingen en bijkomende bedrijfscontext.

Een goed model maakt AI-antwoorden niet automatisch juist, maar het verkleint de kans op verkeerde interpretaties en maakt controle eenvoudiger.

Dennis Houthoofd, oprichter Beyond KPI. 25+ jaar ervaring in finance, data en AI voor Vlaamse KMO's. Meer over Dennis.