9. blok Fáze návrhu databáze, konceptuální modelování

9. blok

Fáze návrhu databáze, konceptuální modelování

Studijní cíl Tento blok je věnován základům databázového modelování. V základu budou probrány jednotlivé fáze návrhu databáze. Dále bude student tohoto bloku seznámen s relačním modelem dat, jenž je podstatný pro pochopení databázového modelování. Dále se bude tento blok detailněji zabývat fází konceptuálního modelování.

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 z oboru databázových systémů, jako jsou relační datový model, databázový systém, tabulka, relace…. 1. Fáze návrhu databáze V této části bloku budou popsány jednotlivé části životního cyklu vývoje databázového systému. Při definování životního cyklu je důležité si uvědomit, že jeho jednotlivé fáze nemusí striktně následovat za sebou. Někdy se mohou jednotlivé fáze po sobě opakovat, jako součást kontrolního mechanismu vývoje aplikace pro databázový systém. Díky těmto opakováním se mohou identifikovat a eliminovat chyby učiněné v předcházejících fázích návrhu. Základním kamenem každého databázového projektu je stanovení si cíle spolu se stanovením jednotlivých dílčích cílů. Pod stanovením cíle se můžeme představit stanovení hlavního poslání databázového systému. Pod dílčími cíly si naopak můžeme představit jednotlivé kroky na cestě k finální podobě aplikace využívající databázový systém. S pojmem návrhu databáze úzce souvisí pojem metodologie návrhu. Metodologie návrhu je strukturovaný přístup používající procedury, techniky, nástroje a dokumentaci s cílem podpořit a usnadnit proces návrhu. Metodologie návrhu se

David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/9 – Fáze návrhu databáze, konceptuální modelování

1

tedy skládá ze stádií a stádia lze dále dělit na jednotlivé kroky. Stádia jsou vhodná pro plánování, kontrolu a zhodnocení vývojového projektu. Proces tvorby návrhu databázového systému je určen k definici všech prostředků, které budou podporovat celkové poslání, ale i dílčí cíle pro výsledný databázový systém. Proces návrhu databázového systému můžeme rozčlenit na tři základní fáze. Konceptuální, logický a fyzický návrh. Fáze konceptuálního návrhu se snaží o identifikaci podstatných objektů (entit), které budou v rámci databázového systému implementovány. Zároveň se v této fázi hledají i vazby mezi nalezenými objekty. Tato fáze návrhu by měla být absolutně nezávislá na úvahách o pozdějším fyzickém provedení systému. Ve fázi logického návrhu dochází k převodu nalezených objektů a pojmenovaných relací mezi nimi na množinu tabulek. V této části přichází na řadu popis modelu pomoci specifického modelu dat. Typicky se využívá relačního modelu dat, který je ovšem zbaven úvah o fyzické realizaci modelu. Ve fázi fyzického návrhu databáze dochází k rozhodnutím o implementaci v prostředí cílového databázového systému. V této fázi je nutná velmi dobrá znalost cílového databázového systému, ve kterém bude výsledná aplikace implementována.


2

Plánování databáze

Definice systému

Sběr a analýza požadavků

Návrh databáze Konceptuální návrh

Logický návrh

Fyzický návrh

Implemetace Obrázek 1 - Fáze návrhu databáze


3

2. Před návrhové fáze vývoje databázového systému. Výše popsané fáze návrhu (konceptuální, logický a fyzické) budou probrány v rámci bloků e-learningu velmi detailně. Tato kapitola se věnuje fázím, které probíhají ještě před samotnou fází návrhu databáze. Ačkoliv se tyto fáze neřadí přímo do databázového návrhu, jsou pro jednotlivé fáze databázového návrhu velmi důležité. Mezi tyto fáze se řadí:   

Plánování databáze. Definice systému. Sběr a analýza požadavků.

