Er wordt een relatie gelegd tussen twee databasetabellen wanneer een tabel een externe sleutel heeft 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 tot stand te brengen
Laten we de basisprincipes van primaire en externe sleutels bekijken. Een primaire sleutel identificeert op unieke wijze elk record in de tabel. Het is een type kandidaatsleutel die meestal de eerste kolom in een tabel is en automatisch door de database kan worden gegenereerd om te zorgen dat deze uniek is.
Een externe sleutel is een andere sleutel (niet de primaire sleutel) die wordt gebruikt om een record te koppelen aan gegevens in een andere tabel.
Bekijk bijvoorbeeld deze twee tabellen die aangeven welke docent welke cursus geeft.
Hier is de primaire sleutel van de Courses-tabel Course_ID. Zijn buitenlandse sleutel is Teacher_ID:
| Cursus id | Cursus naam | Teacher_ID |
|---|---|---|
| Course_001 | Biologie | Teacher_001 |
| Course_002 | Wiskunde | Teacher_001 |
| Course_003 | Engels | Teacher_003 |
U kunt zien dat de foreign key in Courses overeenkomt met een primaire sleutel in Teachers:
| Teacher_ID | Naam leraar |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Veronica |
| Teacher_003 | Jorge |
We kunnen zeggen dat de foreign key van Teacher_ID heeft geholpen om een verhouding tussen de vakken Cursussen en Docenten.
Typen databaserelaties
Met behulp van externe sleutels of andere kandidaat-sleutels kunt u drie soorten relaties tussen tabellen implementeren:
Een op een: Dit type relatie staat slechts één record aan elke kant van de relatie toe.
De primaire sleutel heeft betrekking op slechts één record - of geen - in een andere tabel. In een huwelijk heeft elke echtgenoot bijvoorbeeld slechts één andere echtgenoot. Dit soort relaties kan in een enkele tabel worden geïmplementeerd en gebruikt daarom geen externe sleutel.
Een te veel: Een één-op-veel relatie maakt het mogelijk dat een enkele record in een tabel gerelateerd is aan meerdere records in een andere tabel.
Overweeg een bedrijf met een database met tabellen voor klanten en orders.
Een enkele klant kan meerdere bestellingen kopen, maar een enkele bestelling kan niet aan meerdere klanten worden gekoppeld. Daarom bevat de tabel Orders een externe sleutel die overeenkomt met de primaire sleutel van de tabel Klanten, terwijl de tabel Customers geen externe sleutel zou hebben die verwijst naar de tabel Orders.
Veel te veel: Dit is een complexe relatie waarin veel records in een tabel kunnen verwijzen naar veel records in een andere tabel. Ons bedrijf heeft bijvoorbeeld waarschijnlijk niet alleen tabellen met klanten en bestellingen nodig, maar heeft waarschijnlijk ook een productentabel nodig.
Nogmaals, de relatie tussen de tabel Klanten en Orders is één-op-veel, maar houd rekening met de relatie tussen de tabel Orders en Producten. Een bestelling kan meerdere producten bevatten en een product kan aan meerdere bestellingen worden gekoppeld: verschillende klanten kunnen een bestelling plaatsen die een aantal van dezelfde producten bevat. Dit soort relatie vereist minimaal drie tabellen.
Wat zijn Database Relaties belangrijk?
Het tot stand brengen van consistente relaties tussen databasetabellen helpt de gegevensintegriteit te waarborgen en bij te dragen aan de normalisatie van de database. Wat als we bijvoorbeeld geen tabellen aan een externe sleutel hebben gekoppeld en in plaats daarvan de gegevens in de tabellen Cursussen en docenten hebben gecombineerd, zoals:
| Teacher_ID | Naam leraar | Cursus |
|---|---|---|
| Teacher_001 | Carmen | Biologie, Math |
| Teacher_002 | Veronica | Wiskunde |
| Teacher_003 | Jorge | Engels |
Dit ontwerp is niet flexibel en schendt het eerste principe van database-normalisatie, First Normal Form (1NF), waarin wordt gesteld dat elke tabelcel één enkel, afzonderlijk gegeven moet bevatten.
Of misschien hebben we besloten om gewoon een tweede record toe te voegen voor Carmen, om 1NF af te dwingen:
| Teacher_ID | Naam leraar | Cursus |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_001 | Carmen | Wiskunde |
| Teacher_002 | Veronica | Wiskunde |
| Teacher_003 | Jorge | Engels |
Dit is nog steeds een zwak ontwerp, waarbij onnodige duplicatie en wat wordt genoemd wordt geïntroduceerd data-invoegafwijkingen , wat alleen maar betekent dat het kan bijdragen aan inconsistente gegevens.
Als een docent bijvoorbeeld meerdere records heeft, wat als sommige gegevens moeten worden bewerkt, maar de persoon die de gegevensbewerking uitvoert, niet beseft dat er meerdere records bestaan? De tabel zou dan verschillende gegevens voor dezelfde persoon bevatten, zonder een duidelijke manier om het te identificeren of te vermijden.
Door deze tabel in twee tabellen te splitsen, leren docenten en cursussen (zoals hierboven weergegeven), ontstaat de juiste relatie tussen de gegevens en wordt de consistentie en nauwkeurigheid van gegevens gewaarborgd.
