Skip to content

Basissleutels die databasebeheer eenvoudig maken

15 de juni de 2021
high angle view of technicians working in server room 580501777 59d7dbd422fa3a001179ba2c 60d2a9b38c714b9bbe5127049e682cc5

Zoals u wellicht al weet, gebruiken databases tabellen om informatie te ordenen. (Als u geen basiskennis hebt van databaseconcepten, lees dan Wat is een database?) Elke tabel bestaat uit een aantal rijen, die elk overeenkomen met een enkel databaserecord. Dus, hoe houden databases al deze records recht? Het is door het gebruik van sleutels.

Primaire sleutels

Het eerste type sleutel dat we zullen bespreken, is de primaire sleutel. Elke databasetabel moet een of meer kolommen hebben die zijn aangewezen als de primaire sleutel. De waarde van deze sleutel moet uniek zijn voor elk record in de database. Stel bijvoorbeeld dat we een tabel hebben met de naam Werknemers die personeelsinformatie bevat voor elke werknemer in ons bedrijf. We moeten een geschikte primaire sleutel selecteren die elke werknemer op unieke wijze identificeert. Uw eerste gedachte zou kunnen zijn om de naam van de werknemer te gebruiken. Dat zou niet goed uitpakken, want het is denkbaar dat je twee medewerkers met dezelfde naam in dienst neemt. Een betere keuze zou kunnen zijn om een ​​uniek werknemers-ID-nummer te gebruiken dat u aan elke werknemer toewijst wanneer ze worden aangenomen. Sommige organisaties kiezen ervoor om voor deze taak burgerservicenummers (of vergelijkbare overheidsidentificaties) te gebruiken, omdat elke werknemer er al een heeft en ze gegarandeerd uniek zijn. Het gebruik van burgerservicenummers voor dit doel is echter zeer controversieel vanwege privacyoverwegingen. (Als u voor een overheidsorganisatie werkt, is het gebruik van een sofinummer mogelijk niet legaal volgens de privacywet van 1974.) Om deze reden zijn de meeste organisaties overgestapt op het gebruik van unieke identificatiegegevens (werknemers-ID, studenten-ID, enz.) .) die deze privacyzorgen niet delen. Nadat u een primaire sleutel hebt gekozen en de database hebt ingesteld, zal het databasebeheersysteem de uniciteit van de sleutel afdwingen. Als u een record in een tabel probeert in te voegen met een primaire sleutel die een bestaande record dupliceert, mislukt het invoegen. De meeste databases zijn ook in staat om hun eigen primaire sleutels te genereren. Microsoft Access kan bijvoorbeeld worden geconfigureerd om het gegevenstype AutoNummering te gebruiken om een ​​unieke ID toe te wijzen aan elk record in de tabel. Hoewel dit effectief is, is dit een slechte ontwerppraktijk omdat het u een betekenisloze waarde geeft in elk record in de tabel. Waarom zou je die ruimte niet gebruiken om iets nuttigs op te bergen?

Buitenlandse sleutels

Een ander type is de externe sleutel, die wordt gebruikt om relaties tussen tabellen te maken. In de meeste databasestructuren bestaan ​​natuurlijke relaties tussen tabellen. Terugkerend naar onze werknemersdatabase, stel u voor dat we een tabel met afdelingsinformatie aan de database wilden toevoegen. Deze nieuwe tabel zou Afdelingen kunnen heten en zou een grote hoeveelheid informatie over de afdeling als geheel bevatten. We zouden ook informatie willen opnemen over de medewerkers van de afdeling, maar het zou overbodig zijn om dezelfde informatie in twee tabellen te hebben (Medewerkers en Afdelingen). In plaats daarvan kunnen we een relatie tussen de twee tabellen maken. Laten we aannemen dat de tabel Afdelingen de kolom Afdelingsnaam als primaire sleutel gebruikt. Om een ​​relatie tussen de twee tabellen te maken, voegen we een nieuwe kolom toe aan de tabel Medewerkers met de naam Afdeling. Vervolgens vullen we de naam in van de afdeling waartoe elke medewerker behoort. We informeren het databasebeheersysteem ook dat de kolom Afdeling in de tabel Medewerkers een externe sleutel is die verwijst naar de tabel Afdelingen. De database zal vervolgens de referentiële integriteit afdwingen door ervoor te zorgen dat alle waarden in de kolom Afdelingen van de tabel Werknemers overeenkomende vermeldingen hebben in de tabel Afdelingen. Merk op dat er geen uniciteitsbeperking is voor een externe sleutel. We hebben mogelijk (en hoogstwaarschijnlijk) meer dan één medewerker die tot één afdeling behoort. Evenzo is er geen vereiste dat een item in de tabel Afdelingen een corresponderend item in de tabel Werknemers heeft. Het is mogelijk dat we een afdeling hebben zonder medewerkers.