Fáze plánování databáze je počátečním bodem databázového projektu. V této fázi jsou stanoveny základní cíle a priority celého projektu. Je stanoven hlavní cíl databázového systému. Zároveň se stanovují i milníky, kterých je nutné postupně dosahovat. Jako u jiných softwarových projektů by měl být stanoven odhad rozsahu potřebné práce, rozdělení práce mezi členy vývojového týmu a v neposlední řadě se odhaduje i finanční náročnost celého projektu. Často se ve fázi plánování databáze, především u větších projektů, definují standardy vývoje. Tzn., jsou stanoveny standardy sběru dat, způsoby specifikace formátů, formát dokumentace či postup návrhu a implementace. Při definici systému dochází k identifikaci rozsahu a hranic systému, který zkoumáme, identifikuje se rozhraní vůči jiným informačním systémům. Při definici systému se nesledují pouze aktuální uživatelské pohledy, nýbrž musí být počítáno se všemi předpokládanými budoucími pohledy. Přesto jsou uživatelské pohledy velmi důležitou částí definice systému. Uživatelský pohled definuje to, co se od databázového systému požaduje z hlediska konkrétního pracovního postavení (může to být pohled vysokého manažera společnosti stejně jako pohled běžného pracovníka), či se může jednat o pohled určité provozní oblasti (marketing, lidské zdroje, CRM, …). Databázový systém má tak většinou více uživatelských pohledů. Uživatelské pohledy jsou velmi důležité, pomáhají totiž zajistit, že žádný významný uživatelský aspekt není opomenut. Jejich užitečnost navíc stoupá spolu se složitostí modelovaného systému, protože umožňují rozčlenit modelovaný systém na menší, lépe zvladatelné celky. Jiná definice hovoří o uživatelských pohledech jako o požadavcích na to, jaká data budou do databáze ukládaná a jaké transakce se s daty budou provádět. Závěrečnou přípravnou fází před zahájením samotného modelovaní je fáze sběru požadavků a jejich následná analýza. V této fázi proběhne sběr a analýza informací David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/9 – Fáze návrhu databáze, konceptuální modelování

4

o organizaci či objektu zájmu, kterému bude databáze sloužit. Sběr informací se provádí pro každý významný uživatelský pohled a jeho součástí bývá:   

popis používaných nebo vytvářených dat, podrobnosti o tom, jak jsou data vytvářena a používána, všechny další požadavky na databázový systém.

Tyto informace se následně analyzují, aby se určily požadavky, které je nutné implementovat do návrhu nového databázového systému. Tyto požadavky se dále archivují jako součást specifikace požadavků. Určení těch správných požadavků je kritická činnost, neboť systém s neúplnou implementací uživatelských požadavků může být z pohledu uživatele těžko použivatelný a může to vést až k odmítnutí systému jako celku.


5

3. Konceptuální návrh databáze Ve fázi konceptuálního návrhu databáze je vytvořen tzv. konceptuální model dat, jenž je založen na datech získaných z analýzy objektu, který se snažíme převést do cílového databázového systému. Obvyklým výstupem konceptuálního návrhu databáze je ER diagram. Ovšem v tomto případě se jedná o ER diagram vysoké úrovně obsahující úplnou reprezentaci datových požadavků objektu, který má databáze podporovat. Konceptuální fáze návrhu identifikuje podstatné entity a relace1, které bude nutné v databázi reprezentovat. Konceptuální návrh je základní zdroj informací pro fázi logického návrhu. Pro konceptuální návrh jsou podstatné tyto úkoly:       

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

Jelikož standardním výstupem této fáze bývá ER diagram, je dobré připomenout základní prvky, které by měl výsledný ER diagram obsahovat:     

entity, relace, atributy a domény atributů, primární klíče a alternativní klíče, integritní omezení.

3.1. Krok 1 – Identifikace entit Počáteční krokem při tvorbě ER modelu by měla být identifikace hlavních objektů modelovaného systému. Tyto objekty pak představují entity pro model. Standardně považujeme za entitu rozlišitelný a identifikovatelný objekt reality. Nebo též se dá entita definovat jako objekt reálného světa, který je předmětem zájmu a má smysl o něm uchovávat informace. Z pohledu modelu se entitami mohou stát osoby, hmotné i nehmotné objekty, události (rezervace, objednávka, reklamace, …) či pojmy důležité z pohledu modelovaného systému. 1

