Er lopen her en der enthousiaste discussies over het al dan niet gebruiken van surrogaatsleutels bij datamodel implementaties. Deze discussie binnen data warehousing wil ik hier even loslaten, deze is sterk verwaterd door de gekozen modellering 3NF, Ster of Data Vault.
Bij OLTP systemen valt er regelmatig wel wat te zeggen van het gebruik van Surrogaat sleutels. Er is een snelle mapping naar objectmodellen, er is minder pijn in de applicatie bij wijziging van business sleutels, en zo kunnen er redenen genoeg zijn om een surrogaat sleutel als primary key voor de tabellen te kiezen.

Het is echter van essentieel belang dat de business keys wel onderkend worden, en ook altijd in de database als constraint afgedwongen worden. Wet van Wout: “Voor elke constraint die niet in de database afgedwongen is ontstaat na verloop van tijd een rij die niet aan deze constraint voldoet” De programma’s kunnen best de constraint proberen af te dwingen, maar op een moment wordt door migratie, handmatige actie of tijdelijk in productie nemen van een buggy programma of bewakende trigger de constraint toch overtreden.

Een nog belangrijkere wet vind ik: “Een surrogaat sleutel mag een systeem nooit verlaten”. Een surrogaat sleutel die het systeem verlaat is namelijk niet meer technisch noch mag door het initiërende system willekeurig aangepast worden. De surrogaatsleutel die het systeem verlaat wordt onbedoeld een business key die met de bijbehorende hoeveelheid aandacht bewaakt en gepubliceerd moet worden. Verwijdering moet in alle verwante systemen geverifieerd worden, garantie op unieke uitgifte bewaakt worden, aanpassing of hernummering moet door de systemen heen gepropageerd worden, noem maar op. Voorbeeld is personeelsnummer of klantnummer. Nog zwaarder is het als de sleutel de organisatie verlaat. Denk maar eens na over de hoeveelheid organisatie die nodig is voor beheren van het sofinummer of het kenteken van een auto.
Als een surrogaat sleutel zo beheerd moet worden zijn alle voordelen van zo’n sleutel ongeveer verdwenen en kan beter serieus over centrale, bewaakte uitgifte van een business key nagedacht worden, maar dan met in volle bewustzijn van de hoeveelheid werk die dit meebrengt.

Ik heb bij een klant gewerkt waar voor een ordersysteem prachtig 3NF gemodelleerd alle tabellen volgens de richtlijnen van Oracle en regelen der kunst gemodelleerd waren. Een werkelijk prachtig stukje werk, waar goed en gedegen over nagedacht was. Technische id’s voor de primary keys en altijd een unique index op de business key. Behalve bij orderregels. Ik kan die gedachten wel volgen. Het ordernummer is een technische sleutel verheven tot business key, primaty key orderId. De business key voor orderregel wordt dat orderId met iets als orderregel volgnummer? Een moeilijk te genereren volgnummer, terwijl er al een surrgogaatsleutel orderregelId is die vergelijkbare inhoud heeft. Laten we die maar weglaten. Later tijdens het koppelen van het systeem aan het mainframe, waar de levering gedaan werd, onstond een probleem. De status van levering werd per stuks geleverd en soms werd 1 artikel van de 2 bestelde afgeleverd, waardoor de orderregel met aantal 2 eigenlijk 2 statussen had.
Als er een business key had bestaan had men deze vast gehouden en een nieuwe entiteit orderregel in status bedacht of zo. Maar de ontwerper/programmeur voelde zich bevoegd om de orderregel te splitsen in twee regels met aparte statussen, met de som van de aantallen gelijk aan het bestelde aantal. Bevoegd omdat de sleutel die gebruikt was toch maar technisch was, en die dus op technische gronden opnieuw uitgegeven of zelfs verwijderd kon worden.
Nu was er een data warehouse aan dit systeem gekoppeld die niet anders kon dan de technische sleutel orderregelId als business key bombarderen; een andere identiteit had de regel niet. Consternatie alom toen ineens orderregels verwenen!
Zo was met de beste intenties de surrogaatsleutel buiten het systeem getreden, niet verheven tot business key en niet in identiteit of uniciteit niet te bewaken in welk systeem dan ook.