Slowly Changing Dimensions in een Lakehouse: SCD Type 2 in Microsoft Fabric met Delta-tabellen

Wat zijn Slowly Changing Dimensions en waarom ze in een Lakehouse extra belangrijk zijn

Dimensies zijn de woorden bij je cijfers: klant, product, regio, kanaal. In de praktijk veranderen die woorden, en dat is precies waar analyses vaak ontsporen. In een Lakehouse is die impact extra zichtbaar, omdat je data sneller door de keten gaat en meerdere teams dezelfde tabellen hergebruiken. In klassieke warehouses werd dit al opgelost met SCD-patronen, maar in moderne platformen wil je het liefst dezelfde zekerheid met minder frictie. Delta-tabellen helpen daarbij omdat je betrouwbaar updates en inserts kunt doen zonder dat je de hele tabel steeds moet herschrijven. Daardoor kun je historiek “meeschrijven” met je pipeline, in plaats van het achteraf te repareren. Het belangrijkste uitgangspunt is simpel: als de business vragen stelt over het verleden, moet jouw model het verleden kunnen reproduceren. “Wat was de productprijs toen de order werd geplaatst?” is een andere vraag dan “wat is de prijs vandaag?”. Zodra je dat onderscheid maakt, wordt SCD geen technisch trucje maar een modelkeuze die je BI beschermt.

SCD Type 2 uitgelegd in normale mensentaal

SCD Type 2 betekent dat je veranderingen niet overschrijft, maar opslaat als een nieuwe versie. De oude versie blijft bestaan, alleen markeer je die als niet meer actueel en geef je aan tot wanneer die geldig was. De nieuwe versie start vanaf de wijzigingsdatum en wordt de “current” versie. Je herkent SCD2 meestal aan drie dingen: een sleutel om de entiteit te herkennen (bijvoorbeeld product_id), een geldigheidsperiode (start_date en end_date) en een indicator zoals is_current. Soms voeg je een hash toe van relevante attributen om wijzigingen snel te detecteren, zeker als je veel kolommen hebt. Microsoft’s Fabric-voorbeeld gebruikt precies dat idee met een hash en een current-flag. De praktische winst is dat je rapporten niet “meeveranderen” met stamdata. Als een productnaam vandaag wordt aangepast, blijft de productnaam in een analyse van vorig jaar nog steeds de naam die toen gold. Dat klinkt als detail, maar het is het verschil tussen een dashboard dat vertrouwen opbouwt en een dashboard dat discussies uitlokt.

Historische context vastleggen in een Delta-tabel in een Fabric Lakehouse

In Microsoft Fabric Lakehouse werk je met Delta-tabellen als opslaglaag voor je curated data. Voor SCD Type 2 ontwerp je je dimensietabel zo dat hij meerdere versies per natuurlijke sleutel kan bevatten. Denk aan product_nk (natuurlijke sleutel), een surrogate key (optioneel maar vaak handig), attributen, start_date, end_date en is_current. De laadlogica bestaat conceptueel uit twee acties wanneer een attribuut wijzigt: je sluit de huidige rij af en je voegt een nieuwe rij toe. In Delta Lake wordt dit vaak uitgedrukt met een merge-achtige aanpak waarbij je bestaande “current” records update en de nieuwe versie insert. Delta’s documentatie laat dit zien als een patroon waarbij je updates “staged” zodat je zowel de afsluiting als de insert netjes verwerkt. Fabric-implementaties zie je vaak in notebooks (PySpark) of in Dataflow Gen2, afhankelijk van het team en de governance. Belangrijk is dat je het onderscheid bewaakt tussen Fabric Lakehouse en Fabric Warehouse, omdat niet elke omgeving dezelfde SQL-merge mogelijkheden heeft. Voor Lakehouse met Delta en Spark heb je de juiste bouwstenen om dit robuust te doen.

Praktisch voorbeeld: een product dat in de loop van de tijd verandert

