Granulariteit (grain)

Wat is granulariteit?

Granulariteit, in het Engels grain, is het antwoord op één vraag: wat stelt één rij in deze tabel voor? Dat antwoord bepaalt het detailniveau van je data en dus welke vragen je er later mee kan beantwoorden.

Neem verkoopdata. Dezelfde verkoop kan je op drie niveaus bewaren:

• Eén rij per bestelregel. Elk product op elk kassaticket is een aparte rij. Dit is het fijnste niveau: je ziet welke producten samen gekocht worden.

• Eén rij per bestelling. Eén ticket, één rij, met het totaalbedrag. Het productdetail is weg, maar je ziet nog per klant en per dag wat er verkocht werd.

• Eén rij per klant per maand. Alles opgeteld. Compact en snel, maar je kan enkel nog maandtrends per klant bekijken.

Drie keer dezelfde verkoop, drie totaal verschillende tabellen. Vergelijk het met de resolutie van een foto: uitzoomen op een scherpe foto kan altijd, maar uit een wazige foto haal je geen details terug die er nooit in zaten.

Eerst de grain, dan pas dimensies en meetwaarden

Ralph Kimball, de grondlegger van dimensioneel modelleren, beschrijft het ontwerp van een feitentabel in vier vaste stappen:

1. Kies het businessproces dat je wil meten (verkoop, facturatie, voorraad).

2. Leg de grain vast: wat stelt één rij voor?

3. Kies de dimensies (klant, product, datum, winkel).

4. Kies de meetwaarden (aantal, bedrag, korting).

De grain komt bewust vóór de dimensies en meetwaarden. Elke kandidaat-dimensie en elke kandidaat-meetwaarde moet namelijk passen bij de grain. Is je grain "één bestelregel", dan hoort een verzendkost daar niet thuis, want die bestaat per bestelling en niet per regel. Wil je hem toch opnemen, dan moet je hem eerst verdelen over de regels of naar een aparte tabel verhuizen.

Kimball noemt de grain-verklaring een bindend contract op het ontwerp. Zolang dat contract niet uitgesproken is, blijft elke discussie over kolommen en berekeningen los zand.

Dubbeltellingen en gemiddelden van gemiddelden

De meeste rapportfouten die op rekenfouten lijken, zijn eigenlijk grain-fouten. Twee klassiekers kom je overal tegen.

De dubbeltelling na een join. Een bestelling heeft drie bestelregels en een verzendkost van 10 euro, die op bestellingsniveau leeft. Koppel je die verzendkost aan de bestelregels en tel je daarna op, dan wordt 10 euro plots 30 euro. De join heeft de verzendkost drie keer gekopieerd, één keer per regel. Op één bestelling valt dat op, op een jaar aan data glipt het zo je managementrapport binnen.

Het gemiddelde van gemiddelden. Winkel A heeft 100 tickets met gemiddeld 50 euro, winkel B heeft er 10 met gemiddeld 20 euro. Het echte gemiddelde ticket is 47,27 euro (5.200 euro gedeeld door 110 tickets). Wie de twee winkelgemiddelden middelt, komt op 35 euro uit. De kleine winkel weegt dan even zwaar als de grote. Zodra je een gemiddelde berekent op een tabel die zelf al gemiddelden bevat, reken je op de verkeerde grain.

Daarom is de regel bij Kimball ook hard: verschillende grains horen nooit samen in één feitentabel. Een tabel waarin dagcijfers en maandtotalen door elkaar staan, telt elke maand dubbel zodra iemand er een som over draait.

Fijn of grof: welke grain kies je?

De fijnste grain, zoals de individuele bestelregel, bewaart alle vragen voor later. Aggregeren kan altijd achteraf: van bestelregels maak je in één beweging dagtotalen of maandcijfers. De omgekeerde weg bestaat niet. Wie enkel maandcijfers bewaart, kan nooit meer terug naar de vraag welke producten samen verkocht werden.

Fijn heeft wel een prijs: meer opslag en zwaardere query's, zeker met miljoenen bestelregels per jaar.

Een grovere grain is de bewuste ruil: sneller en compacter, in ruil voor detail dat definitief weg is. Een voorraadtabel is een goed voorbeeld. In plaats van elke individuele voorraadbeweging te bewaren, volstaat vaak een dagelijkse foto: één rij per product per dag met de eindstand. Voor trendanalyse is dat genoeg, met een fractie van de rijen.

De praktische middenweg in een data warehouse: bewaar de fijnste grain die je bron toelaat als basistabel, en bouw daar waar nodig aggregatietabellen bovenop voor snelheid. Dan heb je beide.

