Poslední úpravy - Vyhledat:

SQL

O modelování

Power Designer

Oracle Data Modeler

Zdroje...

edit SideBar

DM /

Power Designer – Co udělat s dědičností

Jak udělat dědičnost

Máte entitní typ a nějaké speciální podtypy tohoto entitního typu:


Proč je zde kód služby součástí primární identifikace, je odhaleno níže.

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 >

Upravit - Historie - Tisk - Poslední úpravy - Vyhledat
Poslední úprava stránky: 29.02.2012, 19:21