|
DM /
Power Designer – Co udělat s dědičnostíJak udělat dědičnostMáte entitní typ a nějaké speciální podtypy tohoto entitního typu: Pro vyznačení skutečnosti, že jde o podtypy, použijeme nástroj Inheritance z palety:  Tímto nástrojem táhneme myší od podtypu k nadtypu,  v modelu se objeví tyto symboly:  Od dalších podtypů táhneme nástrojem Inheritance ne již k nadtypu, ale k symbolu "kopečku" v modelu.  Symbol "kopečku" je uzel, který lze posouvat; představuje objekt pro nastavení vlastností dědičnosti:  Poklepáním na objekt "kopečku" dostaneme jeho dialog Properties. V něm slouží Name, Code a Comment stejně jako u všech objektů v PD. Zaškrtnutí Mutually exclusive children a Complete znázorní tyto volby obrázky v symbolu "kopečku" v modelu, nicméně Power Designer pro tyto volby do fyzického modelu nic nevygeneruje. Triky, kterými můžete eventuelně zajistit odpovídající omezení pro databázi, jsou popsány níže.  Varianty mapováníNa kartě Generation musíte rozhodnout, která z variant mapování dědičnosti bude použita. V případě, že generujete rodiče i děti, je nutno náležitě přepnout Inherit only primary attributes:  Kydž generujete pouze rodiče (celý příklad je zde):  Když generujete pouze děti:  – pro tuto hierarchii:  Jak zajistit vzájemnou výlučnost či úplnost členěníMožná vás zarazilo, proč v příkladu výše uváděném má entita Sluzba jako primary identifier označeny dva atributy, kód služby a ještě typ služby. Důvodem je záměr zajistit vzájemnou výlučnost podtypů. Prvním krokem je tento, tj zahrnutí atributu, odlišujícího o jaký podtyp se jedná, do primary identikikace nadtypu. Pro tento atribut zároveň vymezíme povolené hodnoty – v tomto příkladu je tím odlišujícím atributem typ služby, a vymezíme pro něj hodnoty o a d:  Další kroky se provedou až ve vygenerovaném fyzickém modelu. V něm ve sloupcích vzniklých v podtypech z toho odlišujícího atributu, zděděného z nadtypu v rámci primární identifikáce, zúžíme vymezení hodnot na jedinou povolenou hodnotu, odpovídající tomu kterému podtypu:   Tím je celý trik dokončen. Jeho účinek je zajištěn referenční integritou složených cizích klíčů:  Služba, která je v tabulce OPERACE, nemůže být v tabulce ND a obráceně. Navíc jsou tyto případy konzistentně označeny kódem podtypu v tabulce SLUZBA. Tento trik je možno použít i v případě "absorpce" podtypů do tabulky nadtypu (když se generuje pouze rodič) - viz Výlučnost při absorpci do nadtypu . U rozdělení do podtypů (když se generují pouze děti) je tento trik nepoužitelný. Pokud by šlo o úplnost či neúplnost členění, částečné opatření můžeme provést u nadtypu vyjmenováním či nevyjmenováním dalších přípustných hodnot do atributu odlišujícího jednotlivé podtypy. Podmínku, aby každá služba v nějaké z podřízených tabulek skutečně byla, na SQL úrovni jednoduše nazajistíme (odůvodnění ponechávám bystrému čtenáři). < Identifikační závislost | Power Designer postupně | Alternativní klíče > |