Grain in Power BI

In een ster-schema in Power BI staat elke dimensietabel aan de één-kant van een relatie en de feitentabel aan de veel-kant. Dat werkt alleen als elke feitentabel een consistente grain heeft. Microsoft benoemt dat expliciet in zijn modelleringsrichtlijnen: laad feiten altijd op één consistent detailniveau in.

Het klassieke voorbeeld is budget naast verkoop. Je verkoopcijfers staan per kassaticket per dag, je budget staat per winkel per maand. Die twee grains mogen naast elkaar bestaan, zolang elke grain zijn eigen feitentabel krijgt en beide via gedeelde dimensies aan elkaar hangen. Wie ze in één tabel propt of rechtstreeks aan elkaar relateert, krijgt problemen.

Veel fouten die eruitzien als DAX-bugs zijn in werkelijkheid grain-fouten. Enkele herkenbare symptomen: hetzelfde budgetbedrag dat bij elke dag van de maand herhaald wordt, een totaalregel die niet gelijk is aan de som van de rijen erboven, of een relatie die plots veel-op-veel wil worden. In al die gevallen is de eerste vraag niet "wat is er mis met mijn measure?" maar "wat stelt één rij voor in elk van deze tabellen?".

Ook stuksprijzen zijn een grain-kwestie. Een prijs per stuk leeft op regelniveau en optellen over regels is zinloos. Microsoft raadt aan zo'n kolom te verbergen en enkel measures met minimum, maximum of gemiddelde aan te bieden.

Grain en KPI-definities

Elke KPI-definitie bevat een grain-uitspraak, ook al staat het woord er niet in. "Omzet per maand per winkel" legt vast op welk niveau je telt. Wie dat niveau niet uitspreekt, krijgt dashboards die elkaar tegenspreken.

Twee rapporten die dezelfde omzet anders tonen, verschillen zelden in hun bron. Ze verschillen in grain: het ene telt per bestelling, het andere per bestelregel, of retours worden op een ander niveau afgetrokken. Leg daarom bij elke KPI vast op welk detailniveau de teller en de noemer geteld worden, net zoals je de formule zelf vastlegt.

Waar moet je op letten bij het werken met grain

• Laat de grain nooit impliciet. Spreek hem uit bij het ontwerp, vóór er ook maar één kolom gekozen wordt. Een grain die alleen in iemands hoofd bestaat, is geen grain.

• Documenteer per tabel wat één rij voorstelt. Eén zin per tabel volstaat: "één rij is één bestelregel", "één rij is één product per dag". Zet die zin in je datacatalogus of desnoods in de tabelbeschrijving.

• Mix nooit twee niveaus in één tabel. Detailrijen en subtotalen samen in één tabel is vragen om dubbeltellingen. Splits ze in twee tabellen met elk hun eigen grain.

• Kijk uit met bron-exports. Excel-exports en rapporten uit ERP-systemen mengen vaak detailregels met subtotaal- en totaalregels. Filter die eruit voor je er een model op bouwt.

• Doe de één-zin-test. Kan een collega die de tabel voor het eerst ziet in één zin zeggen wat één rij voorstelt? Zo niet, dan is de grain niet vastgelegd, hoe goed de rest van het model ook oogt.

FAQ over granulariteit

1. Is granulariteit hetzelfde als cardinaliteit?
Nee. Granulariteit zegt wat één rij in een tabel voorstelt. Cardinaliteit gaat over aantallen: hoeveel unieke waarden een kolom heeft, of hoe twee tabellen zich verhouden (één-op-veel, veel-op-veel). Ze raken elkaar wel: de grain van je feitentabel bepaalt mee welke cardinaliteit je relaties krijgen.

2. Welke grain kies ik voor een nieuwe feitentabel?
De fijnste grain die je bron toelaat, tenzij het datavolume of je vraagstelling een goede reden geeft om grover te gaan. Aggregeren kan altijd later, verfijnen niet.

3. Kan ik twee grains combineren in één rapport?
Ja, maar niet in één tabel. Geef elke grain zijn eigen feitentabel en verbind ze via gedeelde dimensies. Zo toont Power BI verkoop per dag en budget per maand netjes naast elkaar in dezelfde visual.

4. Hoe herken ik een grain-probleem in bestaande cijfers?
Drie signalen: totalen die groeien nadat je tabellen gekoppeld hebt, hetzelfde bedrag dat bij elke detailregel herhaald wordt, en gemiddelden die verschillen naargelang de weg waarlangs je ze berekent. Zie je één van de drie, controleer dan eerst wat één rij voorstelt in elke betrokken tabel.