Vztah one-to-many v databázi nastane, když každý záznam v tabulce A může mít mnoho propojených záznamů v tabulce B, ale každý záznam v tabulce B může mít pouze jeden odpovídající záznam v tabulce A.
Vztah jeden k mnoha v databázi je nejběžnějším návrhem relační databáze a je jádrem dobrého návrhu.
Databáze mohou také implementovat vztah jeden k jednomu a vztah mnoho k mnoha.
Příklad vztahu jeden k mnoha
Zvažte vztah mezi učitelem a kurzy, které vyučují. Učitel může učit více tříd, ale kurz by neměl stejný vztah s učitelem.
Pro každý záznam v tabulce Učitelé může být v tabulce Kurzy mnoho záznamů. Tento příklad ilustruje vztah jeden k mnoha: jeden učitel na více kurzů.
Proč je důležité navázat vztah mezi jedním a mnoha
K reprezentaci vztahu jedna k mnoha potřebujete alespoň dvě tabulky. Podívejme se proč.
Dodržování prvního normálního návrhu formuláře
Možná jsme vytvořili tabulku, do které chceme zaznamenávat jména a vyučované kurzy. Můžeme navrhnout tabulku učitelů a kurzů takto:
| Teacher_ID | Teacher_Name | Kurz |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | angličtina |
Co když Carmen vyučuje dva nebo více kurzů? S tímto designem máme dvě možnosti. Mohli bychom to přidat do stávajícího záznamu Carmen takto:
| Teacher_ID | Učitel_Name | Kurz |
|---|---|---|
| Teacher_001 | Carmen | Biologie, matematika |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | angličtina |
Výše uvedený návrh je však nepružný a mohl by později způsobit problémy při vkládání, úpravách nebo odstraňování dat. Ztěžuje vyhledávání dat.
Tento návrh také porušuje první princip normalizace databáze, First Normal Form (1NF), který uvádí, že každá buňka tabulky by měla obsahovat jeden samostatný kus dat.
Pravidlo druhé normální formy
Další alternativou designu může být přidání druhé desky pro Carmen:
| Učitel_ID | Učitel_Name | Kurz |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_001 | Carmen | Math |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | angličtina |
Tento přístup se drží 1NF, ale je stále špatným návrhem databáze, protože zavádí redundanci a může zbytečně zahltit velkou databázi. Ještě důležitější je, že data mohou být nekonzistentní.
Co kdyby se například změnilo jméno Carmen? Někdo, kdo pracuje s daty, může aktualizovat její jméno v jednom záznamu a neaktualizovat ho ve druhém záznamu.
Tento návrh porušuje standard Second Normal Form (2NF), který dodržuje 1NF a musí se také vyvarovat redundanci více záznamů. Pravidlo 2NF toho dosahuje oddělením podmnožin dat do více tabulek a vytvořením vztahu mezi nimi.
Jak navrhnout databázi s mnoha vztahy
Chcete-li implementovat vztah jedna k mnoha v tabulce Učitelé a Kurzy, rozdělte tabulky na dvě a propojte je pomocí cizího klíče.
Zde jsme odstranili sloupec Kurz v tabulce Učitelé:
| Učitel_ID | Učitel_Name |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Veronica |
| Teacher_003 | Jorge |
A tady je tabulka kurzů. Všimněte si, že jeho cizí klíč, Teacher_ID, propojuje kurz s učitelem v tabulce Učitelé:
| Course_ID | Course_Name | Teacher_ID |
|---|---|---|
| Course_001 | Biologie | Teacher_001 |
| Course_002 | Math | Teacher_001 |
| Course_003 | angličtina | Teacher_003 |
Vyvinuli jsme vztah mezi tabulkou Učitelé a tabulkou Kurzy pomocí cizího klíče. Toto uspořádání nám říká, že Carmen učí biologii i matematiku a že Jorge učí angličtinu.
Vidíme, jak tento design zabraňuje možnému propouštění, umožňuje jednotlivým učitelům vyučovat více kurzů a implementuje vztah typu one-to-many.
