Ster-schema

Wat is een ster-schema?

Een ster-schema is een datamodel waarbij je één centrale feitentabel hebt en daar één of meer dimensietabellen aan hangt. Als je het tekent, lijkt het op een ster: de feitentabel in het midden, de dimensies eromheen als punten van de ster. Dit patroon is sinds Ralph Kimball in de jaren '90 de standaard voor BI-rapportering.

De gedachte is eenvoudig. De feitentabel bevat meetbare gebeurtenissen (orders, transacties, klikken, voorraadmetingen). De dimensietabellen bevatten de context van die gebeurtenissen (klanten, producten, datums, winkels). In een rapport kies je een dimensie om op te filteren of te groeperen en meet je iets op de feitentabel.

Je kan het vergelijken met een kassaticket. Het ticket zelf is het feit: drie pakken koffie verkocht op 17 april. De kassabon ernaast met klantgegevens, productspecificaties en winkelinfo zijn de dimensies.

Waarom is een ster-schema zo belangrijk?

Prestaties
BI-engines zoals VertiPaq (de kern van Power BI) zijn expliciet geoptimaliseerd voor ster-schema's. Ze comprimeren de kolommen extreem efficiënt en voeren joins tussen een feit en meerdere dimensies in hoge snelheid uit. Wanneer je hetzelfde model herschrijft als genormaliseerde rij, kelderen de prestaties vaak met een factor tien of meer.

Eenvoud voor gebruikers
Business-gebruikers herkennen meteen wat ze waar moeten slepen. Alle cijfers komen uit de feitentabel, alle categorieën uit dimensies. Geen discussies over welke van de vijftien tabellen eigenlijk de klant beschrijft.

Herbruikbaarheid van dimensies
Eén klantdimensie voedt tientallen feitentabellen. Eén datumdimensie werkt in elk model dat je ooit maakt. Zo voorkom je dat iedereen zijn eigen klantendefinitie verzint.

DAX-vriendelijkheid
DAX is ontworpen met een ster-schema in het achterhoofd. Time-intelligence-functies, CALCULATE-patronen en filtercontext werken allemaal optimaal wanneer je feit en dimensies netjes gescheiden houdt.

Wat zit in een feitentabel?

Een feitentabel bevat rijen die gebeurtenissen vastleggen. Elke rij is één gebeurtenis: één verkoopregel, één klik, één meting.

Sleutels naar dimensies
Voor elke bijbehorende dimensie een vreemde sleutel: KlantId, ProductId, DatumId, WinkelId. Deze sleutels zijn het stuur om naar dimensies te navigeren.

Numerieke maten
Hoeveelheden, bedragen, duurtijd, aantallen. De getallen die je optelt, gemiddeldes, ratios.

Geen beschrijvingen
De feitentabel bevat geen klantnaam of productomschrijving. Die staan in de dimensies. Op die manier blijft de feitentabel smal en snel.

Wat zit in een dimensietabel?

Een dimensietabel beschrijft een perspectief, bijvoorbeeld een klant of een product. Eén rij per uniek item.

Surrogaatsleutel
Een interne ID, los van de businesskeys in de bron. Dat maakt Slowly Changing Dimensions mogelijk en vangt veranderingen in bronsystemen op.

Attributen
Alle beschrijvende kolommen: naam, categorie, regio, segment. Liever veel denormalisatie dan een sterrenkussen van extra tabellen.

Hiërarchieën
Vaak ingebouwd, bijvoorbeeld Land > Regio > Stad > Winkel. Heel handig voor drill-downs in rapporten.

Ster-schema versus snowflake-schema

Een snowflake-schema is een uitgebreide variant waarbij dimensies zelf weer in kleinere dimensies opgedeeld zijn (bijvoorbeeld Product > Categorie > Subcategorie als drie aparte tabellen). Technisch puurder, maar in de praktijk zelden de moeite:

Minder prestaties
Meer joins betekent langzamere queries, zeker in VertiPaq.

Complexer DAX
Filtercontext moet door meer tabellen wandelen. Tijdsintelligentie en cross-filter-patterns worden sneller onbeheerbaar.

Moeilijker voor gebruikers
Business-analysten verdwalen in de extra tabellen.

Vuistregel: denormaliseer altijd naar een ster, tenzij je een hele goede reden hebt om te snowflaken.

Hoe bouw je een ster-schema in Power BI of Fabric?

1. Vertrek vanuit de use case. Welke vragen moeten beantwoord worden? Die vragen definiëren de feiten en de dimensies.

2. Identificeer feittabellen. Elke fysieke gebeurtenis (verkoop, logging, meting) wordt een aparte feittabel, op zijn eigen granulariteit.

3. Bouw conformed dimensions. Eén klanttabel, één producttabel, één datumtabel voor het hele model. Dat heet conformed dimensions in Kimball-termen.

4. Denormaliseer. Alle attributen van een klant in één klanttabel, alle attributen van een product in één producttabel. Geen extra lookup-tabellen tenzij echt nodig.

5. Stel relaties correct in. Single-direction filters van dimensie naar feit, cardinality 1-op-veel. Vermijd bi-directionele filters, die zijn bijna altijd een symptoom van een model dat elders fout zit.

6. Verschuil fact-tabellen niet. Ze mogen breed zijn (veel rijen), maar hun structuur moet helder zijn: sleutels plus maten.

Valkuilen

Alles in één grote tabel
Beginnende Power BI-gebruikers laden vaak één brede tabel uit Excel of SQL met klant, product, datum en verkoopcijfer in elkaar gevlochten. Het werkt op kleine data, maar loopt vast zodra het groeit. Investeer vroeg in een echt dimensioneel model.

Feittabellen met beschrijvingen
ProductNaam of KlantSegment in de feittabel duwt de geheugenvoetafdruk omhoog en remt het model. Duw die kolommen naar de dimensie en link via de surrogaatsleutel.

Geen aparte datumtabel
Een echte datumtabel met elke dag tussen begin en eind is onontbeerlijk voor tijdsintelligentie. Laat die niet afleiden uit de feittabel zelf.

Te veel relaties
Een feittabel die aan dertig dimensies hangt wordt onleesbaar. Bekijk of je kleinere feittabellen kan maken per onderwerp, met elk een beperkte set dimensies.

Snowflake uit gemakzucht
Dimensies verder opsplitsen omdat de bron zo genormaliseerd was, is geen goede reden. Bouw je dimensie plat in Power Query of in je data warehouse-laag.