Egy adatbázisban egy-egy csomó kapcsolat akkor következik be, ha az A. táblázatban szereplő összes rekordnak számos csatolt rekordja lehet a B. táblázatban, de a B. táblázatban szereplő összes rekordnak csak egy megfelelő rekordja lehet az A. táblázatban. Egy-egy-sok kapcsolat a egy adatbázis a legáltalánosabb relációs adatbázis-tervezés és a jó tervezés középpontjában áll.
Tekintsük a tanár és az általuk tanított tanfolyamok közötti kapcsolatot. A tanár több tanfolyamot taníthat, de a tanfolyamnak nem lenne ugyanolyan kapcsolata a tanárral.
Ezért a Teachers tábla minden egyes rekordja esetében sok adat szerepelhet a tanfolyamok táblázatában. Ez egy egy-sok kapcsolat: egy tanár több tanfolyamra.
Miért fontos az egy-sok kapcsolat kialakítása?
Ahhoz, hogy egy-sok kapcsolatot képviseljen, legalább két asztalra van szüksége. Lássuk, miért.
Talán létrehoztunk egy tanári táblát, amelyben meg akartuk jegyezni a tanított neveket és tanfolyamokat. Ezt úgy tervezhetjük meg:
Teacher_ID | Tanár neve | Tanfolyam |
---|---|---|
Teacher_001 | Carmen | Biológia |
Teacher_002 | Veronika | Math |
Teacher_003 | Jorge | angol |
Mi van, ha Carmen két vagy több kurzust tanít? Ennek a designnak két lehetősége van. Hozzá tudnánk adni Carmen meglévő rekordjához:
Teacher_ID | Tanár _Name | Tanfolyam |
---|---|---|
Teacher_001 | Carmen | Biológia, matematika |
Teacher_002 | Veronika | Math |
Teacher_003 | Jorge | angol |
A fenti felépítés azonban rugalmatlan, és később problémákat okozhat az adatok beszúrása, szerkesztése vagy törlése során.
Nehéz keresni az adatokat. Ez a terv sérti az adatbázis normalizálásának első elvét, az első normál űrlapot (1NF) , amely kimondja, hogy minden egyes táblázatos cellának egyetlen, különálló adatrészletet kell tartalmaznia.
Egy másik tervezési alternatíva lehet, hogy egyszerűen hozzá egy második rekord Carmen:
Tanár _ID | Tanár _Name | Tanfolyam |
---|---|---|
Teacher_001 | Carmen | Biológia |
Teacher_001 | Carmen | Math |
Teacher_002 | Veronika | Math |
Teacher_003 | Jorge | angol |
Ez 1NF-hez ragaszkodik, de még mindig rossz adatbázissal rendelkezik, mert bevezeti a redundanciát, és feleslegesen felborulhat egy nagyon nagy adatbázis. Ennél is fontosabb, hogy az adatok következetlenek lehetnek. Például, ha Carmen neve megváltozott? Az adatokkal dolgozó személy frissítheti a nevét egy rekordban, és nem frissítheti azt a második rekordban. Ez a terv megsérti a második normál űrlapot (2NF), amely 1NF-hez ragaszkodik, és el kell kerülnie a több rekord elbocsátását azáltal, hogy elválasztja az adatbevitelt több táblázatba, és létrehozza a közöttük lévő kapcsolatot.
Hogyan tervezzünk egy adatbázist az egy-sok kapcsolaton keresztül?
A Tanárok és a tanfolyamok táblázat egy-sok kapcsolathoz történő megvalósításához kettőt töröljük a táblázatokat, és idegen kulcs segítségével linkeljük őket.
Itt töröltük a Tanfolyam táblázatot a Tanárok táblázatban:
Tanár _ID | Tanár _Name |
---|---|
Teacher_001 | Carmen |
Teacher_002 | Veronika |
Teacher_003 | Jorge |
És itt van a kurzusok táblája. Ne feledje, hogy az idegen kulcs, a Teacher_ID, egy tanfolyamot kapcsol össze egy tanárral a Tanárok táblában:
Course_ID | A tantárgy neve | Teacher_ID |
---|---|---|
Course_001 | Biológia | Teacher_001 |
Course_002 | Math | Teacher_001 |
Course_003 | angol | Teacher_003 |
A tanárok és a kurzusok tábla közötti kapcsolatot egy idegen kulcs használatával fejlesztettük ki.
Ez azt mondja, hogy mindkét biológiát és matematikát Carmen tanítja, és Jorge angolul tanít.
Láthatjuk, hogy ez a design elkerüli-e az esetleges elbocsátást, lehetővé teszi az egyéni tanárok számára, hogy több tanfolyamot tanítanak és egy-sok kapcsolatot valósítanak meg.
Az adatbázisok egy-egy kapcsolatot és sok-sok kapcsolatot is megvalósíthatnak.