V rámci e-learningových lekcí je pojem relace chápán jako vztah mezi dvěma entitami (tabulkami) a nikoliv ve smyslu relační algebry, kdy pojem relace označuje tabulku. David Žák, Jiří Zechmeister, Tomáš Váňa 6 IDAS1/9 – Fáze návrhu databáze, konceptuální modelování

Vymezit samotný pojem entita je relativně složité. Samotný pojem entita je dosti volně definován, jelikož neexistuje jednoznačné pravidlo, které by říkalo, která data klasifikovat jako entity a která data zase jako relace. Velmi přitom závisí na osobním úhlu pohledu dané osoby, která model vytváří. Jednou z možných metod identifikace entit je zkoumání uživatelských požadavků, především pak slovníku dat. V tomto slovníku se pak můžeme zaměřit především na podstatná jména, která mohou posloužit jako kandidátní entity. Naopak slovesa ze slovníku můžou být označena jako kandidáty na relace. Při hledání entit na základě slovníku dat se postupuje tak, že se v dokumentu vyhledávají hlavní objekty zájmu (například osoby, pojmy či zájmy) a dochází k vyloučení položek, které jen označují vlastnosti jiných objektů. Jinou cestou při hledání entit je nalezení objektů se samostatnou existencí. Například položka Student může být entitou, neboť student existuje i bez toho, abychom znali jeho jméno, adresu či jiné osobní informace. Jednou z největších komplikací při zjišťování entit z datového slovníku může být to, že entity v datovém slovníku nemusí vyskytnout přímo. Můžou se tam objevit jejich příklady či jejich analogie. Například místo klíčového slova student se mohou ve slovníku dat vyskytnout konkrétní studenti či různé typy studentů (prezenční student, student kombinovaného oboru, student magisterského programu, absolvent, …). Celý problém je navíc komplikovaný tím, že uživatelé často uvádějí ve slovníku dat synonyma a homonyma. Při používaní synonym se často ve slovníku dat objevují pojmy, které mají ve své podstatě stejný význam (přeprava - transport). V případě homonyma dochází k používání slov, jejž mají význam v závislosti na použitém kontextu (program – program kina, plán práce, studijní program nebo program jako software). Při výběru těch správných entit by nám měly pomoci postupné iterace. Aplikací iterací na fázi identifikace entit pomůže odfiltrovat nalezená synonyma a zároveň pomůže ujasnit význam nejednoznačně pojmenovaných entit. Výstupem fáze identifikace entit by měl být seznam entit. Uvažujeme li například informační systém pro VŠ, mohl by tento seznam obsahovat následující položky: Student Studijní materiál Test

Vyučující Zkouška Práce

Program Předmět Hodnocení výuky

Obor Fakulta

3.2. Krok 2 – Identifikace relací Po identifikaci entit přichází na řadu fáze identifikace relací (vztahů), které mezi entitami existují. Zde nám opět mohou pomoci specifikace uživatelských


7

požadavků, ve kterých budeme předně vyhledávat slovesné výrazy. Typicky se může jednat o výrazy typu:   

Student si zapisuje Předměty. Student se přihlašuje na Zkoušku. Vyučující vyučuje Předmět.

