UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE Datové modelování

Transkript

UNICORN COLLEGE
Katedra informačních technologií
BAKALÁŘSKÁ PRÁCE
Datové modelování
Autor BP: Anatoliy Kybkalo
Vedoucí BP: Ing. Miroslav Žďárský
2013 Praha
Čestné prohlášení
Prohlašuji, že jsem svou bakalářskou práci na téma datové modelování vypracoval samostatně,
pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších
informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury
a použitých zdrojů.
Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením,
jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení
§ 11 a následujících autorského zákona č. 121/2000 Sb.
V Praze dne 1. 5. 2013
…….……………………………
(Anatoliy Kybkalo)
Poděkování
Děkuji vedoucímu bakalářské práce Ing. Miroslavu Žďárskému za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
Data modeling
5
Abstrakt
Datové modelování je oborem, který se zabývá návrhem struktury a organizace dat.
Je to proces, při kterém převádíme reálné objekty na objekty datové, s cílem zachytit
v datovém modelu realitu, o které si chceme uchovávat informace. Návrh správné databáze
není vždy jednoduchý úkol a mnoho databázových architektů se potýká s problémy již v
počátcích projektu, kdy je potřeba identifikovat základní entity, které budou obsazeny
v databázi.
Při návrhu databáze není pouze jedno správné řešení, ale je jich hned několik. Tato
bakalářská práce se zabývá datovým modelováním a popisuje postupy a praktiky, pomocí
kterých se dá dosáhnout nejvhodnějších možností realizace databáze.
V první části bakalářské práce je popsán a vysvětlen konceptuální a E-R diagram,
který se používá v počátcích modelování. Dále je popsán UML jazyk a design patterny v
datových modelech. Následně jsou podrobně rozebrány databázové modely (síťový,
hierarchický, objektový a relační). Také jsou představeny nástroje, které mohou být
využity pro datové modelování např. Enterprice Architect, Microsoft Visio a další.
V druhé části bakalářské práce je příklad z reálného života, kde klientská firma
chce vytvořit na míru ušitý software a je potřeba navrhnout databázi, která bude sloužit
jako úložiště informací pro tento program. Pro tuto business problematiku je zpracován
návrh pro všechny zmiňované databázové modely.
Klíčová slova: konceptuální model, E-R diagram, UML jazyk, design pattern, síťový
model, objektový model, relační model, hierarchický model.
6
Abstract
Data modelling is specialization dealing with design of the structure and data organization.
It is a process, in which we transfer real object to data objects to transcribe the reality into
data model. Designing the right database is not always an easy task and most of the database architects are dealing with problems since beginning of the project, when it is needed
to identify basis entities that we will use in the database.
There is not just one correct solution to designing database, there are many. This
work covers data modelling and describes procedures and practices, which can be used to
reach the best possibilities for implementing a database.
The first part of this work describes and explains conceptual and E-R diagram that
is used in the beginnings of data modelling. Further we explain UML language and design
patterns in data modelling. Furthermore this work analyses database models (network, hierarchical, relational and object). Also we introduce tools that can be used for data modelling, for example Enterprice Architect, Microsoft Visio and more.
The second part of this work is real life example, in which client company wants
software tailored and we have to suggest database, that will be used as a data storage for
this program. We suggest design in all of the mentioned database models for this business
issue.
Keywords: Conceptual model, E-R diagram, UML language, design pattern, network model, object model, relational model, hierarchical model.
7
Obsah
1.
Úvod ..................................................................................................................................... 11
2.
Zpracování dat...................................................................................................................... 12
2.1.
Data a informace .............................................................................................................. 12
2.2.
Informace ......................................................................................................................... 12
2.3.
Data .................................................................................................................................. 12
2.4.
Data a jejich význam ........................................................................................................ 13
2.5.
Význam dat v databázích ................................................................................................. 13
2.6.
Agendové zpracování dat ................................................................................................. 13
3.
Definice databáze................................................................................................................. 14
3.1.
Aplikační úloha ................................................................................................................. 14
3.2.
Databáze a její oddělení od programu ............................................................................. 14
4.
Princip tří architektur ........................................................................................................... 15
5.
Konceptuální model ............................................................................................................. 16
5.1.
Lineární zápis .................................................................................................................... 16
5.2.
E-R diagram ...................................................................................................................... 16
6.
Logicky datový model........................................................................................................... 17
7.
Fyzický datový model ........................................................................................................... 18
8.
Modelovací prostředky ........................................................................................................ 19
8.1.
Modelovací jazyk UML ..................................................................................................... 19
8.2.
Historie UML .................................................................................................................... 19
8.3.
Význam UML .................................................................................................................... 20
8.4.
Diagramy UML.................................................................................................................. 21
8.5.
Doménový diagram .......................................................................................................... 21
8.6.
Class diagram ................................................................................................................... 22
8.6.1.
Třída ......................................................................................................................... 22
8.6.2.
Asociační vazba ........................................................................................................ 23
8.6.3.
Multiplicita ............................................................................................................... 23
9.
Databázové modely.............................................................................................................. 24
10.
Hierarchický databázový model ........................................................................................... 25
10.1.
Uzly a jejich propojení .................................................................................................. 25
10.2.
Způsoby ukládaní dat v hierarchické struktuře ............................................................ 26
10.3.
Hierarchická databáze v současnosti. .......................................................................... 27
8
11.
Síťový databázový model ..................................................................................................... 27
11.1.
Uzly a jejich propojení .................................................................................................. 27
11.2.
Síťový model v současnosti .......................................................................................... 28
12.
Relační databázový model ................................................................................................... 28
12.1.
Historie relačního databázového modelu .................................................................... 28
12.2.
Relace ........................................................................................................................... 29
12.3.
Atomická hodnota ........................................................................................................ 30
12.4.
Primární klíč.................................................................................................................. 30
12.5.
Propojování tabulek ..................................................................................................... 31
12.6.
Cizí klíč .......................................................................................................................... 31
12.7.
Vazební tabulka ............................................................................................................ 32
12.8.
Normalizace relační databáze ...................................................................................... 32
12.9.
Boyce coddova normální forma – BCNF....................................................................... 33
13.
Objektově orientované databáze......................................................................................... 34
13.1.
Objektový databázový model....................................................................................... 35
13.2.
Postup tvorby objektové databáze .............................................................................. 37
13.3.
Objektová normalizace ................................................................................................ 38
13.4.
Tří objektové normální formy – ONF ........................................................................... 38
13.4.1.
1ONF......................................................................................................................... 38
13.4.2.
2ONF......................................................................................................................... 39
13.4.3.
3ONF......................................................................................................................... 40
14.
Best practices v datovém modelování ................................................................................. 41
15.
Návrhové vzory – (design patterns) ..................................................................................... 42
15.1.
Definice návrhového vzoru .......................................................................................... 42
15.2.
Příklady návrhových vzorů ........................................................................................... 43
15.2.1.
Hierarchická struktura dat ........................................................................................... 43
15.2.2.
Dědičnost tříd ........................................................................................................... 44
15.2.3.
Předem neznáma struktura dat ............................................................................... 48
15.2.4.
Číselník ..................................................................................................................... 50
16.
CASE nástroje pro datové modelování................................................................................. 52
17.
Praktická část ....................................................................................................................... 55
18.
Business zadáni .................................................................................................................... 55
19.
Tvorba konceptuálního modelu ........................................................................................... 56
19.1.
Tvorba lineárního zápisu .............................................................................................. 58
9
19.2.
Tvorba E-R diagramu .................................................................................................... 59
Tedy E-R diagram v našem případě by mohl vypadat takto: ....................................................... 60
20.
Tvorba logického modelu relační databáze ......................................................................... 63
21.
Tvorba fyzického modelu relační databáze.......................................................................... 67
21.1.
Další možnost zakreslení .............................................................................................. 74
22.
Tvorba logického modelu objektové databáze .................................................................... 78
23.
Tvorba fyzického modelu objektové databáze .................................................................... 80
24.
Tvorba modelu hierarchické databáze................................................................................. 83
25.
Tvorba modelu sítové databáze ........................................................................................... 87
25.1.
Pravidla pro definování setu ........................................................................................ 88
26.
Závěr..................................................................................................................................... 92
27.
Conclusion ............................................................................................................................ 93
28.
Seznam použitých knižních zdrojů ....................................................................................... 94
29.
Seznam použitých internetových zdrojů .............................................................................. 95
30.
Seznam obrázků ................................................................................................................... 96
31.
Seznam tabulek .................................................................................................................... 98
32.
Seznam příloh....................................................................................................................... 99
10
Bakalářská práce
Data modeling
1. Úvod
O datovém modelování bylo napsáno nespočet světových publikací. Jedná se o problematiku, která se rozvíjí už přes dvacet let. Ve většině dosavadní literatuře je předpokládáno,
že struktura datových entit je předem známá a postačí ji jen správně namodelovat. Avšak
častým problémem je onu strukturu najít a z určité reality ji abstrahovat. Proto jedním
z cílů této práce, je začít modelovat databázi od samotného počátku, kdy je nám předloženo business zadání od zákazníka a naším úkolem je naleznout entity, vytvořit jejich strukturu a několik databázových modelů (hierarchický, síťový, relační, objektový).
V praktických projektech současnosti datové modelování dosahuje metodické
úrovně. Výjimkou mohou být projekty malého rozsahu, kde vývojáři přistupují rovnou
k tvorbě např. relační struktury, spoléhajíc na svou zkušenost. Vzniklý model nemusí být
špatný a může fungovat, ovšem jeho kvalita je závislá na kvalitě zkušeností jeho tvůrce.
Takovýto přístup při tvorbě velkých IS není možný, protože se musí řešit velké množství
datových prvků a vazeb mezi nimi. Z těchto důvodů je vhodné využít metodicky čistý přístup. Dalším cílem tedy bude představit jednu z metodik, zvanou principem tří architektur.
Datové modelování trpí často nejednoznačnou terminologií, je to způsobeno různými překlady terminů z původního anglického jazyka. Často se setkáváme s odlišnou interpretací významů některých termínů. Přímo ukázkovým příkladem je „relace“. Tento
termín označuje dvojrozměrnou datovou strukturu, ale často se zaměňuje s „relationship“,
což v překladu znamená „vztah“. Proto je cílem bakalářské práce nastolit pořádek
v terminologii týkající se datového modelování. Na začátku práce bude kapitola věnována
právě pro vysvětlení některých základních pojmů, které je nutno znát před začátkem modelování. Další důležité termíny budou vysvětleny v rámci příslušných kapitol.
Pokud chceme vytvořit funkční databázi, je nutné znát principy námi zvoleného databázového modelu. Cílem této práce bude představit a podrobně popsat čtyři v dnešní době nejznámější modely. Dále uvést nástroje, modelovací jazyky, design patterny a best
practices, které je možno využit nejen pro jejich tvorbu, ale i v průběhu celého procesu
modelování.
11
Data modeling
2. Zpracování dat
Před samotným modelováním je vhodné si uvědomit, s čím budeme pracovat.
Proto je nezbytné si odpovědět na základní otázky.

Jaký je rozdíl mezi daty a informacemi?

Jaký je význam dat?

Jak jsou data ukládána?

Jakým způsobem můžeme pracovat s daty?
2.1.
Data a informace
Data jsou základem veškerých počítačových systémů. Pro chod počítačů jsou data naprosto
klíčová a bez nich by nemohly fungovat. Daty je tvořen jak operační systém, tak i aplikace.
Dokonce i na internet můžeme nahlížet jako na soustavu organizovaných dat. Pro mnoho
lidí slova data a informace mají stejný význam. Opak je pravdou. [1]1
2.2.
Informace
Informace je výsledkem porovnávání, spojování nebo počítání s daty. Nejedná se tedy o
data jako taková. Informace dávají smysl a jako lidské bytosti jsme schopni je vyhodnotit a
pochopit podstatu jejich sdělení. Příkladem mohou být školní testy. Pokud uchováme číselné výsledky všech studentů, můžeme se dopočítat k průměru třídy nebo určit průměr
celé školy. Převádíme tedy statistické údaje (uložená data) na použitelnou informaci. [1]
2.3.
Data
Spojená data dohromady do smysluplné podoby, jsme schopni vyhodnotit a vidět v nich
informaci, kterou nesou. Pokud se budeme bavit o nespojitých datech, která jsou separována a samostatně stojící, pak se jedná o způsob zápisu informace. Pro porovnání může posloužit již zmiňovaný příklad testů. Kdybychom viděli jen číslo 25, tak je to pro nás osamocený údaj, který sám o sobě nic neříká. Ale pokud bychom spojili více údajů dohromady např., že jsou to body z testu určitého žaka, najednou jsme schopni vnímat jistou informaci, kterou tyto spojená data přinášejí. [1]
1
David PROCHÁZKA: Oracle - průvodce správou, využitím a programováním. Strana 17-23.
12
Data modeling
2.4.
Data a jejich význam
Význam dat je nedoceněn. Není vhodné vnímat data jen jako stavební prvky informací.
Data jsou nedílnou součástí každé činnosti počítače. Pokaždé, když provedeme
s počítačem nějakou akci, data se posílají skrze zařízení, pomocí jedniček a nul. Dokonce i
vývojáři mnohdy své zdrojové kódy ukládají jako datové soubory. A to jen potvrzuje všudypřítomnost dat v počítačovém světě. Pokud opustíme abstraktní svět jedniček a nul, se
kterým se běžný uživatel ve většině případů nedostane do styku, protože tyto data jsou pro
něj neviditelná, dostaneme se k databázovým systémům, kde jsou ukládána konkrétní data,
která nesouvisí s počítači jako takovými. [1]
2.5.
Význam dat v databázích
V rámci datových struktur pracujeme s konkrétními daty. Nejčastějším případem, o kterém
se jedná, jsou evidence zboží, osob, poboček, aut a různého dalšího majetku. Tyto data
jsou využívána mnoha systémy. Poskytují schopnost efektivního vyhledávání, výpočetní
funkce, sestavy a podobné operace. Databázi si můžeme představit jako jednu knihovnu,
ve které jsme schopni se orientovat a efektivně vyhledávat knihy podle různě zvolených
kritérií. [1]
2.6.
Agendové zpracování dat
Přesto, že první generace počítačů vznikla hlavně pro matematické výpočty, nedlouho na
to, se začaly používat i pro zpracování dat pro jiné účely. Od prvních počítačů až po dnešní, se úlohy evidence dat programovaly pomocí dostupných programovacích jazyků. Protože ve většině případů se nejednalo o jeden, ale o celou sadu programů, které řešily konkrétní úlohy neboli agendy, nazývají se počáteční etapy úloh tohoto typu agendové zpracování dat. Později byla vyvinuta databázová technologie pro zpracování dat a i přes výhody,
které přinášela, se objevují nové implementace agendového zpracování. Nevýhodou oproti
databázovým technologiím je plná závislost dat a programu, kde každý program se musí
starat, jak o svůj aplikační problém, tak i o formát fyzického uložení dat na média.
Dávkované zpracování agendy probíhalo tak, že se data zaznamenala na počítačové
medium, což mohl být štítek, magnetická páska nebo disketa. Po vložení do počítače, data
byla načtena do paměti a následně byla zpracována pomocí výpočtů, třídění atd. [1]
13
Data modeling
3. Definice databáze
Databáze představuje paměťové médium, kde je uložena uspořádaná množina dat. Součástí
je také software, který umožňuje přístup k těmto datům a jejich editací. Tento systém se
nazývá DBMS – Database Management System. V závislosti na kontextu, použitím slova
databáze se myslí data i software zároveň. Součásti databáze jsou prvky, které mohou být
tabulkově nebo objektově zaměřené. Data, která jsou v těchto prvcích uložena, se nazývají
záznamy. Části těchto záznamů jsou pak jednotlivé položky. [1]
3.1.
Aplikační úloha
Je to konkrétní program, který je vytvořen za použití prostředků DBMS nad konkrétní databázi. Ucelený systém těchto aplikačních úloh nad společnou databázi můžeme nazvat
databázovým informačním systémem. Jedná se o celek, který je naprogramovaný v jednom
DBMS a jeho datové struktury jsou navržené tak, aby všechny aplikační úlohy měly
k těmto strukturám optimální přístup. Řeší vyhledání, zpracování, uložení informací, a také
jejich úpravu do čitelné podoby pro uživatele. Jinými slovy databázový systém je DBMS a
báze dat dohromady. [1]
3.2.
Databáze a její oddělení od programu
Databázová technologie se liší od programování hlavně tím, že je oddělená datová struktura od programů. Díky vlastnostem DBMS se dají datové struktury definovat samostatně a
nezávisle na programových. Přínosem je, že při rozhodnutí změnit datovou strukturu není
nezbytné měnit i program a naopak při změně programu není nutno měnit i datovou strukturu, se kterou pracuje. [1]
Obrázek 1 - Oddělení datové struktury od programu.
Zdroj – vlastní zpracování.
14
Data modeling
4. Princip tří architektur
Před samotným začátkem vytváření datového modelu, je nutné vědět, jakou část reality
chceme zobrazit a jakým způsobem budeme v konečné fázi vývoje s daty pracovat. Zpravidla pro popis procesu vývoje těchto modelů se využívá princip tří architektur, též známý
pod zkratkou P3A. Právě tato metodika umožňuje rozdělit problematiku návrhu datové
základny na části, které jsou na různé úrovni abstrakce. Jak již vyplívá z názvu P3A je složena ze tří úrovní [2]:

Konceptuální úroveň – Na této úrovni je definován předmětný obsah datové
základny. Konceptuální návrh se nezabývá způsobem implementace, ale určuje, co
je obsahem databáze.

Technologická úroveň – Zde je tvořen model, který znázorňuje technologickou
koncepci řešení. Model ukazuje, jak jsou data v databázi organizována. Například
při volbě relační databáze se používá relační schéma.

Implementační úroveň – Tato úroveň se zabývá otázkou výběru konkrétní
databázové platformy, která bude sloužit pro vytvoření navrhnuté datové základny.
Zde jsou využívaná různá specifika vývojového prostředí a programovacího jazyka.
Tato úroveň definuje čím je technologické řešení realizováno.2
Důvodem takového rozdělení, je docílení pružnosti případných změn databáze. Před zpracováním každé změny je zjištěno, jaké úrovni náleží.
Konceptuální změny mohou být např. přidání další nové entity. Technologické – přechod z
relační databáze na objektovou. Implementační – změna platformy z Oracle na MS SQL.
Obrázek 2 - Sled úrovní P3A.
2
Melichar, J. (5. 4 2002). Datové modelování poprvé. Navštíveno 16. 3. 2013
http://www.dbsvet.cz/view.php?cisloclanku=2002040501
15
Data modeling
5. Konceptuální model
Návrh databáze často vychází z business zadání. V tomto dokumentu jsou zákazníkem
shrnuté požadavky na systém. Zadání ve většině případů nesděluje, co by mělo být obsahem systému, ale spíše klientská očekávaní, neboli jak by měl systém podle jejich představ
fungovat. Úkolem databázového architekta je identifikovat ze zadání základní entity. Jsou
to prvky, které jsou z databázového hlediska zajímavé, protože se o nich musejí udržovat
data. Model, který obsahuje výčet těchto entit a jejich vazeb, je znám jako konceptuální. [3]
Na začátku tvorby datového modelu je obvykle vytvořen konceptuální model jako
první a dále se postupuje podle obecně známého doporučení postupovat od shora dolů.
To znamená, že modelování probíhá od toho nejobecnějšího zobrazení po to nejdetailnější.
5.1.
Lineární zápis
Konceptuální model může být vyjádřen dvěma způsoby. Jednou z variant je tzv. lineární
zápis, který popisuje entity a vazby textem. [3]
ENTITA_1 (atribut_1, atribut_2)
ENTITA_2 (atribut_1, atribut_2)
VZTAH (ENTITA_1, ENTITA_2, vztahovy_atribut_1, vztahovy_atribut_2)
5.2.
E-R diagram
Druhou variantou je E-R diagram, pomocí kterého je možno entity a jejich vazby zakreslit
graficky. Tento způsob je preferovanější, jelikož při velkém počtu prvků, je přehlednější
než textová podoba. V tomto diagramu je použito tří hlavních grafických prvků [3]:3

Obdélník – Vyjadřuje entitu a její název se nachází uvnitř tohoto uzlu.

Kosočtverec – Uzel vyjadřující mezi entitní vztah.

Oval – Reprezentuje atribut dané entity.
3
Žďárský, M.(2. 3 2009). RDB Tvorba modelů. Navštíveno 2. 4. 2013
https://uu.unicornuniverse.eu/ues/sesm?SessFree=ues:UCL-BT:RDB.CZ/LEC03/GL
16
Data modeling
Obrázek 3 - Ukázka E-R diagramu.
Zdroj – http://www.zdrojak.cz/wp-content/uploads/2010/03/kino-film-1.png
6. Logicky datový model
Tento model je využíván v technologické úrovni P3A a představuje prostřední úroveň abstrakce a jakýsi mezikrok mezi konceptuálním a fyzickým modelem, kde je datová struktura
popisována v obecné rovině bez závislosti na konkrétním databázovém stroji. V tomto modelu též nenajdeme informace o tom, jakým způsobem budou data ukládaná. Výhodu přináší všude tam, kde není dopředu známá cílová databázová platforma, nebo vytvářená databáze bude nasazena na více serverech, od různých dodavatelů, přičemž výskyt druhé
zmiňované situace je čím dál častější, protože tvůrci aplikací jsou nuceni dodržovat firemní
technologické standardy nebo již existující prostředí zákazníka. Pokud by byl použit rovnou fyzický datový model, pro dodavatele aplikace by to znamenalo navrhnout datový
model pro každou platformu zvlášť a to přináší značnou neefektivnost.
Logický model tedy přináší určité zobecnění, pomocí kterého získáme nezávislost
modelu na konkrétním databázovém systému, tzn. že není závislý na databázové platformě,
avšak i nadále zůstává schopnost převést tento model do implementačního prostředí.
Kdybychom tvořili datovou strukturu na míru už od začátku analýzy rovnou pro databázový systém Oracle, tak při pozdějším rozhodnutí zákazníka přejít na jinou databázi
např. MySQL, museli bychom nejspíš vytvářet celý návrh znova. Proto je výhodnější vytvořit nejdříve logický datový model, který bude obecnější a na tomto základě dále navrhovat strukturu pro konkrétní databázový systém.
Příkladem takového logického modelu muže byt relační schéma. Principy relačních
a dalších databází jsou představeny v následujících kapitolách.
17
Data modeling
Obrázek 4 - Příklad logického modelu.
Zdroj – http://ondramandik.com/article/1/relation_scheme_1.png
7. Fyzický datový model
Pod fyzickým modelem si můžeme představit logický model rozšířený o specifické informace pro konkrétní databázovou platformu např. datové typy. Tento model se drží nejnižší
úrovně abstrakce a používá se v implementační fázi P3A. Značné ulehčení přinášejí CASE
nástroje, které umožňují přímo vygenerovat z modelu např. SQL skript pro vytvoření databázové struktury. [3]
Obrázek 5 - Příklad fyzického modelu.
Zdroj – http://www.sparxsystems.com/enterprise_architect_user_guide/9.0/images/erdgentrans.png
18
Data modeling
8. Modelovací prostředky
Modelovací jazyk je uměle vytvořeným jazykem, který slouží k předání informací nebo
popisu systému, za pomocí struktury, která je definována souborem pravidel.
Modelovací jazyk se dělí na dva druhy:

Textový – Vyjadřování pomocí klíčových slov, které jsou standardizované.

Vizuální – Toto grafické zobrazení používá k popisu problematiky diagramy, ve
kterých se nacházejí symboly. Ty jsou pak spojeny vazbami vyjadřující vztahy
mezi nimi.
V dnešní době je aktivně používáno kolem 20 grafických modelovacích jazyků,
např. BPMN - Business Proccess Modeling Notation, Petriho sítě a další. Pro datové modelování, je také možné využit jazyk UML, použití kterého je v České republice velice rozšířené. [4]4
8.1.
Modelovací jazyk UML
Unified Modeling Language neboli v překladu sjednocený modelovací jazyk, je
univerzálním standardem už od roku 1997 a slouží pro vizuální modelování. Velice hojně
se využívá při modelování objektově orientovaných softwarových systémů, ale díky
zabudovaným rozšiřujícím mechanismům, je vhodný také pro modelování databází.
Tento jazyk slouží pro sjednocení a spojení dosavadních modelovacích postupů
v softwarovém inženýrství. Krátce po představení začalo UML být podporováno většinou
výrobců modelovacích nástrojů. Obsahem jazyka UML nejsou v žádném případě metodiky
modelování. Neříká nám nic o tom, jak bychom měli systém navrhovat. UML jako celek
poskytuje jen standard pro popis modelu a jejich zobrazení. [4]
8.2.
Historie UML
Po tom co se OOP jazyk rozšířil, začaly se hledat způsoby jak nahlížet na informační systém různými pohledy a již roku 1988 existovalo nespočet různých standardů a specifikací,
pomocí kterých se zakreslovaly objekty nebo jiné součásti aplikace. V roce 1994 mezi nejznámější patřily OMT – Object Modeling Technique od autora J. Rumbaugha a Boochová
metoda jejímž autorem byl G. Booch. Téhož roku společně přicházejí do firmy Rational
Software (Rational Software byla koupená firmou IBM), s cílem sjednotit své metody
a vytvořit jednotný jazyk. Roku 1995 se k nim přidal Ivar Jacobson s metodologií OOSE
a o dva roky později se jim společně podařilo vytvořit standard UML. [5]5
4
Čapka, D. (14. 6 2012). 1. díl - Úvod do UML. Získáno 27. 2. 2013 http://www.devbook.cz/uml-uvod-historie-vyznam-adiagramy
5
Vojtěch MERUNKA, Antonín CARDA, Jiří POLÁK: Datové modelování. Strana 44.
19
Data modeling
Postupem času se projevil zvýšený zájem velkých korporací o existenci a údržbu
takového standardu. Důvodem je bezpochybně usnadnění dokumentace a zajištění komunikace v rámci různých projektů. V roce 1997 mezinárodní konsorcium s názvem OMG –
Object Management Group schvaluje UML jako první otevřený objektové orientovaný
modelovací jazyk a od té doby dohlíží na jeho specifikace. OMG je otevřená instituce, ve
které figurují významné a velké firmy jako IBM, Oracle, Microsoft, HP a další. Roku 2005
byl tento jazyk upraven pomocí výraznějších změn a nyní se nabízí ve verzi UML 2.0. [5]
8.3.
Význam UML
Známým faktem je, že komplexnost informačních systémů s postupem času vzrůstá. Ještě
před nedávnem jeden člověk byl schopen naprogramovat cely systém, avšak tyto doby jsou
nenávratně pryč. Protože dnešní velké systémy jsou opravdu složité, je vhodné nejprve
vytvořit jejich návrh, ne si sednout a hned začít psát kód programu. Po fázi navrhování
přichází implementace, kde jeden člověk na to nestačí, proto je potřeba pracovat v týmu
několika programátorů. Dalším problémem, se kterým se můžeme setkat v průběhu tvorby
IS, jsou změny v zadání klienta, na které jsme nucení reagovat. UML je nástroj, který pomáhá se s těmito problémy vypořádat. Můžeme ho využít v počátcích projektu pří analýze,
kdy je komunikováno se zákazníkem a zjišťováno, co vlastně budeme vytvářet nebo ve
fázi designu, kde řešíme, jakým způsobem bude systém vytvořen. [4]
Jazyk UML je možné použít třemi způsoby:

Jako náčrt – Diagramy se mohou používat v zjednodušené podobě jako náčrty,
které jsou často kreslené ručně na papír, při jednání se zákazníkem nebo při
diskutování nad určitým problémem v týmu. Je to mnohdy rychlejší způsob předání
informací mezi lidmi, než popisovat problematiku textem. Důležitou vlastností
diagramů je jejich abstrakce. Každý diagram muže znázorňovat systém vždy pod
jiným uhlem pohledu. To znamená, že jsme schopni zanedbat zbytek systému a
rozkreslit jen tu část, která je důležitá. Použitím UML diagramů se snižuje riziko
špatného navržení systému, protože nebudeme schopni něčemu dobře porozumět.

Jako plán – Tento diagram je podstatně detailnější, než náčrt. Je tvořen pomocí
CASE nástroje a využívá se jako implementační plán pro programátory systému.
Tím se zlepšuje týmová komunikace a ulehčuje průběh celé implementace, jelikož
programátoři se v systému lépe orientují. Po tom, co vývoj systému je dokončen,
mohou být tyto diagramy zahrnuty do dokumentace. A protože UML je
standardem, měl by se v systému vyznat i člověk, který se nepodílel na jeho tvorbě.

Jako programovací jazyk – Třetím a posledním způsobem jakým je možno UML
využít je programovací jazyk. Pokud vytvoříme detailní diagram, lze z něj
vygenerovat kódovou šablonu, která se stává základem pro implementaci.
Např. v databázovém prostředí je často využíváno těchto modelů pro generování
zakládacích skript.
20
Data modeling
8.4.
Diagramy UML
Na danou chvíli se UML skládá z čtrnáctí diagramů, viz obrázek. [6]6
Obrázek 6 - Rozdělení UML diagramů.
Zdroj – http://www.devbook.cz/images/5/uml/diagrams.png
Jelikož v této práci je řešena problematika modelování databází, zaměříme se hlavně na větev diagramů struktury a to konkrétně na Class diagram, pomocí kterého je možno
namodelovat jak logický, tak i fyzický datový model, zejména u relačních a objektových
databází.
8.5.
Doménový diagram
Jedná se o zjednodušenou formu class diagramu, kde základním prvkem je třída, která
představuje ukládaný element. Neobsahuje metody a má pouze důležité atributy. Zde je
možno pojmenovávat identifikátory např. názvy tříd nebo atributů s diakritikou. Diagram
je platformově nezávislý a případné atributy jsou pouze obecné, tudíž nemají žádný datový
typ. Hodí se zejména pro tvorbu logického modelu některých databází. Přiklad můžete
vidět na obr. 4 v předchozí kapitole.
6
21
Data modeling
8.6.
Class diagram
Class diagram se využívá při implementaci systému. V databázovém odvětví se používá
k tvorbě fyzických datových modelů. Tento diagram je odlišný od doménového tím, že
musí být úplný a obsahovat všechny entity, které budou uloženy v databázi. U každé třídy
jsou uvedeny veškeré její atributy a metody. Class diagram je platformově závislý, to znamená, že atributům je určen jejich datový typ pro danou databázi a také se již nevyskytuje
diakritika v názvech. [6]
8.6.1. Třída
Třídou je reprezentován soubor objektů, které mají stejné vlastnosti a chovaní, jedná se
tedy o jakousi šablonu, ve které je zachycena struktura objektu.
Obrázek 7 - Třída.
Atribut je strukturální vlastnost třídy, která nese nějakou informaci o tomto objektu,
např. jméno, příjmení atd. Grafická podoba těchto prvků je obdélníkového tvaru rozdělena
na tři vodorovné části. Nahoře je umístěn název, v prostřední části se nalézají její atributy
a v dolní jsou zapsány její metody. Stereotyp umožňuje klasifikovat třídy, díky čemuž jsme
schopni např. vytvořit tabulku, kterou použijeme ve fyzickém datovém modelu pro relační
databázi. [7]7
Obrázek 8 - Příklad třídy se stereotypem tabulky.
7
Varga, M. (16. 7. 2009). OAD Úvod do modelování IS. Získáno 24. 3. 2013
https://uu.unicornuniverse.eu/ues/sesm?SessFree=ues:UCL-BT:OAD.CZ/LEC05/GL
22
Data modeling
8.6.2. Asociační vazba
Tato vazba reprezentuje vztah mezi dvěma entitami. V diagramech je znázorněna rovnou,
případně lomenou nepřerušovanou čárou, která spojuje ikony. [8]
Obrázek 9 - Základní asociační vazba.
Ve výchozím nastavení je směr na obě strany, tudíž obě entity mají na sebe odkaz.
Toto chování může být změněno přidáním šipky, která oboustranný směr upravuje a vyjadřuje, že odkaz má jen entita, na kterou nesměřuje šipka. [8]8
Obrázek 10 - Usměrněná asociační vazba.
8.6.3. Multiplicita
Touto násobností je definován počet instancí třídy vůči vazbě, a tím pádem je omezen celý
vztah dvou entit. Nejlépe pochopitelnou ukázkou je příklad s letadlem. Letadlo obsahuje
200 míst.
Obrázek 11 - Multiplicita.
200
1
Letadlo
Sedadlo
Multiplicita se zapisuje po obou stranách vztahu a definuje číselné omezení vyjadřující počet objektů příslušné třídy. Pokud není zadaná, znamená to výchozí stav, tedy
hodnotu 1. Multiplicita může byt zapsána pomocí čísla, výčtem čísel, intervalem nebo speciálním znakem a v případě nutností je možné tyto varianty kombinovat. Při kombinovaní
8
23
Data modeling
musí být dodržená disjunkce, to znamená, že se číselné hodnoty nesmějí překrývat, viz
následující obrázek. [7]
Obrázek 12 - Příklady multiplicity.
Třida
0..1
0 nebo 1
Třida
1..N
1 až N
Třida
0..*
0 až N
Třida
1..50
1 až 50
Třida
0 až N toto
použití je
schodne s 0..*
*
Třida
1
Právě 1
Třida
Pokud není uvedena
žádná násobnost, je
výchozí multiplicitou 1
Třida
4,5..9
Omezení výčtem: 4,5 až 9
9. Databázové modely
Databázový model konkretizuje strukturu dat v informačních systémech. Při tvorbě tohoto
modelu se vychází z konceptuálního návrhu. Proces, během kterého se navrhuje tato
struktura, je nazýván modelováním dat. Výsledkem tohoto procesu je databázové schéma,
ve kterém jsou deklarovány datové typy.
Způsobů, jak uložit data a jejich vazby v databázi, je hned několik. Během vývoje,
kterým databáze prošly, byly vyvinuty tyto 4 základní databázové modely. Samozřejmě
existují i další, např. pro ukládání souborů nebo kombinace relační a objektové databáze.
Nicméně v rámci této práce budou rozebraný pouze následující modely:
24
Data modeling
Obrázek 13 - Seznam databázových modelů.
Nejstaršími jsou modely hierarchický a síťový. Podle Jaroslava Klechrela tyto
v dnešní době, již zastaralé modely, nejsou schopny vyhovět nárokům, které jsou na
databáze kladené. Proto v drtivé většině, informační systémy pro ukládání dat využívají
novější relační a objektové databáze.9 Já se na základě získaných poznatků během psaní
této práce s jeho názorem ztotožňuji.
10. Hierarchický databázový model
„Pro hierarchický databázový model nebyl ustanoven žádný standard“9. Tento model byl
nejvíce používán v tehdejších sálových počítačích, a to v jeho nejpopulárnější verzi pod
označením IMS – Information Management System. Vývojem prvních verzí se zabývaly
firmy North American Aviation a IBM na konci 60. let pro americký program pilotovaných kosmických letů, známého jako Apollo.
Data jsou uspořádaná do hierarchické struktury a jsou vyobrazená v podobě převraceného stromu. Nejvýše postavenou je prvek nazývaný kořenem, z kterého následně vycházejí větve.
10.1.
Uzly a jejich propojení
Obsahem uzlu je souhrn záznamů. Vztahy mezi uzly jsou reprezentovány termíny rodič a
jeho potomek. Kde uzel s označením rodič může být sdružen s více než jedním uzlem
označovaným jako potomek, ale na druhou stranu potomek může být sdružen pouze
s jedním rodičem. Přístup k hledaným záznamům probíhá od kořene a dále ve směru hierarchie, tedy po vybrané větvi až k listům.
9
KLECHREL, J: Inženýrské zpracování dat – databáze. 2001. Strana 2. http://audis.ic.cz/Access.pdf
25
Data modeling
Uzly je možné rozdělit do několika kategorií podle toho, kde se ve stromu nacházejí.

