En en-till-många-relation i en databas uppstår när varje post i tabell A kan ha många länkade poster i tabell B, men varje post i tabell B kan bara ha en motsvarande post i tabell A.
En en-till-många-relation i en databas är den vanligaste relationsdatabasdesignen och är kärnan i bra design.
Databaser kan också implementera en en-till-en-relation och en många-till-många-relation.
Exempel på en en-till-många-relation
Tänk på förhållandet mellan en lärare och de kurser de undervisar i. En lärare kan undervisa i flera klasser, men kursen skulle inte ha samma relation med läraren.
Därför, för varje post i en lärartabell, kan det finnas många poster i kurstabellen. Det här exemplet illustrerar en en-till-många-relation: en lärare till flera kurser.
Varför det är viktigt att etablera en en-till-många-relation
För att representera en en-till-många-relation behöver du minst två tabeller. Låt oss se varför.
Anslutning till den första normala formdesignen
Kanske skapade vi en tabell där vi vill spela in namnet och de kurser som undervisas. Vi kan designa en lärare och kurstabell så här:
| Teacher_ID | Teacher_Name | Kurs |
|---|---|---|
| Teacher_001 | Carmen | Biology |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | engelska |
Vad händer om Carmen undervisar i två eller flera kurser? Vi har två alternativ med denna design. Vi skulle kunna lägga till det till Carmens befintliga rekord, så här:
| Teacher_ID | Lärare_Name | Kurs |
|---|---|---|
| Teacher_001 | Carmen | Biologi, matematik |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | engelska |
Men designen ovan är oflexibel och kan resultera i problem senare när du infogar, redigerar eller raderar data. Det gör det svårt att söka efter data.
Denna design bryter också mot den första principen för databasnormalisering, First Normal Form (1NF), som säger att varje tabellcell ska innehålla en enda, diskret databit.
Den andra normala formregeln
Ett annat design alternativ kan vara att lägga till en andra post för Carmen:
| Lärare_ID | Lärare_Name | Kurs |
|---|---|---|
| Teacher_001 | Carmen | Biology |
| Teacher_001 | Carmen | Math |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | engelska |
Det här tillvägagångssättet följer 1NF men är fortfarande dålig databasdesign eftersom det introducerar redundans och kan blåsa upp en stor databas i onödan. Ännu viktigare är att uppgifterna kan bli inkonsekventa.
Tänk till exempel om Carmens namn ändrades? Någon som arbetar med data kan uppdatera hennes namn i en post och misslyckas med att uppdatera det i den andra posten.
Denna design bryter mot standarden Second Normal Form (2NF), som följer 1NF och måste också undvika redundanser för flera poster. 2NF-regeln uppnår detta genom att separera delmängder av data i flera tabeller och skapa en relation mellan dem.
Hur man designar en databas med en-till-många-relationer
För att implementera en en-till-många-relation i tabellen Lärare och kurser, dela tabellerna i två och länka dem med en främmande nyckel.
Här tog vi bort kurskolumnen i Lärartabellen:
| Lärare_ID | Lärare_Name |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Veronica |
| Teacher_003 | Jorge |
Och här är kurstabellen. Observera att dess främmande nyckel, Teacher_ID, länkar en kurs till en lärare i Lärartabellen:
| Course_ID | Course_Name | Teacher_ID |
|---|---|---|
| Course_001 | Biology | Teacher_001 |
| Course_002 | Math | Teacher_001 |
| Course_003 | engelska | Teacher_003 |
Vi har utvecklat en relation mellan tabellen Lärare och kurser med hjälp av en främmande nyckel. Det här arrangemanget berättar för oss att Carmen undervisar i både biologi och matematik och att Jorge undervisar i engelska.
Vi kan se hur den här designen undviker eventuella uppsägningar, tillåter enskilda lärare att undervisa i flera kurser och implementerar en en-till-många-relation.