Důležité při hledání relací mezi entitami je zaměřit se na relace, které jsou uživatelskými požadavky požadované. Mezi entitami může být totiž mnoho relací, ale jen některé mohou být skutečně požadované. Nepožadované relace, i když jsou myslitelné, se pak do výsledného modelu nemodelují. Navíc některé relace mohou být modelovány jinou relací (relacemi) a jejich zahrnutí do modelu by vedlo k tzv. redundantní (nadbytečné) relaci. Velkou pozornost je tedy nutné věnovat všem relacím (explicitním i implicitním) zaznamenaným ve specifikaci uživatelských požadavků. V principu by tedy mělo dojít ke kontrole všech dvojic nalezených entit. Důležité je uvědomit si, že entita nemusí mít žádný vztah k jiným entitám, ale může být pro námi modelovaný systém podstatná z pohledu plnění uživatelských požadavků. Proto by neměla být přijata myšlenka, že entita bez vazby na okolní entity je pro systém bezvýznamná a proto může být z modelu odstraněna. Dále je dobré uvědomit si, že ve valné většině případů budou nalezené relace binární, tedy že se budou týkat přesně dvou entit. To ovšem neznamená, že by mělo být z procesu identifikace relací vyřazeno hledání relací unárních (relace týkající se jedné entity), či relací obsahující více entit. Pro přehledné zobrazení relací, můžeme využít následující tabulku: Entita Student Student Vyučující Vyučující Program Fakulta Student

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

Entita Předmět Zkouška Předmět Zkouška Obor Program Fakulta

Tabulka 1 - Tabulka nalezených relací

Často je lepší místo velké tabulky relací uvést relace v grafické podobě. Viz zjednodušený obrázek:


8

<<Entity>> Student

<>

Zapisuje >

<<Entity>> Předmět

<>

< Učí

<<Entity>> Vyučující

<>

Přihlašuje >

Vytváří

<<Entity>> Zkouška

<>

Studuje >

<<Entity>> Fakulta

<>

<>

Nabízí >

<<Entity>> Program

<>

Má >

<<Entity>> Obor

2

Obrázek 2 - Grafická reprezentace relací

Po identifikaci všech relací, které jsou z pohledu výsledného modelu podstatné, přichází na řadu určení multiplicity každé z relací. Multiplicita vyjadřuje počet výskytů jedné entity, které se mohou vztahovat k jedinému výskytu související entity. Multiplicita se považuje za jedno z integritních omezení. Pokud budeme uvažovat o binární relaci, multiplicita může mít podobu jedna k jedné (1:1), jedna k více (1:*, 1:N) a více k více (*:*, M:N). Pokud se na místě jedničky objeví nula (0:1,0:N), znamená to, že daná entita se vztahu účastnit nemusí. Za příklad multiplicity 1:1 můžeme považovat např. takový vztah Zaměstnance a Fakulty, kdy můžeme říct, že jeden Zaměstnanec může řídit maximálně jednu fakultu a zároveň jedna fakulta může být řízena jedním zaměstnancem. Vztah 1:* (1:N) se dá reprezentovat vztahem mezi Fakultou a Programem. Jedna Fakulta může nabízet n studijních programů, avšak jeden studijní program může být nabízen nejvýše jednou fakultou. A nakonec vztah *:* (M:N) může být reprezentován vztahem mezi Studentem a Předmětem, kdy jeden Student může studovat více Předmětů a zároveň jeden Předmět může být studován více Studenty. Po určení jednotlivých multiplicit můžeme rozšířit naší původní tabulku: Entita Student Student Vyučující Vyučující Program Fakulta Student

Multiplicita 1..* 1..* 1..* 1..1 1..1 1..1 0..*

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

Multiplicita 0..* 0..* 0..* 0..* 1..* 1..* 1..1

Entita Předmět Zkouška Předmět Zkouška Obor Program Fakulta

Tabulka 2 - Tabulka nalezených relací spolu s údajem o multiplicitě

2

V tomto případě se jedná o ER digram vytvořený pomocí notace UML. Existují i jiné notace. Tyto notace jsou uvedený na závěr tohoto bloku v kapitole o ER diagramech. David Žák, Jiří Zechmeister, Tomáš Váňa 9 IDAS1/9 – Fáze návrhu databáze, konceptuální modelování

Dle údajů v tabulce můžeme aktualizovat zjednodušený model:

<<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>> 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 3 - Grafická reprezentace relací doplněná o multiplicity

