UNICORN COLLEGE. Katedra informačních technologií BAKALÁŘSKÁ PRÁCE. Datové modelování. Autor BP: Anatoliy Kybkalo. Vedoucí BP: Ing.

Transkript

1 UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Autor BP: Anatoliy Kybkalo Vedoucí BP: Ing. Miroslav Žďárský 2013 Praha

2

3 Č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 (Anatoliy Kybkalo)

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

5 5

6 Abstrakt 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

7 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

8 Obsah 1. Úvod Zpracování dat Data a informace Informace Data Data a jejich význam Význam dat v databázích Agendové zpracování dat Definice databáze Aplikační úloha Databáze a její oddělení od programu Princip tří architektur Konceptuální model Lineární zápis E-R diagram Logicky datový model Fyzický datový model Modelovací prostředky Modelovací jazyk UML Historie UML Význam UML Diagramy UML Doménový diagram Class diagram Třída Asociační vazba Multiplicita Databázové modely Hierarchický databázový model Uzly a jejich propojení Způsoby ukládaní dat v hierarchické struktuře Hierarchická databáze v současnosti

9 11. Síťový databázový model Uzly a jejich propojení Síťový model v současnosti Relační databázový model Historie relačního databázového modelu Relace Atomická hodnota Primární klíč Propojování tabulek Cizí klíč Vazební tabulka Normalizace relační databáze Boyce coddova normální forma BCNF Objektově orientované databáze Objektový databázový model Postup tvorby objektové databáze Objektová normalizace Tří objektové normální formy ONF ONF ONF ONF Best practices v datovém modelování Návrhové vzory (design patterns) Definice návrhového vzoru Příklady návrhových vzorů Hierarchická struktura dat Dědičnost tříd Předem neznáma struktura dat Číselník CASE nástroje pro datové modelování Praktická část Business zadáni Tvorba konceptuálního modelu Tvorba lineárního zápisu

10 19.2. Tvorba E-R diagramu Tedy E-R diagram v našem případě by mohl vypadat takto: Tvorba logického modelu relační databáze Tvorba fyzického modelu relační databáze Další možnost zakreslení Tvorba logického modelu objektové databáze Tvorba fyzického modelu objektové databáze Tvorba modelu hierarchické databáze Tvorba modelu sítové databáze Pravidla pro definování setu Závěr Conclusion Seznam použitých knižních zdrojů Seznam použitých internetových zdrojů Seznam obrázků Seznam tabulek Seznam příloh

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

12 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] 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

13 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

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

15 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. ( ). poprvé. Navštíveno

16 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ší 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.( ). RDB Tvorba modelů. Navštíveno

17 Obrázek 3 - Ukázka E-R diagramu. Zdroj 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

18 Obrázek 4 - Příklad logického modelu. Zdroj 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 18

19 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] 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. ( ). 1. díl - Úvod do UML. Získáno Vojtěch MERUNKA, Antonín CARDA, Jiří POLÁK:. Strana

20 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

21 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 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í 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 Vojtěch MERUNKA, Antonín CARDA, Jiří POLÁK:. Strana

22 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] 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. ( ). OAD Úvod do modelování IS. Získáno

23 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 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 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 Vojtěch MERUNKA, Antonín CARDA, Jiří POLÁK:. Strana

24 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. 0 nebo Třida 1 až N 1..N Třida 0 až N 0..* Třida 1 až Třida 0 až N toto použití je schodne s 0..* Právě 1 * 1 Třida Třida Pokud není uvedena žádná násobnost, je výchozí multiplicitou 1 Omezení výčtem: 4,5 až 9 4,5..9 Třida Třida 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

25 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 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 Strana

26 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 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

27 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 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

28 Obrázek 15 - Obecné uspořádání uzlů v síťovém modelu 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 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 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

29 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í 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

30 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 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í 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 ATRIBUT_1 ATRIBUT_2 1 Hodnota Hodnota 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

31 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é 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

32 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 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. ( ). RDB Relační model. Získáno , 32

33 Obrázek 19 - Normální formy 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. ( ). poprvé. Navštíveno

34 Tabulka 2 - Rozvrh v NF3. Prednaska Ucitel Mistnost Hodina EHT Jančích :00 EHT Jančích :00 SEC Hartman DK 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 Mistnost Hodina EHT :00 EHT : 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

35 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í 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ě: 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 12 Vojtěch MERUNKA, Antonín CARDA, Jiří POLÁK: Strana

36 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

37 Obrázek 20- Porovnání RDM a ODM 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

38 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 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í 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í ONF 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: Strana

39 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 ONF 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

40 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 ONF 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

41 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. ( ). 20 Database Design Best Practices. Získáno , 41

42 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í 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

43 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 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] 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. ( ). RDB Tvorba modelů. Získáno , 43

