Vztah jedna k více 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 jedna k mnoha v databáze je nejběžnějším návrhem relační databáze a je jádrem dobrého designu. Databáze mohou také implementovat vztah jedna k jedné a vztah mnoho k mnoha.
Příklad vztahu one-to-many
Zvažte vztah mezi učitelem a kurzy, které učí. Učitel může učit více tříd, ale kurz by s učitelem neměl stejný vztah. Proto pro každý záznam v tabulce učitelů může být v tabulce kurzů mnoho záznamů. Tento příklad ilustruje vztah jedna k více: jeden učitel k více kurzům.
Proč je důležité navázat vztah one-to-many
Chcete-li reprezentovat vztah jedna k více, potřebujete alespoň dvě tabulky. Uvidíme proč.
Dodržování prvního normálního designu formuláře
Možná jsme vytvořili tabulku, do které chceme zaznamenat název a vyučované kurzy. Mohli bychom navrhnout tabulku Učitelé a kurzy takto:
| ID učitele | Jméno učitele | Kurs |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_002 | Rozrazil | Matematika |
| Teacher_003 | Jorge | Angličtina |
Co když Carmen učí 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, například takto:
| ID učitele | Učitel_Název | Kurs |
|---|---|---|
| Teacher_001 | Carmen | Biology, Math |
| Teacher_002 | Rozrazil | Matematika |
| Teacher_003 | Jorge | Angličtina |
Výše uvedený design je však nepružný a může později vést k problémům při vkládání, úpravách nebo mazání dat. Ztěžuje vyhledávání dat. Tento design 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ý datový údaj.
Druhé pravidlo normálního tvaru
Další alternativou designu může být přidání druhého záznamu pro Carmen:
| Učitel_ID | Učitel_Název | Kurs |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_001 | Carmen | Matematika |
| Teacher_002 | Rozrazil | Matematika |
| Teacher_003 | Jorge | Angličtina |
Tento přístup dodržuje 1NF, ale stále je špatný návrh databáze, protože zavádí redundanci a může zbytečně nafouknout velkou databázi. Ještě důležitější je, že data by se mohla stát nekonzistentní. Například co když se změnilo jméno Carmen? Někdo, kdo pracuje s daty, může aktualizovat své jméno v jednom záznamu a v druhém záznamu se mu to nepodaří. Tento design porušuje standard Second Normal Form (2NF), který dodržuje 1NF a musí také zabránit nadbytečnosti více záznamů. Pravidlo 2NF toho dosahuje rozdělením podmnožin dat do více tabulek a vytvořením vztahu mezi nimi.
Jak navrhnout databázi s relacemi jeden na mnoho
Chcete-li v tabulce Učitelé a kurzy implementovat vztah jedna k více, 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_Název |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Rozrazil |
| Teacher_003 | Jorge |
A tady je tabulka kurzů. Jeho cizí klíč, Teacher_ID, propojuje kurz s učitelem v tabulce Učitelé:
| Course_ID | Název kurzu | ID učitele |
|---|---|---|
| Course_001 | Biologie | Teacher_001 |
| Course_002 | Matematika | Teacher_001 |
| Kurz_003 | Angličtina | Teacher_003 |
Pomocí cizího klíče jsme vyvinuli vztah mezi tabulkou Učitelé a Kurzy. Toto uspořádání nám říká, že Carmen učí biologii i matematiku a že Jorge učí angličtinu. Vidíme, jak se tento design vyhne jakémukoli možnému nadbytečnosti, umožní jednotlivým učitelům učit více kurzů a implementuje vztah jedna k mnoha. Více od Lifewire
-
Co je databázový vztah?
-
Vložení databáze do první normální formy
-
Uvedení databáze do třetí normální formy (3NF)
-
Úvod do databázových vztahů
-
Co je to přechodná závislost v databázi
-
Definice diagramu entita-vztah
-
Jak mohou nové inteligentní pneumatiky poháněné umělou inteligencí pomoci změnit dopravu
-
Plná funkční závislost v normalizaci databáze
-
Základy normalizace databáze
-
Fakta vs. Dimenzionální tabulky v databázi
-
Atribut databáze definuje vlastnosti tabulky
-
Co je to instance databáze?
-
Glosář běžných termínů v databázi
-
Co je schéma databáze?
-
Vytváření databázových vztahů v Accessu
-
Model databáze ACID
Vaše práva na soukromí
Lifewire a naši partneři třetích stran používají soubory cookie a zpracovávají osobní údaje, jako jsou jedinečné identifikátory, na základě vašeho souhlasu s ukládáním a / nebo přístupem k informacím v zařízení, zobrazováním personalizovaných reklam a pro měření obsahu, přehled publika a vývoj produktů. Chcete-li změnit nebo odvolat váš výběr souhlasu pro Lifewire.com, včetně vašeho práva vznést námitku, kde je použit oprávněný zájem, klikněte níže. Nastavení můžete kdykoli aktualizovat pomocí odkazu „Ochrana osobních údajů v EU“ v dolní části jakékoli stránky. Tyto volby budou globálně signalizovány našim partnerům a nebudou mít vliv na data procházení. Seznam partnerů (prodejců)
My a naši partneři zpracováváme údaje pro:
Aktivně pro identifikaci skenujte vlastnosti zařízení. Používejte přesná geolokační data. Ukládejte a / nebo přistupujte k informacím na zařízení. Vyberte přizpůsobený obsah. Vytvořte si osobní profil obsahu. Měření výkonu reklamy. Vyberte základní reklamy. Vytvořte si přizpůsobený profil reklam. Vyberte přizpůsobené reklamy. Aplikujte průzkum trhu a získejte přehled o publiku. Měření výkonu obsahu. Vyvíjejte a vylepšujte produkty. Seznam partnerů (prodejců)