3.3. Krok 3 - Identifikace atributů a spojení atributů s entitami a relacemi. Dalším krokem při tvorbě ER diagramu při konceptuálním modelovaní je identifikace faktů (vlastností), které budeme o entitách a relacích zpracovávat. Z těchto faktů se následně stanou atributy databázového modelu. Jedním ze způsobů, jak tyto atributy identifikovat, je opět prozkoumat uživatelské požadavky, především pak slovník dat. Při identifikaci entit se ve slovníku hledají zejména podstatná jména, při identifikaci relací se pozornost zaměřuje na slovesa. Při identifikaci atributů dochází k hledání jmenných frází (číslo studenta, název předmětu, jméno, titul, …). Atributy ve většině případů vyjadřují nějakou vlastnost či stav dříve identifikované entity nebo relace. Jednou z dalších cest jak nalézat atributy je u každé entity a relace si položit prostou otázku: „Jaké informace o dané entitě/relaci bude nutné uchovávat?“. Atributy můžeme rozdělit do následujících skupin:   

Jednoduché/složené atributy. Odvozené atributy. Atributy relací.

Jednoduchý atribut je takový atribut, který už je dále nedělitelný. Příkladem takového atributu může být například křestní jméno. Naopak složeným atributem se rozumí takový atribut, který je možné dále rozložit na jednoduché/složené atributy. Příkladem může být adresa, kterou lze dále dekomponovat na ulici, číslo popisné, město atd. Příklad složeného atributu:


10

Adresa Ulice

Název Popisné

Město

PSČ

Číslo Evidenční Orientační Obrázek 4 - Složený atribut

Kromě rozdělení atributů na jednoduché a složené, existuje jejich rozdělení na atributy s jedinou hodnotou a na atributy s více hodnotami. Za atribut s jedinou hodnotou můžeme považovat například atribut jméno u entity Člověk. Taková entita bude mít vždy jedno charakteristické jméno. Typickým představitelem atributu s více hodnotami je telefonní číslo. Každá osoba totiž může potenciálně mít více telefonních čísel (číslo domů, mobilní telefon, pracovní telefon, …). Pro zobrazení vícehodnotového atributu jsou prakticky dvě možnosti. Buďto atribut znázorníme spolu s danou entitou a označíme ho jako vícehodnotový, nebo se z daného atributu vytvoří samostatná entita (např. Telefonní číslo), která by se vztahovala k původní entitě přes relaci jedna k více (1:*). Atribut, který je odvoditelný (vypočitatelný) z jiných atributů, se označuje jako odvozený atribut. Ačkoliv se ve výsledném modelu tyto atributy neobjeví, je třeba je v modelu uchovávat, aby nedošlo ke ztrátě informací při modifikaci nebo odstranění atributů, ze kterých by atribut byl odvozen. Je důležité vědět, že ačkoliv entity jsou tvořeny atributy, tak ne vždy platí, že daný atribut je pevně svázán s danou entitou. V určitých případech se takový atribut může pojit k určité relaci. Takový atribut pak nazýváme atributem relace. Příkladem může být atribut datum_nastupu (vyjadřuje, kdy daný student na fakultu nastoupil), který má smysl až ve chvíli, kdy je realizována relace mezi studentem a fakultou. Velmi často se stává, že se po připojení atributů k relacím a entitám objeví entity nové, které byly v předchozích krocích opomenuty. V tomto případě je nutné vrátit se k prvnímu kroku, zaevidovat nové entity a provést revizi souvisejících relací. Může se stát, že po přiřazení atributů entitám bude více entit sdílet stejné (nebo velmi podobné) sady atributů. V tu chvíli se dá uvažovat o reprezentování těchto entit pouze entitou jedinou. David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/9 – Fáze návrhu databáze, konceptuální modelování

11

Výstupem tohoto kroku může být jednoduchá tabulka, která vyjadřuje vztah jednotlivých entit s vybranými atributy. Složené atributy se uvádí v závorce. 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

