Er wordt een relatie tot stand gebracht tussen twee databasetabellen wanneer een tabel een externe sleutel gebruikt die verwijst naar de primaire sleutel van een andere tabel. Dit is het basisconcept achter de term relationele database.
Hoe een buitenlandse sleutel werkt om een relatie op te bouwen
Een primaire sleutel identificeert elk record in de tabel op unieke wijze. Het is een type kandidaatsleutel die meestal de eerste kolom in een tabel is en die automatisch door de database kan worden gegenereerd om ervoor te zorgen dat deze uniek is. Een refererende sleutel is een andere kandidaatsleutel (niet de primaire sleutel) die wordt gebruikt om een record te koppelen aan gegevens in een andere tabel.
Beschouw bijvoorbeeld deze twee tabellen die aangeven welke leraar welke cursus geeft. Hier is de primaire sleutel van de tabel Courses Course_ID. De externe sleutel is Teacher_ID:
| Cursus_ID | Cursusnaam | Teacher_ID |
|---|---|---|
| Cursus_001 | Biologie | Leraar_001 |
| Cursus_002 | Wiskunde | Leraar_002 |
| Cursus_003 | Engels | Leraar_003 |
Je kunt zien dat de externe sleutel in Cursussen overeenkomt met een primaire sleutel in Docenten:
| Teacher_ID | Teacher_Name |
|---|---|
| Leraar_001 | Carmen |
| Leraar_002 | Veronica |
| Leraar_003 | Jorge |
We kunnen zeggen dat de externe sleutel Teacher_ID heeft geholpen om een relatie tot stand te brengen tussen de cursussen en de tabellen voor docenten.
Soorten databaserelaties
Door externe sleutels of andere kandidaatsleutels te gebruiken, kunt u drie soorten relaties tussen tabellen implementeren:
Een-op-een
Dit type relatie staat slechts één record toe aan elke kant van de relatie. De primaire sleutel heeft betrekking op slechts één record (of geen) in een andere tabel. In een huwelijk heeft bijvoorbeeld elke echtgenoot slechts één andere echtgenoot. Dit soort relatie kan in een enkele tabel worden geïmplementeerd en gebruikt daarom geen externe sleutel.
Een-op-veel
Een een-op-veel-relatie maakt het mogelijk dat een enkele record in de ene tabel wordt gerelateerd aan meerdere records in een andere tabel. Overweeg een bedrijf met een database met tabellen met klanten en bestellingen.
Een enkele klant kan meerdere bestellingen kopen, maar een enkele bestelling kan niet aan meerdere klanten worden gekoppeld. Daarom zou de tabel Orders een externe sleutel bevatten die overeenkomt met de primaire sleutel van de tabel Klanten, terwijl de tabel Klanten geen externe sleutel zou hebben die naar de tabel Orders verwijst.
Veel-op-veel
Dit is een complexe relatie waarin veel records in een tabel kunnen worden gekoppeld aan veel records in een andere tabel. Ons bedrijf heeft bijvoorbeeld waarschijnlijk de tabellen Klanten en Bestellingen nodig, en waarschijnlijk ook een tabel Producten.
Nogmaals, de relatie tussen de tabel Klanten en Bestellingen is een-op-veel, maar houd rekening met de relatie tussen de tabel Bestellingen en Producten. Een bestelling kan meerdere producten bevatten en een product kan aan meerdere bestellingen worden gekoppeld, aangezien meerdere klanten een bestelling kunnen plaatsen die enkele van dezelfde producten bevat. Voor dit soort relaties zijn minimaal drie tabellen nodig.
Waarom zijn databaserelaties belangrijk?
Het tot stand brengen van consistente relaties tussen databasetabellen helpt de gegevensintegriteit te waarborgen en draagt bij aan de normalisatie van de database. Wat als we bijvoorbeeld geen tabellen zouden koppelen via een externe sleutel en in plaats daarvan de gegevens in de tabellen Cursussen en Docenten zouden combineren, zoals:
| Teacher_ID | Teacher_Name | Cursus |
|---|---|---|
| Leraar_001 | Carmen | Biologie, Wiskunde |
| Leraar_002 | Veronica | Wiskunde |
| Leraar_003 | Jorge | Engels |
Dit ontwerp is inflexibel en schendt het eerste principe van databasenormalisatie, First Normal Form, dat stelt dat elke tabelcel een enkel, afzonderlijk stuk gegevens moet bevatten.
Of misschien hebben we besloten om een tweede record toe te voegen voor Carmen, om 1NF af te dwingen:
| Teacher_ID | Teacher_Name | Cursus |
|---|---|---|
| Leraar_001 | Carmen | Biologie |
| Leraar_001 | Carmen | Wiskunde |
| Leraar_002 | Veronica | Wiskunde |
| Leraar_003 | Jorge | Engels |
Dit is nog steeds een zwak ontwerp en introduceert onnodige duplicatie en zogenaamde anomalieën bij het invoegen van gegevens, wat betekent dat het kan bijdragen aan inconsistente gegevens. Als een leraar bijvoorbeeld meerdere records heeft, wat als sommige gegevens moeten worden bewerkt, maar de persoon die de gegevensbewerking uitvoert, zich niet realiseert dat er meerdere records bestaan? De tabel zou dan verschillende gegevens voor dezelfde persoon bevatten, zonder enige duidelijke manier om deze te identificeren of te vermijden.
Door deze tabel in twee tabellen te splitsen, Docenten en Cursussen, wordt de juiste relatie tussen de gegevens gecreëerd en daardoor wordt de consistentie en nauwkeurigheid van de gegevens gegarandeerd.
