Snapshot fact table

Wat is een snapshot fact table?

Een snapshot fact table legt de toestand van iets vast op een vast moment, niet de losse gebeurtenissen die tot die toestand leidden. Een gewone feittabel bewaart elke verkoop, elke betaling of elke klik als een aparte rij. Een snapshot bewaart de stand van zaken: de voorraad per product aan het einde van elke dag, het saldo per rekening op elke maandultimo.

Het begrip komt uit het dimensioneel modelleren van Ralph Kimball. In een ster-schema staat een feittabel centraal, omringd door dimensietabellen met context (klant, product, datum). Kimball onderscheidt drie soorten feittabellen, en twee daarvan zijn snapshots.

De reden dat je ze nodig hebt: sommige vragen gaan over een toestand op een moment, niet over gebeurtenissen. "Hoeveel stuks lagen er gisteravond in het magazijn?" beantwoord je niet vlot door transacties op te tellen. Je zou elke inkomende en uitgaande beweging sinds dag één moeten samenvoegen, en dat klopt zelden helemaal.

De drie soorten feittabellen

Kimball's model kent drie types, en de keuze bepaalt hoe je tabel groeit en welke vragen ze aankan.

Transaction fact table
Eén rij per gebeurtenis, op het moment dat ze plaatsvindt: één verkoopregel, één pinbetaling, één ritje. Dit is het meest voorkomende type. De tabel groeit met elke transactie en is onregelmatig gevuld: op een drukke dag veel rijen, op een stille dag bijna geen.

Periodic snapshot fact table
Eén rij per entiteit per vaste periode. Aan het einde van elke dag, week of maand schrijf je voor elke rekening, elk product of elke winkel één rij met de stand op dat moment. Ook als er die periode niets bewoog, komt er een rij, met een nul of de vorige waarde. De tabel groeit dus voorspelbaar: aantal entiteiten maal aantal periodes.

Accumulating snapshot fact table
Eén rij per procesinstantie, die je bijwerkt terwijl het proces vordert. Denk aan een order die van "geplaatst" naar "verzonden" naar "geleverd" gaat. De rij bestaat al zodra de order binnenkomt en wordt telkens overschreven zodra een volgende stap bereikt is. Dit is het enige type waar je bestaande rijen updatet in plaats van nieuwe toe te voegen.

Periodic snapshot: de stand op vaste momenten

Een periodic snapshot beantwoordt vragen over een niveau of een saldo. Twee klassieke voorbeelden:

• Voorraad. Elke avond schrijf je per product en per magazijn hoeveel stuks er op de plank liggen. Een jaar later teken je perfect de voorraadevolutie van artikel X uit, zonder alle leveringen en verkopen opnieuw te moeten samenrekenen.

• Rekeningsaldo. Op elke maandultimo leg je het saldo van elke rekening vast. Zo heb je een betrouwbare basis voor rapporten over openstaand bedrag of gemiddeld saldo per klantgroep.

Het kenmerk: elke entiteit verschijnt in elke periode, ook zonder beweging. Dat maakt de tabel dicht en regelmatig, en precies daarom betrouwbaar voor trends. De grain (wat één rij voorstelt) is hier "één product per magazijn per dag", niet "één beweging".

Semi-additieve maten: optellen over de tijd mag niet

Snapshots brengen een addertje mee dat veel rapporten stilletjes fout doet lopen. Een saldo of een voorraadstand is een semi-additieve maat: je mag ze over sommige dimensies optellen, maar niet over de tijd.

Neem rekeningsaldi. Over klanten heen mag je optellen: het totale saldo van al je klanten is gewoon de som van de losse saldi. Over de tijd heen loopt het mis. Het saldo van een kwartaal is niet de som van de drie maandsaldi. Als een klant elke maand 1.000 euro op zijn rekening heeft staan, is zijn kwartaalsaldo geen 3.000 euro.

Voor de tijdsas neem je daarom de laatste waarde (het saldo op de laatste dag van de periode) of een gemiddelde, nooit de som. In Power BI en DAX bestaan hier aparte functies voor, net omdat een gewone SUM over de tijd het verkeerde cijfer geeft. Voorraad gedraagt zich net zo: optellen over magazijnen mag, optellen over dagen niet.

Accumulating snapshot: één rij die meegroeit met een proces

Het derde type past bij een proces met een duidelijk begin en einde en een paar vaste tussenstappen: order fulfilment, een schadedossier, een sollicitatietraject. Je maakt één rij per instantie (per order, per dossier) en werkt die bij naarmate ze door de stappen wandelt.

Typisch heeft zo'n rij meerdere datumkolommen, één per mijlpaal: besteldatum, verzenddatum, leverdatum. Bij aanmaak zijn de latere datums nog leeg. Elke keer een mijlpaal bereikt wordt, vul je de bijbehorende datum in en herbereken je de doorlooptijden ertussen: dagen tussen bestellen en verzenden, tussen verzenden en leveren.

Daardoor beantwoordt dit type meteen vragen die de andere twee moeilijk aankunnen: hoeveel orders zitten nu tussen verzonden en geleverd, en waar lopen de grootste vertragingen op? De tabel blijft klein, want je voegt geen rijen toe per stap, je overschrijft de bestaande rij.

Welk type kies je?

De drie types sluiten elkaar niet uit. In een volwassen model staan ze vaak naast elkaar, elk voor hun eigen soort vraag. Gaat het over losse gebeurtenissen, dan wil je een transaction feittabel. Gaat het over een niveau of saldo op vaste momenten, dan een periodic snapshot. Gaat het over de voortgang en doorlooptijd van een proces, dan een accumulating snapshot.

Let bij snapshots altijd op de grain en op de semi-additieve maten. Definieer scherp wat één rij voorstelt, één entiteit per periode of één procesinstantie, en spreek af hoe je saldi over de tijd samenvat. Wie dat overslaat, bouwt rapporten die op klantniveau kloppen maar op kwartaalniveau verkeerde totalen tonen.