3.4. Krok 4 – Nalezení domén atributů. Výstupem tohoto kroku je určení domén jednotlivých atributů, nalezených v předchozím kroku. Doména je přípustná množina hodnot, z níž mohou čerpat své hodnoty jeden nebo i více atributů. Příkladem může být například osobní číslo studenta. Jeho doménou může být sedmi místný znakový řetězec s pevnou délkou, jehož první dva znaky jsou „ST“ a zbývající znaky tvoří čísla, tedy čísla 00000 – 99999. Dalším příkladem může byt doména atributu „studuje“ u entity Student. Zde můžeme určit doménu jako jeden znak, jenž může nabývat pouze hodnot „A“ a „N“ Základními informacemi o doméně jsou tedy:  

Přípustná množina hodnot atributu. Velikost a formát atributu.

3.5. Krok 5 - Vyhledání kandidátních, primárních a alternativních klíčů. Cílem tohoto kroku je identifikace tzv. kandidátních klíčů, a pokud jich pro danou entitu existuje více než jeden, vybrat mezi nimi primární klíč a ostatní určit jako klíče alternativní. Důležité při určování kandidátních klíčů je vynechání těch atributů, jenž mohou nabývat hodnoty null. Pokud by byl kandidátní klíč tvořen více atributy, tak ani jeden z těchto atributů nesmí nabývat hodnoty null. Pokud bude pro danou entitu zvoleno více kandidátních klíčů, musí být jeden z nich zvolen jako klíč primární. Za primární klíč by měl být zvolen kandidátní klíč, jenž:    

obsahuje minimální množství atributů, u něhož je malá pravděpodobnost změny hodnot, má velice nízkou pravděpodobnost, že v budoucnu ztratí jedinečnost, obsahuje nejmenší počet znaků (pokud se jedná o textový atribut), nebo obsahuje nejmenší maximální hodnotu (číselný atribut)


12

3.6. Krok 6 - Kontrola redundance v modelu. Redundance (nadbytečnost) se v modelu vyskytne ve chvíli, kdy nalezneme dvě entity, které ve skutečnosti vyjadřují jeden a tentýž objekt v rámci modelované problematiky. Může se stát, že v modelu systému pro VŠ vzniknou entity Vyučující a Školitel. Mezi oběma entitami bude navíc vazba 1:1. To je totiž typický případ, kdy redundance vznikají. V tomto případě je vhodné obě entity spojit do jedné. Pokud mají obě entity své primární klíče, vybere se jeden z nich a druhý se ponechá jako alternativní. Proto je při kontrole vhodné nejprve projít všechny vazby 1:1 a prověřit entity na obou stranách relace, zda náhodou nevyjadřují tutéž skutečnost. Druhý typ redundance, méně nápadný než první, který při modelování vzniká, je redundance relací. V tomto případě se v modelu vyskytne relace, která vyjadřuje informaci, kterou lze získat prostřednictvím jiné relace (relací). Na zjednodušeném modelu je vidět příklad redundantní relace: <>

< Vyučuje 0..N

<<Entity>> Student

<>

<>

Zapisuje >

< Učí

0..N


0..N

0..N

1..N

0..N

<<Entity>> Vyučující

Obrázek 5 - Redundantní relace

V uvedeném případě je vazba mezi entitami Student a Vyučující nadbytečná. Stejnou informaci lze totiž získat z vazby mezi Studentem a Vyučujícím přes entitu Předmět. Proto můžeme přímou vazbu mezi Vyučujícím a Studentem odstranit. S odstraňováním redundantních vazeb se pojí jedno upozornění. Ne vždycky platí, že pokud mezi dvěma stejnými entitami relace, že jedna z nich redundantní. Někdy může druhá relace vyjadřovat něco jiného než relace první. Zde je důležité pochopit kontext obou dvou relací. Příkladem může být následující obrázek:

<<Entity>> Fakulta 1..1 <> Zaměstnává >

0..1

<> < Vede 0..1

0..N

<<Entity>> Zaměstnanec

Obrázek 6 - Neredundantní relace


13

