Late arriving dimensions (laatkomende dimensies)

Wat is een late arriving dimension?

Een late arriving dimension, in het Nederlands een laatkomende dimensie, is een dimensierij die te laat aankomt om het feit te kunnen linken dat er al naar verwijst. Het feit is er, de bijhorende context nog niet. Een verkoop wordt geboekt op naam van klant C-8842, maar die klant staat nog niet in je klantdimensie omdat het CRM-systeem nog niet gesynchroniseerd heeft.

Vanuit het feit gezien heet net hetzelfde probleem een early arriving fact: het feit is vroeger binnen dan zijn dimensie. Beide termen beschrijven dezelfde situatie vanuit een ander vertrekpunt.

Waarom is dat lastig? Elke rij in je feittabel heeft een surrogaatsleutel nodig die naar een dimensierij wijst. Bestaat die dimensierij niet, dan heeft het feit niets om aan te haken. Je wil het feit niet weggooien, want dan mis je omzet. Het permanent in een bak "Onbekend" duwen is ook geen optie, want dan verlies je de link zodra de klant wel opduikt.

Waarom komt een dimensie te laat?

In een klassieke nachtelijke batch waar eerst alle dimensies laden en dan pas de feiten, gebeurt dit zelden. Het duikt op zodra de volgorde niet meer gegarandeerd is. Het kassasysteem stuurt een verkoop meteen door, maar het klantenbestand komt uit een apart CRM dat maar één keer per nacht draait, dus de transactie is er uren voor de klantfiche. Bij event-gedreven pipelines is het nog scherper: feiten komen binnen op het moment dat ze gebeuren, en wachten tot de dimensie zeker geladen is, zou je real-time laag traag maken.

De standaardaanpak volgens Kimball

Ralph Kimball beschrijft één nette oplossing: maak op het moment van laden een tijdelijke dimensierij aan, een inferred member of placeholder. Die rij bevat wat je al weet, namelijk de natuurlijke sleutel uit het feit, plus generieke "Onbekend"-waarden voor de rest en een vlag die aangeeft dat de rij nog afgeleid is. Kimball verwoordt het mechanisch: botst de ETL op een broncode die nog niet in de dimensie zit, dan maakt ze meteen een dimensierij aan, haalt de surrogaatsleutel op en geeft die terug aan de feitverwerking. Het feit laadt door met een geldige link.

1. Detecteer de ontbrekende sleutel. Het feit verwijst naar een natuurlijke sleutel die nog geen dimensierij heeft.

2. Maak de inferred member aan. Nieuwe dimensierij met de natuurlijke sleutel, een verse surrogaatsleutel, de vlag op afgeleid en "Onbekend" voor de beschrijvende kolommen.

3. Laad het feit meteen. Het feit krijgt de surrogaatsleutel van de inferred member en gaat door.

4. Vul later de echte waarden in. Zodra de dimensiegegevens alsnog binnenkomen, overschrijf je de placeholder met een Type 1 update. De surrogaatsleutel blijft dezelfde, dus geen enkele feitrij hoeft herschreven te worden.

Dat laatste is de kern: omdat de surrogaatsleutel niet verandert, vul je enkel de lege plekken op de dimensierij in. De techniek leunt op het idee van Slowly Changing Dimensions en op een goed gekozen surrogaatsleutel.

Voorbeeld met een klantdimensie

Een webshop registreert om 14:32 een verkoop op naam van klant C-8842. Die klant zit nog niet in de klantdimensie, want de CRM-sync draait pas 's nachts.

De ETL maakt meteen een inferred member aan: surrogaatsleutel 50231, natuurlijke sleutel C-8842, naam en stad en segment op "Onbekend", en de vlag op afgeleid. De verkoop laadt met surrogaatsleutel 50231 en telt gewoon mee in de omzet van vandaag.

De volgende ochtend brengt de CRM-sync de echte klant binnen: C-8842 is Els Vermeulen uit Hasselt, segment "KMO". De ETL vindt rij 50231 via de natuurlijke sleutel en overschrijft de "Onbekend"-velden met de echte waarden. De vlag springt van afgeleid naar bevestigd. Surrogaatsleutel 50231 is nooit veranderd, dus de verkoop van gisteren wijst nu vanzelf naar de volledige klantfiche.

Laatkomende dimensie versus laatkomend feit

Het spiegelbeeld van een laatkomende dimensie is een laatkomend feit: een feit dat pas dagen of weken later binnenkomt, terwijl de dimensie ondertussen al meerdere historische versies heeft. Hier bestaat de context dus wel, en de vraag is aan welke versie het late feit moet hangen. Het antwoord is de versie die actief was op het moment van de gebeurtenis. Je zoekt in de dimensie de rij waarvan begin- en einddatum de transactiedatum omsluiten, en gebruikt die surrogaatsleutel. Net daarom is SCD Type 2 zo belangrijk: zonder versiegeschiedenis kan je die juiste rij niet terugvinden.

Stel dat een verkoop van drie weken geleden vandaag pas binnenkomt en klant C-8842 intussen verhuisd is van Hasselt naar Gent. In de dimensie staan dan twee Type 2-versies. Het late feit hoort bij de Hasselt-versie, want dat was de actieve rij op de verkoopdag. Je pikt dus niet de nieuwste rij, maar de rij die op de feitdatum geldig was. Het verschil met een laatkomende dimensie zit in welke kant te laat is: daar mist de context en maak je een placeholder, hier bestaat de context al en zoek je de juiste versie op datum.

Waar moet je op letten bij het gebruik van laatkomende dimensies

Ruim je inferred members echt op
Een placeholder die maanden op "Onbekend" blijft staan, is een gat in je rapportering. Plan een controle die openstaande afgeleide rijen opvolgt en waarschuwt als er gegevens ontbreken die er al hadden moeten zijn.

Vermijd dubbele inferred rijen voor dezelfde sleutel
Komen twee feiten voor dezelfde nieuwe klant vlak na elkaar binnen, dan mag je maar één placeholder aanmaken. Laat je aanmaaklogica eerst de natuurlijke sleutel controleren, anders krijg je twee dimensierijen voor dezelfde klant.

Leg vast wat er gebeurt bij het invullen
De eerste keer dat de echte gegevens arriveren, is dat een Type 1 overschrijving van de placeholder. Daarna volg je het gewone SCD-beleid van die dimensie, dus mogelijk Type 2 voor latere wijzigingen. Documenteer dat, anders weet niemand nog wanneer welke logica geldt.

Communiceer de "Onbekend"-periode naar de business
Zolang een placeholder niet ingevuld is, verschijnt een deel van je omzet onder "Onbekende klant". Wie dat niet weet, denkt aan een fout in het rapport. Benoem het openlijk zodat gebruikers begrijpen waarom een segment tijdelijk leeg is.