Kořen – Je to uzel, který nemá nad sebou žádného rodiče.

Větev – Uzel, mající nad sebou svého rodiče a pod sebou svého potomka.

List – Jedná se o uzel, který je v hierarchii stromu jako úplně poslední, tudíž má
nad sebou rodiče, ale nemá pod sebou svého potomka.
Obrázek 14 - Obecné uspořádání uzlů v hierarchickém modelu.
Díky existenci přímého propojení mezi uzly je získání dat velice rychlé.
V hierarchickém modelu je též automaticky prosazována referenční integrita, kterou je
zajištěno, že záznam v potomkovi musí nezbytně mít vazbu se záznamem v rodiči. Pokud
tedy bude smazán rodič, budou smazáni všechny jeho potomci. V hierarchické databázi
není podporována tvorba komplexních vztahů. Proto se často objevují redundantní data.
10.2.
Způsoby ukládaní dat v hierarchické struktuře
Jedním ze způsobů jak lze uložit hierarchickou strukturu je formát XML, který poskytuje
velikou výhodu v tom, že záznam je čitelný jak pro počítače, tak i pro uživatele. Data, která jsou uložena tímto způsobem, využívají pro své hierarchické rozděleni uzlů, elementy
a jejich vnořováni. Informace o elementu je možné uložit do jeho atributů.
Další elegantní, avšak při velkém počtu dat pro člověka méně přehlednou metodou
jak takovou strukturu uložit, je pomocí jednoduchého seznamu, ve kterém se udržuje informace o rodiči u každého řádku.
26
Data modeling
10.3.
Hierarchická databáze v současnosti.
Navzdory tomu, že tento druh databáze je nejstarší a pochází z konce 60. let, zhodnotil
bych jeho možnost použití v dnešní době jako stále aktuální téma. Ovšem je vhodný jen
pro vybranou problematiku reálného světa. Více o tomto modelu a hlavně jeho ukázky
naleznete v praktické časti.
11. Síťový databázový model
Síťová databáze byla z historického hlediska vyvinuta jako druhá v pořadí za hierarchickou. Vývoj byl zahájen už v šedesátých letech minulého století. Avšak první oficiální specifikace síťového modelu byla představena roku 1971 na konferenci CODASYL (Conference on Date System Languages), výborem DTG (Database Task Group).
Základem modelu se stal ukazatel, který vyjadřuje vztah mezi jednotlivými položkami v databázi. Pomocí těchto vztahů, které mohou být jak lineární, tak i cyklické, lze
v síťovém modelu poměrně snadno realizovat složitější vazby mezi uzly.
Na rozdíl od hierarchické databáze, síťová přináší výhodu v ještě rychlejším přístupu k datům. Vyhledání konkrétních nebo odvozených údajů není nijak složité, protože je
možno začít kdekoli v rámci modelu. Uživateli je umožněno se dotazovat mnohem komplexnějšími dotazy, než v modelu hierarchickém. Značným omezením při práci
s množinovými strukturami je nutnost znát strukturu této databáze. Výrazným nedostatkem, kterým síťový model trpí, jsou omezení při změnách jeho struktury, kdy v mnoho
případech není jiná možnost nežli vytvořit celý model od znova.
11.1.
Uzly a jejich propojení
Uzel představuje souhrn záznamů. Pomocí množinové struktury, kterou jsou reprezentovány vztahy v síťové databázi, je umožněno vytvořit vztah mezi dvěma uzly tak, že jeden
z nich je formulován jako vlastník a druhý uzel jako člen. Tato metoda přináší značnou
změnu oproti vztahu rodič a potomek, který je znám z hierarchického modelu. Konkrétně
v tom, že záznam v členovi může být provázán s více záznamy v uzlu typu vlastník. Vzniká tedy možnost připojit uzle nejen v různých úrovních, ale též na úrovni stejné.
Přestože se v následujících letech síťový model dále rozšiřoval, v dnešní době by se
větší komerční dostupná implementace hledala těžko. Důvodem byl velký zájem o relační
databázový model, který byl uveden na počátku 80. let.
27
Data modeling
Obrázek 15 - Obecné uspořádání uzlů v síťovém modelu.
11.2.
Síťový model v současnosti
Otázkou je, proč se ještě vůbec zabývat síťovým modelem v současnosti, když se až na pár
starších systémů nepoužívá a zda-li jeho principy nejsou zastaralé. Z mého pohledu je užitečné znát některé metody, které jsou zabudovány do standardu síťového modelu, i dnes.
Aktuální metodou i na dnešní dobu jsou: použití unikátního databázového klíče, realizace
vazeb pomocí setů, atd. Ukázky síťového modelu jsou v praktické části této práce.
12. Relační databázový model
12.1.
Historie relačního databázového modelu
Tento model je z historického hlediska nejmladší. Vznikl o trochu později než modely
hierarchický a síťový. Jako první ho představil matematik Dr. Codda, v odborném článku
firmy IBM, který vyšel v roce 1971. Teoretická definice tohoto modelu se opírala o pojem
matematické relace. Dr. Codda též uvedl matematickou definici pojmů entita, vazba
a atribut, včetně jejich typů a hodnot. Zavedl též pojmy, které se týkaly množiny atributů
a jejich funkčních závislostí. A jelikož tyto závislosti ovlivňují správnost entitních struktur,
stanovil tímto pravidla, pomocí kterých se dá rozpoznat správná struktura databáze.
Následně uvedl jazyk pro manipulaci s daty, a hlavně vyhledávání informací v relační
databázi.
28
Data modeling
12.2.
Relace
Pod pojmem relace je vhodné si představit dvourozměrnou tabulku, kde atributy jsou reprezentovány sloupci a záznamy řádky. Názvy těchto atributů (neboli názvy sloupců) musí
být unikátní v rámci celé tabulky.
Obrázek 16 - Obecný příklad relace.
V relačním modelu je tedy často uchylováno k záměně pojmů relace za tabulku.
Rozdíl mezi matematickými a databázovými relacemi je ten, že databázové jsou proměnné
v čase. Změny, které nastávají v reálném světě, jsou pak zachyceny pomocí aktualizací,
které mění hodnoty vybraných atributů nebo přímo upravují prvky relace.
Vlastnosti tabulky, které vyplývají z definice relace, jsou následující:

Na pořadí řádku nezáleží, protože relace je množinou.

Každý údaj musí být atomickou položkou.

Na pořadí sloupců nezáleží, neboť atributy také tvoří množinu.

Každý řádek v tabulce musí být jednoznačně identifikovatelný.

Musí být dodržena homogenita sloupců (hodnoty odpovídají příslušné doméně).
Konkrétnější pravidla mohou být definována integritním omezením atributů:

Check – Definuje specifická omezení hodnoty, přičemž ta jsou konkrétnější než
samotná omezení datového typu sloupce. Příkladem budiž omezení číselného
rozmezí 0-100.

Not null – Je přípustné vynechání některých položek při vkládání dat do tabulky.
Pokud se tak stane, prázdné místo je nahrazeno objektem pod názvem null, který
reprezentuje nevyplněnou hodnotu. V situaci, kdy vzniká potřeba, aby údaje
29
Data modeling
v příslušném atributu byly vyplněny, je nutno využít integritního omezení not null,
které zakazuje jejich nevyplnění.

Unique – Znamená, že hodnota určitého atributu musí být v rámci tabulky
jedinečná, tudíž se nesmí opakovat. Pokud např. máme relaci osob a sloupci jméno
nastavíme unique, můžeme jméno Anatoliy do tabulky vložit pouze jednou.
12.3.
Atomická hodnota
Je to taková hodnota, kterou nelze dále z logického pohledu dělit. Například pokud
hodnota je Anatoliy Kybkalo, tak je patrné, že tuto informaci lze determinovat na menší
logické části. Proto do tabulky se musí uložit do dvou různých sloupců. Pravděpodobně
pojmenovaných jako Jméno a Příjmení.
12.4.
Primární klíč
Jelikož je relace množinou, kde pořadí jednotlivých řádků není určeno, není také zajištěná
adresace těchto řádků, pomocí které bychom byli schopni určitý řádek nalézt. Z těchto důvodů se do relačního modelu přidává další speciální konstrukce, která umožňuje jednotlivé
řádky jednoznačně očíslovat. Tato konstrukce se nazývá primárním klíčem, kde hodnoty
musí být unikátní, aby při dotazu na konkrétní řádek nebylo vráceno řádků více.
Tabulka 1 - PK v relaci.
ID
1
2
ATRIBUT_1
Hodnota
Hodnota
ATRIBUT_2
Hodnota
…..
Primární klíč může být jak jednotlivý atribut, tak i soustava více atributů. V praxi se
vybírají hodnoty, které v rámci celé tabulky nemohou být stejná. Např. v případě evidence
osob může jako PK být vybráno rodné číslo, protože se nemůže stát, že dvě osoby budou
mít toto číslo stejné. Určování, který atribut bude sloužit jako PK, přináší několik úskalí,
se kterými se musí počítat. Např. pokud se bude jednat o mezinárodní databázi lidí, tak
čeští občané sice mohou mít rodné číslo, ale občané jiných států nemusí. V případě, kdy
nejsme schopni zajistit unikátnost PK, se do tabulky přidává atribut ID, který slouží jako
číselník a každému řádku přidělí neopakovatelné číslo v rámci celé tabulky.
30
Data modeling
12.5.
Propojování tabulek
Při návrhu relační databáze je potřeba určit i logické vazby, pomocí kterých jsou tabulky
provázané. Před samotným vytvořením této vazby je potřeba pochopit jak ten vztah
vypadá. Například pokud by se jednalo o vztah fotbalového tymu a hráčů. Můžeme
bezpečně prohlásit, že v jednom týmu hraje více hráčů, ale jeden hráč hraje pouze
v jednom týmu. Z tohoto popisu se dále stanovuje kardinalita, která je definovaná
násobností každého konce vazby.
Pro určení kardinality jsou k dispozici tyto tři základní možnosti.

1:1 – Tato kardinalita stanovuje, že jeden záznam v jedné tabulce má vazbu s právě
jedním záznamem v tabulce druhé.

1:N – Záznam v rámci jedné tabulky muže mít vazbu s více záznamy z tabulky
druhé.

M:N – V jedné tabulce se může vyskytovat vice záznamů, které mají vazbu s více
záznamy v tabulce druhé.
12.6.
Cizí klíč
Cizí klíč se používá k provázání záznamů, které se nacházejí v různých tabulkách
a mají spolu určitý vztah. Tento způsob provázání poskytuje možnost definovat akce, které
nastanou při smazání nebo změně jednotlivých záznamů v cizí tabulce. Této možnosti je
vhodné využít v případě, že je potřeba při editaci záznamu v jedné tabulce, editovat
záznam v tabulce druhé.
Nejjednodušší formou provázání záznamů v relacích s kardinalitou 1:1 nebo 1:N,
je vytvoření nového speciálního atributu ve vhodné relaci. Tento nově vytvořený sloupec
symbolizuje cizí klíč a je do něj umístěn primární klíč záznamů z tabulky jiné.
Obrázek 17 - Propojení tabulek cizím klíčem.
31
Data modeling
12.7.
Vazební tabulka
Pokud se bude jednat o kardinalitu N:M, přidáním nového atributu do jedné z tabulek,
nemůžeme docílit správného propojení záznamů. V takovém případě se používá vazební
tabulka. Skládá se ze dvou a více atributů, do kterých se umisťují primární klíče
propojených relací.
Obrázek 18 - Vazební tabulka.
12.8.
Normalizace relační databáze
Jedná se o proces, při kterém je optimalizována struktura databázové tabulky, s cílem vytvořit takovou relaci, která nebude obsahovat redundantní data a práce s nimi bude co nejefektivnější. Normální forma (NF) je pravidlo, které by měla data splňovat. Čím na vyšší
úrovni NF relace je, tím víc je optimalizována pro práci s daty v ní. Formy jsou seřazené
vzestupně a každá následující zahrnuje formu předchozí. [10]10

0NF – Aby relace splňovala tuto nultou normu, je nezbytní aby obsahem této
tabulky byl alespoň jeden sloupec, který je schopný obsahovat neatomické hodnoty.

1NF – Pokud všechny sloupce v tabulce obsahují hodnoty, které nelze dále logicky
dělit, tedy jsou to prvky atomické, relace je v první normální formě.

2NF – Tabulka je v této normě, pokud obsahuje pouze takové atributy, které jsou
závislé na celém klíči. Tím je myšleno, že veškeré hodnoty se vztahují k PK.

3NF – Jestliže je absence závislostí mezi neklíčovými sloupci, relace splňuje třetí
normální formu.

4NF – V této formě je relace tehdy, pokud obsahuje sloupce, které popisuji pouze
jednu souvislost nebo jeden fakt.

5NF – Pokud se do relace přidá nový atribut, následkem čehož by se tabulka
rozpadla na tabulky dvě, splňuje tato relace pátou formu.
10
Žďárský, M. (16. 2 2009). RDB Relační model. Získáno 26. 2 2013,
32
Data modeling
Obrázek 19 - Normální formy.
12.9.
Boyce coddova normální forma – BCNF
Byla vytvořena roku 1974 Dr. Coddem a Dr. Boycem s cílem rozšířit třetí normální formu.
Důvodem byly anomálie vyskytující se při použití složených klíčů. Podstata této formy je,
že nesmí existovat funkční závislost mezi dvěma klíči. [11]11
Aby byla tato normální forma porušena, musí nastat tyto specifické okolnosti:

V obsahu relace se nalézá více než jeden kandidátní klíč.

Minimálně dva z těchto klíčů, musí být složené z více jak jednoho atributů.

Společný atribut se musí nalézat aspoň ve dvou z těchto složených kandidátních
klíčích.
Každá relace, která splňuje BCNF, musí zákonitě splňovat i NF3, avšak ne každá
relace, která spadá do NF3, musí splňovat BCNF.
Příkladem může být tabulka rozvrhu, která má atributy Prednaska, Ucitel, Mistnost
a Hodina. Dále máme dva složené klíče (Hodina, Ucitel) a (Mistnost, Hodina).
11
Skřivánek, F. (23. 10. 2008). Datové modelování poprvé. Navštíveno 7. 3. 2013
33
Data modeling
Tabulka 2 - Rozvrh v NF3.
Prednaska
EHT
EHT
SEC
Ucitel
Jančích
Jančích
Hartman
Mistnost
1.1
0.1
DK
Hodina
14:00
17:00
12:30
Přesto že se tato relace nalézá v NF3, jméno učitele se neustále v tabulce opakuje. Proto
není v Boyce coddove normální formě.
Řešením je rozděleni rozvrhu na dvě tabulky takto:
Tabulka 3 - První tabulka v BCNF.
Prednaska
EHT
SEC
Ucitel
Jančích
Hartman
Tabulka 4 - Druha tabulka v BCNF.
Prednaska
EHT
EHT
Mistnost
1.1
0.1
Hodina
14:00
17:00
13. Objektově orientované databáze
Motivem pro vývoj OODB – Objektově Orientovaných Databázi byla neschopnost relačních databázi uložit a dále zpracovávat objekty podle specifických potřeb aplikací. RDM –
Relační Datový Model není vždy vyhovující pro aplikace, které jsou vytvořené pomocí
objektově orientovaného přístupu, protože je v nich ukládání dat příliš jednoduché. Také je
odlišnost relační struktury v databázi od struktury samotné aplikace a je vynuceno podnikat
řadu mezikroků pro zajištění spolupráce relační databáze s objektově orientovanou aplikací. Tyto mezikroky nejen, že zbytečně zesložiťují aplikaci a mohou snižovat výkon, ale
také zvyšují pravděpodobnost výskytu chyby. Tyto nedostatky byly impulsem pro vývoj
nové konstrukce databáze, která by byla schopná pracovat s objekty lépe, než RDB – Relační databáze.
Nicméně OODB není náhradou RDB, protože vhodnost použití závisí na specifické
oblasti nasazení. Využívají se zejména tam, kde relační databáze svoji jednoduchosti nepřípustně zjednodušují realitu, jelikož disponují malou modelovací schopností. Odděluji
totiž chování od objektu a podporují jen jednoduché datové typy. Proto relační platformy
jsou vhodnou volbou v případě potřeby spravovat velký objem jednoduchých dat.
34
Data modeling
Pojem „objektové databáze“ ve skutečnosti muže vyjadřovat dva zcela odlišné datové modely:

Objektově relační datový model – Jedná se o evoluci ve vývoji, kdy byla doplněna
do relačního modelu možnost práce s datovými strukturami, které jsou využívány
v oblasti objektově orientovaného programovacího jazyka. Velcí výrobci RDB
systémů jako např. Oracle zvolili právě tuto možnost rozšířeni. Principy tohoto
modelu však stále pocházejí z modelu relačního.

Objektově orientovaný datový model – Je to zcela nový datový model, který nemá
s relační databázi nic společného. Do jisté míry je možno na něj nahlížet jako na
rozšíření modelu síťového, kterému byla přidaná možnost pracovat s objekty tak,
jak je zvykem v objektovém programování.
13.1.
Objektový databázový model
Odlišnost ODM od RDM je nezanedbatelně veliká, avšak jednou z možnosti jak uložit data
v ODM je pomocí tabulek. Nicméně jejich struktura se podoba spíše síťovým databázím,
jak můžeme vidět např. v IDMS - Integrated Database Management Systém.
Při určité úrovní abstrakce můžeme uvést tento vztah takto:
„Síťový databázový model + objektové typy dat + polymorfismus = objektový databázový model.“12
ODM je možno charakterizovat následovně:
12

V některých objektových databázích je podporováno až několik desítek typu objektových kolekcí, které můžeme najít v knihovnách OO programovacího jazyka. Příkladem budíš Dictionary, List, Array a mnoho dalších.

V OODB jsou zavedeny pojmy jako kolekce a třída objektů. Zatímco třída pouze
realizuje datový typ objektu, kolekce slouží jako jeho uložiště. Proto je možné
se v praxi setkat s více množinami obsahujícími objekty stejného typu a na druhou
stranu není problém realizovat jednu kolekci, která obsahuje objekty různých tříd.
Za podmínky, že tyto objekty mají několik společných atributů, můžeme je udržovat pohromadě v kolekci a následně různě selektovat. V RDB není možno docílit
nezávislosti mezi druhem dat a jejím uložištěm, protože tabulka vystupuje v roli
kolekce i třídy zároveň.

Složení objektu se dělí na dvě části. V první jsou umístěné datové složky. To mohou být např. informace o objektu nebo jiné objekty. Druhá část obsahuje metody,
které slouží pro manipulaci právě s výše uvedenými datovými složkami. Muže
Vojtěch MERUNKA, Antonín CARDA, Jiří POLÁK: Datové modelování. 2007. Strana 114.
35
Data modeling
se jednat jak o jednoduché operace např. čtení hodnot nebo jejich zápis do datových
složek, tak i o složitější operace, při kterých jsou vypočítávány data, která v objektu
nejsou uložena.

Objekty jsou polymorfní, pokud obsahují společné atributy. Proto pro vznik polymorfismu není nutno, aby třidy mezi sebou bezpodmínečně dědily.

Tak jako v relační databázi každý záznam v rámci jedné tabulky musí mít svůj primární klíč, tak i v objektové databázi je tomu podobně. V rámci jednoho paměťového prostoru má každý objekt svou jednoznačnou identitu. Tento unikátní identifikátor je automaticky přiřazován systémem a je znám pod zkratkou OID – Objekct
IDentifier. OID plní funkci pomyslného ukazatele na objekt v paměti. Po přiřazení
ukazatele danému objektu, zůstává tento intenzifikátor po celou dobu neměnny,
i v případě, že se změní struktura objektu nebo jeho umístění v paměti, kde je uložen. Díky koncepci OID jsme schopní vnímat rozdíl pojmů totožnost objektů a
rovnost dat v nich. Pokud máme dva objekty s naprosto stejnými daty, neznamená
to, že jsou tyto objekty totožné. Často se v ODB tyto identifikátory skrývají pod
rozhráním DBMS, proto je uživatele nemusí vždy nutně vidět.

Na objektovou databázi lze nahlížet i jinač než jako na pouhé uložiště dat pro nějaký program. V ODM muže byt vytvořena taková soustava objektů, která se bude
sama o sobě chovat jako aplikace. Některé programové algoritmy mohou byt uloženy jako metody v objektech rovnou v databázi. Tím se tvorba aplikace, která bude tuto databázi využívat, velice zjednoduší, protože se v podstatě bude jednat jen
o rozhrání, pomocí kterého se budou prezentovat výsledky výpočtů provedených
v rámci ODB serveru.

V ODB je umožněno migrovat objekty mezi několika třídami, a tudíž systém může
obsahovat více než jednu verzi té samé třídy. V praxi to slouží např. k rozdělení
přístupového oprávněni, kdy různí uživatele mají na stejném objektu dostupné různé atributy.
36
Data modeling
Obrázek 20- Porovnání RDM a ODM.
13.2.
Postup tvorby objektové databáze
Při tvorbě RDB máme k dispozici datovou normalizaci, metody datového rozkládání
a metody spojování atributů. Avšak jak již bylo zmíněno ODM není žádnou nadstavbou
RDM a při jeho tvorbě nastává otázkou jakou metodu návrhu zvolit. Problém tkví v tom,
že doposud neexistuje žádná všeobecně uznávaná technika pro postup návrhu objektového
modelu, která by byla standardně používaná. Je tu samozřejmě možnost využit relačních
technik, ale výsledkem návrhu nebude nic jiného nežli „relační databáze v objektovém
prostředí“, kde nebudou využity vlastnosti ODM kvůli kterým byl tento druh modelu vyvinut. Další možnosti je převzetí navrhovaného schématu osahujícího třídy a objekty, rovnou
ze softwarové aplikace, pro kterou budeme tvořit databázi. Jenže struktura, která je použita
v aplikaci není vždy vhodná pro strukturu datovou. Důvodem je, že spousta programových
struktur jsou postaveny na dynamickém chování, kdy velké kolekce objektů jsou ukládaný
do externí paměti a to si v databázích nemůžeme tak jednoduše dovolit.
Pokročilé techniky jako např. objektová normalizace je analytiky téměř neznámý pojem. Proto jsme při tvorbě ODB odkázáni na zkušenosti expertů z praxe, kteří popisují postup návrhu objektové databáze takto:

Prvním krokem je vytvoření konceptuálního modelu, kde budou namodelovány
pouze množiny a nebudou znázorněny zbytečné detaily ohledně softwarové implementace. K tomu je vhodné použít diagram tříd v jazyce UML. V tomto kroku se
též rozpoznají atributy objektů.

V druhém kroku je potřeba najit k namodelovaným množinám potřebné třídy a následně je normalizovat.

V rámci třetího kroku je nutno provést rozhodnutí ohledně toho, které atributy budou datovými složkami a které bude potřeba napsat jako metody.
37
Data modeling

Na závěr je nezbytné otestovat správnost modelu, proto se databáze naplní testovacími daty, tak že se vytvoří konkrétní instance třid a uloží se do vybraných množin.
13.3.
Objektová normalizace
Je potřeba věnovat značnou pozornost formálním technikám, pomocí kterých se navrhují
datové struktury. I přesto, že bylo publikováno několik prací zabývajících se touto tematikou, oblast OODB je v tomto směru teprve na počátku vývoje. Od objektové normalizace
spousta analytiků očekává tyto tři základní vlastnosti [13]: 13

Musí byt splněna co největší možná srozumitelnost, přesnost a jednoduchost. Pro
naplnění těchto vlastnosti by mělo byt použito minimální množství pojmu, tak jak
tomu je např. v normalizacích relačních databází.

Zaměření normalizace by mělo byt soustředěno hlavně na návrh databází. Tím je
myšlena samotná struktura objektů pomoci, které jsou ukládaná data
v databázových systémech. Do této struktury by neměli patřit objekty, které zodpovídají za provoz aplikace.

V případě že by se OO přístup stal univerzálním i pro modelování relačních nebo
entitně-relačních modelu, bylo by vhodné, aby z objektových normalizací šlo nějakým způsobem odvodit normalizace relační.
13.4.
Tří objektové normální formy – ONF
Jedna se o postup, pomocí kterého předejdeme nevhodným úvahám o použití vazeb mezi
objekty nebo jejich skládaní a dědění.
13.4.1.
1ONF
Třída se nalézá v první objektové normální formě, pokud v obsahu objektů této třídy nejsou opakující se atributy. V případě, že se tak stane, je nezbytné vytvořit novou třídu, do
jejíhož objektu budou takové atributy přemístěný. Takto se opakování atributů nahradí
jedinou vazbou na kolekci objektu v nové třídě. Celé schéma splňuje 1ONF pokud, tuto
normu splňují všechny třídy v něm. Pro úplné pochopeni podstaty této NF poslouží následující přiklad:
13
Vojtěch MERUNKA, Antonín CARDA, Jiří POLÁK: Datové modelování. 2007. Strana 90-95.
38
Data modeling
Obrázek 21 - Nenormalizované třídy.
Na tomto obrázku je patrný nenormalizovaný tvar dvou různých objektů obsahujících skupinu opakujících se atributů. Takové řešení je naprosto nesmyslné a v případě, že
součásti objednávky bude stovka produktů, stává se i nepřehledným. Nyní si zobrazíme
přehledné, čisté a elegantní zakresleni struktury podle NF.
Obrázek 22 - Třídy v 1ONF.
13.4.2.
2ONF
Třída je v této normální formě, pokud v jejích objektech nejsou sdílené atributy. Pokud
několik objektů obsahuje totožný atribut nebo dokonce celou skupinu atributů, je potřeba
je přemístit do nového objektu nové třídy a následně sdílené atributy v původních objektech nahradit vazbou na objekt nově vzniklý. Pokud všechny třídy ve schématu splňuji
2ONF, je toto schéma v druhé objektové normální formě. Pro názornou ukázku budeme
pokračovat v příkladu, který již splňuje 1ONF.
39
Data modeling
Objednávka a dodávka je v rámci stejné zakázky, proto jejich atributy jsou sdílené
a stejná data jsou zbytečně uložena na dvou místech současně. Jedná se o konkrétní atributy jako jméno, příjmení a adresa dodavatele apod. Řešením jak předejít redundantním datum, je vytvořit novou třídu Kontakt a přemístit atributy do objektu této třidy.
Obrázek 23 - Třídy v 2ONF
13.4.3.
3ONF
Třída splňuje třetí objektově normální formu, pokud v jejích objektech nejsou atributy,
které jsou nezávislé na objektu, ve kterém se nacházejí. Za předpokladu, že takové atributy
existuji, je nutné je přemístit do objektu nově vytvořené třídy a objektům, ve kterých byly
původně, přiřadit jen vazby na tento nový objekt. Znova budeme rozšiřovat schéma
z předchozí NF.
Jak si můžeme všimnout třída Kontakt obsahuje atributy, které mají samostatný význam. Např. jméno a příjmení osoby nebo adresa. Proto, aby tato třida splňovala 3ONF je
nezbytné ji rozdělit, tak jak je zachyceno na následujícím schématu.
Obrázek 24 - Třídy v 3ONF.
40
Data modeling
Se zde uvedeným přístupem přichází spousta otázek a námětu, jakým směrem by se
měl rozvoj těchto normálních forem uchylovat. Jednou z otázek je např. jak do tohoto přístupu může být zahrnut vztah dědění nebo jiné vazby používané k propojení objektů.
V dnešní době se diskutuje právě o tom, že by se touto tématikou měla zabývat čtvrtá
ONF.
14. Best practices v datovém modelování
Není povinností tyto praktiky dodržovat, poněvadž se jedná jen o doporučení. Je na nás
jakým způsobem si budeme např. pojmenovávat tabulky v naší databázi. Avšak komunita
tvůrců se dlouhá léta snaží vytvořit určité konvence, které vycházejí z dlouhodobé zkušenosti. Pokud je budeme dodržovat nejen, že zajistíme přehledný stav databáze a tím pádem
ulehčíme orientaci lidem, kteří ji netvořili, ale potřebuji s ní pracovat, ale také se vyhneme
případným problémům v budoucnu. V rámci této práce bylo shromážděno několik nejznámějších best practices pro návrh a prací s databází. [14]14

Použijte dobře definované a konzistentní názvy jak pro tabulky, sloupce tak třeba i
pro třídy. Název by měl být jednoznačný a pochopitelný např. škola, student,
předmět atd.

Při pojmenování používejte jednotné číslo. Tabulky nebo třídy jsou souborem
subjektů, není třeba jim dávat plurálové označení. To znamená, že pokud budeme
chtít vytvořit tabulku, která bude obsahovat záznamy studentů, tak ji pojmenujeme
Student a nikoli Studenti.

Snažte se vyhnout mezerám v názvech. Pokud kupříkladu budeme mít atribut
RodneCislo, můžeme se vyhnout případným problémům při pozdějším přístupu
k tomuto atributu. V případě výskytu mezery bude potřeba při sepsání dotazu na
tento atribut zabalit jeho název do speciálních znaků.

Nepoužívejte zbytečně předpony nebo přípony v názvech (tzn. použit Student místo
TbStudent nebo StudentTabulka atd.).

Používejte vždy celočíselný atribut ID. Pokud v současné době není potřeba, může
se hodit v budoucnu např. pro vytvoření vazeb nebo indexovaní.
14
Basaraner, C. (11. 4 2012). 20 Database Design Best Practices. Získáno 10. 3. 2013,
http://architects.dzone.com/articles/20-database-design-best
41
Data modeling

Zkontrolujte integritní omezení primárního klíče, aby bylo nastaveno not null, jinak
mohou nastat problémy při propojovaní tabulek.

Zajistěte, aby byla pro všechny případy k dispozici databázová dokumentace.
Uchovejte své databázové návrhy včetně E-R schématu a případně dalších
komentářů použitých v diagramových popisech.

Pro navýšení bezpečí udržujte hesla v zašifrované podobě a dešifrujte pouze
v případě potřeby.
15. Návrhové vzory – (design patterns)
Mezi výbavou každého profesionála, který se pohybuje tam, kde se vytváří software, musí
byt znalost návrhových vzoru. Umění používat návrhové vzory pro modelování databázi
nabývá stejné důležitosti, jako znalost syntaxe programovacího jazyka, ve kterém tvoříme
aplikaci. Návrhové vzory popisují elegantní a nespočetněkrát vyzkoušena řešení jednotlivých problémů při tvorbě modelu. Tyto vzory byly vytvářený dlouhodobou praktickou
zkušenosti, kdy tvůrci byli vynuceni několikrát předělávat své modely, než řešení bylo
správné a elegantní.
15.1.
Definice návrhového vzoru
Návrhový vzor popisuje problém a jeho řešení. Struktura vzoru muže obsahovat tyto části:

Název – Jedná se o krátké nebo jednoslovní označeni vzoru. Protože návrhové
vzory slouží také pro usnadnění komunikace, není žádoucí, aby docházelo
k dlouhému a složitému vysvětlování použitého pojmu v názvu.

Popis problému – Předmětná definice toho co dany vzor řeší.

Podmínky – Soupis veškerých okolností a jevů, které musí být brány v potaz, neboť
mohou ovlivňovat použití konkrétního vzoru. Některé jevy mohou být prospěšné
použitému řešení, jiné mohou přinášet nežádoucí konflikty. Proto návrhový vzor by
měl popisovat okolnosti, při kterých je vhodné ho použít a na druhou stranu
okolnosti, které nějakým způsobem jeho použití omezují. V popisu muže být
zahrnuto i např. nastavení systému, které je nutno před použitím vzoru uskutečnit.

Řešení – Je to soubor pokynů, pravidel a vztahů pomoci, ve kterých je popsán
postup řešení problému, krok za krokem. Zde se nejčastěji využívá kombinace
psaného textu s vizuálními diagramy, obrazy nebo schématy, na kterých je
objasněn princip vzoru.
42
Data modeling

Příklady – V každém návrhovém vzoru by měl být uveden alespoň jeden příklad,
který znázorňuje praktické použití tohoto vzoru, a tím pomáhá uživateli lépe
pochopit a osvojit předávanou myšlenku.