Na obrázku jsou dvě entity a mezi nimi dvě relace. Na první pohled by se mohlo jednat o redundantní relaci, ale při bližším pohledu na jednotlivé relace je zřejmé, že každá z relací vyjadřuje jinou informaci. Relace „Zaměstnává“ nese i informaci o tom, kteří zaměstnanci spadají pod danou fakultu, kdežto relace „Vede“ udává, který ze zaměstnanců je vedoucím dané fakulty. A proto než bude daná relace prohlášena za redundantní, musí být nejprve posouzen kontext, do kterého je daná relace zasazena. 3.7. Krok 7 - Posouzení zda model podporuje uživatelské transakce. Pokud byly provedeny předchozí kroky pečlivě a svědomitě, měl by být k dispozici ER model plně popisující modelovaný objekt. Nyní je nutné zkontrolovat, zda daný model podporuje požadované transakce (činnosti). V podstatě se jedná o manuální provedení požadovaných operací nad modelem. Pokud je nad modelem možné provést všechny požadované transakce (operace), může být model považován za kompletní. V opačném případě je pravděpodobné, že ve výsledném modelu chybí nějaká entita, relace nebo atribut. V zásadě lze pro kontrolu uživatelských transakcí použít dvě metody:  

Metoda popisu transakcí. Metoda sledovaní cest transakcí.

Při metodě popisu transakce se kontroluje, zda všechny informace (entity, relace, a jejich atributy) potřebné pro realizaci jedné konkrétní transakce jsou k dispozici. Například v modelu VŠ můžeme položit otázku: „Které předměty vyučuje daný vyučující“. Údaje o vyučujících jsou uloženy v entitě Vyučující, informace o konkrétních předmětech jsou uloženy v entitě Předmět. A k určení jednotlivých předmětů daného vyučujícího využijeme relace „Učí“. Tuto transakci je tedy možno s v rámci tohoto modelu vykonat. Při druhé metodě se požadované transakce reprezentují pomocí cest přímo v ER diagramu. Doslova jde o spojení všech zainteresovaných entit a relací a zjištění, zda je daná cesta průchodná.

4 Entitě-relační modelovaní a ER-diagramy Entitě relační (ER) modelování se snaží překlenout problémy spojené s tím, že každý člověk (ať už programátor, návrhář či běžný uživatel) má na data jiný pohled. Výsledkem ER modelovaní je model, který je jednotný, srozumitelný a neobsahuje víceznačnosti. Typickým výstup ER modelování je tzv. ER-diagram (zkráceně ERD). ER modelování je typickým příkladem návrhu databáze shora dolů. Tzn., že nejprve jsou nalezeny ty nejdůležitější entity spolu s relacemi mezi těmito entitami. Až David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/9 – Fáze návrhu databáze, konceptuální modelování

14

následně se přidávají podrobnější informace. Například méně podstatné entity či atributy jednotlivých entit a relací. Ačkoliv panuje všeobecné shoda o jednotlivých výstupech ER modelování, tak už neexistuje všeobecná shoda o tom, jak tyto jednotlivé elementy ER modelovaní graficky znázornit. Následující obrázek zobrazuje některé z používaných notací pro zápis ER diagramů.

Obrázek 7- Možné notace pro zápis ER diagramů. Zdroj: [1]


15

