De status van dit document is voorlopig en zou nog kunnen wijzigen.
Identificeren
Volgens het Van Dale-woordenboek betekent identificeren zoveel als “het vaststellen van de identiteit”. Hiervoor is een kenmerk nodig waarmee we hetgeen waarvan we de identiteit willen vaststellen binnen een bepaalde context zonder twijfel kunnen onderscheiden van andere dingen. In registers gebruiken we hiervoor in de regel een identificatieveld, gevuld met een primaire sleutel. Zo’n veld “saves a database ID field in an object to maintain identity between an in-memory object and a database row” (Martin Fowler). Fowler stelt ook dat “in essence, Identity Field is mind-numbingly simple. All you do is store the primary key of the relational database table in the object’s fields”.
Kenmerken van primaire sleutels
We zouden het voor wat betreft ‘identificeren’ kunnen laten bij de constatering dat heel simpel is. De keuze voor wat we in het identificatieveld invullen kan echter verstrekkende gevolgen hebben voor de bruikbaarheid, performance en evolueerbaarheid van het register. Dit betekent dat we goed moeten nadenken over de vorm van onze primaire sleutels. Het loont daarom te onderzoeken welke kenmerken daarvan we belangrijk vinden. Dit levert het volgende lijstje op:
- uniciteit
- onveranderlijkheid
- communiceerbaarheid
- prestatiebevordering
- betekenisloosheid
Unicititeit schrijft voor dat de primaire sleutel binnen een bepaalde context uniek moet zijn, dus afwijkend van alle andere primaire sleutels binnen de context. Omdat die context in een federatief systeem potentieel erg groot of zelfs onbegrensd is, heeft een primaire sleutel met een überhaupt (bijna) gegarandeerd uniek karakter zoals Universally unique identifier (UUID) de voorkeur boven sleutels waarvoor dat unieke karakter alleen binnen systeemgrenzen kan worden gegarandeerd zoals incrementeel oplopende sleutels.
Onveranderlijkheid betekent dat een eenmaal toegekende primaire sleutel niet meer verandert. Omdat het bijwerken van primaire sleutels in bestaande records tot fouten kan leiden is dit in ’tradtionele’ opslagsystemen een zwaarwegende wens. Binnen opslagsystemen die werken op basis van het append onlyprincipe kunnen bestaande records niet worden bijgewerkt. Dientengevolge is onveranderlijkheid van primaire sleutels binnen systemen die volgens dit prince werken een eis.
Betekenisloosheid gaat over eventuele informatie die aan de vorm van een primaire sleutel te ontlenen is, en heeft te maken met het uit die sleutel af te leiden informatie over registratiecontext, -moment en -volgorde. In geval van bijvoorbeeld een ordernummer dat (deels) bestaat uit de datum waarop de order is geplaatst is dit waarschijnlijk geen probleem, of misschien vanwege communiceerbaarheid (zie hieronder) zelfs gewenst. Binnen ‘Uit betrouwbare bron’ werken we echter aan een generiek register, zonder vooraf vastgesteld toepassingsgebied. Dit register kan gebruikt gaan worden voor vastlegging van (zeer) gevoelige (persoons)gegevens. Dit maakt het voorstelbaar dat niet iedere gebruiker geautoriseerd is om informatie over bijvoorbeeld het moment van vastlegging in te zien. Deze informatie mag in dat geval via de sleutel niet alsnog ‘weglekken’.
Communiceerbaarheid heeft te maken met de aansluiting tussen een businessdomein en de IT-voorziening(en) die zo’n domein ondersteunen. De begrijpelijkheid en doorontwikkelbaarheid van die systemen zijn erbij gebaat dat ze zo dicht mogelijk aansluiten bij de gebruiken en werkwijzen van het businessdomein. Communiceerbaarheid is een belangrijke pijler onder Fully Communication Oriented Information Modeling (FCO-IM), waarbinnen wordt aangenomen dat ‘identifiers’ (of primaire sleutels) zijn afgleid van bedrijfsregels en door een domeinexpert aan een modelleur worden uitgelegd.
Prestatiebevordering betekent dat de vorm van primaire sleutel er zoveel mogelijk aan bijdraagt dat samenhangende gegevens binnen zo kort mogelijke tijd uit het register kunnen worden opgehaald. Dit kan worden bereikt door primaire sleutels te kiezen die in het businessdomein worden gebruikt om selecties te maken (‘queryen’), deze sleutels niet langer te maken dan nodig en het opslagsysteem in staat te stellen te optimaliseren op basis van uit de sleutel afleidbare vastleggingsvolgorde.
Bovenstaande leidt, binnen de context van ‘Uit betrouwbare bron’, tot de volgende ordnening van belang van deze kenmerken:
- uniciteit -> MUST
- onveranderlijkheid -> MUST
- betekenisloosheid -> MUST
- communiceerbaarheid -> SHOULD
- prestatiebevordering -> SHOULD
Duidelijk is echter dat deze kenmerken niet allemaal met elkaar verenigbaar zijn. Bijvoorbeeld:
- De eis voor uniciteit is gebaat bij een complexe identificator waarvan (bijna) geen tweede kan bestaan, terwijl de wens naar communiceerbaarheid vraagt om een idenitificator die eenvoudig mondeling of schriftelijk kan worden uitgewisseld.
- De eis aan onveranderlijkheid bost met de wens naar herkenbaarheid voor ‘de business’, waarbinnen inzichten over hoe te identificeren over tijd kunnen veranderen.
- En de wens via de primaire sleutel geen contextinformatie te lekken staat op gespannen voet met de wens naar optimale prestaties, omdat opslagsystemen efficiënter werken op basis van incrementeel oplopende identificatoren.
Ergo: het is onmogelijk aan alle gewenste kenmerken tegelijkertijd invulling geven. Dat betekent dat we moeten zoeken naar de minst kwade optie.
Soorten primaire sleutels
Om bovengenoemde kenmerken beargumenteerd af te kunnen wegen, is het behulzaam te kijken naar de soorten (primaire) sleutels die worden onderscheiden:
- Een natuurlijke sleutel is een unieke, in een register gebruikte sleutel die ook in de wereld daarbuiten (dus in het domein van ‘de business’) gebruikt wordt om het in het register beschreven ding aan te duiden. Dit type sleutel heeft dus zowel binnen als buiten het register betekenis. Natuurlijke sleutels worden ook wel ’logisch’, ‘functioneel’ of ‘betekenisvol’ genoemd.
- Een surrogaatsleutel is een unieke, in een register gebruikte sleutel die in de wereld daarbuiten (dus in het domein van ‘de business’) niet gebruikt wordt om het in het register beschreven ding aan te duiden. Dit type sleutel heeft dus alleen binnen de context van het register betekenis. Surrogaatsleutels worden ook wel ’technisch’ of ‘betekenisloos’ genoemd.
- Een samengestelde sleutel is een sleutel die bestaat uit een samenvoeging (compositie) van meerdere andere sleutels. Dit kunnen zowel natuurlijke als surrogaatsleutels zijn, hoewel dat eerste (veel) meer voor de hand ligt.
Zowel natuurlijke als surrogaatsleutels hebben voor en nadelen.
Natuurlijke sleutels:
- faciliteren door herkenbaarheid binnen businessdomein aansluiting tussen dat domein en ondesteunende IT-middelen.
- ondersteunen uniforme communicatie, omdat het ‘opwaarderen’ van surraatsleutels naar natuurlijke sleutels, met als gevolg dat burgers en bedrijven met wéér een nieuw nummer geconfronteerd worden, wordt voorkomen.
- zijn vrijwel nooit écht onveranderlijk. Zo kunnnen op het eerste gezicht stabiele waarden als bijvoorbeeld een Burgerservicenummer in uitzonderlijke gevallen worden gecorrigeerd, terwijl naamsverandering van een land een verandering van de ISO 3166-landcode tot gevolg kan hebben (Zo had introductie van de naam ‘Timor-Leste’ een wijziging van de landcode van TP naar TL tot gevolg).
Surrogaatsleutels:
- kunnen zodanig gekozen worden dat ze (vrijwel) gegarandeerd uniek zijn (UUID).
- bestaan onafhankelijk van veranderingen in het businessdomein die gevolgen kunnen hebben voor de onveranderlijkheid van de sleutel.
- kunnen zodanig gekozen worden dat ze de prestaties van het register bevorderen (automatisch-oplopende integer, UUIDv7), maar
- omdat de surrogaatsleutel vanwege ontbrekende businessbekenis niet of heel beperkt voor queryen wordt gebruikt, moeten voor dat doel ’extra’ sleutels worden opgeslagen en indexen bijgehouden. Dit beïnvloed de prestaties van het register weer negatief.
De scheiding tussen natuurlijke en surrgaatsleutels is niet hard. Het verleden leert dat surrogaatsleutels vaak voorzien in een (latente) behoefte binnen het businessdomein om eenvoudiger of preciezer te kunnen aanwijzen, waardoor ze langzaamaan veranderen in natuurlijke sleutels. Voorwaarde hiervoor lijkt wel dat zo’n sleutel (in tegenstelling tot bijvoorbeeld een UUID) een enigszins communiceerbaar karakter heeft.
Literatuur
- Introductie in Database Magazine over Logische en technische sleutels door Toon Loonen
- Argumenten bij keuze voor natuurlijke of surrogaatsleutels door Scott Ambler