Een één-op-veel-relatie in een database doet zich voor wanneer elk record in Tabel A veel gekoppelde records in Tabel B kan hebben, maar elk record in Tabel B slechts één corresponderend record in Tabel A.
Een één-op-veel-relatie in een database is het meest voorkomende relationele databaseontwerp en vormt de kern van goed ontwerp.
Databases kunnen ook een één-op-één-relatie en een veel-op-veel-relatie implementeren.
Voorbeeld van een één-op-veel-relatie
Denk na over de relatie tussen een leraar en de cursussen die ze geven. Een docent kan meerdere klassen lesgeven, maar de cursus heeft niet dezelfde relatie met de docent.
Daarom kunnen er voor elk record in een tabel Docenten veel records in de tabel Cursussen zijn. Dit voorbeeld illustreert een één-op-veel-relatie: één docent tot meerdere cursussen.
Waarom het opzetten van een één-op-veel-relatie belangrijk is
Om een een-op-veel-relatie weer te geven, heb je ten minste twee tabellen nodig. Laten we eens kijken waarom.
Naleving van het eerste normale vormontwerp
Misschien hebben we een tabel gemaakt waarin we de naam en de gegeven cursussen willen opnemen. We kunnen een tabel voor docenten en cursussen als volgt ontwerpen:
| Teacher_ID | Teacher_Name | Cursus |
|---|---|---|
| Leraar_001 | Carmen | Biologie |
| Leraar_002 | Veronica | Wiskunde |
| Leraar_003 | Jorge | Engels |
Wat als Carmen twee of meer cursussen geeft? We hebben twee opties met dit ontwerp. We zouden het als volgt kunnen toevoegen aan Carmen's bestaande record:
| Teacher_ID | Leraar_Name | Cursus |
|---|---|---|
| Leraar_001 | Carmen | Biologie, Wiskunde |
| Leraar_002 | Veronica | Wiskunde |
| Leraar_003 | Jorge | Engels |
Het bovenstaande ontwerp is echter niet flexibel en kan later tot problemen leiden wanneer u gegevens invoegt, bewerkt of verwijdert. Het maakt het zoeken naar gegevens moeilijk.
Dit ontwerp schendt ook het eerste principe van databasenormalisatie, First Normal Form (1NF), waarin staat dat elke tabelcel een enkel, afzonderlijk stuk gegevens moet bevatten.
De tweede normaalvormregel
Een ander ontwerp alternatief zou kunnen zijn om een tweede record voor Carmen toe te voegen:
| Leraar_ID | Leraar_Name | Cursus |
|---|---|---|
| Leraar_001 | Carmen | Biologie |
| Leraar_001 | Carmen | Wiskunde |
| Leraar_002 | Veronica | Wiskunde |
| Leraar_003 | Jorge | Engels |
Deze benadering houdt zich aan 1NF, maar is nog steeds een slecht database-ontwerp omdat het redundantie introduceert en een grote database onnodig kan laten opzwellen. Wat nog belangrijker is, is dat de gegevens inconsistent kunnen worden.
Wat als de naam van Carmen bijvoorbeeld verandert? Iemand die met de gegevens werkt, kan haar naam in één record bijwerken en deze niet bijwerken in de tweede record.
Dit ontwerp schendt de Second Normal Form (2NF)-standaard, die voldoet aan 1NF en ook de redundantie van meerdere records moet voorkomen. De 2NF-regel bereikt dit door subsets van gegevens te scheiden in meerdere tabellen en er een relatie tussen te creëren.
Een database ontwerpen met één-op-veel-relaties
Om een een-op-veel-relatie in de tabel Docenten en Cursussen te implementeren, splitst u de tabellen in tweeën en koppelt u ze met een externe sleutel.
Hier hebben we de kolom Cursus in de tabel Docenten verwijderd:
| Leraar_ID | Leraar_Name |
|---|---|
| Leraar_001 | Carmen |
| Leraar_002 | Veronica |
| Leraar_003 | Jorge |
En hier is de tabel Cursussen. Merk op dat de externe sleutel, Teacher_ID, een cursus koppelt aan een leraar in de tabel Docenten:
| Cursus_ID | Cursusnaam | Teacher_ID |
|---|---|---|
| Cursus_001 | Biologie | Leraar_001 |
| Cursus_002 | Wiskunde | Leraar_001 |
| Cursus_003 | Engels | Leraar_003 |
We hebben een relatie ontwikkeld tussen de docenten en de tabel Cursussen met behulp van een externe sleutel. Deze regeling vertelt ons dat Carmen zowel biologie als wiskunde doceert en dat Jorge Engels doceert.
We kunnen zien hoe dit ontwerp mogelijke ontslagen vermijdt, individuele docenten in staat stelt meerdere cursussen te geven en een een-op-veel-relatie implementeert.
