• Zobrazit
• Upravit
• Historie
• Tisk

Dvoutvářné entity

< Entity | Tutoriál informační analýzy | Genaralizace/specializace >

V některých případech mohou uživatelé pod stejným názvem chápat z různých pohledů obsahy odlišné, ale natolik svázané, že je obtížné je odlišit. Uvažujte například "knihu". Když si chce čtenář vypůjčit knihu z knihovny, zadá název, autora, eventuelně vydání. Z jeho pohledu tím knihu určí jednoznančně. Když si prohlíží historii svých výpůjček, zajímá ho jen jaký byl název vypůjčené knihy, jakého měla autora, eventuelně jaké to bylo vydání. Dva čtenáři mohou z pohledu těchto čtenářů mít ve stejnou chvíli vypůjčenou stejnou knihu, když jich má knihovna stejných více. Když se zeptáte knihovníka, podle čeho vyhledává knihu, řekne že podle umístění, autora a inventárního čísla. Pro daný název, autora a vydání může knihovník nalézt více knih. Když se ho zeptáme, kde která kniha je, řekne na které je polici či který čtenář ji má vypůjčenou či že je v opravě. Z pohledu knihovníka může mít jednu knihu v jednu chvíli vypůjčenou jen jeden čtenář. Je vidět, že čtenář a knihovník v tomto případě pod slovem "kniha" rozumí každý něco jiného. Čtenář myslí "titul", knihovník myslí "svazek". Mezi "titul" a "svazek" je vztah "svazek je exemplářem titulu".

Čtenáři si půjčují svazky, ale vybírají si tituly. Knihovník spravuje vybavenost knihovny dostatečným počtem svazků pro každý titul, a stará se o osud těchto svazků. Po navrácení svazku čtenářem ho umísťuje do lokace, kam patří (do skladu, do určitého oddělení...). Pokud si čtenář žádá knihu, knihovník vyhledá volné svazky žádaného titulu a pomůže mu k těmto svazkům se dostat. – Výpůjčka v tomto modelu je slabý entitní typ, k její identifikaci slouží identifikace vypůjčeného svazku a údaj o čase vypůjčení (značka tlustého přeškrtnutí vyjadřuje identifikační závislost, další součásti identifikace jsou tučně).

Kdybychom při analýze nerozeznali tyto dvě entity, hrozilo by nám, že budeme zapisovat tutéž informaci vícekrát, pokud povedeme záznamy o jednotlivých svazcích a informace o titulu se budou opakovat u každého svazku toho titulu. Nebo pokud povedeme záznamy jen o titulech a pouhém počtu exemplářů každého z nich, ztratíme přehled o odlišných svazcích jednoho titulu, nebudeme schopni je rozlišit a odlišně s nimi zacházet. Nezjistíme například, který čtenář měl daný svazek vypůjčen a může být zodpovědný za jeho stav, nezajistíme archivní svazky určené jen k prezenčnímu vypůjčování a pod.

Jiné příklady jsou rozebrány ve výukových videích Má to dvě tváře (část 1) a Má to dvě tváře (část 2).

Jak takovým problémům zabránit? Pomůže důsledná analýza:

• identifikátorů
• odhadu počtu objektů daného typu
• atributů, které pro daný entitní typ připadají do úvahy
• popisů vysvětlujících co entitní typ představuje.

Když se to nepodaří, do návrhu databáze se dostanou chyby, které způsobí neschopnost plnit požadavky uživatelů, či vzniknou chyby z nekonzistentního zapisování údajů na různých místech, které mají být stejné. Takové problémy je třeba řešit co nejdříve, protože budou vyžadovat změnu datových struktur, a to představuje náklady zvyšující se s objemem dat v databázi a množstvím aplikačních programů pracujících s datovými strukturami, které bude třeba změnit. Pro hledání skrytých závislostí mezi daty lze použít účelové softwarové nástroje, toto hledání však má smysl, až když jsou v databázi nějaká data, ale s množstvím dat jeho náročnost značně stoupá.

Jak je rozeznat

Ve všech případech se jedná o dvojici entit A a B svázaných vztahem "A je exemplářem B" nebo jinak vyjádřeno "A je (výskytem, kusem) typu B". Entitu A i entitu B přitom lidé běžně pojmenovávají stejně, například "výrobek", "náhradní díl", "služba".
Pokud na otázku

Kolik jich takových (udáme identifikaci) může být?

lze odpovědět, že více, pak se jedná o entitu B – např. "typ výrobku", "typ náhradního dílu".
Pokud na otázku jestli v dané oblasti zájmu

Jedno může být poskytnuto různým klientům?

