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á.
