13. blok Databázové modelování v praxi

13. blok

Databázové modelování v praxi

Studijní cíl Rekapitulace všech kroků při tvorbě databázového modelu. Demonstrace všech fází databázového návrhu na praktickém příkladu. Ukázky z modelování v konkrétním modelovacím nástroji. Přenesení fyzického modelu do databáze.

Doba nutná k nastudování

2 - 3 hodiny

Průvodce studiem Při studiu tohoto bloku se předpokládá, že čtenář je obeznámen se základními pojmy ze všech fází databázového modelování, jako jsou entity, atributy, relace tabulky, kandidátní klíče, primární klíče, cizí klíče, parcialita, kardinalita, apod.

1. Úvod Cílem tohoto bloku je ukázat praktický příklad modelování databázového systému. Postupně budou představeny probrané kroky databázového modelování. Zároveň bude poukázáno na vzájemnou návaznost jednotlivých kroků. Za modelový příklad bylo zvoleno vytvoření informačního systému vysoké školy. Samozřejmě se bude jednat jen o demonstrativní příklad, tudíž systém nebude reflektovat všechny typické potřeby vysokých škol a proto se bude jednat jen o zjednodušený model informačního systému. Předně bude tento blok zaměřen na samotnou fázi modelování databázového systému, tzn., že se soustředí na fáze konceptuální, logického a fyzického modelovaní. O před-návrhových fázích bude předpokládáno, že již proběhly a že máme k dispozici všechny jejich důležité výstupy.

David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/13 – Databázové modelování v praxi

1

2. Konceptuální modelování Jak již bylo řečeno, základním úkolem konceptuálního modelování je identifikace pokud možno co největšího počtu podstatných entit modelovaného systému spolu s relacemi mezi těmito entitami. Zároveň by mělo dojít k nalezení důležitých atributů entit a relací. Všechny důležité kroky konceptuálního modelování se dají shrnout následujícími body: 1. 2. 3. 4. 5. 6. 7.

Identifikace entit. Identifikace relací. Identifikace atributů a spojení atributů s entitami a relacemi. Nalezení domén atributů. Vyhledání kandidátních, primárních a alternativních klíčů. Kontrola redundance v modelu. Posouzení zda model podporuje uživatelské transakce.

Nyní tedy přistoupíme ke kroku číslo jedna.

2.1. Identifikace entit. O detailech hledání entit v rámci konceptuálního modelování se může více dočíst v kapitole o identifikaci entit v rámci bloku o konceptuálním modelování. Předpokládejme, že pro prostudování datového slovníku, který byl vytvořen během před-návrhové fáze tvorby databázového modelu, byly vybrány následující důležité entity. Pro lepší přehlednost je dobré vytvořit seznam nebo tabulku pro zobrazení nalezených entit. Zvolíme tabulku: Student Studijní materiál

Vyučující Zkouška

Program Předmět

Obor Fakulta

Tabulka 1 - Nalezené entity.

Samozřejmě že seznam není kompletní, neboť informační systémy vysokých škol bývají velmi rozsáhlé, tudíž čítají velký počet entit. Je důležité uvědomit si, že tento seznam entit nelze nikdy prohlásit za konečný. V pozdějších částech modelovaní se totiž mohou objevit entity nové, jejichž výskyt nebyl v raných fázích modelování zřejmý. V tu chvíli je nutné seznam entit aktualizovat o nově nalezené entity. Naopak se může i stát, že v pozdějších fázích budou identifikovány entity, které z pohledu modelovaného systému pozbyly smyslu. Ty je naopak nutné ze seznamu entit odstranit. Proto se na celý proces tvorby databázového modelu pohlíží jako na iterativní proces, jehož jednotlivé fáze se mohou stále opakovat.


2

2.2. Identifikace relaci. Nyní, když máme k dispozici seznam pro nás všech důležitých entit, je nutné začít hledat vztahy mezi těmito entitami. K tomu slouží seznam nalezených entit spolu s datovým slovníkem nalezeným v před-návrhové fázi tvorby databázového modelu. Podrobnější informace o identifikaci relaci naleznete opět v bloku o konceptuálním modelování, konkrétně v kapitolt věnující se identifikaci relací v bloku konceptuálního modelování. Výstupem této fáze může být opět přehledná tabulka všech nalezených relací. Entita Student Student Vyučující Vyučující Program Fakulta Student Vyučující Studijní materiál

