Het uniek kunnen identificeren van entiteiten is van groot belang voor een datawarehouse. Binnen transactiesystemen die de bron vormen voor een datawarehouse wordt dit doorgaans netjes geregeld door een unieke index te definiëren op de velden die een entiteit identificeren. Op deze manier kan worden afgedwongen dat op ieder moment in de tijd het betreffende veld of combinatie van velden de unieke sleutel vormen van een entiteit binnen het betreffende systeem. Wanneer we vervolgens data uit het betreffende transactiesysteem willen inlezen in een datawarehouse, kunnen we op basis van deze unieke sleutel bepalen bij welke entiteit een bepaald data item hoort.

In deze post wil ik wat dieper ingaan op het concept unieke sleutel. De ene sleutel is de andere niet. Sleutels hebben aspecten die soms over het hoofd worden gezien maar die van wezenlijk belang zijn voor het kunnen ‘volgen’ van een entiteit binnen een bepaald bronsysteem door de tijd heen.

Eeuwig versus Tijdelijk

Vaak wordt er vanuit gegaan dat een unieke sleutel binnen een bronsysteem voor altijd gekoppeld blijft aan een en dezelfde entiteit. Dit is echter een aanname die door de werkelijkheid kan worden ingehaald. In systemen waar gebruikers de mogelijkheid hebben om unieke sleutels te wijzigen, kan het al dan niet bedoeld, gebeuren dat de sleutel die voorheen aan entiteit A was gekoppeld nu verbonden is met entiteit B. Zelfs de veelgebruikte technische sleutel (ook wel surrogaatsleutel genoemd) is wat dat betreft niet veilig. Het kan namelijk voorkomen dat een bestaand transactiesysteem wordt overgezet naar een andere database, waarbij de technische sleutels opnieuw gegenereerd en aan entiteiten gekoppeld worden. In een dergelijk geval is het heel waarschijnlijk dat de technische sleutels gerecycled worden. Kort gezegd: Er zijn unieke sleutels die Eeuwig zijn en er zijn unieke sleutels die Tijdelijk zijn. Wat betreft tijdelijke sleutels is het nog nuttig om te weten of ze alleen Gecontroleerd, of ook Ongecontroleerd, kunnen wijzigen. Van een sleutel die gecontroleerd wijzigt, krijgen we bij ieder geval van wijziging een signaal. Naar aanleiding van dit signaal kunnen we maatregelen nemen zodat we de betreffende entiteit in het bronsysteem kunnen blijven volgen in het datawarehouse. Bij sleutels die ongecontroleerd kunnen wijzigen, kan dat niet en hebben we te maken met een zekere foutkans. Bij een transactiesysteem dat we middels een Changed Data Capture mechanisme volgen, wijzigen tijdelijke sleutels altijd gecontroleerd. Een ander voorbeeld van een gecontroleerd wijzigende tijdelijke sleutel is een surrogaatsleutel binnen een transactiesysteem waarvan we op de hoogte gehouden worden, als er bijvoorbeeld een datamigratie plaatsvindt.

Universeel versus Optioneel

In de loop der tijd kan er voor een bepaald entiteittype een nieuwe unieke sleutel ontstaan. Bijvoorbeeld binnen het basisonderwijs is het sinds een aantal jaren verplicht om in correspondentie over een leerling met overheidsinstanties het centraal uitgegeven onderwijsnummer te gebruiken. Leerlingvolgsystemen zijn dientengevolge uitgebreid met een extra uniek veld ‘Onderwijsnummer’. Voor reeds uitgestroomde leerlingen was echter geen onderwijsnummer beschikbaar. Daarom is in veel systemen het veld ‘Onderwijsnummer’ naast uniek (voor zover ingevuld) ook Optioneel: het mag de waarde NULL bevatten. Omgekeerd kunnen reeds bestaande sleutels in onbruik raken en zo Optioneel worden. De tegenhanger van het kenmerk Optioneel noem ik Universeel.

Sterk versus Zwak

Tot slot kan het voorkomen dat een veld of een combinatie van velden logischer wijze gebruikt kan worden als sleutel maar dat binnen het bronsysteem geen uniciteit wordt afgedwongen. Dit type sleutel noem ik Zwak vanwege de verhoogde foutkans. Dit is een type sleutel dat bij voorkeur vermeden moet worden als identificatiemiddel maar helaas zijn we hier soms, bij gebrek aan beter, op aangewezen. Wanneer we zwakke sleutels gebruiken voor identificatie, doen we er goed aan de mogelijkheid in te bouwen om op zo simpel mogelijke wijze de gevolgen van een achteraf fout gebleken identificatie terug te draaien. Het alternatief is: accepteren dat er een zekere foutmarge is. De tegenhanger van het kenmerk Zwak noem ik Sterk: uniciteit wordt afgedwongen in het bronsysteem.

Een taxonomie van sleutels

Alle sleutels zijn te karakteriseren met een combinatie van bovenstaande kenmerken. In de onderstaande tabel zijn alle mogelijke combinaties weergegeven. Iedere combinatie in de tabel staat dus voor een type sleutel. Per type sleutel is aangegeven of deze een 100% betrouwbare (+) mogelijkheid biedt om een entiteit in een bepaald bronsysteem door de tijd heen te volgen in het datawarehouse of niet (-).

Let wel dat ook de classificatie van een sleutel een momentopname is. Door omstandigheden kunnen hierin wijzigingen optreden. Een sleutel die bijvoorbeeld op een bepaald moment Universeel is, kan in de loop der tijd in onbruik raken en worden vervangen door een andere sleutel. Vanaf dat moment is hij Optioneel.

Ieder datawarehouse dat gevoed wordt met data die op discrete momenten in de tijd (dus niet continue) aan een bronsysteem wordt onttrokken, loopt het gevaar, het spoor van bepaalde entiteiten kwijt te raken als er niet 100% veilige sleutels in het spel zijn. In wezen is het datawarehouse dan gebouwd op drijfzand. Mijn inschatting is dat dit vaker wel dan niet aan hand is. Ga maar na: de meeste bronsystemen leven in het hier en nu. Ze houden vaak geen rekening met wijzigingen van unieke sleutels door de tijd heen. Enige relativering is hier wel op zijn plaats. Unieke sleutels die op de werkvloer een rol spelen (de niet-technische sleutels dus), hebben doorgaans niet de neiging om om de haverklap van waarde te veranderen. Dit zou op de werkvloer namelijk resulteren in een voortdurende zoektocht naar de juiste informatie binnen een bronsysteem. Het dagelijks werk zou hierdoor sterk belemmerd worden. Aan de andere kant geldt ook hier de wet van Murphy: ’Anything that can go wrong will go wrong’.

Daarom is het goed je te realiseren waar dit probleem kan optreden. Nog beter is het om dit probleem op een of andere manier te kwantificeren. Het is onmogelijk om de situaties te identificeren waar dit optreedt, immers dan zou het probleem niet bestaan. Wat we wel kunnen doen is bijvoorbeeld iedere keer dat het datawarehouse wordt geladen, tellen hoeveel sleutelwaarden er in het verleden wel in het bronsysteem stonden  maar nu niet meer. Een andere interessante meting is, daar waar een entiteit met meerdere sleutels identificeerbaar is, te tellen hoe vaak een bepaalde sleutelwaarde door de tijd heen is gecombineerd met verschillende waarden van de alternatieve sleutel. Zo zijn er nog meer metingen te verzinnen (Suggesties zijn zeer welkom!). Een oplossing is dit niet maar het geeft wel enigszins grip op de situatie en helpt ons om iets te zeggen over foutmarge.