Výsledek – Jedná se o shrnutí vyřešených problémů pomocí aplikovaného vzoru a
stav systému po jeho použití. Po aplikování vzoru se mohou objevit pobočné
efekty, které brání dosáhnout požadovaného stavu. Tyto efekty jsou ve většině
případů řešené dalšími doplňujícími návrhovými vzory.

Související vzory – Jak už bylo nakousnuto, mnohdy problém nevyřeší jeden jediný
návrhový vzor, ale je třeba jich využít hned několik. V takových případech vstupní
podmínky pro použití popisovaného vzoru jsou právě výsledky vzoru předchozího.
Než se dosáhne požadovaného cíle, mohou takto byt zřetězeny až desítky vzorů.

Reference – Souhrn situací, kde vzor byl již použit na reálných systémech. Tím se
může případně zvyšovat důvěryhodnost vzoru.
V katalozích profesionálních publikací můžeme najít desítky různých návrhových
vzorů. Nejčastěji jsou tříděny do třech kategorií. V datovém modelování se využívají hlavně strukturální vzory (Structural patterns), které popisuji jak správně vytvořit strukturu
objektů, aby byly splněny veškeré jejich požadované vlastnosti.
15.2.
Příklady návrhových vzorů
Cílem této práce není uvést veškeré návrhové vzory, které jsou v dané chvíli známé, proto
v této kapitole bude uvedeno jen pár vybraných, které řeší nejčastější problémy, se kterými
se můžeme setkat při modelování databáze. [15]15
15.2.1.
Hierarchická struktura dat
Často se stává, že je potřeba uložit stromovou strukturu ideálně v rámci jedné tabulky. Příkladem může být seznam zaměstnanců, kdy je nutné uložit informaci o tom, kdo je nadřízený a kdo podřízený.
15
Ždárský, M. (2. 3 2009). RDB Tvorba modelů. Získáno 2. 4 2013,
43
Data modeling
Obrázek 25 - Struktura zaměstnanců v podniku.
Elegantním řešením pro uložení takové struktury v relační databázi, je vytvořit atribut (sloupec) navíc v tabulce zaměstnanců, kde bude ukládán identifikátor nadřízené osoby
viz následující tabulka.
Tabulka 5 - Databázová tabulka zaměstnanců v podniku.
Jméno
Osoba_1
Osoba_2
Osoba_3
Osoba_4
Osoba_5
ID
1
2
3
4
5
ID nadřízeného
1
1
2
2
Na každém řádku je uložena informace o uzlu včetně toho, kdo je jeho hierarchický
předchůdce. Podmínkou je, že předchůdce může být pouze jeden. Z příkladové tabulky lze
jednoznačně identifikovat kořen stromu, protože hodnota jeho atributu určující nadřízenou
osobu je nevyplněna. Jinými slovy, je to ta nejvýše postavena osoba v rámci společnosti.
15.2.2.
Dědičnost tříd
Při vytváření aplikace v OOP jazyce, je často použita hierarchická struktura tříd, jejichž
instance jsme většinou nuceni ukládat v relační databázi. Tyto instance můžeme ukládat
třemi způsoby, které si ukážeme na následujícím přikladě.
44
Data modeling
Obrázek 26 - Dědičnost v OOP.
Prvním přístupem je Table per class hierarchy, kde pro uložení instancí všech tříd
slouží jedna tabulka. Takže počet sloupců v tabulce se bude rovnat počtu atributů v celé
hierarchické struktuře. Pro zvolený příklad bude tabulka vypadat následovně.
Obrázek 27 - Přístup Table per class.
45
Data modeling
Můžeme si všimnout, že všechny atributy, kromě náležících třídě Osoba, nemusejí
být vyplněny. Tudíž při vložení instance každé třídy, budou vyplněny jen sloupce, které
odpovídají atributům této třidy a do zbylých se vloží hodnota NULL. Tabulka též obsahuje
sloupec TypTridy, ve kterém je uložena informace o tom, do jaké třídy určitý řádek patří.
Tento přístup přináší výhodu v tom, že data jsou pohromadě na jednom místě a přístup k nim je velice snadný. Na druhou stranu je zde i několik nevýhod, např. v případě
velkého počtu atributů se tabulka stává méně přehlednou a navíc může být překročen maximální počet sloupců, který je u každé databáze jiný. Druhou nevýhodou je, že převážná
část sloupců v řádcích obsahuje hodnotu NULL, a tudíž je diskový prostor obsazován zbytečně. Další nevýhodou je absence možnosti nastavit některým sloupcům NOT NULL constrainty a zajistit tak integritu dat na úrovni databáze.
Druhým přístupem je Table per subclass, kde každá třída má svoji tabulku, která
obsahuje atributy pouze této třídy a ne tříd nadřazených. Řádky mezi tabulkami jsou provázaný pomoci stejného ID. Tudíž platí vztah (OsobaID = ZamestnanecID = ProdejceID).
Obrázek 28 - Přístup Table per subclass.
46
Data modeling
Výhoda takového to přístupu je v tom, že nedochází k uložení nepotřebných NULL
hodnot a pokud to je nutné, můžeme nastavovat jednotlivým sloupcům NOT NULL constrainty a tím si vynutit jejich vyplnění.
Mezi nevýhody patří komplikace při získávaní dat o konkrétní instanci, kdy je potřeba načíst data z několika tabulek. Pokud bychom chtěli získat veškeré informace o řidiči, musíme projít a spojit tabulky Ridic, Zamestnanec, Osoba, Kontakt.
Třetím a posledním přístupem je Table per Class, kde se vytváří tabulka pro každou
třídu, která je neabstraktní. V těchto tabulkách jsou uloženy, kromě vlastních atributů též
atributy nadřazených tříd.
Obrázek 29 - Přístup Table per Class.
Výhody tohoto přístupu jsou velmi podobné jako v předchozím případu. Data jednotlivé instance lze snadno a rychle získat, protože jsou uložena v jedné tabulce. Každému
sloupci můžeme nastavit NOT NULL constrainty v závislosti na tom, jestli jsou potřeba.
K nevýhodám patři neexistence centrální evidence identifikátorů, a pokud tedy
chceme hledat instanci třídy jen pomoci ID, je potřeba prohledat všechny tabulky. Při jakékoli úpravě atributů, ať názvu nebo typu, je nutné provádět úpravy v několika tabulkách
najednou. V případě, že je hierarchická struktura rozsáhla a jedná se o změnu atributů
v kořenové třídě, může takový proces být komplikovaný, protože je potřeba změnit atributy ve všech tabulkách.
Jak můžeme vidět způsobů jak vyřešit problém je hned několik, proto pro správnou
volbu je velmi důležité znát požadované vlastnosti databáze. Nejsme omezeni jen na jednu
variantu je možné popsané přístupy kombinovat např. pro první tři úrovně použít Table per
subclass a pro následující úrovně Table per Class.
47
Data modeling
15.2.3.
Předem neznáma struktura dat
Dalším častým problémem, je uložení dat, jejichž struktura při tvorbě aplikace není známá.
Příkladem může být systém spravování chyb, kde uživatel definuje typ chyby a její atributy, které se musejí uložit. Tento problém můžeme řešit pomocí metamodelu.
Metamodelem se myslí pevný datový model, který je složen ze čtyř tabulek a lze ho
využit pro ukládání dat libovolné struktury. Tyto 4 tabulky se dále dělí na dvě skupiny.
Obrázek 30 - Rozdělení metamodelu.
Data
Metadata
Record
Record type
Value
Atributte
Metadata obsahují informace popisující vlastní data, která jsou v metamodelu uložena. Do skupiny metadat patří tyto dvě tabulky:

Record type – Zde je uveden pro každý typ dat jeden řádek, který o něm obsahuje
základní informace a to minimálně ID a logický název typu.

Attribute – V této tabulce je uveden seznam veškerých atributů pro každý typ dat.
Měl by zde být uveden název atributu jeho ID a ID typu, na který se tento atribut
váže.
Druhou skupinou jsou vlastní data, obsahující též dvě tabulky.

Record – Zde je pro každý záznam uveden jeden řádek obsahující atribut, který odkazuje na typ záznamu v tabulce Record type.

Value – V této tabulce je uveden jeden řádek pro každý atribut datového záznamu a
v obsahu tohoto řádku je odkaz na typ atributu v tabulce Attribute a datový záznam
v tabulce Record.
48
Data modeling
Pro lepší představu jak metamodel funguje si pojďme ukázat příklad s dvěma velice
jednoduchými tabulkami Zákazníka a jeho Bydliště.
Obrázek 31 - Tabulky zákazníka a jeho bydliště
Nyní se pojďme podívat, jak bude vypadat struktura v metamodelu.
Obrázek 32 - Tabulky metamodelu
49
Data modeling
V record type je vložen řádek pro každou tabulku. Tedy jsou zde dva záznamy jeden pro zákazníka a druhy pro bydliště. Dále jsou v tabulce attribute uloženy řádky pro
každý atribut v tabulce zákazníka a bydliště. Vlastní data jsou pak uložena v tabulce value
a record.
Přinos metamodelu je v tom, že umožnuje do pevně definovaných tabulek ukládat
strukturovaná data libovolné struktury. Přináší však i několik nevýhod:

Velké množství uložených dat – Pro každý ukládaný atribut je v tabulce value
uložen jeden řádek.

Složité operace pro datovou manipulaci – Abychom načetli jeden záznam, je
nezbytné načíst přinejmenším jeden řádek z tabulky record a podle počtu atributů v záznamu, načíst stejný počet řádků z tabulky value. S podobnou složitosti se setkáváme i při zápisu dat.

Na ukládaná data nelze aplikovat integritní omezení.