Relace Zapisuje Přihlašuje Učí Vytváří Má Nabízí Studuje Publikuje Náleží

Entita Předmět Zkouška Předmět Zkouška Obor Program Fakulta Studijní materiál Předmět

Tabulka 2 - Nalezené relace mezi entitami.

Je vhodné pojmenovávat jednotlivé relace unikátními názvy, které zároveň odráží význam dané relace. Důležité je upozornit na to, že ne všechny nalezené entity musí mít vazby na ostatní identifikované entity. V systému se klidně mohou vyskytovat osamocené entity. Výskyt těchto entit není v žádném případě chybou modelu, a proto je důležité, aby z modelu nebyly odstraněny, protože můžou modelovat velmi důležitou část systému. Výpis jednotlivých relací do tabulky je výhodný, když pracujeme s malým počtem entit a relací. Se zvětšujícím se počtem entit a relací se však stává nepřehledným. Výhodné je proto jednotlivé relace zobrazit graficky, pomocí tzv. ER-diagramu (blok konceptuálního modelování, kapitola o ER modelování), viz příklad:


3

<<Entity>> Stud. materiál

<>

<>

< Náleží <>

<<Entity>> Student

< Publikuje <>

<<Entity>> Předmět

Zapisuje >

<>

<>

Přihlašuje >

Vytváří

<<Entity>> Zkouška

<>

Studuje >

<>

Nabízí >

<<Entity>> Fakulta

<<Entity>> Vyučující

< Učí

<>

<<Entity>> Program

Má >

<<Entity>> Obor

Obrázek 1 - Grafické znázornění relací mezi entitami konceptuálního modelu.

Tento ER-diagram byl vytvořen prostřednictvím UML notace pomocí programu Visio. Samozřejmě existují i jiné programy pro tvorbu ER diagramů podporující nejrůznější notace zápisu ER diagramu. Vždy, před využitím konkrétního programu pro ER modelování je nutné ověřit si, jaké notace daný program využívá a jakým způsobem je graficky reprezentuje. Po identifikaci relací je nutné přistoupit k identifikaci multiplicit relací. Multiplicita vyjadřuje počet výskytů jedné entity, které se mohou vztahovat k jedinému výskytu související entity. Opět je vhodné multiplicity reprezentovat graficky, resp. je zahrnout do původní grafické reprezentace relací. Viz diagram: 0..N

<> < Náleží

<<Entity>> Stud. materiál

0..N

< Publikuje <> 1..1

0..N

<<Entity>> Student 0..N

<> Studuje >

1..N

0..N

<> Zapisuje >

0..N

<> Přihlašuje >

1..1

<<Entity>> Fakulta

<> Nabízí > 1..*

1..1

<<Entity>> Předmět

<<Entity>> Zkouška

<<Entity>> Program

0..N

1..N

<> < Učí

<<Entity>> Vyučující 1..1

0..N

<> < Vytváří <> 1..* Má >

1..1

<<Entity>> Obor

Obrázek 2 - Konceptuální model se znázorněním multiplicit.


4

2.3. Identifikace atributů, spojení atributů s entitami a relacemi. Po nalezení entit, relací a stanovení multiplicit přichází na řadu hledání atributů. Atributy jsou de facto vlastnostmi nalezených atributů a relací. Příkladem atributu entity Student může být studentovo jméno. Příkladem atributu relace, může být například datum zápisu na zkoušku, který by určitě náležel relaci „Přihlašuje“. Více informací o hledání atributů naleznete v kapitole popisující identifikaci atributů v bloku věnovaném konceptuálnímu modelování. Výstup tohoto kroku je opět vhodné reprezentovat tabulkou. Viz tabulka atributů pro vybrané entity. Entita Student

Předmět Zkouška

Atributy cisloStudenta, jmenoStudenta (složený: stJmeno, stPrijmeni), stDatumNarozeni, stRodneCislo, adresa (složený: stUlice, stCp, stMěsto, stPsc), stEmail, stTelefon, stPohlavi, stStuduje kodPredmetu, prNazevPredmetu, prPocetKreditu cisloZkousky, zkDatumZkousky, zkMaxStudentu Tabulka 3 - Příklady nalezených atributů k vybraným entitám.

