|
DM /
Vztahy mezi objekty< Co jsou ISA vztahy | Tutoriál informační analýzy | Role ve vztahu >
Předchozí dvě věty vyjadřují dva vztahy, první mezi skladatelem a písní, druhý mezi písní a zpěvákem. Skladatel, píseň, zpěvák jsou entitní typy a "složil", "nazpíval" jsou typy vztahů. Abychom se nevyjadřovali těžkopádně, místo "typ vztahu" se říká jen "vztah", podobně jako místo "typ entity" se říká jen "entita". Pokud jde o konceptuální modelování, to se týká vždy typů (entit, vztahů, atributů), takže slovo "typ" se většinou vynechává. Vztah zachycuje skutečnost, že mezi dvěma či více entitami je nějaká konkrétní souvislost. Obsahová náplň této souvislosti je to, co odlišuje jeden vztah od druhého, tedy vztah "složil" je jiný než vztah "nazpíval". Můžeme uvažovat vztahy i mezi více než dvěma entitami, například je příklad (výskyt) vztahu mezi zpěvákem, písní a filmem, ve kterém zpěvák nazpíval tu píseň. Počtu entit, mezi kterými daný vztah je, se říká arita vztahu – vztah "složil" z první věty v této kapitole má aritu 2, vztah "nazpíval" z druhé věty má také aritu 2, ale vztah "nazpíval ve filmu" z předchozí věty má aritu 3. Vztahům s aritou 2 se říká binární, s aritou 3 ternární, s aritou 4 kvaternární... V konceptuálním modelování se však ponejvíce setkáváme se vztahy binárními. KardinalitaAčkoli jednu píseň složil jen jeden člověk, nazpívat ji mohlo více lidí: Tato skutečnost se týká kardinality vztahu. Vztah "nazpíval" má kardinalitu n:m : jednu píseň mohlo nazpívat více zpěváků a jeden zpěvák mohl nazpívat více písní, protože i: Vztah "složil" má kardinalitu 1:n :
– jeden skladatel mohl složit více písní, ale jednu píseň složil jediný skladatel. Kardinalita vztahu se v grafickém znázornění konceptuálního modelu vyjadřuje grafickou značkou:  Symbol vraní nohy  (crow's foot) vyjadřuje kardinalitu "více". Čte se u daného vztahu od entity na vzdálené straně k symbolu vraní nohy, přes tvar slovesa "moci", dále pojmenování vztahu, následuje slovo "více" a nakonec jméno entity, na které vraní noha "stojí": například "Skladatel mohl složit více písní." Tato značka je velmi oblíbená, neboť připodobňuje rozvětvení v diagramu výskytů: Pokud na nějakém konci linky znázorňující vztah není rozvětvení – vraní noha, znamená to kardinalitu 1. To čteme od tvaru slova "kterýkoli" přes název entity na protější straně, dále název vztahu, pak tvar výrazu "nejvýše jeden" až k názvu druhé entity: například "Kteroukoli píseň složil nejvýše jeden skladatel." Na jiném příkladu vysvětluje kardinalitu k více výukové video Vazba k více - v tabulkách databáze.
PovinnostZajímavá je otázka tzv. povinnosti vztahu. Rozptylme hned zpočátku všechny nejasnosti a řekněme, že to co modelujeme jsou vzorce dostupných informací. Takže ačkoli každou píseň někdo složil, ne u každé písně je její skladatel znám. Zároveň v konceptuálním modelu zachycujeme požadovanou funkcionalitu systému: ačkoli každý zpěvák, aby byl zpěvákem, musel nějakou píseň nazpívat, my v našem systému budeme mít i záznamy o zpěvácích, u kterých nevíme, co nazpívali. Z tohoto pohledu budou povinné vztahy v konceptuálních modelech poměrně vzácné. Povinnost daného vztahu pro daný entitní typ znamená, že pro každý výskyt toho entitního typu v našem systému musí v našem systému též existovat nějaký další, který je s ním v uvažovaném vztahu: pokud by pro typ ZPĚVÁK byl vztah "nazpíval" povinný, pak bychom pro každého zpěváka v našem systému museli mít nějakou píseň, o které bychom měli zaznamenáno, že ji tento zpěvák nazpíval. Pokud nechceme, aby náš systém takto fungoval, modelujeme vztah "nazpíval" jako nepovinný pro entitu ZPĚVÁK. Představme si, že pro SKLADATELE to budeme vyžadovat, že SKLADATELÉ budeme mít jen tehdy, když k nim budeme mít nějakou píseň, kterou složili. Pak to znamená mimo jiné i to, že když z databáze vymažeme nějakou píseň, musíme zkontrolovat, jestli pro jejího skladatele máme ještě nějakou další píseň. Když nebude žádná další, bude nutno vymazat i toho skladatele. Taková funkcionalita je pochopitelně dosti náročná... Povinnému vztahu se také říká totální, nepovinnému parciální. Různá značeníPovinnost se v Barkerově notaci znázorňuje plnou čarou, volitelnost (opak povinnosti) přerušovanou čarou u entitního typu, pro nějž má povinnost platit: pro každého SKLADATELE v našem systému chceme mít v naší databázi nějakou PÍSEŇ, kterou složil:  Jediný povinný vztah v tomto modelu je vztah "složil" pro entitu SKLADATEL. Tzn. každý SKLADATEL složil nějakou PÍSEŇ. Tento vztah je účelově pro náš výklad modelován takto – v realistickém modelu bychom pro takový systém neměli pravděpodobně žádný vztah povinný pro ani jednu z entit. Barkerova notace má tu výhodu, že je nejsrozumitelnější pro neinformatiky, kterým má být model prezentován. Bohužel, někteří informatici ji pletou v ohledu toho, které entity se týká přerušovaná čára půlky linky představující vztah, a proto se často používá Information Engineering notace, kde jsou obě omezení - kardinalita a povinnost – pro danou entitu na stejné půlce linky vztahu:  V information engineering notaci duté kolečko znamená "nemusí", čárka napříč linie vztahu znamená "musí". Tedy: "Každý SKLADATEL musel složit alespoň jednu PÍSEŇ a mohl jich složit více." "Kterákoli PÍSEŇ nemusela být nazpívána žádným ZPĚVÁKEM, ale mohla být nazpívána i více ZPĚVÁKY." "Kterákoli PÍSEŇ nemusela být složena žádným SKLADATELEM, a mohla být složena nanejvýš jedním SKLADATELEM." Duté kolečko se dá také chápat jako číslo 0, čárka napříč jako číslo jedna. Takže můžeme číst: SKLADATEL složil 1 až více PÍSNÍ, PÍSEŇ byla složena 0 až 1 SKLADATELEM, PÍSEŇ nazpívalo 0 až více ZPĚVÁKŮ, ZPĚVÁK nazpíval 0 až více PÍSNÍ. Tento přístup ke značení má ještě jednu variantu, a to s čísly, představujícími minimální a maximální kardinalitu. Minimální kardinalita 1 je vlastně povinnost, minimální kardinalita 0 je nepovinnost. Tato varianta se prosadila v UML notaci:  UML notace, vyžadující součinnost obou mozkových hemisfér – rozpoznání obrazu se musí výrazně kombinovat s přečtením znaků. Diskusi k volbě vhodného značení a uspořádání modelů lze číst například v textu Davida C. Haye. Můžeme doporučit i porovnání jednotlivých notací od stejného autora. V tomto výukovém textu jsme se rozhodli používat modifikovanou notaci Barkerovu.
Atributy vztahuNa komunitním webu mohou registrovaní členové známkovat jednotlivé objekty zájmu dané komunity, dejme tomu počítačové hry. Každý člen může jedné hře udělit jen jednu známku. Ne každý člen známkoval každou hru, dokonce nemusel známkovat žádnou. Jsou i hry, které nebyly nikým známkovány, ale samozřejmě jsou hry oznámkované větším počtem členů. Pokud jde o informaci, kdo kterou hru známkoval, vystačili bychom se vztahem
Členové se identifikují loginem, hry svým názvem. Grafické vyjádření modelu by vypadalo takto:  Tento model neumožňuje zachytit informaci o udělených známkách. Známka je hodnota, měla by být tedy modelována jako atribut. Známka ovšem není atributem ČLENA, neboť jednotlivé známky udělené jedním ČLENEM jsou různé v závislosti na hodnocené HŘE, a ani není atributem HRY, protože známky udělené HŘE se odlišují podle ČLENA, který danou HRU hodnotil. Atribut "známka" je vlastností vztahu mezi nimi. Slovy bychom požadovanou informaci vyjádřili
Graficky vyjádříme takový typ informací takto:  V Barkerově notaci není místo pro atributy vztahů, zde použité značení je naše vlastní. V původní Chenově notaci i v moderním UML na to prostředky jsou, naše značka je podobná oběma těmto notacím. K úplnému objasnění, co je atribut vztahu, může pomoci tabulka s případy vztahu s příslušným atributem:
Tabulku s příklady vztahu nezaměňujte s relační databázovou tabulkou. Primární klíče pro relační databázové tabulky nebyly zvoleny, použité identifikátory jsou identifikátory konceptuální úrovně ("business identifikátory"). Ani názvy sloupců zde neznamenají volbu názvů sloupců pro relační databázovou tabulku. Ukažme si ještě, jak bychom modelovali více atributů pro daný vztah. Například si představme, že pro účely správy zmíněného komunitního webu je potřeba vědět, kdy byla která známka udělena. Požadovaný typ faktu lze slovy vyjádřit takto:
Grafické vyjádření takového typu informací bude vypadat takto:  Kvůli kompaktnosti grafické podoby modelu volíme přístup podobný UML, tedy všechny atributy jednoho vztahu v jednom boxu. Tabulka s případy vztahu s příslušnými atributy:
V této tabulce jsou zvýrazněny sloupce tvořící klíč. Zjištění jaké sloupce tvoří klíč v tabulce s příklady vztahu, je nástrojem ke kontrole správnosti modelu. V našem příkladu je klíčem tabulky dvojice sloupců ČLEN a HRA, podle pravidel může každý ČLEN oznámkovat jednu HRU pouze jednou (když svůj názor změní, starý záznam se přepíše novým). Arita(viz též videa vazba tří, další vazba tří?, ještě jedna vazba tří) Ačkoli většina vztahů, se kterými se v datové analýze setkáme, je binární, jsou i případy, kdy s binárními vztahy nevystačíme. Představme si cestovní kancelář nabízející dobrodružné akce, na které je potřeba určité vybavení. Někteří zákazníci mají takové vybavení svoje, někteří si některé součásti vybavení na zakoupenou akci od cestovní kanceláře zapůjčí. Je třeba evidovat, který zákazník si na kterou akci zapůjčil jaké vybavení, přitom pro daný typ vybavení cestovní kancelář nerozlišuje jednotlivé kusy od sebe, jen při převzetí zkontroluje stav a rozhodne, jestli se ten kus bude dál používat, nebo ne. Zákazníkům se samozřejmě účtuje cena nejen podle účasti na akci, ale i podle zapůjčených součástí vybavení. Cestovní kancelář tedy potřebuje informace typu
Takovou informaci nelze složit z částečných informací
neboť jeden zákazník se mohl zúčastnit více akcí, přičemž na některých si dané vybavení zapůjčil, na jiných ne (měl ho odjinud). A na dané akci si dané vybavení mohlo zapůjčit více zákazníků, nevěděli bychom, kteří to byli. Vztah ".. si na .. zapůjčil .." je ternární, potřebujeme znát, která trojice objektů se ho zúčastnila, částečná informace nestačí. Graficky vyjádříme tento typ informace takto:  Ani pro ternární vztahy není v Barkerově notaci místo. V UML se používá značka kosočtverce. U ternárního vztahu je již obtížné pojmenovávat vztah slovesnou vazbou, která se by se dala použít ve větě jako přísudek, takže se většinou používá jmenné označení: místo ".. si na .. zapůjčil .." například "zapůjčení". Ačkoli u binárních vztahů se dá jejich "pojmenování" volit tak, aby se dalo použít ve větách jako přísudek v jednom či druhém směru čtení (Barkerova notace dokonce vyžaduje formulaci pro oba směry čtení), u ternárních vazeb to téměř nikdy nebývá možné. Jmenná podoba pojmenování vztahu spolu se symbolem kosočtverce navozuje představu objektu. Taková představa je ale přirozená – pojmy "výpůjčka", "volba", "spotřeba", "zkouška" ... jsou běžně používané, kvůli zjednodušení, jako odkaz na nějaký konkrétní případ vztahu. Aritu vztahu nejlépe ověříme na tabulce s případy vztahu. Pro náš příklad:
Klíčem v této tabulce je trojice všech sloupců, a nelze ji vytvořit joinem tabulek s méně sloupci. Co je klíčem v tabulce s případy vztahu zjistíme, když hledáme dostatečné množství případů vztahu, tak aby se ukázalo, jaké shody a odlišnosti mohou nastat. Zároveň nám tato metoda pomůže zjistit, zda nelze tutéž informaci efektivněji získat ze dvou jiných – jestli nemůžeme složit uvažovaný vztah ze dvou vztahů s nižším počtem rolí, tj. s nižší aritou. Demonstrujme si to na následujícím příkladu: V knihovně evidujeme tituly, autory, a máme nějaké kategorie, do kterých jsou tituly zařazeny. Pokud bychom modelovali ternární vztah
pak tabulka s případy vztahu by vypadala takto:
Efektivněji však lze tutéž informaci zapsat takto:
Jinými slovy, jde o dva nezávislé vztahy
Grafické vyjádření:  Uvažovavý rádoby ternární vztah jde z těchto dvou binárních vztahů složit. Příklad prve uvedeného skutečně ternárního vztahu "zapůjčení" byl dosti sofistikovaný, častější případy více-árních vztahů jsou ty, kdy vztah má ještě nějaké atributy. Uvažme například firmu vyrábějící nábytek na zakázku. Výroba postupuje od jednoho řemeslníka ke druhému, předávají si práci a pokračují další fází. Je třeba evidovat, který z nich spotřebovat při své práci na kterém výrobku kolik kterého materiálu. Jsou tedy potřeba informace typu
Ačkoli v různých fázích se typicky používá různý materiál, není to stoprocentní pravidlo. Ačkoli jednu fázi na jednom výrobku typicky provádí jeden pracovník, může se stát, že jich je i více. Tabulka s příklady vztahu:
Klíčem této tabulky je trojice sloupců PRACOVNÍK, VÝROBEK, MATERIÁL. Vazba "spotřeba" mezi entitami PRACOVNÍK, VÝROBEK, MATERIÁL je ternární, "množství" je atribut této vazby. Grafické vyjádření modelu pro tento typ informací:  Název vztahu je v tomto případě vepsán do symbolu kosočtverce, protože vedle něj již není vhodné místo. Takto se přibližujeme notaci Ch.Chena. Vazební entityDoposud uvažované příklady vystačily s konstrukcí entit, vztahů mezi nimi, a atributů. Někdy však potřebujeme posunout chápání vztahu k představě entity, říká se tomu vazební entity. Pracovníci firmy například mohou dosahovat určitých kvalifikací, a za skutečnost, že určitý pracovník dosáhl určité kvalifikace, se vždy musí zaručit nějaký další pracovník firmy. Firma tedy potřebuje uchovávat informace typu:
Tabulka s případy vztahu:
Klíčem této tabulky je dvojice PRACOVNÍK, KVALIFIKACE. Zjistit co je klíčem tabulky lze například tak, že se těch, co znají danou problematiku, zeptáme, zda by bylo možné, aby firma měla ještě další záznam:
Jejich odpověď (v tomto případě negativní) nám to objasní. – Na rozdíl od vztahu "ohodnotil", zde sloupec RUČITEL není atributem, protože obsahuje identifikátor entity obsažené v modelu. Řešením je modelovat vazební entitu "DOSAŽENÍ" pro vztah "PRACOVNÍK p dosáhl KVALIFIKACE k":  DOSAŽENÍ je slabý entitní typ, je identifikačně závislý na PRACOVNÍKOVI, kterým bylo kvalifikace dosaženo, a KVALIFIKACI, které bylo dosaženo. Značky tlustého přeškrtnutí vyjadřují tyto dvě identifikační závislosti. Pro vztah mezi DOSAŽENÍM a jeho ručitelem nebylo zvoleno pojmenování vztahu, ale byla pojmenována role v něm. Povšimněte si ještě, jaká pojmenování byla zvolena pro vztahy k entitám hrajícím role v původním vztahu "dosáhl": "kým" a "čeho". To je typická situace, pojmenování pro takto nově vzniklé vztahy se obtížně hledá, naštěstí český jazyk nám poskytuje bohaté prostředky, například pomocné otázky na větné členy. Ale i to někdy nestačí, potom můžeme použít pojmenování rolí z původního vztahu, z nějž vazební entita vznikla. Opakovatelné události(viz též video opakovaná vazba) S jednoduchou konstrukcí vztahu nevystačíme také, když k uskutečnění vztahu může dojít opakovaně, a je třeba evidovat ty případy, kdy nastal. Představme si výpůjčky v knihovně. Jeden svazek (viz příklad v kapitole Dvoutvářné entity) může být po jeho navrácení znovu vypůjčen – událost "ČTENÁŘ x si vypůjčil SVAZEK y" je opakovatelná. Eviduje se historie výpůjček: kdy bylo co komu půjčeno. Jde o informace typu
Tabulka s případy vztahu:
ČTENÁŘ č.4258 si 1.2.2009 půjčil tři knihy, jednu z nich, s čárovým kódem 3142229757, po prohlédnutí tentýž den vrátil a jiný ČTENÁŘ, č.3184, si ji toho dne vypůjčil. Druhou knihu, s čárovým kódem 3142218611, vrátil ČTENÁŘ č.4258 za měsíc, a ČTENÁŘ č.9482, který na ni čekal, si ji 7.3.2009 vypůjčil. Za měsíc ji tento vrátil, a první ČTENÁŘ, č.4258, si ji opětovně 20.4.2009 vypůjčil. (Údaje o vrácení v této tabulce chybí.) Protože jeden svazek může být v jednu chvíli zapůjčen jen jedinému čtenáři, klíčem předchozí tabulky musí být dvojice SVAZEK, odkdy, jak to i naznačují ukázané případy. Kdyby se měly evidovat jen aktuální výpůjčky, vystačili bychom s modelem:  Vztah aktuálního vypůjčení má kardinalitu 1:n. Pokud ale máme evidovat historii výpůjček, musíme modelovat slabou entitu VÝPŮJČKA:  V tomto modelu je zvýrazněn atribut "odkdy" sloužící k identifikaci VÝPŮJČKY. (Takovéto zvýrazňování klíčů děláme, jen když je to potřeba, protože v případech, kdy je více alternativních klíčů, byli bychom nuceni jeden vybrat a ostatní potlačit.) Model vyjadřuje, že identifikace entity VÝPŮJČKA je složena z atributu "odkdy" a odkazu na entitu SVAZEK. Jiný příklad. Soutěž tanečních párů probíhá v kolech, každé kolo posuzuje porota složená z několika porotců. Každý porotce v každém kole přidělí každému páru body podle svého uvážení. Musí se zaznamenávat informace typu
Tabulka s případy vztahu:
Klíčem v této tabulce je trojice sloupců POROTCE, PÁR, kolo. PÁR v jednom kole mohl dostat různé body od různých POROTCŮ, POROTCE v jednom kole mohl dát různé body různým PÁRŮM, PÁR od jednoho POROTCE mohl dostat různé body v různých kolech. Pokud by šlo pouze o body v jediném kole, vystačili bychom s modelem:  Vztah "ohodnotil" má v jednom kole kardinalitu n:m. Je nepovinný pro obě entity, protože některý POROTCE nemusel v daném kole být v porotě, a některý PÁR se nemusel daného kola zúčastnit. Události typu "POROTCE x přidělil y bodů PÁRU z" se však mohou opakovat v každém kole. Protože máme modelovat ukládání výsledků ze všech kol, potřebujeme slabou entitu HODNOCENÍ:  HODNOCENÍ je identifikačně závislé na POROTCI, kterým bylo hodnoceno, a na PÁRU, který byl hodnocen. K identifikaci HODNOCENÍ je ještě potřeba znát, ve kterém kole to bylo. Proč je potřeba tak pečlivá analýza?Kardinalita, povinnost, arita vztahu se projeví při převodu do databázových struktur, výsledné databázové schéma je jiné, pokud je vztah 1:n, n:1 nebo n:m. Ternární vztahy se realizují jinými strukturami, než binární. Určení povinnosti je nejméně závažné, ale změna za provozu databáze se může setkat s problémem chybějích dat. Rozbor na případechV této kapitole řešené příklady ukazují, jak lze konceptuální analýzu podpořit rozborem případů. Tato metoda poslouží tehdy, kdy se potřebujeme ubezpečit o správnosti modelu nebo když problematice dobře nerozumíme. Při konzultaci s neinformatiky může pomoci tabulka s případy vztahu, diagram výskytů, nebo větná formulace požadovaných informací. Více viz kapitolu Analýza za pomoci příkladů. NeproměnnostMálokterý výklad zásad datového modelování zmiňuje, že by měl analytik zjišťovat, zda jsou uvažované typy vztahů stálé. Například "ZÁKAZNÍK podal OBJEDNÁVKU" je stálý vztah, nemůže se stát, že by došlo ke změně skutečnosti, kdo danou objednávku podal. Zato vztah "PRACOVNÍK vede ODDĚLENÍ" je vztah, který může doznat změn, jednou je vedoucím oddělení jedna osoba, později to může být druhá. StatistikyPro rozhodování o vhodné organizaci databáze poslouží i informace o statistikách kardinality a u nepovinných vztahů o počtu entitních výskytů, které v daném vztahu jsou. Například většina knih má jediného autora, ačkoli existují knihy s více autory. A počet autorů u jedné knihy nebývá vyšší než 20. Nebo ačkoli v knihovně mohou být záznamy o titulech, ke kterým knihovna nemá žádné knihovní jednotky (svazky), je taková situace vzácná. < Co jsou ISA vztahy | Tutoriál informační analýzy | Role ve vztahu > |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
