Pokud hledáte, jak v Power Designeru (používanému při výuce na VŠE) převést konceptuální model do fyzického, podívejte se na Jak vygenerovat fyzický model a co v něm udělat dalšího.
Zde vysvětíme obecný "algoritmus" převodu konceptuálního datového modelu do relačního databázového schématu. (Jiné databázové modely zatím přesahují rámec našeho záměru.)
Postup transformace je dnes již natolik rutinní, že je zabudován do téměř všech CASE nástrojů. Nicméně je dobré vědět, co se přitom děje, abychom rozuměli, a abychom eventuálně mohli zvolit jinou možnost, pokud se to pro naši konkrétní aplikační oblast lépe hodí. Mnohé CASE nástroje pro některé prvky modelu nabízejí možnost volby, co s nimi při generování relačního schématu udělat, jiné tu možnost nenabízejí.
Postup transformace lze popsat v následujících krocích.
- Každý složený atribut rozložte do složek, opakujte tak dlouho, až není dalších složených atributů.
- Vícehodnotové atributy převeďte na vztah k "hodnotovému" entitnímu typu představujícímu doménu atributu.
- Pro každý atribut vyberte nejvhodnější datový typ.
- Rozhodněte o primárních klíčích pro entitní typy.
Volba primárních klíčů úzce souvisí s efektivitou ukládání dat a provozu relační databáze. To proto, že v relačních databázích primární klíče tabulek slouží k provazování záznamů
cizími klíči, a k podpoře efektivity realizace těchto vazeb se používá technologie indexování. Efektivita indexování je závislá na datové velikosti klíče, a efektivita celé konstrukce je závislá na stabilitě klíče.
Protože jiné sledovatelné účely, jako je podpora vyhledávání na základě sémantických identifikátorů, lze naplnit nezávislými prostředky, je v současné době tendence navrhovat pro primární klíče tabulek nevýznamové umělé identifikátory (často pojmenovávané ID), a ostatní alternativní klíče definovat jako další unikátní sloupce –
diskuse k této problematice od Scotta W. Amblera. Završením této tendence je možnost v moderních objektově-relačních databázích přiřazovat záznamům skryté identifikátory, jejichž hodnota není dostupná nikomu kromě databázového systému.
- Rozhodněte o všech ISA vztazích (tj. o dědičnosti), co se s nimi má udělat. Pro každou typovou hierarchii připadají do úvahy 3 možnosti, s případným definováním pohledů:
- Absorpce do nadtypu. Bude jedna tabulka, ve které bude vše. Specifické atributy podtypů vytvoří nepovinné sloupce v této tabulce. – Tato volba je vhodná v případě, když nemáme žádný důvod mít pro podtypy zvláštní tabulky. Nevýhodou je, že vznikají sloupce s významným množstvím NULL hodnot, a je nutno eventuálně definovat složité integritní podmínky pro řádky tabulky. Můžeme, pokud je to potřeba, definovat pohledy pro jednotlivé podtypy.
- Rozdělení do podtypů. Každý podtyp bude tvořit jednu tabulku, ve které bude všechno pro tento podtyp, včetně zděděných vlastností. Takže nebude žádná tabulka pro nadtyp. – Tato volba je vhodná v případě, že nepotřebujeme tabulku pro nadtyp, a podtypy tvoří členění, tj. nepřekrývají se a vyčerpávají všechny případy z nadtypu. Můžeme, pokud je to potřeba, definovat union-pohled pro nadtyp.
- Separace vlastností. Bude jedna tabulka pro nadtyp, a pro každý podtyp další tabulka se sloupci specifickými pro tento podtyp a s cizím klíčem ukazujícím na "mateřský" záznam v tabulce nadtypu. Tyto cizí klíče budou zároveň unikátní v tabulkách podtypu. Pokud měl některý podtyp jiný identifikátor, než nadtyp, definujte v tabulce tohoto podtypu alternativní klíče. – Tato volba je vhodná v případě, pokud potřebujeme jak tabulku pro nadtyp (například pro nějakou kontrolu), a pro podtypy máme specifická pravidla či specifické vztahy. Můžeme definovat pohledy, se všemi atributy, pro nadtyp i pro podtypy.
- Rozhodněte o všech vztazích 1:1, co s nimi. (Ryzí 1:1 jsou vzácné, častější je případ, že takový vztah může někdy nabýt kardinality 1:n.). Opět jsou 3 možnosti:
- Dominantní role. Vztah bude mapován k jednomu entitnímu typu v tabulce tohoto entitního typu, jako cizí klíč odkazující do tabulky příslušející k tomu druhému entitnímu typu. – Tato volba je nejčastější, protože jedna z rolí bývá tzv. dominantní:
Například vedoucí oddělení hraje dominantní roli vůči oddělení: v běžné situaci má každé oddělení vedoucího (má jednoho a ne více vedoucích), zato většina pracovníků nejsou vedoucími oddělení. Takže vztah "vede" mezi oddělením a pracovníkem bude mapován jako cizí klíč do tabulky pro oddělení. Na tomto příkladu si můžeme uvědomit, že ve výjimečných případech může jeden pracovník vést více oddělení, takže tento vztah není ryzí 1:1, ačkoli typicky ano. – Pokud chceme zajistit ryzí kardinalitu 1:1, musíme požadovat unikátnost pro sloupec s příslušným cizím klíčem (v tomto příkladu v tabulce oddělení unikátnost pro sloupec odkazující na vedoucího).
Pokud má vztah atributy, mapujeme je do tabulky odpovídající ne-dominantní roli jako další sloupce. Například datum, odkdy je tento pracovník vedoucím toho oddělení, bude jako další sloupec v tabulce oddělení.
- Další tabulka. Bude vytvořena další tabulka pro ten 1:1 vztah. Ta bude tedy mít dva cizí klíče, jeden odkazující do tabulky pro první entitní typ, druhý do tabulky pro druhý entitní typ. Pokud chceme zajistit skutečně 1:1, musí každý z těchto cizích klíčů být v tabulce unikátní. – Tato volba je vhodná, pokud výskyt vztahu je vzácný jak pro entity prvního typu tak i pro entity druhého typu.
Například pokud chceme evidovat manželské vztahy mezi zaměstnanci, budou výskyty vzácné, a hodí se takováto varianta.
Pokud má vztah atributy, mapujeme je do tabulky vztahu jako další sloupce.
- Společná tabulka. Oba entitní typy mapujeme do společné tabulky, se dvěma množinami sloupců, v první budou sloupce příslušné k prvnímu entitnímu typu, ve druhé sloupce příslušné k druhému entitnímu typu. Tato volba je vhodná, pokud je vztah povinný pro oba entitní typy, a navíc je stabilní.
Například evidujeme taneční páry, žádný tanečník či tanečnice nejsou sólo. Ale i tento vztah nemusí být v delším časovém horizontu stabilní, tato logická organizace dat by se hodila jen pro průběh jediné soutěže.
Pokud má vztah atributy, mapujeme je do společné tabulky vztahu jako další sloupce. Například odkdy daný pár spolu tančí.
- Každý samostatný entitní typ mapujte do samostatné tabulky. Každý jednoduchý atribut entitního typu mapujte do samostatného sloupce příslušné tabulky.
Zvažme, zda pro "hodnotový" entitní typ podle bodu 2. budeme vůbec nějakou tabulku definovat. Pokud pro daný atribut nevytvoříme číselník, nejspíš takovou tabulku nepotřebujeme. V této fázi si ji však ještě mysleme, na konci celého procesu transformace ji odstraníme.
- Každý vztah n:m nebo vztah s aritou vyšší než 2 mapujte do samostatné tabulky. Pro každou roli vztahu bude v této tabulce jeden sloupec obsahující cizí klíč odkazující do tabulky odpovídajícího entitního typu.
Například vztah "nazpíval" mezi písní a zpěvákem mapujeme do tabulky se sloupci nazvanými například "pisen", "zpevak", v nichž budou cizí klíče odkazující do tabulky "PISEN" resp. "ZPEVAK".
Primární klíč v tabulce mapující takový vztah je složený z množiny všech těchto zmíněných cizích klíčů.
Případné atributy vztahu mapujte do dalších sloupců tabulky vztahu.
- V některých případech může být vhodné, jako primární klíč tabulky vztahu navrhnout umělý klíč, a klíč složený z kombinace cizích klíčů odkazujících na role ve vztahu definovat jako alternativní. Důvodem k takové volbě může být potřeba se na řádky tabulky vztahu odněkud odkazovat.
- Mapujte vztahy 1:n:
- Běžné je mapování do sloupce s cizím klíčem v tabulce na straně n. Například pro vztah "kdo podal" mezi objednávkou a zákazníkem vytvoříme v tabulce objednávek sloupec odkazující do tabulky zákazníků. Případné atributy vztahu mapujeme do dalších sloupců tabulky na straně n. Pokud vztah "kdo podal" má atribut "kdy", vznikne z něj další sloupec v tabulce objednávek.
- Méně běžné je mapování do samostatné tabulky. Tato volba je vhodná pro případy, kdy role na straně n je nepovinná a vzácná. Například některé dokumenty jsou součástí jiného dokumentu. Takový vztah "je součástí" můžeme mapovat do samostatné tabulky. Od mapování vztahu m:m se tato volba odlišuje tím, že v tabulce vztahu bude sloupec odpovídající podřízené roli primárním klíčem. Pro vztah "je součástí" by byl v příslušné tabulce primárním klíčem sloupec s odkazem na podřízený dokument.
Rozhodně ne všechny předchozí kroky lze svěřit automatice CASE nástroje (např. Power Designeru používanému při výuce na VŠE) , co se má rozhodnout, musíte rozhodnout sami. Někdy musíte CASE nástroji pomoci nějakým trikem.
Normalizovaná databáze
Databáze, ve které se žádný údaj či fakt zbytečně neopakuje, je normalizovaná. Uvažte například údaje o kontaktních adresách na dodavatelské firmy, nebo záznamy o skutečnostech, že daný uživatel navštívil danou stránku. Pokud si budeme zapisovat kontaktní adresu na dodavatele ke každému zboží zvlášť, bude naše databáze nenormalizovaná. Pokud při každé návštěvě každého uživatele budeme zaznamenávat, které stránky navštívil (a nikoli třeba ještě časový údaj), pak bude naše databáze nenormalizovaná.
Formální otázky normalizace relační databáze odložme stranou. Panuje však pověra, že použijeme-li standardní transformaci konceptuálního modelu do relačního schématu, například uvedenou v této kapitole, pak získáme normalizovanou databázi. Není to nutně pravda, výsledek záleží na kvalitě konceptuální informační analýzy. Například dvoutvářné entity jsou typickým případem, kdy je snadné se dopustit chyby. Jsou i jiné případy. Takže na normalizaci musíme myslet už při konceptuální analýze: aby každý typ faktu byl modelován jen jednou, aby typy fakt byly nerozložitelné.
Normalizace je dobrá k tomu, abychom
- usnadnili zapisování nových dat, protože nebude nutno je zapisovat více než jednou
- usnadnili aktualizaci dat, protože nebude nutno přepisovat na více místech
- zabránili nekonzistenci v datech (pokud by se informace o zákazníkovi zapisovaly do každé objednávky znova, mohlo by v každé jeho objednávce o něm být zapsáno něco jiného)
- zabránili ztrátě dat (například kdybychom smazali všechny objednávky nějakého zákazníka, nemuseli bychom již o tom zákazníkovi mít žádnou informaci)
- usnadnili výpočty relevantních statistik z dat (například kolik procent z našich stránek který návštěvník viděl)
- výrazně omezili nutnost budoucích radikálních změn ve schématu a navázaných aplikacích
Denormalizace
Postup transformace popsaný v této kapitole vede v bezchybných případech k normalizovanému schématu. To ale nemusí být vždy žádoucí, normalizované schéma je typicky "rozlámáno" do mnoha tabulek, které je třeba při práci s daty propojovat. Pokud se tomu z nějakého dobrého důvodu chceme vyhnout, tzv. denormalizujeme. Nebo pokud se chceme vyhnout opětovným vyhodnocováním stejných výrazů, a místo toho ukládáme výsledky těchto výpočtů do databáze.
Například do položky faktury zaznamenáme i vypočítaný údaj "množství*jednotková cena". Nebo kromě rodného čísla zapíšeme i datum narození nebo pohlaví. Nebo do záznamu o studentovi budeme zapisovat i počet získaných kreditů, i když se dá vypočítat ze záznamů o jeho zkouškách. Při zápisech studentů pak nemusí být systém zatěžován opakovaným ověřováním, zda si může ještě něco zapsat. Nebo do záznamu o knihovní jednotce zapíšeme, zda je vypůjčená, i když se to dá zjistit ze záznamů o výpůjčkách. Usnadní to vyhledávání volných jednotek.
Jak je vidět, denormalizujeme proto, aby
- se usnadnilo vyhledávání potřebných dat
- omezilo vypočítávání výsledků, které jsou stále stejné.
Co denormalizovat
Je vidět, že při normalizaci a denormalizaci jde o jakýsi kompromis mezi usnadněním aktualizací dat a usnadněním jejich vyhledávání. Při rozhodování pomůže, když rozdělíme modelovaná fakta na ta, která odrážejí aktuální stav, který se může měnit, a na fakta archivní, jež jednou zaznamenána se měnit nebudou. U archívních dat se denormalizace bát nemusíme, dokud nenarazíme na problém s objemem dat.
U dat, jež podléhají aktualizacím, záleží rozhodování na provozu databáze, co se má spíše podpořit, jak často který požadavek nastává.