Následně je nutné u nalezených atributů identifikovat jejich domény (kapitola o nalezení domén atributů, blok konceptuálního modelování) a určit kandidátní, primární a alternativní klíče (kapitola o vyhledávání klíčů, blok konceptuálního modelování).

2.4. Validace konceptuálního modelu Pod pojem validace konceptuálního modelu se dají zahrnut kroky kontroly redundance a kontroly podpory uživatelských transakcí. V případě kontroly redundance (nadbytečnosti) se kontroluje, zda model některé skutečnosti nemodeluje zbytečně vícekrát. Redundance se může vyskytnout jednak u entit, kdy se v modelu objeví více entit, které však ve všech případech modelují tutéž skutečnost. Redundance může postihnout i relace, tzn., že v modelu se mezi dvěma entitami objeví relace, kterou je možné vyjádřit pomocí jiné relace (jiných relací). A konečně, redundance může postihnout i atributy, kdy máme v modelu sice různě pojmenované atributy, avšak všechny vyjadřují stejnou vlastnost. Redundance je ve většině případů považovaná za škodlivou a proto je jí dobré z modelu odstranit. O výjimce, kdy je redundance žádoucí, informuje kapitola o řízeném zavedení redundace z bloku věnovaného fyzickému modelování. Po odstranění redundancí z modelu je nutné prověřit, zda výsledný model podporuje všechny navržené a požadované uživatelské transakce. Jinak řečeno, zda nad navrženým modelem bude možné provádět všechny požadované operace a zda model umožňuje ukládání všech požadovaných informací. V této fázi by mělo vyjít David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/13 – Databázové modelování v praxi

5

najevo, že byly některé důležité entity a relace opomenuty, nebo že byly neprávem odebrány. Více informací o kontrole uživatelových transakcí naleznete v kapitole popisující kontrolu uživatelských transakcí (blok konceptuálního modelování).

2.5. Shrnutí konceptuálního modelování Výstupem konceptuálního modelování je ER diagram zachycující entity a relace. Model je zatím oproštěn od implementačních detailů, avšak zachycuje základní logiku modelovaného systému. Model by neměl obsahovat žádné redundance a zároveň byl splňovat všechny požadované uživatelské transakce. Námi vytvořený ER diagram a nalezené atributy budou sloužit jako podklad pro fázi logického modelovaní.


6

3. Logické modelování Základním zdrojem informací pro logické modelování je diagram vytvořený ve fázi konceptuálního modelování. Podstatou logického modelování je převedení nalezených entit a relací na tabulky a relace mezi těmito tabulkami. Kompletní teoretický základ logického modelovaní je popsán v příslušném e-learningovém bloku věnovaného logickému modelování. V rámci tohoto bloku bude logické modelování představeno z praktické stránky. Bude představen nástroj pro tvorbu logických modelů, kde bude následně konceptuální model převeden na logický.

3.1. Logické modelování prakticky Tvorba logického modelu bude provedena pomocí programu Toad Data Modeler (TDM) ve verzi čtyři, konkrétně v jeho freewarové verzi. Je dobré zdůraznit, že TDM umožňuje přímou konverzi logického modelu do fyzického modelu. TDM využívá pro vizualizaci ER-diagramu IE notace. Alternativně může používat i notaci IDEF1X. Specifikem IE notace, například oproti UML notaci, je v grafickém zobrazení multiplicit. Následující tabulka osvětlí význam jednotlivých grafických zobrazení.

IE notace

UML Notace 1..N 0..N 1..1 0..1

Tabulka 4 - Grafické znázornění multiplicity v logickém modelu.

Nyní bude představen samotný modelovací nástroj Toad Data Modeler 4. Freeware verzi je možné stáhnou z: http://modeling.inside.quest.com. Základní rozhraní aplikace vypadá následovně:


7

Obrázek 3 - Modelovací nástroj Toad Data Modeler.

V podstatě se dá rozdělit na tři základní část: 1. Pracovní plocha (Workspace), do které se tabulky a relace logického modelu umisťují. 2. Logical Model Explorer - udržuje strom všech objektů použitých v modelu. 3. Panel obsahující objekty a nástroje pro tvorbu modelů.

