Poslední úpravy - Vyhledat:

SQL

O modelování

Power Designer

Oracle Data Modeler

Zdroje...

edit SideBar

DM /

Entity

< Atributy entit a vztahů | Tutoriál informační analýzy | Dvoutvářné entity >

Entita nebo atribut?

Někdy bývá obtížné rozhodnout, zda nějakou věc modelovat jako entitu nebo atribut. Kdo je více orientován do objektového programování, má tendenci modelovat častěji jako objektové typy – entity, kdo je více orientován databázově, má opačnou tendenci. Příkladem může být "adresa" – modelovat ji jako složený atribut, či jako samostanou entitu?
Vodítkem může být, zda o uvažované věci můžeme sdělit více, než jen uvažovaný obsah. Pokud nemůžeme, jedná se o hodnotu. Hodnoty je lépe modelovat jako atributy. A co entity? Na entity se obvykle odkazujeme pomocí jejich identifiktorů, například "student Vonásek" nebo "zboží B251" – v žádném případě se nepředpokládá, že identifikátorem vyjádříme o entitě vše. Oproti tomu, pokud sdělíme hodnotu (například "13 kg"), vyjářili jsme vše.
Podle tohoto vodítka, adresu bychom ve většině případů modelovali jako atribut. Pokud by se však k adrese vázaly další informace, protože by na té adrese bylo sídlo nějaké čínnosti důležité v oblasti zájmu, mohli bychom ji modelovat jako entitu. Dost pravděpodobně bychom pro tuto entitu našli vhodnější název, například "sídlo", "pobočka", "dílna","sklad". Možná by taková entita měla i jiný identifikátor, než jen adresu, například "pobočka Vojtěškova".

Slabé entitní typy

Při dekompozici problematiky někdy vytváříme entitní typy, které samy o sobě nemají smysl, ale jsou součástí celku daného souvislostí s nějakým jiným entitním typem. Příkladem mohou být položky objednávky, které jistě mají smysl jen jako náležitosti k objednávce, nebo výpůjčky knihy, opět mající smysl jen v souvislosti s tou knihou, jejíž výpůjčky to jsou. Lze si představit i jinou konceptualizaci, ve které takové entitní typy vůbec nebudeme vytvářet, ale "položky objednávky" či "výpůjčky" jsou pojmy, které lidé v daných aplikačních oblastech běžně používají a rozumějí jim. Obsah těchto pojmů sice většinou není větší než nějaký souhrn dat a vztahů k jiným objektům (položka objednávky kromě toho, že je součástí nějaké objednávky, má vztah k nějaké položce katalogu zboží, výpůjčka kromě vypůjčené knihy i k výpůjčiteli...) ale právě tyto jiné vztahy posouvají představu takových slabých pojmů směrem k chápání jich jako entity.
Takovýmto případům entitních typů se říká slabé entitní typy. Poznáme je tak, že z vlastních atributů těchto entit nelze složit jejich identifikátor, k identifikaci je potřeba znát ještě entitu nebo entity, se kterými jsou spojeny – například k identifikaci položky objednávky je potřeba znát, ke které objednávce patří.
Vztah, který pro slabý entitní typ slouží k jeho identifikaci, je nositelem identifikační závislosti této slabé entity na té jiné entitě.

Pojmenování

Pro vyjádření podstaty, pro pochopení a pro srozumitelnost modelu je důležité najít výstižné názvy entit. Někdy s tím jsou však problémy, například proto, že zvolený název má jiný obecný význam, než v jakém je v modelu použit. Pak je namístě doplnit vysvětlující popis. Někdy dobře poslouží, když uvedeme několik konkrétních příkladů. Pokud exitují zvláštní případy, mezi příklady uvedeme i tyto zvláštní případy.
Například jako "učitel" na vysoké škole může pracovat zaměstnanec školy s pedagogickým úvazkem, externista či hostující vyučující. Může jít i o zaměstnance, který poskytuje škole nějaké provozní služby a příležitostně poskytuje školení v oboru těchto služeb.

Synonyma

Různí uživatelé mohou pro stejný entitní typ používat různé názvy. Například "učitelům" někteří administrativní pracovníci vysoké školy mohou říkat "pedagogové". Analýza má podchytit, jak uživatelé v dané oblasti zájmu entitám říkají – pokud jim různí uživatelé říkají různě, je potřeba tuto skutečnost respektovat. Potom pro název nějakého entitního typu máme synonyma. Je však třeba dát pozor, aby se jednalo o skutečně stejný význam, protože častější jsou případy, kdy jde sice o významy překrývající se, ale ne úplně shodné. Zde je vidět, jak důležitá je definice připojená k názvu typu.

Nevhodná pojmenování

Pojmenování má vyjadřovat jaké objekty entita přestavuje, a nikoli formu, jakou se o nich vedou záznamy. Vyhýbejte se nic- nebo málo-říkajícím názvům. Podezřelé jsou vždy názvy "položka", "řádek", "záznam", "zpráva", "výsledek"... Například "položka" může být "skladová položka", "položka objednávky", "položka menu". "Záznam" může být "záznam o kontrole", a entita, kterou takto nevhodně nazýváme, je vlastně "kontrola". Zde uvedený seznam rozhodně nelze považovat za úplný výčet nevhodných názvů.

Dvoutvářné entity

Zvláštní kapitolu věnujeme otázce tzv. dvoutvářných entit (nazývám je tak podle Richarda Veryarda). Jde o případy, kdy je obtížné rozeznat, že pod tímtéž názvem se skrývají dva entitní typy, spojené specifickým vztahem.

< Atributy entit a vztahů | Tutoriál informační analýzy | Dvoutvářné entity >

Upravit - Historie - Tisk - Poslední úpravy - Vyhledat
Poslední úprava stránky: 01.06.2011, 10:05