Een één-op-veel relatie in een database treedt op wanneer elke record in tabel A veel gekoppelde records in tabel B kan hebben, maar elke record in tabel B mag slechts één overeenkomende record in tabel A hebben. Een één-op-veel-relatie in een database is het meest voorkomende relationele databaseontwerp en vormt de kern van een goed ontwerp.
Overweeg de relatie tussen een leraar en de cursussen die ze geven. Een leraar kan meerdere cursussen geven, maar de cursus zou niet dezelfde relatie met de docent hebben.
Daarom kunnen er voor elk record in een docententabel veel records in de tabel Courses zijn. Dit is een een-op-veel-relatie: een leraar voor meerdere cursussen.
Waarom het belangrijk is om een één-op-veelrelatie tot stand te brengen
Om een één-op-veel-relatie te vertegenwoordigen, hebt u ten minste twee tabellen nodig. Laten we eens kijken waarom.
Misschien hebben we een tabel gemaakt waarin we de naam en de vakken die we hebben geleerd wilden vastleggen. We kunnen het zo ontwerpen:
| Teacher_ID | Naam leraar | Cursus |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_002 | Veronica | Wiskunde |
| Teacher_003 | Jorge | Engels |
Wat als Carmen twee of meer cursussen geeft? We hebben twee opties met dit ontwerp. We zouden het gewoon kunnen toevoegen aan het bestaande album van Carmen, zoals dit:
| Teacher_ID | Leraar_Naam | Cursus |
|---|---|---|
| Teacher_001 | Carmen | Biologie, Math |
| Teacher_002 | Veronica | Wiskunde |
| Teacher_003 | Jorge | Engels |
Het bovenstaande ontwerp is echter niet flexibel en kan later problemen veroorzaken bij het invoegen, bewerken of verwijderen van gegevens.
Het maakt het moeilijk om naar gegevens te zoeken. Dit ontwerp is in strijd met het eerste principe van database-normalisatie, First Normal Form (1NF), waarin wordt gesteld dat elke tabelcel een enkel, afzonderlijk gegeven moet bevatten.
Een ander ontwerpalternatief kan zijn om gewoon een tweede record voor Carmen toe te voegen:
| Leraar_ID KAART | Leraar_Naam | Cursus |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_001 | Carmen | Wiskunde |
| Teacher_002 | Veronica | Wiskunde |
| Teacher_003 | Jorge | Engels |
Dit komt overeen met 1NF maar is nog steeds een slecht databaseontwerp omdat het redundantie introduceert en een zeer grote database onnodig kan laten bloat. Nog belangrijker is dat de gegevens inconsistent kunnen worden. Wat als Carmen's naam is veranderd? Iemand die met de gegevens werkt, kan haar naam in één record bijwerken en deze in de tweede record niet bijwerken. Dit ontwerp schendt Second Normal Form (2NF), dat voldoet aan 1NF en dat ook de overtolligheden van meerdere records moet voorkomen door subsets van gegevens te scheiden in meerdere tabellen en een relatie tussen deze tabellen te creëren.
Hoe een database met een-op-veel relaties te ontwerpen
Om een één-op-veel relatie in de tabel Teachers and Courses te implementeren, splitsen we de tabellen in twee en koppelen ze met een externe sleutel.
Hier hebben we de kolom 'Cursus' verwijderd uit de tabel Teachers:
| Leraar_ID KAART | Leraar_Naam |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Veronica |
| Teacher_003 | Jorge |
En hier is de tabel Courses. Merk op dat zijn foreign key, Teacher_ID, een cursus koppelt aan een leraar in de tabel Teachers:
| Cursus id | Cursus naam | Teacher_ID |
|---|---|---|
| Course_001 | Biologie | Teacher_001 |
| Course_002 | Wiskunde | Teacher_001 |
| Course_003 | Engels | Teacher_003 |
We hebben een relatie tussen de tabel Leraren en de cursus ontwikkeld met een externe sleutel.
Dit vertelt ons dat zowel Biology and Math wordt gegeven door Carmen en dat Jorge Engels leert.
We kunnen zien hoe dit ontwerp mogelijke redundanties vermijdt, individuele docenten in staat stelt meerdere cursussen te geven en een een-op-veel-relatie implementeert.
Databases kunnen ook een één-op-één-relatie en een veel-op-veel-relatie implementeren.