44 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. ID Jméno ID nadřízeného 1 Osoba_1 2 Osoba_2 1 3 Osoba_3 1 4 Osoba_4 2 5 Osoba_5 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 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

45 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

46 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

47 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

48 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

49 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

50 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 Čí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

51 Tabulka 6- Relace osob. ID_osoba Jmeno Hodnost 1 Anatoliy Manažer 2 Michal Manažer 3 Tomáš Prodejce 4 Josef Prodejce 5 Alexandr Prodejce 6 Martin Ř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 Jmeno ID_hodnost 1 Anatoliy 1 2 Michal 1 3 Tomáš 2 4 Josef 2 5 Alexandr 2 6 Martin 3 Tabulka 8 - Číselník. ID_hodnost Popis 1 Manažer 2 Prodejce 3 Ř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

52 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 CA- SE 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 Visio 16 a modelovací jazyk UUBML 17 - 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: 17 Odkaz na domovskou stránku výrobce: 18 Buchlák, P. ( ). CIT Konceptuální modelování. Získáno

53 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 SmartDraw 19. Obrázek 34 - SmartDraw. 19 Odkaz na domovskou stránku výrobce: ABA 53

54 Pro modelování logického a fyzického modelu může posloužit Enterprice Architect 20 nebo PowerDesigner 21 a jazyk UML. 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: 21 Odkaz na domovskou stránku výrobce: 54

55 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 u 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

56 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

57 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

58 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, , hodnost, číslo bankovního účtu, pobočka) ZÁKAZNÍK (jméno, příjmení, rodné číslo, telefon, , 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, ) 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

59 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

60 Tedy E-R diagram 23 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

61 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

62 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

63 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ý model 24 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

64 ž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

65 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

66 Ú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

67 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 Z náhledu můžeme vidět, že fyzický model 25 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

68 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

69 Obrázek 52 - Detail dodavatele. 69

70 Obrázek 53 - Detail smluv, produktu a služeb. 70

71 Obrázek 54 - Detail zaměstnance. 71

72 Obrázek 55 - Detail pobočky, automobilu a záznamů. 72

73 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říloze Zakládací skript v jazyce SQL pro model na obrázku 50 se nachází v příloze pod názvem ZAKLADA- CI_SKRIPT_SQL. 73

74 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 model 27 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ý model 28 této denormalizované datové struktury. 27 Model v plné velikosti je v příloze pod názvem LOGIC- KY_MODEL_RELACNI_DATABAZE_DENORMALIZOVANY. 28 Model v plné velikosti je v příloze pod názvem FYZIC- KY_MODEL_RELACNI_DATABAZE_DENORMALIZOVANY. 74

75 Obrázek 57 - Dodavatelská smlouva. 75

76 Obrázek 58 - Zákaznická smlouva. 76

77 Obrázek 59 - Pobočka, automobil, záznamy. 77

78 22. Tvorba logického modelu objektové databáze Tento model 29 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

79 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

80 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 modelu 30 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

81 Obrázek 63 - Detail osoby. Obrázek 64 - Detail smlouvy. 81

82 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 zde 31. 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 82

83 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říloze 32. 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

84 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

85 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áze 33 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

86 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 idnad nazevpobocky mesto ulice jmeno prijmeni 1 0 Edenská Praha U Slavie Skalská Brno Prosecká Praha Bratislavská Anatoliy Kybkalo Praha Veselská Jan Novák Praha Beranových Božena Savková Brno Dobratická Petr Krejcárek Brno Tupolevova Rudolf 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

87 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

88 Obrázek 70 - Prvky v modelu síťové databáze 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. FIRMA-POBOCKA POBOCKA-ZAMESTNANEC Firma Pobočka Zaměstnanec 88

89 Jeden záznam může být členem libovolneho počtu setů. Obrázek 72 - Záznam jako členem vice setu. Zaměstnanec Automobil ZAMĚSTNANEC-ZÁZNAMJIZDY Záznam Jizdy AUTOMOBIL-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-ZAMĚSTNANEC Pobočka POBOČKA-AUTOMOBIL 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. Smlouva Produkt SMLOUVA-SPOJENI Spojeni PRODUKT-SPOJENI 89

90 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. Pobočka Zákazník Dodavatel Produkt Služba 1 p_a p_z 0..* 0..* Automobil Zaměstnanec 1 ZAM-ZS 1 ZAK-ZS 0..* 1..* Zákaznická smlouva 1 1 DOD-DS ZS-S1 1 PRO-S3 PRO-S1 0..* 0..* Spojeni1 1 SLU-S2 1 1 ZS-S2 a_z ZAM-ZJ ZAM-ZK 0..* 0..* 0..* ZAM-DS 0..* 1..* 1..* 0..* Záznam Jizdy ZáznamKomunikace Dodavatelská smlouva DOD-S * Spojovaci3 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

91 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