Pokud chceme začít vytvářet nový logický model, je nejprve nutné nový model vytvořit. To se provede přes menu File -> New -> Model. Po kliknutí na model se objeví následující formulář:


8

Obrázek 4 - Založení nového logického modelu.

V rámci toho formuláře se vybírá, jaký typ modelu bude vytvořen. Jelikož se nacházíme ve fázi logického modelování, zvolíme záložku „Logical Data Model“ a v ní položku „Logical model“. Současně můžeme vyplnit jméno modelu, pokud se chceme vyhnout přiřazení implicitního jména. Po potvrzení formuláře se otevře nový pracovní prostor, ve kterém můžeme náš logický model vytvářet. Pro tvorbu modelu je nejdůležitější panel nástrojů nazvaný „Designer“. Na tomto panelu pro modelování asi nejčastěji využijete následující tři objekty: Entita – v kontextu logického modelování se jedná o tabulku, kterou chceme modelovat. Relace – identifikující relace spojující dvě tabulky. Tento typ relace po převodu na fyzický model umístí kopii primárního klíče rodičovské tabulky do tabulky dceřiné, kde se tento cizí klíč zároveň stane i klíčem primárním.


9

Neidentifikující relace – opět slouží pro vytvoření relace mezi dvěma tabulkami, ovšem v tomto případě se z primárního klíče rodičovské tabulky stane jen cizí klíč dceřiné tabulky.

3.1.1. Vytvoření tabulky Nyní se můžeme přesunout k tvorbě samotného logického modelu databáze. Zvolíme tedy objekt entity a vložíme jej do našeho pracovního prostoru. Po přesunutí do prostoru bychom měli vidět prázdnou tabulku:

Obrázek 5 - Prázdná tabulka logického modelu.

Dvojklikem na prázdnou tabulku (alternativně pravý klik a volba „Edit…“) otevřeme formulář pro zadávání jednotlivých vlastností tabulky:

Obrázek 6 - Detail tabulky logického modelu.


10

Na záložce „General“ jsou nejdůležitěji položky „Caption“ a „Name“. Položka „Name“ udává skutečné jméno tabulky, kdežto položka „Caption“ udává název, který se bude zobrazovat v rámci modelu. Po vyplnění obou položek můžeme přejít k záložce „Attributes“.

Obrázek 7 - Zobrazení sloupců tabulky logického návrhu.

Na této záložce přidáváme jednotlivé sloupce tabulky. Sloupec přidáme stiskem tlačítka „Add“. U každého sloupce můžeme kromě jeho jména a jména, které se bude zobrazovat v rámci modelu, nastavit i jeho datový typ. Jelikož se jedná o logický model, zde uvedené datové typy nebudou korespondovat datovými typy žádného databázového systému. Jedná se pouze o obecné datové typy. U určitých datových typů, jako třeba „Number“ je možné specifikovat i přesnost daného typu. Obdobně u řetězce s proměnlivou délkou je možné specifikovat maximální počet ukládaných znaků. K tomu slouží sloupce „p1“ a „p2“. Upozornění: Cizí klíče se v TDM nemodelují, jsou totiž reprezentovány relacemi a jsou tedy generovány automaticky. Další důležitou záložkou modelu je záložka „Unique Identifiers“. Záložku „Description“ je vhodné využít pro popis významu dané tabulky. Může se zde například specifikovat význam tabulky v kontextu daného systému, můžou zde být zaznamenány různé změny, které byly nad tabulkou provedeny, nebo zde může být popsán obecný formát ukládaných dat. Záložka „To Do“ pak může sloužit pro záznam budoucích plánovaných změn tabulky.


11

Obrázek 8 - Unikátní identifikátory tabulky logického návrhu.

Základním úkolem záložky „Unique Identifiers“ je specifikovat primární klíče dané tabulky. Dále je možné specifikovat i alternativní klíče. V každé tabulce bude vždy specifikován minimálně jeden klíč, a to klíč primární. Nyní je nutné určit, které sloupce tabulky se stanou primárním klíčem. To se provede dvojklikem na již existující unikátní identifikátor.

Obrázek 9 - Výběr sloupců, jejž se stanou primárním klíčem dané tabulky.


12