Složitější dotazování – Každý dotaz prováděný nad metamodelem je značně
složitější než nad „klasickým“ datovým modelem. Sloupec value, který se nalézá v tabulce value, obsahuje hodnoty různých atributů, které patří různým záznamům, tato skutečnost výrazně omezuje optimalizaci databázových operaci a
tabulky Value a Record se mohou stát „úzkým hrdlem aplikace“.
Dalším v této práci nepopsaným přístupem pro ukládání předem neznámé struktury
dat je ukládání binárních dat a dynamické generování datového modelu za běhu aplikace.
15.2.4.
Číselník
Představme si situaci, kdy je potřeba u každého záznamu uchovávat jistou informaci, která
je stejná u více záznamů v rámci celé tabulky. Příkladem může být tabulka s lidmi, kde
musí být u každé osoby definováno zda-li se jedná o prodejce, manažera nebo řidiče. Jednou z možnosti je vytvořit atribut Hodnost přímo v tabulce osob.
50
Data modeling
Tabulka 6- Relace osob.
ID_osoba
1
2
3
4
5
6
Jmeno
Anatoliy
Michal
Tomáš
Josef
Alexandr
Martin
Hodnost
Manažer
Manažer
Prodejce
Prodejce
Prodejce
Řidič
Nebo můžeme využit číselník a propojit relace pomoci ID_hodnost.
Tabulka 7 - Relace osob s použitím číselníku.
ID_osoba
1
2
3
4
5
6
Jmeno
Anatoliy
Michal
Tomáš
Josef
Alexandr
Martin
ID_hodnost
1
1
2
2
2
3
Tabulka 8 - Číselník.
ID_hodnost
1
2
3
Popis
Manažer
Prodejce
Řidič
Při vzniklé potřebě editovat nějakou hodnost, není nutno projíždět každou osobu ale
postačí upravit pouze jeden záznam v tabulce hodností. Např. pokud se firma rozhodne, že
z prodejců udělá skladníky. Bude se editovat atribut Popis u hodnosti s ID_hodnost
2 (dva).
Z uvedeného příkladu můžeme vypozorovat výhodu v jednoduché editaci. Nevýhoda spočívá v potřebě vytvořit další tabulku a vazbu na tabulku předchozí. Další nevýhodou
je složitější přístup k datům, než v předchozí variantě. Nyní abychom zjistili, jakou má
osoba hodnost, musíme projít dvě tabulky místo jedny.
51
Data modeling
16. CASE nástroje pro datové modelování
Nástroje používané při vývoji softwarových aplikací se nazývají CASE – Computer Aided
Software Engineering. Těmito nastrojí je podporován jak strukturální, tak i objektově orientovaný vývoj. CASE nástroje pomáhají člověku zajistit souvislosti, které sám není schopen mentálně pojmout. Jejich použití nám nezaručuje bezchybný vývoj, protože se jedná
o nástroj, který nám může pomoct při modelování, to však neznamená, že budeme modelovat problematiku správně.
Pro návrh databáze se dá vybrat hned několik vhodných kandidátů z cele řady CASE nástrojů, které nás budou provázet od počátku vývoje až do konce. Vzniká tedy otázka,
který nástroj je lepší. Na to se nedá jednoduše odpovědět, protože v dnešní době většina
těchto programů umožnuje vytvářet stejné výstupy a tím se rozdíl mezi nimi stírá.
V začátcích modelování, kdy je potřeba identifikovat základní entity, ve většině
případů pouhé business zadání nestačí, proto je nutné komunikovat s klientem pro získání
doplňujících informací. Pro tento účel můžeme použít software Microsoft Visio16 a modelovací jazyk UUBML17 - Unicorn Unified Business Modeling Language, který vyvíjí česká
firma Unicorn a. s. a popisuje ho takto:
„Cílem jeho používání je usnadnění prezentace myšlenek a zlepšení komunikace
mezi lidmi - ať ve vztahu s okolím podniku (zákazníci, partneři atd.) nebo uvnitř pracovního týmu (a samozřejmě i mimo business). Což ve výsledku napomáhá vyhnout se rizikům
vzájemného nedorozumění.“18
Tento jazyk obsahuje velký balík grafických prvků, pomocí kterých můžeme podpořit proces identifikace databázových entit a rychlou komunikaci mezi zaměstnanci
v následovném vývoji. Jak takový model vypadá, je ukázáno v praktické časti této práce.
Modely vytvořené pomoci UUBML mohou sloužit i jako konceptuální modely na vysoké
úrovni abstrakce.
16
Odkaz na domovskou stránku výrobce: http://office.microsoft.com/en-us/visio/business-and-softwarediagrams-visio-professional-FX103472299.aspx
17
Odkaz na domovskou stránku výrobce: https://unicornuniverse.eu/cz/modelovaci-jazyk-uubml.html
18
Buchlák, P. (11. 2. 2010). CIT Konceptuální modelování. Získáno 3. 4. 2013
https://uu.unicornuniverse.eu/ues/sesm?SessFree=ues:UCL-BT:CIT.CZ/LEC09/GL
52
Data modeling
Obrázek 33 - Microsoft Visio.
Pokud vytváříme konceptuální model v podobě E-R diagramu, tak jak byl představen v předchozích kapitolách, můžeme využit nástroj SmartDraw19.
Obrázek 34 - SmartDraw.
19
Odkaz na domovskou stránku výrobce:
http://www.smartdraw.com/specials/ppc/smartdraw.htm?id=104640&gclid=COzAuMqvrrYCFREfzQodbWE
ABA
53
Data modeling
Pro modelování logického a fyzického modelu může posloužit Enterprice Architect nebo PowerDesigner21 a jazyk UML.
20
Obrázek 35 - Enerprice Architect.
Jak si můžete všimnout z náhledů, všechny tyto CASE nástroje jsou si podobné a
práce v nich je často velmi intuitivní. Přestože existuje daleko více těchto nástrojů, v této
kapitole jsou ukázány pouze ty, které jsou využity v praktické časti této bakalářské práce.
20
Odkaz na domovskou stránku výrobce: http://www.sparxsystems.com/
Odkaz na domovskou stránku výrobce:
http://www.sybase.com/products/modelingdevelopment/powerdesigner
21
54
Data modeling
17. Praktická část
Po té, co v teoretické části byly zmíněny veškeré podstatné věci pro to, abychom mohli
vytvořit funkční databázi, přichází praktická část, kde si to předvedeme v praxi. Pro tento
účel bylo vymyšleno zadání, ve kterém fiktivní firma požaduje na míru vytvořený informační systém. Z hlediska toho, že tato bakalářská práce je věnována datovému modelování, to pro nás není tak zajímavá informace. Pokud se ale zamyslíme pečlivěji, zjistíme, že
pro tento IS bude potřeba vytvořit databázi.
Samozřejmě, že projekt nezačíná hned tvorbou konkrétních datových struktur,
jakmile přijdeme z první schůzky s klientem, ale důkladnou analýzou prostředí firmy, požadavkem FURPS+, identifikací procesu probíhajících ve firmě atd. Jelikož zpracování
celého projektu od počátku do konce by bylo nad rámec této práce, omezíme se pouze na
návrhu databáze podle business zadání a upřesňujících informaci od analytiků.
Pro demonstraci nejefektivnějšího řešení tohoto konkrétního případu, budou vytvořeny čtyři datové modely a to pro databázi relační, objektovou, hierarchickou a síťovou.
Následně budou porovnány výhody a nevýhody těchto modelu pro tento specificky příklad.
18. Business zadáni
Firma Unifest, s.r.o. je novým členem na trhu poskytovatelů plastových oken. Protože tento trh je bohatý na konkurenci, firma se rozhodla vložit svou první investici do informačního systému, který by firmě zajišťoval lepší schopnost řídit podnik, a firma by mohla získat
konkurenci schopnost na trhu. Byla provedena základní analýza, kde byly zjištěny základní
požadavky firmy na systém. Firma Unifest má několik poboček po celé ČR a jejich síť
se nadále rozrůstá. Organizace potřebuje systém, který by evidoval a umožňoval práci s
informacemi o pobočkách, služebních autech, zaměstnancích, zákaznících, smlouvách,
dodavatelích, službách a nabízeném zboží. Unifest se potýká s problémem v komunikaci
mezi pracovníky, která probíhá pouze prostřednictvím osobních emailu a telefonu. Toto je
velice efektivní řešení, protože jak víme, telefonická domluva je nejrychlejší, avšak
v případech nutnosti naprosto nedohledatelná. Proto bude nutné zajistit komunikaci pomoci systémových zpráv.
55
Data modeling
19. Tvorba konceptuálního modelu
Již z takového krátkého zadání jsme schopni určit většinu základních entit, o kterých bude
potřeba uchovávat nějaká pro firmu zajímavá data. V prvním kroku může být vytvořen
model na velmi vysoké úrovni abstrakce, pomocí kterého můžeme dolaďovat s klientem
jeho požadavky na data, která budou v databázi uložena.
Obrázek 36 - Konceptuální model na vysoké úrovní abstrakce.
Tento model byl představen vedení firmy za účelem projednání konkrétnějších informací. Všimnete si, příjemného vzhledu jednotlivých ikon, které mohou být pro běžného
člověka, který se nevyzná v datovém modelování o hodně pochopitelnější nežli E-R diagram, tak jak ho známe. Tento způsob zachycení entit může o hodně zlepšit orientaci zákazníka v celé struktuře.
Na základě předchozího modelu byly zjištěny dodatečné poznatky, které mohou
ovlivnit strukturu dat v databázi. Byly tedy doplněny podrobnosti o některých entitách.
56
Data modeling
Zaměstnanci společnosti jsou rozděleny do hierarchické struktury. Nejvýše postaveným je majitel firmy, který je zároveň ředitelem. Dále ve vedení firmy jsou dva manažeři, kteří zodpovídají za chod firmy a účetní řešící finanční problematiku. V rámci pobočky
je jeden vedoucí a několik běžných pracovníků. Následující obrázek zachycuje firemní
hierarchickou strukturu zaměstnanců.
Obrázek 37 - Firemní hierarchie.
Dalším upřesněním je, že firma sice potřebuje vést evidenci automobilů, ale do tohoto pojmu zahrnovaly i jakýsi záznam jízd, kde bude jasně napsáno kdo, kdy a kolik
s autem najel kilometrů. Tímto je zjištěna nová entita, kterou bude potřeba v databázi zachytit.
Obrázek 38 - Záznam jízdy.
57
Data modeling
19.1.
Tvorba lineárního zápisu
Dále bylo s vedením klientské firmy projednáno, jaká data budou chtít o jednotlivých entitách ukládat. Tyto požadavky můžeme zachytit na lineárním zápisu konceptuálního modelu podobajícího se seznamu, který bychom jinak stejně museli nějakým způsobem sepsat.
POBOČKA (název, adresa, datum založeni)
PRODUKT (název, výrobce, cena, popis, počet skladovaných kusů)
SLUŽBA (název, cena, popis)
ZAMĚSTNANEC (jméno, příjmení, rodné číslo, bydliště, plat, osobní telefon, pracovní
telefon, email, hodnost, číslo bankovního účtu, pobočka)
ZÁKAZNÍK (jméno, příjmení, rodné číslo, telefon, email, bydliště, bankovní spojení, číslo
účtu, název společnosti, sídlo, IČ, DIČ, název společnosti)
AUTOMOBIL (výrobce, značka, datum výroby, datum pořízení, počet najetých kilometrů,
datum vypršení platnosti STK, popis, pobočka, SPZ)
ZÁZNAM JÍZDY (zaměstnanec, automobil, datum převzetí, datum odevzdaní, počet najetých kilometrů, popis provedeného poškození)
ZÁZNAM KOMUNIKACE (odesílatel, příjemce, datum, název, obsah zprávy)
DODAVATEL (název společnosti, sídlo, jméno jednajícího, příjmení jednajícího, IČ, DIČ,
bankovní spojení, číslo účtu, telefon, email)
SMLOUVA (představitel jedné strany, představitel druhé strany, účel smlouvy, předmět
smlouvy, kupní cena a platební podmínky, doba plnění, místo plnění, způsob plnění,
sankční ujednání, odpovědnost za vady zboží a záruka, trvaní smlouvy, vyčet produktu,
vyčet služeb, datum uzavření, počet kusu)22
Po výčtu těchto entit též můžeme zaznamenat jejich vztahy, avšak tento postup
bych osobně volil v případě grafického zobrazení, protože při velkém počtu vazeb nezkušeny člověk se může lehce zamotat. Pro ukázku zápis některých vztahu by vypadal takto:
PRACUJE (ZÁKAZNÍK, POBOČKA)
UŽÍVÁ (ZÁKAZNÍK, AUTOMOBIL)
DODÁVÁ (DODAVATEL, PRODUKT)
22
Smlouva může být jak s dodavatelem tak i se zákazníkem, podle toho se též odvíjí její položky,
např. smlouva s dodavatelem nebude nikdy obsahovat výčet služeb atd.
58
Data modeling
19.2.
Tvorba E-R diagramu
Stejně jako v případě lineárního zápisu, kdy při velkém počtu vazeb se stává nepřehledným, i E-R diagram muže trpět stejným problémem, tentokrát však ne kvůli vazbám, ale
velkému počtu atributů. Jako příklad si ukažme, jak by vypadal diagram, který obsahuje
všechny atributy.
Obrázek 39 - Příklad E-R diagramu se všemi atributy.
Jak je patrné, zatím jsou zobrazeny pouze dvě entity, ale grafických prvků je tam daleko
více. Nyní si představme, že by se diagram skládal z desítek nebo stovek entit, a každá
z nich by měla desítky atributů. Samozřejmě, že není problém takový diagram vytvořit, ale
musíme brát na vědomí, že čím víc je model komplexnější, tím víc je složitější se v něm
vyznat.
Z uvedených důvodů bych volil postup, při kterém se zaznamenají veškeré atributy
pomocí lineárního zápisu a následně se vytvoří E-R diagram, kde budou zachyceny hlavně
vazby mezi entitami a pouze některé jejich atributy.
59
Data modeling
Tedy E-R diagram23 v našem případě by mohl vypadat takto:
Obrázek 40 - E-R diagram firmy Unifest.
Model může doprovázet popis entit, ale pro databázové účely nás spíš zajímá, co
se o každý entitě bude ukládat a jak budou provázaný, než její chování, které je důležité
spíše pro tvorbu informačního systému. Navíc diagram se tvoří proto, aby bylo všechno
přehledné a na první pohled jasné, tudíž aby nebyl důvod popisovat problematiku dlouhým
textem. Pro ještě větší zjednodušení je možné celý E-R diagram rozdělit do jednotlivých
částí, které budou obsahovat pouze některé entity.
23
Diagram v plné velikosti je v příloze pod názvem „E-R_DIAGRAM“.
60
Data modeling
Obrázek 41 - E-R detail pobočky, zaměstnance, automobilu a záznamů.
Na pobočce pracuje zaměstnanec, který může posílat zprávy ostatním zaměstnancům v rámci systému. Na pobočce může též být automobil, který zaměstnanci mohou využívat pro pracovní účely. Musejí však zaznamenávat svou jízdu v jistém záznamů kde vyplňují, o jaký automobil se jednalo, počet najetých km a tak dále.
Obrázek 42 - E-R detail dodavatelské smlouvy.
61
Data modeling
Zaměstnanec uzavírá s dodavatelem smlouvu za účelem koupě produktu, který firma Unifest bude následně nabízet zákazníkům. V systému je pak vytvořena karta s dodavatelskými údaji.
Obrázek 43 - E-R detail zákaznické smlouvy.
Zákazník se zaměstnancem firmy Unifest uzavírá smlouvu s cílem koupit produkt,
službu nebo kombinaci obojího. Pokud tak učiní je v systému vytvořena jeho karta
s osobními údaji.
Pokud máme vytvořeny E-R diagram a jsme si jisti, že nebyla vynechána žádná entita, můžeme přistoupit k tvorbě Logického modelu.
62
Data modeling
20. Tvorba logického modelu relační databáze
Výchozím bodem pro tvorbu logického modelu bude model konceptuální, a to jak
v podobě lineárního zápisu, tak i v podobě E-R diagramu. Jelikož logický model zachycuje
hlavně databázovou strukturu, je nutné se rozhodnout, kterou databázi budeme modelovat.
Protože v dnešní době je převážně v IS používaná relační databáze, namodelujeme si ji
jako první. Jeden z příkladů jak může vypadat logický model24 pro zvolený příklad:
Obrázek 44 - Logicky model.
Jak je patrné, tabulky jsou provázané pomocí ID klíčů a tudíž je možné je spojovat.
Např. pokud bychom objevili vadný výrobek na skladě a chtěli zjistit, jaká firma nám ho
dodala, případně jim zavolat, podíváme se do smlouvy, která obsahuje tento produkt a následně zjistíme dodavatele a jeho kontakt. Procházíme tedy tabulky (Produkt, ProduktDodavatelskaSmlouva, DodavatelskaSmlouva, Dodavatel, Kontakt). Dále si můžete všimnout,
24
Model v plné velikosti je v příloze pod názvem „LOGICKY_MODEL_RELACNI_DATABAZE“.
63
Data modeling
že byl použit pattern, který byl popsán v teoretické části, na tabulku zaměstnance pro udržení informace o tom, kdo je jeho nadřízený a pattern číselníku na tabulku hodnosti. Model
též obsahuje několik vazebních tabulek, které zajištují spojení N:M. Vazby mezi entitami
čteme takto: jeden zaměstnanec může uzavřít žádnou až nekonečno smluv, ale v každé
smlouvě je uveden pouze jeden zaměstnanec.
Pojďme si pro lepší přehlednost celkový model rozdělit do několika částí.
Obrázek 45 - Detail zákazníka.
Údaje o zákazníkovi jsou rozděleny do několika tabulek a samotný záznam zákazníka v tabulce Zakaznik se skládá pouze z cizích klíčů, které odkazuji na všechny ostatní
záznamy. Obdobným způsobem je řešen i dodavatel.
Obrázek 46 - Detail dodavatele.
64
Data modeling
Obsahem každé smlouvy může být více produktů a zároveň jeden produkt může být
obsažen ve více smlouvách, proto je potřeba vazby mezi smlouvami řešit pomocí vazebních tabulek a stejně tak postupovat i v případě služeb.
Obrázek 47 - Detail smluv, produktu a služeb.
65
Data modeling
Údaje o zaměstnanci se ukládají stejně jako u dodavatele či zákazníka, rozdíl je
v tom, že zaměstnanec může být obsažen jak v dodavatelské smlouvě tak i v zákaznické,
navíc je mu přidělena hodnost, plat a jeho záznam udržuje informaci o tom, kdo je jeho
nadřízený, což je zajištěno vazbou na vlastní tabulku.
Obrázek 48 - Detail zaměstnance.
Obrázek 49 - Detail pobočky, automobilu a záznamů.
66
Data modeling
21. Tvorba fyzického modelu relační databáze
Na základě logického modelu je navrhnut fyzický model, který obsahuje veškeré potřebné
náležitosti pro vytvoření databáze. To znamená, že je definován typ atributů, jsou zvoleny
primární a cizí klíče, je určeno jaké atributy budou v rámci tabulky unikátní, případně které
nemohou zůstat s hodnotou NULL a na závěr jsou vytvořené tabulkové vazby. Jelikož
v tomto příkladu nehraje roli, pro jakou platformu bude model vytvořen, zvolil jsem si
SQL Server 2008. Z náhledu můžeme vidět, že fyzický model25 je na nejnižší možné úrovni abstrakce a oproti logickému modelu značně komplexnější.
Obrázek 50 - Fyzický model relační databáze.
25
Model v plné velikosti je v příloze pod názvem „FYZICKY_MODEL_RELACNI_DATABAZE“.
67
Data modeling
Pomocí CASE nástroje Enterprice Architect, ve kterém byl model tvořen, můžeme
převést grafickou podobu databáze na zakládací skript. Přínosem je velké usnadnění a časová úspora, protože nemusíme vytvářet databázi manuálně v jazyce SQL. Zde je vhodné
též model rozdělit na menší kusy, aby se zlepšil přehled entitních vazeb.
Obrázek 51 - Detail zákazníka.
68
Data modeling
Obrázek 52 - Detail dodavatele.
69
Data modeling
Obrázek 53 - Detail smluv, produktu a služeb.
70
Data modeling
Obrázek 54 - Detail zaměstnance.
71
Data modeling
Obrázek 55 - Detail pobočky, automobilu a záznamů.
72
Data modeling
Automaticky vygenerovaný skript na založení tabulky automobilů z tohoto fyzického modelu relační databáze vypadá takto:
CREATE TABLE Automobil (
ID_automobil int NOT NULL,
ID_pobocka int NOT NULL,
Vyrobce varchar(50) NOT NULL,
Znacka varchar(50) NOT NULL,
Datum_vyroby datetime NOT NULL,
Datum_porizeni datetime NOT NULL,
Pocet_najetych_km int NOT NULL,
Datum_STK datetime NOT NULL,
Popis text,
SPZ varchar(10) NOT NULL );
Následujícím kusem kódu je definován primární klíč tabulky.
ALTER TABLE Automobil ADD CONSTRAINT PK_Automobil
PRIMARY KEY CLUSTERED (ID_automobil);
Poslední kus kódu, který je zde uveden definuje cizí klíč pobočky.
ALTER TABLE Automobil ADD CONSTRAINT FK_Automobil_Pobocka
FOREIGN KEY (ID_pobocka) REFERENCES Pobocka (ID_pobocka);
Ukázali jsme si, jak by se dala založit jedna tabulka v jazyce SQL, ovšem náš model obsahuje mnohem více relací a vazeb. Kompletní skript vygenerovaný nástrojem Enterprise Architect je v příloze26.
26
Zakládací skript v jazyce SQL pro model na obrázku 50 se nachází v příloze pod názvem „ZAKLADACI_SKRIPT_SQL“.
73
Data modeling
21.1.
Další možnost zakreslení
Nemůžeme tvrdit, že model v této kapitole je jedinou správnou možností zakreslení. Další
variantou je podrobit model27 určitému stupni denormalizace např. takto:
Obrázek 56 - Druhý logicky model relační databáze.
Je patrné, že počet relací se značně zmenšil. Na druhou stranu se ale zvětšil počet
atributů v jednotlivých tabulkách. To znamená, že např. pro kontakty, již neexistuje pouze
jedna centrální tabulka, ale uvádějí se u dodavatele, zákazníka a zaměstnance zvlášť. Toto
řešení není nesprávné a záleží jen na požadavcích na databázi, které variantě dáme přednost. Přínosem tohoto řešení je snazší přístup k datům, protože při dotazování nemusíme
procházet tolik tabulek jako v předchozím případu. Také zde chybí použití číselníku a hodnost zákazníka je vkládaná rovnou do jeho tabulky.
Nyní si pojďme ukázat, jak by vypadal fyzický model28 této denormalizované datové struktury.
27
Model v plné velikosti je v příloze pod názvem „LOGICKY_MODEL_RELACNI_DATABAZE_DENORMALIZOVANY“.
28
Model v plné velikosti je v příloze pod názvem „FYZICKY_MODEL_RELACNI_DATABAZE_DENORMALIZOVANY“.
74
Data modeling
Obrázek 57 - Dodavatelská smlouva.
75
Data modeling
Obrázek 58 - Zákaznická smlouva.
76
Data modeling
Obrázek 59 - Pobočka, automobil, záznamy.
77
Data modeling
22. Tvorba logického modelu objektové databáze
Tento model29 je velice podobný logickému modelu relační databáze, který jsme viděli
v předchozí kapitole na obrázku 44. Stejně jako tam, i v tomto případě vycházíme
z konceptuálního E-R diagramu a lineárního zápisu.
Struktura dat v ODB a aplikaci napsanou pomocí OOP by měla být co nejvíce podobná, co se entit a jejich vazeb týče. Proto přece byla tato databáze vymyšlena, aby objekt, se kterým pracuje aplikace, byl uložen beze změny a odpadl problém s jeho transformací do tabulkové podoby pro relační databázi. Díky ukazatelům OID, které řeší samotná
databázová platforma, již se nemusíme zabývat přidáváním nových ID atributu. Též odpadá potřeba řešit M:N vazby pomocí spojovacích entit, jak tomu bylo v relačním modelu,
kde tuto funkci zastupovaly spojovací tabulky. Dle mého názoru je to značný krok kupředu
v databázovém vývoji, protože proces tvorby datových modelu se podstatně zjednodušil a
diagramy jsou přehlednější než v RDB. Pojďme se tedy podívat na možnou strukturu dat
objektové databáze znázorněnou na logické úrovni.
Obrázek 60 - Logický model objektové databáze.
29
Model v plné velikosti je v příloze pod názvem „LOGICKY_MODEL_OBJEKTOVE_DATABAZE“.
78
Data modeling
Výraznou změnou je vytvoření jedné kupní smlouvy namísto dodavatelské a zákaznické zvlášť. Jedná se o další možnou variantu zakreslení. Smlouva má vždy dvě strany
a to kupujícího a prodávajícího, to jestli se to bude týkat zákazníka nebo dodavatele, nebo
jestli bude zaměstnanec firmy kupující nebo prodávající, bude řešeno samotnou aplikací
a do databáze se budou ukládat jen ty atributy, které se smlouvy opravdu týkají.
Dále si všimněte, že třídy Zakaznik a Dodavatel jsou prázdné, není to však chyba.
Toto rozdělení může posloužit pro případné rozšíření v budoucnu. Třídy mohou obsahovat
i metody, které vypočítávají potřebné informace z ostatních atributů a tím odlehčují samotné aplikaci.
Obrázek 61 - Přiklad metod v objektové databázi.
U osoby je možno spočítat její věk z rodného čísla. U automobilu lze rychle spočítat kolik zbývá času do skončení platnosti STK. U kontaktu je možno zjistit operátora
z prvního trojčíslí telefonu. Stejně tak může být vypočítaná celková částka ve smlouvě
pomocí sečtení cen veškerých položek, ať už služeb nebo produktů. Tyto metody jsou ukázány jen pro demonstraci toho, co může být s jejich pomocí řešeno.
Propojení tříd je zajištěno pomocí speciálních relationships setu. Jak zápis takového setu vypadá je předvedeno v následující kapitole, kde je ukázán příklad kódu v jazyce
OQL.
79
Data modeling
23. Tvorba fyzického modelu objektové databáze
Z logického modelu můžeme přikročit k tvorbě modelu fyzického. To přináší potřebu rozhodnout se jaký typy atributů budou v databázi podporovány. Pokud aplikace bude napsaná pomocí programovacího jazyka C# nebo java, je vhodné si zvolit databázovou platformu, která tento jazyk podporuje též a ukládat do databáze objekty se stejnými typy atributů
jako v aplikaci. Pro naši databázi si tedy zvolíme jazyk C#.
Obrázek 62 - Fyzický model objektové databáze.
Jak můžeme vidět v tomto modelu30 jsou již definovány typy všech atributů a vazby
jsou popsány dvojitě. Takovýto způsob popisu je potřeba pro tvorbu relationships setů,
které zajištují propojení tříd. Pojďme se znova podívat na detailnější zobrazení tohoto modelu.
30
Model v plné velikosti je v příloze pod názvem „FYZICKY_MODEL_OBJEKTOVE_DATABAZE“.
80
Data modeling
Obrázek 63 - Detail osoby.
Obrázek 64 - Detail smlouvy.
81
Data modeling
Obrázek 65 - Detail pobočky, auta, zaměstnance a záznamů.
Nyní si ukážeme, jak by vypadal zápis jedné z třídy pomocí jazyka OQL. Další dle
mého názoru kvalitní přiklad, jak funguje objektová databáze můžeme naleznout zde31.
Bohužel pouze v anglickém jazyce.
class Automobil {
attribute string vyrobce;
attribute string znacka;
attribute int najeteKm;
…
relationship (Pobocka) je_prirazen inverse Pobocka::vlastni;
…
kolikZbyvaCasu( ); };
Aby vazba automobilu a pobočky byla kompletní, je potřeba umístit do třídy Pobocka druhou stranu spojení tedy takto:
relationship list (Automobil) vlastni inverse Automobil::je_prirazen;
Znamená to, že objekt pobočky bude vlastnit list nebo-li „seznam“ objektů typu automobil.
31
Dokument vysvětlující principy objektové databáze a jazyka OQL
http://wps.prenhall.com/wps/media/objects/3310/3390076/hoffer_ch15.pdf
82
Data modeling
24. Tvorba modelu hierarchické databáze
Nyní přichází na řadu tvorba hierarchického modelu. Hned na začátku je potřeba vyřešit,
pomocí kterého jazyka a nástroje ho budeme modelovat. Jelikož hierarchické databáze jsou
téměř zapomenuty a jejich použití v IS zastíněno relačními, dnešní CASE nástroje nejsou
na jejich tvorbu zaměřené a tudíž nám nezbývá nic jiného než tvorbu simulovat pomocí
jiných nástrojů a modelovacích jazyků, které v době slávy hierarchických databází ani neexistovala. Abychom se vyhnuli dlouhé diskuzi o tom, který nastroj je lepší, použijeme
rovnou stejný jako v předchozích modelech, tedy Enterprise Architect a jazyk UML.
Hierarchicky model firmy Unifest by mohl vypadat následovně a v plné velikosti je
možné ho vidět v příloze32.
Obrázek 66 - Logický model hierarchické databáze.
Jako kořenový element byla zvolena samotná entita firmy. Do tohoto elementu
se můžou uložit důležité informace o společnosti. Pokud se spustíme na druhou úroveň, nic
extra divného nezaznamenáme. Jsou zde entity, které byly identifikovaný v rámci této společnosti, ale ve chvíli, kdy se podíváme na třetí úroveň, zjistíme, že entity se začínají opakovat. Důvody proč tomu tak je, jsou popsány v teoretické časti, ale přesto si zde vysvětlíme tuto problematiku ještě jednou na tomto konkrétním příkladu.
32
Model v plné velikosti se nalézá v příloze pod názvem „LOGICKY_MODEL_HIERARCHICKE_DATABAZE“.
83
Data modeling
Pravidla hierarchické databáze říkají, že pokud bude odstraněn rodič, bude odstraněn i potomek. Pro lepší pochopení, proč tedy dochází ke zdvojení záznamů, se zaměříme
na izolovanou část tohoto modelu.
Firma vlastní pobočku, na které pracují zaměstnanci a jsou k ní přiřazeny automobily. Zde je vše v pořádku. Pokud se firma rozhodne zrušit pobočku, zaměstnanec a automobil bude jednoduše přeřazen na jinou a pobočka bude smazána z databáze. Nyní se
pojďme podívat na záznam jízdy, ve kterém je nutno zachytit, kdo dopravní prostředek
řídil a o jaký automobil se jednalo. Zde se znova opakují záznamy automobilů a zaměstnance, a tak nastává otázka, jestli bychom nemohli pozměnit strukturu a navázat záznam
jízdy např. na automobil takto:
Obrázek 67 - Další možné řešeni izolované části.
Odpověď na tuto otázku nemůže být jednoznačná, protože zaleží na požadavcích
firmy. V případě, že automobil bude odstraněn z databáze, budou smazány i všechny jeho
záznamy jízd. Pokud firma po prodání automobilu, nechce mít k dispozici informace
o jízdách, je toto řešení v pořádku. Představme si však situaci, že firma během roku automobil prodá a tím ztratí i záznamy jízd a na konci téhož roku bude chtít vedení firmy zjistit, který zaměstnanec ujel nejvíce kilometrů. Samozřejmě, že to bude možné, ale některé
záznamy budou chybět a tak výsledek reportu nebude přesný.
84
Data modeling
V hlavním modelu je entita zákazníka, na kterou je navázaná entita smlouvy.
V tomto případě takovou vazbu je možné provést bez větších diskuzí, protože osoba, která
s firmou uzavře alespoň jednu smlouvu, je evidovaná jako zákazník a je nepravděpodobné,
že bude smazána. Z těchto důvodu můžeme ponechat vazbu tak jak je, protože pokud bude
vytvořen nový zákazník, musí byt vytvořena i smlouva. Dále je nutné, aby smlouva měla
vazbu s firemním pracovníkem, který ji uzavřel a produktem nebo službou, které
se smlouva týká , proto zde musíme znova vytvořit duplikované záznamy, které již existují
v databázi na jiném místě. Stejným způsobem je řešen též dodavatel a smlouvy s ním.
Na tomto praktickém přikladu můžeme pozorovat velkou nevýhodu hierarchické
databáze v její neschopnosti udržovat entitní vazby N:M. Proto většina tvůrců informačních systémů se uchyluje k použití novějších typu databází, kde nemusejí tento problém
řešit pomocí duplikace záznamů.
Často fyzický model ani nebyl kreslen a rovnou se z tohoto logického zobrazení
a doprovodného seznamu atributů přistupovalo k ruční tvorbě databáze např. pomocí seznamu. Proto se můžeme pouze domnívat, jak by následující fyzický model mohl vypadat.
Pravděpodobně by se moc od logického nelišil. Na rozdíl od něj by obsahoval navíc jen
atributy, které by byly umístěny v příslušných uzlech. Pokud databáze bude tvořena seznamem, mezi atributy by měly také patřit ID záznamů a ID nadřazeného záznamu. Jak by
mohl takový fyzický model hierarchické databáze33 vypadat je možné vidět na následujícím obrázku.
Obrázek 68 - Fyzický model hierarchické databáze.
33
Model v plné velikosti se nalézá v příloze pod názvem „FYZICKY_MODEL_HIERARCHICKE_DATABAZE“.
85
Data modeling
Data podle vytvořených modelu mohou být uložena následujícími způsoby:
Tabulka 9 - Uloženi hierarchické databáze.
id
1
2
3
4
5
6
7
idNad
0
0
1
1
1
2
2
nazevPobocky
Edenská
Skalská
-
mesto
Praha
Brno
Praha
Praha
Praha
Brno
Brno
ulice
U Slavie
Prosecká
Bratislavská
Veselská
Beranových
Dobratická
Tupolevova
jmeno
Anatoliy
Jan
Božena
Petr
Rudolf
prijmeni
Kybkalo
Novák
Savková
Krejcárek
Dub
…
…
…
…
…
…
…
…
Jedná se o seznam, který obsahuje tolik sloupců kolik je atributů všech entit.
U každého řádku jsou vyplněny jen ty, které se ho týkají a zbytek zůstává prázdný. První
dva záznamy jsou pobočky a jejich atribut ID_nad je vyplněn hodnotou 0 což je identifikátor kořenového elementu. Dále následují zaměstnanci a jejich ID_nad obsahuje ID pobočky na které pracuji.
Druhou variantou je uloženi v jazyce XML.
…
<Pobocka nazevPobocky=“ Edenská“ mesto=“Praha“ ulice=“ U Slavie“ …>
<Zamestnanec jmeno=“ Anatoliy“ prijmeni=“Kybkalo“ …></Zamestnanec>
<Zamestnanec jmeno=“ Jan“ prijmeni=“ Novák“ …></Zamestnanec>
<Zamestnanec jmeno=“ Božena“ prijmeni=“ Savková“ …></Zamestnanec>
</Pobocka>
<Pobocka nazevPobocky=“ Skalská“ mesto=“ Brno“ ulice=“Prosecká“ …>
<Zamestnanec jmeno=“ Petr“ prijmeni=“ Krejcárek“ …></Zamestnanec>
<Zamestnanec jmeno=“ Rudolf“ prijmeni=“ Dub“ …></Zamestnanec>
</Pobocka>
…
Jak bylo naznačeno pro firmu Unifest je použití této databáze možné, avšak naprosto nevhodné. Otázka tedy zní: Pro který případ, je hierarchická databáze vhodnější? Pojďme si uvést jiný příklad z reality, na který by se tato databáze dala uplatnit lépe.
86
Data modeling
Obrázek 69 - Hierarchická databáze vysoké školy.
Vysoka škola je rozdělena na fakulty, které mají své katedry a děkany. Jednotlivé
katedry mají své vedoucí a zaměstnance. Pokud bude zrušena jedna fakulta, nebude už
existovat její děkan ani příslušné katedry se zaměstnanci. Zde nedochází k žádné duplicitě
záznamu, proto dle mého názoru je to ideální příklad pro použití hierarchické databáze.
25. Tvorba modelu sítové databáze
Pro grafické zobrazení prvku této databáze můžeme využít konceptuální model ale poněkud v jiné podobě než je E-R diagram. Tento postup zobrazení se používal převážné
v dobách, kdy byl síťový model vymyšlen a E-R zobrazení jak ho známe nyní, neexistovalo.
87
Data modeling
Obrázek 70 - Prvky v modelu síťové databáze.
25.1.
Pravidla pro definování setu
Záznam může být členem jednoho setu a zároveň vlastníkem setu jiného. V následujícím
obrázku se tedy jedná o Pobočku.
Obrázek 71 - Záznam jako člen a vlastník.
POBOCKA-ZAMESTNANEC
FIRMA-POBOCKA
Firma
Pobočka
88
Zaměstnanec
Data modeling
Jeden záznam může být členem libovolneho počtu setů.
Obrázek 72 - Záznam jako členem vice setu.
Zaměstnanec
Automobil
Záznam Jizdy
AUTOMOBIL-ZÁZNAMJIZDY
ZAMĚSTNANEC-ZÁZNAMJIZDY
Jeden záznam může být vlastníkem libovolného počtu setů.
Obrázek 73 - Záznam jako vlastník vice setu.
POBOČKA-AUTOMOBIL
POBOČKA-ZAMĚSTNANEC
Pobočka
Zaměstnanec
Automobil
Stejně jako v relačních databázích i zde nelze vytvořit vztah M:N napřímo. Pro tento účel
slouží spojovací typ záznamu a dvě vazby typu 1:M.
Obrázek 74 - Záznamy a vztah M:N.
Produkt
Smlouva
Spojeni
SMLOUVA-SPOJENI
PRODUKT-SPOJENI
89
Data modeling
Pojďme se podívat, jak by síťový model mohl vypadat jako celek pro firmu Unifest.
Obrázek 75 - Datová struktura síťové databáze.
Zákazník
Pobočka
1
1
0..*
0..*
0..*
Zaměstnanec
Automobil
1
ZAM-ZS
Zákaznická
smlouva
1
0..*
ZAM-ZJ
0..*
ZS-S1
DOD-DS
Spojeni1
PRO-S3
SLU-S2
ZS-S2
ZAM-ZK
ZAM-DS
0..*
0..*
Záznam Jizdy
0..*
0..*
1
1
a_z
1
PRO-S1
1..*
p_z
p_a
1
1
ZAK-ZS
Služba
Produkt
Dodavatel
ZáznamKomunikace
1..*
1..*
Dodavatelská
smlouva
1
DOD-S3
1..*
Spojovaci3
0..*
Spojeni2
Na tento obrázek můžeme nahlížet zároveň jako na logický model a je velice pravděpodobné, že z tohoto zobrazení a ze seznamu všech potřebných atributů, byla rovnou
vytvářena databáze. Dle mého názoru nemá cenu se pokoušet vytvářet fyzický model pomocí jazyka UML, protože stejně nebudeme moci automaticky vygenerovat zakládací
skript, jak tomu bylo v relační databázi. Navíc nejedná se o nezbytnost, bez které bychom
nedokázali pochopit datovou strukturu tohoto příkladu.
Hlavním rozdílem oproti relačnímu datovému modelu je v realizaci vztahů. Stejně
jako u RDM, jsou i zde vztahy realizovány vazbou s kardinalitou 1:M, ale vztah je zaznamenán pomocí ukazatele na vazební entitu. K datovým tabulkám je připojena systémová
část, kde se nachází tolik odkazů, ke kolika jiným záznamům je záznam v tabulce vázán.
Na následujícím příkladu, se pokusím názorně vysvětlit podstatu ukládání dat v síťové databázi.
Obrázek 76 - Obecné propojení záznamů v síťové databázi.
90
Data modeling
Tedy pokud stejný princip aplikujeme na náš příklad, bude to vypadat takto:
Obrázek 77 - Konkrétní propojení záznamů v síťové databázi.
Pokud bychom potřebovali přiřadit další automobil první pobočce, postačí ho umístit do tabulky automobilů. Tento záznam bude mít DBK 345 a číslo 26, tudíž je nutné automobilu s číslem 25 změnit p_a na 345 a novému automobilu pod číslem 26 stanovit p_a
na 102. Stejným způsobem bude zajištěno propojení pobočky a zaměstnanců setem p_z.
Pokud srovnávám síťovou databázi s relační, docházím k závěru, že principy novější relační databáze jsou pro mě jednodušší na pochopení, proto i složitější propojení záznamů mi připadají méně „zamotané“ jako v síťové databázi.
91
Data modeling
26. Závěr
Tato bakalářská práce měla několik základních cílů. Jedním z nich bylo představit problematiku datového modelování a základní postupy pro tvorbu databáze. Modelování databáze může být mnohdy náročný proces, proto jsem v teoretické části popsal postup návrhu,
modely, které je možno využít a jazyk UML, pomocí kterého lze tyto modely vytvořit.
Dále jsou popsány čtyři databáze, jejichž principy je nezbytné znát v případě jejich výběru
pro aplikování na určitý případ. Na konci této časti, jsou též popsány design patterny, které
řeší několik z nejčastěji vyskytovaných problémů, co se struktury dat týče a best practices,
které dopomáhají stanovit určitou konvenci v modelování.
Člověk může přečíst nespočet teorie a přesto danou problematiku nepochopit do
hloubky, proto jsem v praktické části této bakalářské práce předvedl postup návrhu databáze od samotného business zadání, kde jsou identifikovány základní databázové entity, pomocí konceptuálních modelů na různé úrovni abstrakce a následně vytvořil logické
a fyzické modely pro různé typy databáze. Jelikož ve světě dnešních informačních systémů
je relační databáze nejpopulárnější, uznal jsem za vhodné pro ní předvést více než jednu
ukázku datové struktury.
Pokud chcete začít modelovat databázi, zaměřte se hlavně na:

Co nejvčasnější odhalení veškerých entit, protože čím později se na ně přijde, tím
bude více práce s předěláváním nebo s případným začleněním do datového modelu.

Vhodnou volbu typu databáze ještě před zahájením tvorby logického modelu. Jak
jsme si ukázali, ne vždy může být zvolena databáze ideální pro danou datovou
strukturu.

Zjištění, zda-li neexistuje pattern, který popisuje řešení vašeho problému, protože
s největší pravděpodobností, už se s tímto problémem někdo setkal a vy, byste objevovali již objevené.

Dodržování alespoň těch základních best practices. Není to sice povinností, ale
zlepšíme tím orientaci lidem, kteří mají též co dočinění s tvorbou vaší databáze
a jsou s patterny obeznámeny.
Během psaní této práce jsem si potvrdil, že neexistuje pouze jedno správné zobrazení jakéhokoli modelu. Vždy je hned několik možností jak „obrázek“ může vypadat a
pomocí požadavků na databázi můžeme zhodnotit, jestli je vyhovující. Dále mi tato práce
pomohla „udělat si pořádek“ v názvosloví, které se v databázích využívá. Domnívám se, že
informace zpracované v této práci, mohou být přínosem pro širší veřejnost zabývající se
databázovou problematikou, protože podle mého názoru je nedostatek publikací, ve kterých je zpracován průběh návrhu od začátku do konce pro více typu databází na jednom
místě a zejména v českém jazyce.
92
Data modeling
27. Conclusion
This bachelor work had several primary objectives. One of them was to present the issue of
data modelling and basic procedures for database creation. Database modelling can often
be a difficult process, that is why I have described the procedure of designing models that
can be used and language UML, that can be used to create these models, in the theoretical
part. I also described four database whose principles are necessary to know if they are selected for application for given case. At the end of this section there are also described design patterns, that solve some of the most frequent problems that occur in data structure
and some best ways to establish a convention in modelling.
One can read countless publications and still misunderstand the whole issue. Having this in mind I showed the design process from business assignments itself, where we
identify basic database entities by using conceptual models at different levels of abstraction
and then we create logical and physical models, to different types of databases. Because in
today's world of information systems the relational database is the most popular one,
I found it appropriate to show more than one example of data structure for it.
If you want to start database modelling, you need to focus mainly on:

To find all entities as soon as possible, because the later they come the harder it
will be to add them or to remake the data model.

To choose the appropriate type of database before starting working on logic model.
As we have seen, the selected database may not always be ideal for a particular data
structure.

To determine whether there already is a pattern that describes the solution to your
problem, because most likely, you are not the first to encounter this problem and
you would try to solve already solved issues.

To respect at least the most basic best practices. It is not the rule, but it will improve orientation of people who also have something to do with the creation of
your database and are familiar with patterns.
During the writing of this work I have confirmed for myself, that there is not only
one correct view of any model. There are always several ways that "picture" may look and
we can evaluate whether the one we chose is adequate for the requirements. This work also
helped me "to sort out" the terminology that is used in databases. I believe that the information processed in this study may be of benefit to the general public dealing with database problems. Because in my opinion there is a lack of publications that process the design from beginning to the end for multiple database types in one place and especially in
the Czech language.
93
Data modeling
28. Seznam použitých knižních zdrojů
MERUNKA, Vojtěch. CARDA, Antonín. POLÁK, Jiří. Datové modelování. 1. vyd. Praha:
Alfa Publishing, 2006, 177 s. Informatika studium. ISBN 80-868-5154-0.
HERNANDEZ, Michael J. Návrh databází. 1. vyd. Praha: Grada, 2006, 408 s. Informatika
studium. ISBN 80-247-0900-7.
SCHNEIDER, Robert D. MySQL: oficiální průvodce tvorbou, správou a laděním databází.
1. vyd. Praha: Grada Publishing, 2006, 372 s. Informatika studium. ISBN 80-247-1516-3.
CONOLLY, Thomas, Carolyn E BEGG a Richard HOLOWCZAK. Mistrovství - databáze: profesionální průvodce tvorbou efektivních databází. 1. vyd. Brno: Computer Press,
2009, 584 s. Informatika studium. ISBN 978-80-251-2328-7.
BRYLA, Bob, Kevin LONEY a Richard HOLOWCZAK. Mistrovství v Oracle Database
11g: profesionální průvodce tvorbou efektivních databází. 1. vyd. Brno: Computer Press,
2009, 700 s. Informatika studium. ISBN 978-80-251-2189-4.
KOFLER, Michael, Kevin LONEY a Richard HOLOWCZAK. Mistrovství v MySQL 5:
profesionální průvodce tvorbou efektivních databází. 1. vyd. Překlad Jan Svoboda, Ondřej
Baše, Jaroslav Černý. Brno: Computer Press, 2007, 805 s. Informatika studium. ISBN 97880-251-1502-2.
LACKO, Ľuboslav, Kevin LONEY a Richard HOLOWCZAK. 1001 tipů a triků pro SQL:
profesionální průvodce tvorbou efektivních databází. 1. vyd. Překlad Jan Svoboda, Ondřej
Baše, Jaroslav Černý. Brno: Computer Press, 2011, 416 s. Informatika studium. ISBN 97880-251-3010-0.
STANEK, William R, Kevin LONEY a Richard HOLOWCZAK. Microsoft SQL Server
2005: kapesní rádce administrátora. 1. vyd. Překlad Luděk Horčička. Brno: Computer
Press, 2006, 542 s. Informatika studium. ISBN 80-251-1211-X.
SOLAŘ, Tomáš, Kevin LONEY a Richard HOLOWCZAK. Oracle Database 11g: hotová
řešení. 1. vyd. Překlad Luděk Horčička. Brno: Computer Press, 2010, 288 s. K okamžitému použití. ISBN 978-80-251-2886-2.
PROCHÁZKA, David, Steven MORRIS a Peter ROB. Oracle: průvodce správou, využitím
a programováním nad databázovým systémem. 1. vyd. Praha: Grada Publishing, 2009, 168
s. K okamžitému použití. ISBN 978-80-247-2762-2.
SIMSION, Graeme C, Steven MORRIS a Peter ROB. Data Modeling: theory and Practice. 1. vyd. Bradley Beach, NJ: Technics Publications, c2007, xiv, 400 p. K okamžitému
použití. ISBN 09-771-4001-6.
94
Data modeling
29. Seznam použitých internetových zdrojů
Basaraner, C. (11. 4 2012). 20 Database Design Best Practices. Získáno 10. 3 2013, z
architects.dzone: http://architects.dzone.com/articles/20-database-design-best
Buchlák, P. (11. 2 2010). CIT Konceptuální modelování. Získáno 3. 4 2013, z
unicornuniverse: https://uu.unicornuniverse.eu/ues/sesm?SessFree=ues:UCLBT:CIT.CZ/LEC09/GL
Čapka, D. (14. 6 2012). 1. díl - Úvod do UML. Získáno 27. 2 2013, z devbook:
http://www.devbook.cz/uml-uvod-historie-vyznam-a-diagramy
Klechrel, J. (2001). audis.ic.cz/Access.pdf. Získáno 18. 3 2013, z Audis:
http://audis.ic.cz/Access.pdf
Melichar, J. (5. 4 2002). Datové modelování poprvé. Získáno 16. 3 2013, z dbsvet:
Varga, M. (2009). OAD Class diagram. Získáno 24. 3 2013, z unicornuniverse:
https://uu.unicornuniverse.eu/ues/sesm?SessFree=ues:UCLBT:OAD.CZ/LEC05/GL
Žďárský, M. (16. 2 2009). RDB Relační model. Získáno 26. 2 2013, z unicornuniverse:
https://uu.unicornuniverse.eu/ues/sesm?SessFree=ues:UCLBT:RDB.CZ/LEC02/GL
Žďárský, M. (2. 3 2009). RDB Tvorba modelů. Získáno 2. 4 2013, z unicornuniverse:
https://uu.unicornuniverse.eu/ues/sesm?SessFree=ues:UCLBT:RDB.CZ/LEC03/GL
95
Data modeling
30. Seznam obrázků
Obrázek 1 - Oddělení datové struktury od programu...................................................................... 14
Obrázek 2 - Sled úrovní P3A. ............................................................................................................ 15
Obrázek 3 - Ukázka E-R diagramu. ................................................................................................... 17
Obrázek 4 - Příklad logického modelu. ............................................................................................ 18
Obrázek 5 - Příklad fyzického modelu. ............................................................................................. 18
Obrázek 6 - Rozdělení UML diagramů.............................................................................................. 21
Obrázek 7 - Třída. ............................................................................................................................. 22
Obrázek 8 - Příklad třídy se stereotypem tabulky. ........................................................................... 22
Obrázek 9 - Základní asociační vazba. .............................................................................................. 23
Obrázek 10 - Usměrněná asociační vazba........................................................................................ 23
Obrázek 11 - Multiplicita. ................................................................................................................. 23
Obrázek 12 - Příklady multiplicity. ................................................................................................... 24
Obrázek 13 - Seznam databázových modelů. .................................................................................. 25
Obrázek 14 - Obecné uspořádání uzlů v hierarchickém modelu. .................................................... 26
Obrázek 15 - Obecné uspořádání uzlů v síťovém modelu. .............................................................. 28
Obrázek 16 - Obecný příklad relace. ................................................................................................ 29
Obrázek 17 - Propojení tabulek cizím klíčem. .................................................................................. 31
Obrázek 18 - Vazební tabulka. ......................................................................................................... 32
Obrázek 19 - Normální formy........................................................................................................... 33
Obrázek 20- Porovnání RDM a ODM................................................................................................ 37
Obrázek 21 - Nenormalizované třídy. .............................................................................................. 39
Obrázek 22 - Třídy v 1ONF. .............................................................................................................. 39
Obrázek 23 - Třídy v 2ONF ............................................................................................................... 40
Obrázek 24 - Třídy v 3ONF. .............................................................................................................. 40
Obrázek 25 - Struktura zaměstnanců v podniku. ............................................................................. 44
Obrázek 26 - Dědičnost v OOP. ........................................................................................................ 45
Obrázek 27 - Přístup Table per class. ............................................................................................... 45
Obrázek 28 - Přístup Table per subclass. ......................................................................................... 46
Obrázek 29 - Přístup Table per Class................................................................................................ 47
Obrázek 30 - Rozdělení metamodelu. .............................................................................................. 48
Obrázek 31 - Tabulky zákazníka a jeho bydliště ............................................................................... 49
Obrázek 32 - Tabulky metamodelu .................................................................................................. 49
Obrázek 33 - Microsoft Visio. ........................................................................................................... 53
Obrázek 34 - SmartDraw. ................................................................................................................. 53
Obrázek 35 - Enerprice Architect. .................................................................................................... 54
Obrázek 36 - Konceptuální model na vysoké úrovní abstrakce. ...................................................... 56
Obrázek 37 - Firemní hierarchie....................................................................................................... 57
Obrázek 38 - Záznam jízdy. .............................................................................................................. 57
Obrázek 39 - Příklad E-R diagramu se všemi atributy. ..................................................................... 59
Obrázek 40 - E-R diagram firmy Unifest. .......................................................................................... 60
Obrázek 41 - E-R detail pobočky, zaměstnance, automobilu a záznamů. ....................................... 61
96
Data modeling
Obrázek 42 - E-R detail dodavatelské smlouvy. ............................................................................... 61
Obrázek 43 - E-R detail zákaznické smlouvy. ................................................................................... 62
Obrázek 44 - Logicky model. ............................................................................................................ 63
Obrázek 45 - Detail zákazníka. ......................................................................................................... 64
Obrázek 46 - Detail dodavatele........................................................................................................ 64
Obrázek 47 - Detail smluv, produktu a služeb. ................................................................................ 65
Obrázek 48 - Detail zaměstnance. ................................................................................................... 66
Obrázek 49 - Detail pobočky, automobilu a záznamů. .................................................................... 66
Obrázek 50 - Fyzický model relační databáze. ................................................................................. 67
Obrázek 51 - Detail zákazníka. ......................................................................................................... 68
Obrázek 52 - Detail dodavatele........................................................................................................ 69
Obrázek 53 - Detail smluv, produktu a služeb. ................................................................................ 70
Obrázek 54 - Detail zaměstnance. ................................................................................................... 71
Obrázek 55 - Detail pobočky, automobilu a záznamů. .................................................................... 72
Obrázek 56 - Druhý logicky model relační databáze........................................................................ 74
Obrázek 57 - Dodavatelská smlouva. ............................................................................................... 75
Obrázek 58 - Zákaznická smlouva. ................................................................................................... 76
Obrázek 59 - Pobočka, automobil, záznamy. ................................................................................... 77
Obrázek 60 - Logický model objektové databáze. ........................................................................... 78
Obrázek 61 - Přiklad metod v objektové databázi. .......................................................................... 79
Obrázek 62 - Fyzický model objektové databáze. ............................................................................ 80
Obrázek 63 - Detail osoby. ............................................................................................................... 81
Obrázek 64 - Detail smlouvy. ........................................................................................................... 81
Obrázek 65 - Detail pobočky, auta, zaměstnance a záznamů. ......................................................... 82
Obrázek 66 - Logický model hierarchické databáze......................................................................... 83
Obrázek 67 - Další možné řešeni izolované části. ............................................................................ 84
Obrázek 68 - Fyzický model hierarchické databáze. ........................................................................ 85
Obrázek 69 - Hierarchická databáze vysoké školy. .......................................................................... 87
Obrázek 70 - Prvky v modelu síťové databáze. ................................................................................ 88
Obrázek 71 - Záznam jako člen a vlastník. ....................................................................................... 88
Obrázek 72 - Záznam jako členem vice setu. ................................................................................... 89
Obrázek 73 - Záznam jako vlastník vice setu.................................................................................... 89
Obrázek 74 - Záznamy a vztah M:N. ................................................................................................ 89
Obrázek 75 - Datová struktura síťové databáze............................................................................... 90
Obrázek 76 - Obecné propojení záznamů v síťové databázi. ........................................................... 90
Obrázek 77 - Konkrétní propojení záznamů v síťové databázi......................................................... 91
97
Data modeling
31. Seznam tabulek
Tabulka 1 - PK v relaci. ..................................................................................................................... 30
Tabulka 2 - Rozvrh v NF3. ................................................................................................................. 34
Tabulka 3 - První tabulka v BCNF. .................................................................................................... 34
Tabulka 4 - Druha tabulka v BCNF. ................................................................................................... 34
Tabulka 5 - Databázová tabulka zaměstnanců v podniku. ............................................................... 44
Tabulka 6- Relace osob. ................................................................................................................... 51
Tabulka 7 - Relace osob s použitím číselníku. .................................................................................. 51
Tabulka 8 - Číselník........................................................................................................................... 51
Tabulka 9 - Uloženi hierarchické databáze. ..................................................................................... 86
98
Data modeling
32. Seznam příloh
Přílohy se nalézají na přiloženém CD. Toto medium obsahuje modely v plné velikosti, které jsme
mohli vidět v praktické části. Modely jsou uložené ve formátu PNG.
Číslo přílohy
1
2
3
4
5
6
7
8
9
10
Název souboru
E-R_DIAGRAM
FYZICKY_MODEL_HIERARCHICKE_DATABAZE
FYZICKY_MODEL_OBJEKTOVE_DATABAZE
FYZICKY_MODEL_RELACNI_DATABAZE
FYZICKY_MODEL_RELACNI_DATABAZE_DENORMALIZOVANY
LOGICKY MODEL_HIERARCHICKE_DATABAZE
LOGICKY_MODEL_OBJEKTOVE_DATABAZE
LOGICKY_MODEL_RELACNI_DATABAZE
LOGICKY_MODEL_RELACNI_DATABAZE_DENORMALIZOVANY
ZAKLADACI_SKRIPT_SQL
99

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE Datové modelování

Transkript

Podobné dokumenty

zpravodaj prosinec 2011

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Energetické využití odpadů

Sborník anotací 2015

Uèební text - střední škola elektrotechnická, ostrava, na jízdárně 30, po

Dynamips, Dynagen, GNS3

DATOVÉ MODELOVÁNÍ

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

CASE pro podporu databází

Modelování proudění vody na měrném přelivu

Zpravy VMO - Společenské vědy 304

databázový server firebird instalace,konfigurace

ZDE - KOMIX

Databázové systémy IDS

4IT_450 Přehled CASE nástrojů na tuzemském trhu

Nákup zboží českým zákazníkem v zahraničním e

databázové technologie (db) – příprava na szz

Soucast publikace Dobre praxe z benchmarkingu

Hostýnské vrchy

Studijní text - E-learningové prvky pro podporu výuky

SQL - Oracle

Programy ohrožující bezpečnost