Slowly Changing Dimensions (SCD)

Wat zijn Slowly Changing Dimensions?

Slowly Changing Dimensions, meestal afgekort tot SCD, beschrijft hoe je omgaat met wijzigingen in dimensiedata zonder je historische rapportering te breken. Een klant verhuist van Antwerpen naar Gent, een product springt van categorie A naar categorie B, een medewerker krijgt een nieuwe afdeling. Deze wijzigingen gebeuren zelden, maar wél relevant voor analyse: kloppen je cijfers voor 2024 nog als je morgen de categorie bijwerkt?

Ralph Kimball formaliseerde de patronen in zijn boek The Data Warehouse Toolkit. SCD's zijn vandaag nog steeds de standaard in elk data warehouse, elk lakehouse en elk serieus semantisch model.

Je kan SCD vergelijken met een adresgeschiedenis bij een boekhouder. Je kan het oude adres overschrijven met het nieuwe en vergeten waar iemand vroeger woonde. Je kan ook een volledige geschiedenis bijhouden met begin- en einddatum. De keuze hangt af van wat je later met die info wil doen.

De belangrijkste SCD-types

SCD Type 0: nooit wijzigen

De simpelste variant. De kolom mag na initiële inlading niet meer veranderen. Denk aan geboortedatum, initieel aangemaakt-datum of originele contractstart. Pogingen tot wijziging worden genegeerd.

SCD Type 1: overschrijven

De oude waarde wordt vervangen door de nieuwe. Je houdt geen historiek bij. Werkt voor kolommen waar enkel de huidige waarde ertoe doet: telefoonnummer, email, omschrijving.

Voordeel: eenvoudig, geen extra opslag.
Nadeel: historische rapporten worden herschreven. Een verkoop van drie jaar geleden krijgt plots de nieuwe waarde mee, ook al was die toen niet van toepassing.

SCD Type 2: nieuwe rij per versie

Bij elke wijziging maak je een nieuwe rij aan in de dimensietabel. De oude rij krijgt een einddatum en wordt gemarkeerd als inactief, de nieuwe rij krijgt een begindatum en wordt actief. Elke rij heeft zijn eigen surrogaatsleutel.

Voorbeeld: klant verhuist op 2026-03-01 van Antwerpen naar Gent. In de dimensie zitten dan twee rijen voor dezelfde klant, met aparte surrogaatsleutels. Een verkoop van 2025 linkt aan de Antwerpen-rij, een verkoop van 2026-03-05 aan de Gent-rij.

Voordeel: perfecte historiek. Je kan elk rapport reproduceren met de toenmalige staat.
Nadeel: meer opslag en meer complexiteit. ETL-logica moet wijzigingen detecteren en de rijen versioneren.

SCD Type 3: beperkt geheugen

Je bewaart alleen de vorige waarde naast de huidige in twee kolommen: CurrentCity en PreviousCity. Handig voor één-op-één-vergelijkingen (voor en na een migratie), maar je verliest alles wat eerder was.

Voordeel: lichtgewicht, makkelijk in rapporten.
Nadeel: maar één vorig punt. Werkt enkel als er slechts één relevante wijziging is.

SCD Type 6: combinatie (1 + 2 + 3)

Een hybride die drie types combineert: je maakt nieuwe rijen aan zoals Type 2, je bewaart een huidige-waarde-kolom op elke rij zoals Type 1, en je houdt de vorige waarde bij zoals Type 3. Zo kan je zowel historisch als actueel rapporteren zonder complexe queries.

Type 6 is in de praktijk vaak wat je echt nodig hebt, maar de complexiteit van de ETL verdriedubbelt.

Wanneer kies je welk type?

1. Type 0 voor velden die per ontwerp onveranderlijk zijn.

2. Type 1 voor cosmetische attributen: e-mail, telefoonnummer, beschrijving. Niemand gaat rapporteren op een telefoonnummer van drie jaar geleden.

3. Type 2 voor attributen waarop je historisch wil rapporteren: productcategorie, regio, sales-manager, klant-segment. De klassieker voor analytische vragen.

4. Type 3 als er één specifieke oude waarde relevant is naast de huidige (bijvoorbeeld tijdens een migratieperiode).

5. Type 6 als je het comfort van huidige-waarde-filters wil combineren met volledige historiek.

De meeste warehouses mengen types: een dimensietabel met een paar Type 2-kolommen en een paar Type 1-kolommen is gangbaar.

Hoe implementeer je SCD Type 2?

Standaardpatroon in een ETL- of ELT-pipeline:

1. Detecteer wijzigingen. Vergelijk de nieuwe bronrecord met de actieve rij in de dimensie. Via hashes van alle Type 2-kolommen detecteer je snel of er iets veranderd is.

2. Sluit de oude rij af. Zet EndDate op de wijzigingsdatum en IsCurrent op false.

3. Voeg een nieuwe rij in. Nieuwe surrogaatsleutel, nieuwe waarden, StartDate op de wijzigingsdatum, EndDate op NULL of 9999-12-31, IsCurrent op true.

4. Update de feit-koppeling. Nieuwe facttable-rijen linken met de nieuwe surrogaatsleutel, oude rijen blijven linken met de oude.

In Fabric kan je dit met MERGE-statements op Delta-tabellen, met Dataflows Gen2 of met Spark-notebooks. CDC-feeds vormen vaak de input.

Valkuilen

Surrogaatsleutels ontbreken
Zonder surrogaatsleutel kan Type 2 simpelweg niet. Gebruik nooit de businesskey als primaire sleutel in je dimensietabel, want die verandert niet bij een wijziging en dan heb je twee rijen met dezelfde ID.

Verwarring over huidige versus historische filters
Rapporten die zowel alle verkopen aan de huidige Antwerpen-klanten als alle verkopen toen deze klanten in Antwerpen woonden willen tonen, vergen beide een andere join. Leg die patronen vast in een semantisch model met duidelijke measures.

Te veel Type 2-kolommen
Elke cosmetische wijziging triggert dan een nieuwe rij. Je dimensietabel explodeert en performance zakt. Wees selectief: alleen analytisch relevante attributen verdienen Type 2.

Vergeten datum-boundaries
Een ontbrekende EndDate of een overlap tussen rijen leidt tot dubbeltellingen. Test periodiek of voor elke (BusinessKey, Date) exact één actieve rij bestaat.

Historiek onvolledig bij go-live
Bij een nieuwe warehouse vertrek je meestal met de huidige staat als enige versie. Rapporten over jaren daarvoor lopen dan niet juist, tenzij je historische data reconstrueert. Communiceer dat open naar de business.