Sloupce, které chceme označit jako primární klíče, přesuneme do pravého sloupce. Důležité je, abychom po definici sloupců na záložce „Attributes“ tabulku uložili, například přes tlačítko „Apply“ formuláře s detaily tabulky. Pokud bychom tak neučinili, nebyli by v tomto formuláři na výběr žádné sloupce. Po přesunutí formulář potvrdíme, následně potvrdíme i formulář s detaily naší tabulky. Po potvrzení bychom měli dostat následující výsledek:

Obrázek 10 - Výsledná tabulka logického modelu.

3.1.2. Vytvoření relace Tvorba relací bude demonstrována na dvou ukázkových tabulkách. Každá z ukázkových tabulek obsahuje primární klíč:

Obrázek 11 - Tabulky bez relace.

Jak již bylo uvedené výše, v TDM existují dva typy relací, které můžeme realizovat. Jsou to relace identifikující a neidentifikující. Relace se v TDM vytvoří tak, že se vyper příslušný typ relace z nabídky a dané relace se vede vždy od rodičovské tabulky k tabulce dceřiné.


13

Obrázek 12 - Tabulky s ukázkami identifikující a neidentifikující relace.

V rámci logického modelování je rozdíl více méně grafický. Avšak podívejme se, co se s jednotlivými relacemi stane, když dané logické modely převedeme na modely fyzické.

Obrázek 13 - Tabulky s identifikující a neidentifikující relací po převedení na fyzický model.

U identifikující relace došlo k tomu, že primární klíč rodičovské tabulky se stál zároveň i primárním klíčem dceřiné tabulky. Kdežto u neidentifikující relace došlo pouze k vytvoření cizího klíče v dceřiné tabulce. Tuto skutečnost je dobré mít vždy na paměti a před použitím relace se vždy zamyslet nad tím, jakou relaci využít. Nyní se zaměříme na vlastnosti jednotlivých relací. Detail každé relace získáme dvojklikem na příslušnou relaci.


14

Obrázek 14 - Detail relace.

V základních údajích (záložka „General“) každé relace můžeme vyplnit její jméno, její název v rámci modelu. Dále se zde zobrazují informace o tabulkách, které se dané relace účastní a volí se zde i unikátní identifikátor rodičovské tabulky, který se relace účastní. Ovšem asi nejdůležitější záložkou tohoto dialogu je záložka „Cardinality“.


15

Obrázek 15 - Nastavení kardinalit a parcialit v rámci vlastností relace.

Tato záložka slouží pro zadávání kardinalit a parcialit. Jinak řečeno se zde nastavují příslušné multiplicity a to, zda se daná entita vztahu účastnit musí nebo nemusí. Záložka „Description“ slouží pro popis významu relace, může zde být vyjmenována určitá specifika dané relace apod. Záložka „To Do“ opět slouží pro zachycení budoucích plánovaných změn a úprav.

Modelovaní vazby M:N V rámci logického modelování v TDM neexistuje přímý způsob jak tuto vazbu namodelovat (ve fyzickém modelování tato volba existuje). V zásadě ale existují dvě možnosti, jak relaci M:N v logickém modelu vyjádřit. V podstatě záleží na tom, jestli daná relace obsahuje nějaké atributy nebo ne. Pokud daná relace žádné atributy neobsahuje, je možné ji z počátku modelovat jako standardní relaci 1:N s tím že v nastavení příslušné relace na záložce „Cardinality“ se nastaví, že se jedná o relaci typu více k více (vazba „Many“ – „Many“). Výsledek bude následující:


16

Obrázek 16 - Vazba M:N v logickém modelu.

Po převedení na fyzický model TDM automatický vytvoří vazební tabulku. Tento způsob reprezentace relace M:N je jednoduchý, ale neumožňuje vyjádřit relaci, která sebou nese nějaké atributy. Výsledek automatického převodu na fyzický model:

Obrázek 17 - Vazba M:N po převedení na fyzický model.

Pokud chceme ale reprezentovat relace s atributy, je nutné mezi tabulky spojené relaci M:N vložit další tabulku, která bude obsahovat dané atributy relace. Viz příklad:

Obrázek 18 - Znázornění relace typu M:N s atributy v logickém modelu.

A po převodu na fyzický model:

Obrázek 19 - Relace M:N s atributy ve fyzickém modelu.

Samozřejmě je vhodné vazební tabulku nějak vhodně pojmenovat (minimálně v rámci fyzického modelu).


