Sleutels van tabellen

Een sleutel is een attribuut of combinatie van attributen in een tabelrij, waarmee die rij binnen de tabel uniek wordt aangewezen. Voor de sleutel worden attributen gebruikt die de eigenschappen beschrijven die een entiteit binnen zijn verzameling (zijn type) uniek maken. Zo wijst een Nederlands kenteken van een auto één en niet meer dan één auto binnen Nederland aan. Voor de tabel ‘auto’ kan het kenteken dus als sleutel worden gehanteerd.

Een sleutel is een belangrijk onderdeel van een tabel, omdat het systeem er later mee in staat is om de juiste entiteitbeschrijvingen uit de administratie op te halen. Een opdracht bijvoorbeeld aan de salarisdatabase in de trant van: "Verhoog het salaris van de medewerker Jan met 3,2%" kan fouten tot gevolg hebben, omdat ‘Jan’ niet iets is, waarmee één enkele medewerker uniek in de administratie wordt aangewezen. Liever gebruiken we daarvoor een medewerkernummer of een combinatie van gegevens, zoals de achternaam en de geboortedatum. We krijgen dan operaties in de trant van:

"Verhoog het salaris van de medewerker J.A.N. Mulder, geboren op 23-3-1951 met 3,2%",
of:
"Verhoog het salaris van de medewerker met nummer 63709 met 3,2%".

Als we naar de attribuuttypen in een tabel kijken, dan vinden we veelal meer attribuuttypen of combinaties van attribuuttypen, waarmee een entiteitbeschrijving uniek kan worden aangewezen. Bijvoorbeeld kan dit binnen eenzelfde tabel zijn:

medewerkernummer
achternaam+ voorletters + postcode + huisnummer
achternaam + geboortedatum

Al deze attribuuttypen of combinaties daarvan worden kandidaat-sleutel genoemd. Een tabel heeft altijd minstens een kandidaat-sleutel, maar het kunnen er ook meer zijn.

Bij het zoeken naar kandidaat-sleutels vormt het proces-gegevensmodel de voornaamste bron. In de vorm van de bepaalt-regel zijn daar de kandidaat-sleutels benoemd. In zo’n model kan bijvoorbeeld de volgende regel voorkomen:

dag uit
medewerker is geboren op dag
en
naam uit
medewerker is in het register van de Burgerlijke Stand ingeschreven onder de naam
bepaalt
medewerker

We weten dan, dat de naam en de dag (in de rol van geboortedatum) in ieder geval een kandidaat-sleutel vormen voor de tabel MEDEWERKER.

Uit de verschillende kandidaat-sleutels wordt één sleutel gekozen, die we daadwerkelijk zullen gaan gebruiken om rijen uniek aan te wijzen. Deze wordt de primaire sleutel genoemd. Ten opzichte van kandidaat-sleutels wordt aan een primaire sleutel de extra eis gesteld dat het betreffende attribuuttype in iedere rij een reële waarde moet hebben. Als we bijvoorbeeld niet van iedere medewerker weten wanneer deze is geboren, dan kan de combinatie van achternaam en geboortedatum weliswaar een kandidaat-sleutel zijn, maar geen primaire sleutel. Ook niet, als we voor de geboortedatum een defaultwaarde invoeren als we de echte datum niet kennen.

Daarnaast wordt de onderhoudsgevoeligheid van de gegevens en de kans op fouten in de gegevensverzameling gunstig beïnvloed, indien we aan een primaire sleutel nog de volgende eisen stellen:

Het attribuuttype mag niet wijzigbaar zijn. Het is bijvoorbeeld niet handig om postcode en huisnummer te gebruiken als primaire sleutel in de tabel ‘medewerker’, omdat deze kan verhuizen.
De primaire sleutel van een rij mag, na het verwijderen van die rij, niet worden hergebruikt voor de identificatie van een andere rij in de tabel. Het is bijvoorbeeld onhandig om een personeelsnummer van een medewerker, die uit dienst is getreden, te hergebruiken voor een nieuwe medewerker. Ergens in de organisatie kunnen namelijk nog gegevens over deze ex-medewerker voorkomen onder diens primaire sleutel.

In een aantal gevallen wordt gekozen om geen van de kandidaat-sleutels als primaire sleutel te kiezen, maar daarvoor een afzonderlijk nummer te kiezen. Een dergelijk nummer is dan betekenisloos, dat wil zeggen beschrijft geen eigenschap van de entiteit, maar is uitsluitend bedoeld om de entiteitbeschrijving (= rij uit te tabel) uniek te kunnen aanwijzen.

Veelal kan het automatisch door een systeem worden bepaald op het moment van opvoeren van een entiteitbeschrijving. In die gevallen blijft het feit dat nummers worden gebruikt bij voorkeur verborgen voor de gebruikers. Het verschijnt bijvoorbeeld niet op beeldschermen en wordt uitsluitend gebruikt voor de juiste werking van het systeem. We spreken dan over een administratief nummer, dat niet in het Semantisch gegevensmodel (SGM) is gespecificeerd.

In andere gevallen gaat een nummer een eigen plaats verwerven binnen (en soms ook buiten) de organisatie. De gebruiker weet van het bestaan en gebruikt het dan ook regelmatig. Bekende voorbeelden hiervan zijn het sociaal-fiscaal nummer of het inschrijvingsnummer bij de Kamer van Koophandel. Andere veel gebruikte nummers zijn in dit verband: typenummers, medewerkernummers, patiëntnummers, artikelnummers etc. Omdat de gebruiker het bestaan van deze nummers kent zijn ze ook opgenomen in het SGM.

Voor een nummer wordt veelal gekozen in de volgende twee gevallen:

de combinatie van attribuuttypen, die de kandidaat-sleutel vormen is dermate uitgebreid, dat het gebruik ervan complex wordt. Indien bijvoorbeeld voor het entiteittype patiënt als enige kandidaat-sleutel te vinden is diens achternaam + voorletters + geboortedatum + postcode + huisnummer dan zal men al snel kiezen voor een administratief nummer;
er is geen kandidaat-sleutel te vinden waarvan de attribuuttypen altijd een waarde hebben. Dat doet zich bijvoorbeeld voor indien de geboortedatum van de patiënt, medewerker etc. niet altijd is geregistreerd. In zo’n situatie lopen we het gevaar, dat niet wordt voldaan aan de eis van entiteitintegriteit.

Lees verder: Relaties tussen tabellen