Ať už grafická reprezentace modelu jakákoliv, v každém modelu vždy nalezneme dvě základní komponenty. Entity a relace. Entity a relace navíc můžou mít vlastnosti, které je nutné do modelu zahrnout. Entita je základním objektem každého ER diagramu. Na entitu lze pohlížet jako na množinu objektů reálného světa, jejž se vyznačují shodnými vlastnostmi. Každý objekt nacházející se v dané množině se nazývá výskyt entity. Každá entita je nezávislá a může reprezentovat jak objekty se skutečnou existencí, tak i objekty, jejž mají jen existenci pojmovou (abstraktní). V rámci ER diagramu má každá entita jedinečný název. Často entita obsahuje i seznam vlastností, které se v rámci ER modelovaní nazývají atributy. Typicky tedy můžeme při modelovaní narazit na entity Student, Předmět, Fakulta nebo HodnoceníVýuky. S pojmem entita se pojí pojem výskyt entity. Na entitu lze pohlížet jako na množinu výskytů entit. Entitou je tedy například Student a konkrétním výskytem dané entity může být student Jan Novák. Relace je množina spojení mezi entitami. Stejně jako entita, by každá relace měla mít svůj jedinečný název, který by měl korespondovat s jejím významem. Typicky se relace reprezentuje jako spojnice zúčastněných entity. Spolu se spojnicí se uvádí i jméno dané relace. U některých notací se bavíc uvádí i směr dané relace. To má zdůraznit, že této relace má smysl jen v jednom směru. Často se u relací (ať už graficky či textově) udává i tzv. multiplicita. Multiplicita říká, kolik výskytů jedné entity se může vztahovat k jedinému výskytu související entity. Dále se u relací uvádí (opět existují grafické i textové varianty) tzv. omezení participace, které říká, zda se relace účastní všechny výskyty entity nebo jen některé. Na obrázku 7 jsou dvě entity (Person,Location) a relace Born in/Birthplace of. Všechny modely na obrázku zachycují skutečnost, že v každá osoba (entita Person) musí mít uvedeno místo narození (entita Location). Dále uvedené zápisy ER diagramů říkají, že jeden výskyt entity Location může vstoupit do vztahu s více výskyty entity Person. Navíc se výskyt entity Location vždy nemusí účastnit vztahu s entitou Person. Tzn., že v systému se mohou vyskytnout osamocené výskyty entity Location, ale entita Person vždy musí vstoupit do vztahu s entitou Location. Při tvorbě ER modelu v té či oné notaci, je nutné vždy dobře nastudovat danou notaci, protože velmi často se stává, že označení multiplicit a participací bývají mezi notacemi velmi odlišná (někdy i naprosto opačná).


16

Pojmy k zapamatování Pojmy: Metodologie návrhu, konceptuální modelování, plánování databáze, definice systému, sběr a analýza požadavků, entita, relace, atribut, složený atribut, atribut relace, odvozený atribut, doména atributu, kandidátní klíč, redundance dat, ER modelování, ER diagram. Problém: Návrh konceptuálního modelu dat, nalezení entit, relací a atributů, definice domén, nalezení kandidátních klíčů a následné stanovení primárních a alternativních klíčů, kontrola redundancí v modelu, kontrola modelu z pohledu uživatelských transakcí, využití různých notací ER diagramů při ER modelování. Shrnutí  

   

Metodologie návrhu databáze lze rozdělit na tři hlavní fáze: konceptuální, logický a fyzický návrh databáze. Výstupem konceptuálního modelování je vytvoření ER modelu datových požadavků na výsledný systém, v němž je opuštěno od jakékoliv fyzické implementace. Klíčovým prvkem konceptuální modelovaní je nalezení podstatných entit a relací. ER model popisuje entity, relace, atributy, domény atributů, kandidátní klíče apod. Výsledkem logického modelování je specifický model dat nezávislý na cílovém databázovém systému. Fyzický návrh se zabývá převodem logického modelu na model, jenž je implementovatelný v rámci cílového databázového systému.

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

Jaké jsou hlavní fáze návrhu databáze? Jaké je hlavní význam jednotlivých kroků v rámci návrhu databáze? Jakým způsobem se jednotlivé entity v modelu identifikují? Jakým způsobem jsou nalézány jednotlivé atributy? Jakými způsoby je možné zkontrolovat, zda navržený model umožňuje všechny uživatelské transakce.

Odkazy a další studijní prameny 

http://www.ibm.com/developerworks/rational/library/content/03July/250 0/2785/2785_uml.pdf (Entity Relationship Modeling with UML)


17

Odkazy a další studijní prameny 

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

Zdroje 1. Entity-relationship model. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-, 20. 12. 2011 [cit. 2012-02-08]. Dostupné z: http://cs.wikipedia.org/wiki/Entity-relationship_model


18

9. blok Fáze návrhu databáze, konceptuální modelování

Recommend Documents