Egy a többhez viszony egy adatbázisban akkor lép fel, ha az A tábla minden egyes rekordja sok csatolt rekordot tartalmazhat a B táblában, de a B tábla minden rekordja csak egy megfelelő rekordot tartalmazhat az A táblázatban.
Az egy a többhez kapcsolat egy adatbázisban a leggyakoribb relációs adatbázis-tervezés, és a jó tervezés középpontjában áll.
Az adatbázisok egy-egy kapcsolatot és több-többhöz kapcsolatot is megvalósíthatnak.
Példa egy a sokakhoz való kapcsolatra
Vegyük fontolóra a tanár és az általa tanított kurzusok közötti kapcsolatot. Egy tanár több órát is tarthat, de a kurzusnak nem lenne ugyanolyan kapcsolata a tanárral.
Ezért a Tanárok táblázat minden rekordjához több rekord is tartozhat a Tanfolyamok táblázatban. Ez a példa egy egy a többhez viszonyt szemlélteti: egy tanár több kurzushoz.
Miért fontos a személyes kapcsolat kialakítása?
Az egy a többhez kapcsolat ábrázolásához legalább két táblázatra van szükség. Lássuk, miért.
Az első normál formatervezés betartása
Talán készítettünk egy táblázatot, amelyben rögzíteni szeretnénk a neveket és az oktatott kurzusokat. Tervezhetünk egy Tanárok és tanfolyamok táblázatot a következőképpen:
| Teacher_ID | Tanár_neve | Tanfolyam |
|---|---|---|
| Teacher_001 | Carmen | Biológia |
| Teacher_002 | Veronica | Matek |
| Teacher_003 | Jorge | angol |
Mi van, ha Carmen két vagy több kurzust tanít? Két lehetőségünk van ezzel a kialakítással. Hozzáadhatjuk Carmen meglévő rekordjához, így:
| Teacher_ID | Tanár_Név | Tanfolyam |
|---|---|---|
| Teacher_001 | Carmen | Biológia, matematika |
| Teacher_002 | Veronica | Matek |
| Teacher_003 | Jorge | angol |
A fenti kialakí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. Megnehezíti az adatok keresését.
Ez a kialakítás sérti az adatbázis normalizálásának első elvét, a First Normal Form (1NF) elvét is, amely szerint minden táblázatcellának egyetlen, különálló adatot kell tartalmaznia.
A második normál formai szabály
Egy másik tervezési alternatíva lehet Carmen második rekordjának hozzáadása:
| Tanár_ID | Tanár_Név | Tanfolyam |
|---|---|---|
| Teacher_001 | Carmen | Biológia |
| Teacher_001 | Carmen | Matek |
| Teacher_002 | Veronica | Matek |
| Teacher_003 | Jorge | angol |
Ez a megközelítés az 1NF-hez ragaszkodik, de még mindig rossz az adatbázis-tervezés, mert redundanciát vezet be, és szükségtelenül felduzzaszthatja a nagy adatbázisokat. Ennél is fontosabb, hogy az adatok következetlenné válhatnak.
Például mi lenne, ha Carmen neve megváltozna? Előfordulhat, hogy valaki, aki az adatokkal dolgozik, frissíti a nevét az egyik rekordban, és nem tudja frissíteni a második rekordban.
Ez a kialakítás sérti a Second Normal Form (2NF) szabványt, amely megfelel az 1NF-nek, és el kell kerülnie a több rekord redundanciáját is. A 2NF szabály ezt úgy éri el, hogy az adatok részhalmazait több táblára választja, és kapcsolatot hoz létre közöttük.
Hogyan tervezzünk adatbázist egy-a többhez kapcsolatokkal
Az egy a többhez kapcsolat megvalósításához a Tanárok és kurzusok táblázatban bontsa ketté a táblákat, és kapcsolja össze őket idegen kulccsal.
Itt eltávolítottuk a Tanfolyam oszlopot a Tanárok táblázatból:
| Tanár_ID | Tanár_Név |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Veronica |
| Teacher_003 | Jorge |
És itt a Tanfolyamok táblázata. Vegye figyelembe, hogy az idegen kulcsa, a Teacher_ID, egy kurzust a Tanárok táblázatban lévő tanárhoz kapcsol:
| Curse_ID | Tanfolyam_neve | Teacher_ID |
|---|---|---|
| Curse_001 | Biológia | Teacher_001 |
| Tanfolyam_002 | Matek | Teacher_001 |
| Tanfolyam_003 | angol | Teacher_003 |
Kapcsolatot alakítottunk ki a Tanárok és a Tanfolyamok tábla között idegen kulcs használatával. Ez az elrendezés azt mondja nekünk, hogy Carmen biológiát és matematikát is tanít, Jorge pedig angolt.
Láthatjuk, hogy ez a kialakítás hogyan kerüli el az esetleges redundanciákat, lehetővé teszi az egyes tanárok számára, hogy több kurzust tanítsanak, és hogyan valósítja meg az egy-a többhez kapcsolatot.