17

3.2. Shrnutí logického modelování S teoretickými znalostmi z bloku o logickém modelovaní spolu se znalostmi základní tvorby logického modelu v TDM bychom nyní měli být schopní převést ER diagram vytvořený ve fázi konceptuálního modelovaní na logický model. Postupným převodem entit na tabulky a reprezentací nalezených relací bychom měli dojít přibližné k následujícímu modelu:


18

Obrázek 20 - Logické model.


19

4. Fyzické modelování Fyzické modelování přímo navazuje na fázi logického modelování. Teoretický základ fyzického modelovaní je detailně popsán v bloku e-learningu o fyzickém modelování. Tento blok popisuje fyzické modelování z praktické stránky. V rámci tvorby fyzického modelu v TDM existuje velmi silná vazba na logický model. V TDM je logický model přímý zdroj dat pro fyzický model. TDM je schopen automaticky konvertovat logický model na fyzický model konkrétní verze databázového systému.

4.1. Automatické vytvoření fyzického modelu Pokud máme vytvořen v TDM logicky model, není nic jednoduššího, než využít průvodce konverze logického modelu na model fyzický. Průvodce se spustí pravým klikem na kořenovou položku stromu objektů daného logického modelu. V kontextové nabídce pak stačí zvolit „Sync & Convert Wizard“.

Obrázek 21 - Průvodce převodem logického modelu na fyzický.

V úvodním kroku průvodce zvolíme akci „Convert Model to Another Targed Database System“, která převede daný logický model na konkrétní fyzický model vhodný pro konkrétní databázový systém. Dalším důležitým krokem průvodce je krok tři, kdy se volí cílový databázový systém. Zvolíme databázový systém Oracle, konkrétně „Oracle 11g Release 2“. Ostatní kroky můžeme ponechat bez zásahů. Na závěr bychom měli obdržet souhrnné informace o tom, kolik objektů logického modelu bylo převáděno a kolik se jich skutečně do fyzického modelu převedlo. David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/13 – Databázové modelování v praxi

20

Obrázek 22 - Souhrn po převodu logického modelu na fyzický.

Po potvrzení formuláře tlačítkem „Finish“ se zobrazí převedený fyzický model.


21

Obrázek 23 - Fyzický model.


22

Vytvořit fyzický model, pokud máme již existující logický model, je tedy velmi jednoduché. I když fyzické modelování v rámci TDM se do značné míry podobá logickému modelování, jsou zde jisté odlišnosti, které jsou dány vlastnostmi cílového databázového systému, pro který je model vytvářen. Nyní probereme některá specifika fyzického modelovaní v TDM.

4.2. Specifika fyzického modelování Pokud ve fyzickém modelu otevřeme detail tabulky, uvidíme přibližně následující dialog. Jelikož je náš model určen pro databázový systém Oracle můžou se dialogy pro jiné databázové systém mírně odlišovat.

Obrázek 24 - Detail tabulky ve fyzickém modelu.


23

Na první pohled je zřejmé, že detail tabulky obsahuje mnohem více možností, než tomu bylo v případě tabulky logického modelu. Kromě standardních záložek „General“, „Attributes“ a „Keys“, které už byly i u logického modelování, se zde objevují záložky:      



Indexes – Na této záložce se definují indexy dané tabulky. Check Constratints – Tato záložka umožňuje nad tabulkou definovat omezení typu CHECK. Triggers – Zde je možné definovat spouště aktivované specifickou DML operací nad danou tabulkou. Permissions – Umožňuje nastavit přístupová práva jednotlivých uživatelů v rámci databázového systému. SQL Preview – Náhled na SQL skript pro vygenerování tabulky. Relationship – Přehled relací z/do ostatních tabulek. Přehledně zobrazí všechny rodičovské tabulky, zároveň zobrazí i tabulky, pro které je daná tabulka rodičem. Physical Properties – Umožňuje nastavit fyzickou organizaci tabulky.