lze odpovědět, že ano, jedná se o entitu B – např. "typ služby".
Pokud na takové otázky dostaneme opačnou odpověď, jedná se o jedinečný objekt – entitu A – jedinečný výrobek, evidovaný náhradní díl či individuální službu.

Ne vždy je však v modelu potřeba mít oba typy, někdy se v aplikační oblasti vůbec neevidují objekty A – objekty s jedinečnou identifikací, nýbrž se zachází pouze s od sebe nerozlišitelnými elementy, a eviduje se pouze jejich množství. Takovým příkladem jsou předměty prodávané v obchodním domě – na účtu máme kolik jsme jich koupili jakého druhu; obchodník si vede přehled o tom, kolik jich od každého druhu má ve skladu, kolik jich bylo v které dodávce od kterého dodavatele atd. Evidují se tedy jen počty, nikoli individua. Pak se v modelu objevuje jen entita B – např. typ výrobku, typ náhradního dílu, typ služby.

Špatná konceptualizace

Poměrně často se objevující chybou je modelovat jako jednu entitu úmyslně oba významy z toho důvodu, že oba mohou být například účtovány jako nějaká položka faktury. Na účet za opravu auta je možno napsat například 4 pneumatiky určitého typu a jeden motor s uvedením jedinečného čísla motoru. I u motoru se uvede, jakého je typu, ale zatímco je nutno evidovat jednotlivé motory, protože každý z nich má jedinečnou identitu, u pneumatik stačí evidovat jejich počet. Některé náhradní díly jsou typové a vzájemně neodlišitelné, kus jako kus, a jiné odlišujeme podle výrobního čísla.
Pokud takto nestejnorodé objekty zahrneme pod jeden entitní typ,

"Evidence" náhradních dílů, udávající počet kusů na skladu, výrobní číslo kusu (u typových nemá význam, prošktnuto), v jaké faktuře byl kus účtován zákazníkovi (u typových nemá význam, prošktnuto). Evidované kusy na skladu dosud nepředané zákazníkovi nemají uvedené číslo faktury.

vystavujeme se problémům s opakovaným zaznamenáváním týchž údajů o vlastnostech náhradních dílů stejného typu, a kromě toho pravidla pro práci s daty budeme mít složitá: Náhradní díl s konkrétním výrobním číslem nemůže být použit najednou do více zakázek, nemůže být také použit v jedné zakázce ve větším množství. Naopak typový náhradní díl může být použit ve více zakázkách, a v jedné zakázce může být použit i ve více kusech. Dále, u konkrétního použitého náhradního dílu, který má výrobní číslo, je potřeba vědět, do které zakázky byl dodán. Ke každému z těchto typů se vážou jiné procesy a je u nich třeba evidovat jiné skutečnosti. To, že se také mohou zůčastnit "stejného" vztahu (účtování ve faktuře), je slabý důvod pro zavlečení zmíněných problémů.
Podobně jako ve faktuře účtujeme zvlášť provedené úkony a další služby, evidované a neevidované náhradní díly účtujeme také zvlášť. Porobněji pojednává vhodnou konceptualizaci pro tento příklad následující kapitola.

Jak se liší od dědičnosti

V této kapitole rozebíraný vztah "A je exemplářem B" je někdy mylně považován za vztah dědičnosti. Při dědičnosti sice podobně rozdělujeme informace o objektech na tu část, která připadá do úvahy pro obecný nadtyp, a tu část, která je speciální pro podtyp, ale každý jednotlivý konkrétní objekt je jen on sám a jeden – jeho speciální rysy i obecné rysy patří k sobě. Identifikátor platný v rámci obecného nadtypu je i identifikátorem v rámci speciálního podtypu.
Na druhou stranu, identifikátor knižního TITULU, např. ISBN, není identifikátorem SVAZKŮ, které knihovna od tohoto titulu vlastní. Pro SVAZKY si knihovna musí vytvořit vlastní identifikaci, např. evidenční číslo. Pokud z knihovny zmizí nějaký SVAZEK (je zničen, odcizen), neznamená to, že musíme odstranit i příslušný TITUL – vždyť mohou exitovat ještě jiné SVAZKY toho TITULU. I kdyby knihovna přišla o všechny SVAZKY daného TITULU, nemusí přestat tento TITUL evidovat, může mít naději, že čtenářům bude moci zajistit přečtení TITULU nějak jinak či později nějaké SVAZKY pořídit.

Zatímco v jistém smyslu můžeme mít představu, že exempláře - SVAZKY - "dědí" vlastnosti typu - TITULU -, nejedná se o dědičnost ve smyslu, v jakém se používá v informatice. Ta nastává při generelizaci/specializaci, o níž je následující kapitola.

< Entity | Tutoriál informační analýzy | Genaralizace/specializace >