Podřízená tabulka (A.K.A. slabá entita ) je tabulka, jejíž atributy primárního klíče závisí na jiné tabulce, takže podřízená tabulka je identifikována nebo částečně identifikované podle řádků v tabulce závisí na (rodič). Řádky v podřízené tabulce nemohou existovat bez odpovídajícího řádku v nadřazené tabulce.
Pro ilustraci si uveďme jednoduchý a zcela relevantní příklad, který všichni známe:Rodiče a děti v kontextu rodiny . Tento vztah můžeme modelovat pomocí tabulek takto:
Ve výše uvedeném modelu každý řádek v Parents tabulka je jedinečně identifikována pomocí SSN . SSN je vnitřním a jedinečným atributem pro každého rodiče, jde tedy o samostatnou nebo „silnou“ entitu, protože při definování své identity nespoléhá na jinou tabulku.
Děti však vyžadují rodič, aby mohl existovat (Parent_SSN musí odkaz na existující SSN v Parents stůl).
Všimněte si složeného primárního klíče (Parent_SSN, Name ) v Children stůl. To znamená, že děti jsou jedinečně identifikovány podle kombinace z Parent_SSN a Name . Nemůžete se dotazovat na jednotlivé potomky pouze na základě Name protože více rodičů může mít děti se stejným jménem. Podobně se nemůžete dotazovat na jednotlivé potomky pouze na základě Parent_SSN protože jeden rodič může mít mnoho dětí. Když to vezmeme v úvahu, děti částečně identifikuje jejich rodič, tedy identifikace vztah.
Ale nemohou být děti také jednoznačně identifikovány podle SSN? Proč ano, jistě. Pokračujme a upravme náš model tak, aby zahrnoval toto:
Všimněte si, že v této verzi modelu jsme zavedli SSN pole pro Children . Unikátní identita dětí je nyní definováno jejich vlastním vnitřním a jedinečným SSN . Jejich identita již nezávisí na stránce Parents stůl. Ačkoli Parent_SSN pole stále odkazuje na SSN z Parents tabulka, nemá žádnou část v jedinečné identitě dítěte, tedy rodiče mají neidentifikační vztah ke svým dětem a obě tabulky lze nyní považovat za „silné“ samostatné entity.
Kromě toho má tato verze modelu oproti první několik výhod:
- Jeden rodič může mít nyní dvě nebo více dětí se stejným jménem, zatímco integrita entity omezení v předchozím modelu by to neumožňovalo.
- Můžete povolit
Parent_SSNpole obsahujícíNULLzaúčtovat případ, že máte údaje o dítěti, ale nevíte, kdo je jeho rodič.
V obou výše uvedených modelech Parents tabulka je považována za nadřazenou tabulku Children stůl. Nicméně v neidentifikaci vztahy jako ve druhém modelu, Parents je pouze nadřazená tabulka v kontextu cizího klíče Parent_SSN protože Parent_SSN odkazy/závisí na SSN v Parents tabulka, ale není mají jakýkoli podíl na definování skutečné identity dětí.
Chcete-li ilustrovat, proč je kontext důležitý při rozhodování, které tabulky jsou nadřazené/podřízené tabulky, zvažte následující příklad zahrnující kruhovou závislost:
V tomto příkladu jsou zaměstnanci a oddělení jednoznačně identifikováni svými vlastními atributy a neodvozují žádnou část své identity z jiných tabulek.
Zde máme dva neidentifikující vztahy:zaměstnanec pracuje pro oddělení (DeptNo v Employee tabulka) a oddělení je řízeno zaměstnancem (ManagerSSN v Department stůl). Která je nadřazená tabulka? ...dětský stolek?
Záleží na kontextu – o jakém vztahu cizího klíče mluvíte? Tabulka oddělení by byla považována za nadřazenou tabulku v kontextu DeptNo v Employee tabulka, protože DeptNo je odkazující/závislý na Department stůl.
Tabulka Zaměstnanci by však byla považována za nadřazenou tabulku v kontextu ManagerSSN v Department tabulka, protože ManagerSSN je odkazující/závislý na Employee tabulka.