Je dobré se zmínit i o záložkách „Comment“ a „To Do“. V záložce „Comment“ můžeme specifikovat komentář k dané tabulce. V komentáři může být popsán význam dané tabulky, to jaká data tabulka uchovává a to k čemu v rámci modelovaného systému tabulka slouží. Důležité je, že tyto komentáře se v rámci generovaného skriptu připojí k dané tabulce. To znamená, že daný komentář bude uložen i v cílové databázi jako komentář dané tabulky. V podstatě se jedná o analogii komentáře, kterou znáte z klasických programovacích jazyků. Používání komentářů se vřele doporučuje, neboť díky nim bude význam tabulky ihned zřejmý a bude dostupný i ze samotného databázového systému. Záložka „To Do“ opět slouží pro plánování změn v tabulce.


24

Jistých změn doznal i dialog detailu relace:

Obrázek 25 - Detaily relace fyzického modelu.

V rámci dialogu vlastnosti relace došlo k několika změnám. Předně nastavovaní kardinalit a parcialit se přesunuli na hlavní záložku. Nyní už není například možné přes tento dialog definovat vazbu M:N. Tu je možné ve fyzickém modelu vyjádřit jen přes vazební tabulku. TDM pro tento případ přidal k identifikující a neidentifikující relaci v návrháři i relaci typu M:N, která vazební tabulku vytvoří automaticky. Další novinkou ve fyzickém modelu je možnost vytvořit nad daným cizím klíčem relace index (volba „Create Index to Foreign Key“). Dialog vlastností relace ve fyzickém modelu definuje navíc následující záložky:  

Referntial Integrty – Umožňuje nastavit pravidla pro operace UPDATE a DELETE v rodičovské a dceřiné tabulce. Foreign Keys – Zobrazuje vazby jednotlivých atributů z obou tabulek. Výhodné v případě že atribut primárního a cizího klíče nejmenují stejně.


25

 

SQL Preview – SQL skript s definicí dané relace. Index to Foreign Key – Umožňuje specifikovat detaily indexu vytvořeného nad cizím klíčem.

Jistých změn doznal i dialog vlastností atributů tabulky. Ve fyzickém modelovaní má následující podobu:

Obrázek 26 - Detaily sloupce fyzického modelu.

Oproti atributům v logickém modelu je nyní možné specifikovat konkrétní datový typ specifický pro zvolený databázový systém. Dále je možné pro daný atribut definovat využití sekvence (Used Sequence). V případě že definujme použití sekvence, dojde při generování skriptu k vytvoření triggeru, který bude automaticky obstarávat využívání sekvence nad daným atributem. Obzvláště výhodné je definovat sekvence nad umělými primárními klíči. Na této záložce je možné dále David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/13 – Databázové modelování v praxi

26

definovat výchozí hodnotu sloupce, tzn. hodnotu, která se použije, když bude tento sloupce při vkládání opomenut. Obdobně jako u tabulky, i u vlastností sloupců najdeme záložku „Comment“. Záložka umožňuje přidat k danému sloupci komentář. Komentář může osvětlovat význam sloupce v kontextu tabulky, strukturu ukládaných dat nebo význam ukládaných hodnot. Komentáře sloupců mohou být opět zahrnuty do výsledného skriptu. Takové pak komentáře budou opět dostupné přímo z databáze, například dotazem do systémového katalogu. Výhodné je to především proto, že význam sloupce je možné získat přímo z databáze a není nutné jeho význam dohledávat v projektové dokumentaci. Používání komentářů, ať už u tabulek nebo sloupců, přispívá k jednoduššímu pochopení modelu. Rozumné používání komentářů snižuje riziko nedorozumění či špatné interpretace dané tabulky či sloupce. Využívat komentáře je proto více než přínosné a určitě se vyplatí investovat určitý čas do psaní komentářů.

4.3. Vytvoření databáze Jak je vidět, základní aspekty fyzického modelovaní se velmi podobají modelovaní logickému. Základní rozdíl je v tom, že při fyzickém modelovaní nás navíc ovlivňují faktory ovlivněné volbou cílového databázového systému. Nyní tedy máme k dispozici fyzický model databáze. Nyní je na řadě fáze, kdy je nutné daný model aplikovat na databázový systém, tzn. všechny tabulky, relace, omezen, indexy apod., vytvořit v databázi. TDM tuto činnost značně zefektivňuje. Z vytvořeného modelu umožňuje vygenerovat skript, který v databázi všechny definované objekty vytvoří. Průvodce vygenerováním skriptu se spustí z menu „Model“, položka „Generate DLL Script“ nebo stiskem klávesy F9 nad modelem. Poté by se měl zobrazit následující dialog:


27

Obrázek 27 - Výběr objektů pro generování DDL skriptu.

V úvodu je nutné specifikovat, kam bude soubor s výsledným skriptem uložen. Zároveň je v úvodní záložce možné specifikovat, které objekty chceme do vygenerovaného skriptu zahrnout. Další důležité volby se nacházejí na záložce „Detail Setting“.


28

Obrázek 28 - Detailní nastavení před generováním DDL skriptu.

Na této záložce se nachází několik relativně podstatných voleb. Předně hned první volba „Use Quotation Mark“. Tato volba říká, zda mají být vygenerované objekty ve skriptu uváděný v uvozovkách. Zde je lepší tuto volbu nezaškrtávat. Např. v databázovém systému Oracle by to vedlo k tomu, že k těmto objektům by se muselo přistupovat přes přesný název objektu (ve smyslu case-senstive). To by mohlo zanést příliš mnoho komplikací do vývoje databázové aplikace. Mezi další zajímavé možnosti patří možnost vygenerovat hromadně indexy nad všemi cizími klíči, je zde možné zda se do skriptu mají vygenerovat komentáře či je zde možné nastavit oddělovač, který bude oddělovat jednotlivé příkazy ve skriptu. Pokud máme vše nastavené, můžeme přistoupit ke generování samotného skriptu. Generování bude zahájeno stisknutím tlačítka „Generate“. Po dokončení generovaní můžeme výsledný skript zobrazit stiskem tlačítka „Show Code“. David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/13 – Databázové modelování v praxi

29

Následně je možné celý skript zkopírovat, vložit do cílové databáze a spustit. Po dokončení provádění skriptu bychom měli mít v databázi vytvořeny všechny objekty definované ve fyzickém modelu.

5. Shrnutí databázového modelování. V tomto bloku byly demonstrovány základní kroky databázového modelování. Byly rozebrány jednotlivé fáze modelování. Fáze konceptuálního modelování byla probrána spíše z teoretického pohledu, resp. ukázala, jak z prvotních požadavků vzniká hrubý koncept systému. Kapitola poukázala na to, jak se identifikuji entity a relace. Následující kapitoly věnující se logickému a fyzickému modelování popisovaly modelování z praktické stránky. Obě kapitoly se věnovaly modelování v rámci programu Toad Data Modeler. Byly popsány specifika jednotlivých typů modelování spolu s ukázkovými příklady, jak dané databázové objekty vytvořit, Zároveň bylo demonstrováno převedení logického modelu na fyzický. Na konec tohoto bloku bylo ukázáno, jak se jednoduchým způsobem vytvoří z fyzického modelu skript, jenž může být použit pro vytvoření daných objektů v cílové databázi.


30

Pojmy k zapamatování Pojmy: konceptuální modelování, logické modelování, fyzické modelování, entita, relace, atribut, atribut relace, refundace, tabulka, identifikující relace, neidentifikující relace, relace M:N, primární klíč, DDL skript, komentář. Problém: vytvoření konceptuálního modelu, nalezení entit a relací, převod konceptuálního modelu na logický, použití nástroje Toad Data Modeler, automatizovaný převod logického modelu na fyzický, rozdíly mezi logickým a fyzickým modelem, využívání komentářů, tvorba DDL skriptu.

Otázky na procvičení 1. 2. 3. 4. 5.

Uveďte příklady zdrojů informací pro konceptuální modelování. Jaké jsou základní rozdíly v logickém a fyzickém modelování? V čem je specifická IE notace využívaná TDM? Jakými způsoby lze v TDM v logickém modelu reprezentovat vazbu M:N? Jaké jsou rozdíly mezi logickým a fyzickým modelem z pohledu kardinalit a parcialit v TDM? 6. K čemu jsou užitečné při modelování komentáře?

Odkazy a další studijní prameny 1. http://modeling.inside.quest.com/kbcategory.jspa?categoryID=28

Odkazy a další studijní prameny

1. CONOLLY, Thomas, Carolyn BEGG a Richard HOLOWCZAK. Mistrovství databáze: profesionální průvodce tvorbou efektivních Computer Press, 2009. ISBN 978-802-5123-287.


databází.

31

Brno:

13. blok Databázové modelování v praxi

Recommend Documents