Stel: je hebt een productdimensie met product_id, product_name, brand en list_price. In maart verandert de merknaam door rebranding en in juni verandert de prijs door een nieuwe prijslijst. Als je Type 1 zou doen, overschrijf je de naam en prijs en lijken alle historische orders ineens onder de nieuwe merknaam en prijs te vallen. Met SCD Type 2 maak je van elke wijziging een nieuwe rij. De versie tot en met februari krijgt een end_date in maart en is_current = false, en de nieuwe versie krijgt start_date in maart met is_current = true. Als in juni de prijs wijzigt, sluit je de maart-versie af en voeg je een juni-versie toe, zodat je drie versies hebt voor hetzelfde product_id. In je facts, bijvoorbeeld sales_orders, join je niet “blind” op product_id, maar op product_id én een datumvoorwaarde. In de praktijk is dat: orderdatum valt tussen start_date en end_date van de productversie. Zo blijft een order uit februari gekoppeld aan de februari-versie, ook al heet het product vandaag anders. Mini-ontwerp van de Delta-dimensietabel (conceptueel) dim_product_scd2(product_sk, product_id, product_name, brand, list_price, start_date, end_date, is_current, hash) Hoe je de wijziging detecteert (conceptueel) Je vergelijkt de inkomende productrecords met de huidige versie (is_current = true) en checkt of relevante attributen anders zijn. In veel patronen gebruik je hiervoor een hash over de attribuutkolommen, omdat dat schaalbaar blijft als je dimensie groeit. Hoe je de update toepast (conceptueel)

1. Sluit huidige rij: zet is_current = false en end_date = wijzigingsdatum voor het product dat verandert.
2. Insert nieuwe rij: zelfde product_id, nieuwe attributen, start_date = wijzigingsdatum, end_date = 9999-12-31 (of null), is_current = true.

Van historiek naar inzicht: zo gebruik je SCD2 in BI en governance

SCD2 is pas echt waardevol als je BI-laag het correct gebruikt. Dat betekent dat je joins “tijd-bewust” zijn, en dat je model duidelijk maakt welke datum leidend is. In sales is dat vaak orderdatum, in finance boekdatum, en in service een ticketdatum. Als je daar slordig in bent, heb je nog steeds historiek, maar geen historisch juiste analyses. Voor analisten is het prettig als je een standaardpatroon afspreekt: facts joinen op de dimensie waar fact_date >= start_date AND fact_date < end_date (of <= afhankelijk van je definitie). Daarmee kun je ook “as-of” rapportages bouwen: “toon de klantsegmenten zoals ze waren op 31-12”. Dat is precies het soort vraag dat SCD2 mogelijk maakt zonder handmatige correcties. Governance helpt je om dit vol te houden: definieer welke kolommen SCD2-triggering zijn, wie de wijzigingsdatum bepaalt en hoe je late-arriving updates behandelt. In Fabric is het daarnaast slim om je SCD2-dimensies als ‘gold’ assets te positioneren, zodat teams niet ieder hun eigen interpretatie bouwen. Dan wordt je Lakehouse een bron van waarheid in plaats van een verzameling varianten.

Praktische implementatie in een Fabric Lakehouse (Delta + PySpark) (schets)

Onderstaande is een compacte schets van het bekende Delta Lake SCD2-patroon: je “stage’t” updates zodat je zowel het sluiten van de huidige rij als het inserten van de nieuwe rij in één logische flow kunt doen. Dit sluit aan op het officiële Delta Lake merge-voorbeeld voor SCD Type 2. # Conceptuele stappen (schets) # 1) Lees bron (updates) en target (dim_product_scd2) # 2) Filter target op is_current = true # 3) Detecteer veranderingen (bijv. via hash of attribuutvergelijking) # 4) Sluit huidige rijen (set is_current=false, end_date=effective_date) # 5) Insert nieuwe rijen (start_date=effective_date, end_date='9999-12-31', is_current=true) Belangrijk in Fabric-context: als je in andere onderdelen van Fabric werkt (zoals Warehouse), kunnen SQL-mogelijkheden verschillen. In Lakehouse met notebooks en Delta-tabellen heb je doorgaans de juiste route voor SCD2 merges via Spark.

Samenvatting

Met Slowly Changing Dimensions in een Lakehouse zorg je dat je historische analyses stabiel blijven, ook als stamdata wijzigt. SCD Type 2 doet dat door bij elke relevante wijziging een nieuwe dimensierij te maken en de oude versie af te sluiten met een geldigheidsperiode. In een Microsoft Fabric Lakehouse leg je dit vast in een Delta-tabel met start_date, end_date en is_current, en je gebruikt die periode vervolgens in je BI-joins. Daarmee voorkom je dat dashboards terugwerkend veranderen en bouw je vertrouwen in je datamodel.