DBS - řešení 1. úkolu - lichý týden

Takhle jsem si to nějak představoval, když jsem vymýšlel zadání. Existuje stovka správných řešení, tohle je příklad, jak by to mohlo být.

P.S.:Pokud je tam někde chyba, je to zásadně z nepozornosti

1. Ten poslední bod ze zadání (historie a rezervace) jsem neřešil. Později jsem si uvědomil, že to nebyl moc dobrý nápad a asi by to vyžadovalo trochu složitější řešení.
2. Vztah pasažér by mohl být i 1 ku N, pokud uvažujete pasažéry jen jako položky seznamu. Tj. při bookování nebude systém hledat pasažéra, jestli už někdy cestoval, ale prostě vytvoří další záznam. Tak bude každá entita v právě jednom letu.
3. Pasažéry podle mě není vhodné dávat do jedné ISA hierarchie k personálu, nejsou až zas tak příbuzní s posádkou a dědičnosti ala OMO tu moc nevedeme. A vůči relačnímu modelu by to nebylo taky moc ohleduplné.
4. S těmi parcialitami u vztahů let-posádka nebo let-pasažéři je to sporné. Podle reality je jasné, že letadlo nemůže letět prázdné. Jenže let se v systému může nacházet ve stavu, kdy ještě nemá přiřazen personál nebo pasažéry (například ve fázi rezervace). Proto by bylo vhodnější uvažovat let-pasazer(0:N)-(1:N). V našem případě je to konečně jedno, ER modelář stejně parciality v některých případech nepromítne do integritních omezení databázového schématu. Nicméně nuly určitě budou správnější z hlediska implementace.

Pozor na to, náš E-R modelář v Chenově notaci má označení kardinalit obráceně než UML. Zkuste si v modeláři nakreslit dvě entity spojené 1:N vztahem. Poté si změňte zobrazení na zbývající dvě notace (Binary model, UML) a uvidíte rozdíly.

Je nutno se zamyslet nad problémem. Dá se předpokládat, že opatření jsou pro všechny lety do stejné destinace stejná. Tím, že letu určíte destinaci, přiřadíte i potřebná opatření/doporučení. To znamená, že vztah někam jinam než k Destinaci není moc dobře. Výjimkou může být, pokud evidujete u pasažérů, zdali např. mají vízum.

Obdobným problémem může být i vztah let-pasažér. Zde je nutné posadit pasažéra do letu. Pokud to uděláte do letadla, znamenalo by to, že použité letadlo určuje pasažéry, což rozhodně není pravda. Jinak to může být s personálem, i když tam bych je k letadlu taky nedával (ale nejsem manažer letecké společnosti).

Jazykové schopnosti nelze vyjádřit více atributy (angličtina, němčina apod.) pro letušku. Při přidání nového jazyka by bylo potřeba měnit DB schéma. Nejsprávnější řešení je samostatná entita.

Stejným případem jsou opatření/doporučení.

Bez atributů entita postrádá smysl. Bez primárních klíčů nelze digram ani zvalidovat. Uvědomte si, že zde primární klíč jednoznačně identifikuje entitu. Je nutné zvolit správnou kombinaci atributů, aby ta unikátnost dávala smysl. Jako univezální řešení se nabízí tradiční identifikační číslo.

~~DISCUSSION~~