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

Rozměr: px
Začít zobrazení ze stránky:

Download "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 https://uu.unicornuniverse.eu/ues/sesm?sessfree=ues:ucl-bt:rdb.cz/lec03/gl 16

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 https://uu.unicornuniverse.eu/ues/sesm?sessfree=ues:ucl-bt:oad.cz/lec05/gl 22

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 , https://uu.unicornuniverse.eu/ues/sesm?sessfree=ues:ucl-bt:rdb.cz/lec02/gl 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 , https://uu.unicornuniverse.eu/ues/sesm?sessfree=ues:ucl-bt:rdb.cz/lec03/gl 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: https://unicornuniverse.eu/cz/modelovaci-jazyk-uubml.html 18 Buchlák, P. ( ). CIT Konceptuální modelování. Získáno https://uu.unicornuniverse.eu/ues/sesm?sessfree=ues:ucl-bt:cit.cz/lec09/gl 52

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

Hierarchický databázový model

Hierarchický databázový model 12. Základy relačních databází Když před desítkami let doktor E. F. Codd zavedl pojem relační databáze, pohlíželo se na tabulky jako na relace, se kterými se daly provádět různé operace. Z matematického

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

Relační databáze. V dnešní době existuje řada komerčních DBMS, nejznámější jsou:

Relační databáze. V dnešní době existuje řada komerčních DBMS, nejznámější jsou: Relační databáze Pojem databáze, druhy databází Databází se myslí uložiště dat. V době začátků využívání databází byly tyto členěny hlavně hierarchicky, případně síťově (rozšíření hierarchického modelu).

Více

POKROČILÉ POUŽITÍ DATABÁZÍ

POKROČILÉ POUŽITÍ DATABÁZÍ POKROČILÉ POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni pochopit podstatu koncepce databází, navrhnout relační databázi s využitím pokročilých metod, navrhovat a

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) Marketingová komunikace Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) 2. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Minulé soustředění úvod

Více

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky.

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Projekt ESF OP VK reg.č. CZ.1.07/2.2.00/28.0209 Elektronické opory a e-learning pro obory výpočtového

Více

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu:

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu: Úvod do databází Základní pojmy Databáze je množina záznamů, kterou shromažďujeme za nějakým konkrétním účelem. Databáze používáme zejména pro ukládání obsáhlých informací. Databázové systémy jsou k dispozici

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

Více

Analýza a modelování dat. Helena Palovská

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph)

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3aph) 2. a 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Co nás čeká: 2. soustředění 16.1.2009

Více

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH Jindřich Kaluža Ludmila Kalužová Recenzenti: prof. Ing. Milan Turčáni, CSc. prof. Ing. Ivan Vrana, DrSc. Tato kniha vznikla za finanční podpory Studentské grantové

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

4IT218 Databáze. 4IT218 Databáze

4IT218 Databáze. 4IT218 Databáze 4IT218 Databáze Osmá přednáška Dušan Chlapek (katedra informačních technologií, VŠE Praha) 4IT218 Databáze Osmá přednáška Normalizace dat - dokončení Transakce v databázovém zpracování Program přednášek

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

DBS Konceptuální modelování

DBS Konceptuální modelování DBS Konceptuální modelování Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze Michal.Valenta@fit.cvut.cz c Michal Valenta, 2010 BIVŠ DBS I, ZS 2010/11 https://users.fit.cvut.cz/

Více

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Logická struktura systému Objektový diagram Pavel Děrgel, Daniela Szturcová Osnova Modelování objektů objektový diagram Struktura a vazby mezi objekty Dobré zvyky při

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Databázové patterny MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Obsah o Co je databázový pattern o Pattern: Přiřazení rolí o Pattern: Klasifikace Databázové patterny o Odzkoušené a doporučené

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

Semestrální práce 2 znakový strom

Semestrální práce 2 znakový strom Semestrální práce 2 znakový strom Ondřej Petržilka Datový model BlockFileRecord Bázová abstraktní třída pro záznam ukládaný do blokového souboru RhymeRecord Konkrétní třída záznamu ukládaného do blokového

Více

Úvod do principů objektově orientovaného programování

Úvod do principů objektově orientovaného programování OBSAH DISTANČNÍHO E-LEARNINGOVÉHO KURZU PROFESNÍ RŮST ANALYTIKA OD ZÁKLADŮ (BASE) ÚVOD DO TECHNOLOGIÍ INFORMAČNÍCH SYSTÉMŮ Jak funguje počítač na základní úrovni Základy HTML Skripty ve webovských technologiích

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ

ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ RELATIONAL AND OBJECT DATABASES DESIGN DIFFERENCES AND IT S IMPLICATIONS TO MODEL TRANSFORMATION Vít Holub

Více

Základní informace o co se jedná a k čemu to slouží

Základní informace o co se jedná a k čemu to slouží Základní informace o co se jedná a k čemu to slouží založené na relačních databází transakční systémy, které jsou určeny pro pořizování a ukládání dat v reálném čase (ERP, účetní, ekonomické a další podnikové

Více

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

Více

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

Více

Materiál byl vytvořen v rámci projektu Nové výzvy, nové příležitosti, nová škola

Materiál byl vytvořen v rámci projektu Nové výzvy, nové příležitosti, nová škola Materiál byl vytvořen v rámci projektu Nové výzvy, nové příležitosti, nová škola Tento projekt je spolufinancován Evropským sociálním fondem a státním rozpočtem České republiky Co je to databáze? Jaké

Více

2 PŘÍKLAD IMPORTU ZATÍŽENÍ Z XML

2 PŘÍKLAD IMPORTU ZATÍŽENÍ Z XML ROZHRANÍ ESA XML Ing. Richard Vondráček SCIA CZ, s. r. o., Thákurova 3, 160 00 Praha 6 www.scia.cz 1 OTEVŘENÝ FORMÁT Jednou z mnoha užitečných vlastností programu ESA PT je podpora otevřeného rozhraní

Více

předměty: ukončení: Zápočet + Zkouška / 5kb např. jméno, název, destinace, město např. student Jan Novák, narozen 18.5.1974

předměty: ukončení: Zápočet + Zkouška / 5kb např. jméno, název, destinace, město např. student Jan Novák, narozen 18.5.1974 základní informace Databázové systémy Úvodní přednáška předměty: KI/DSY (B1801 Informatika - dvouoborová) KI/P502 (B1802 Aplikovaná informatika) ukončení: Zápočet + Zkouška / 5kb ki.ujep.cz termínovník,

Více

Databázový systém označuje soubor programových prostředků, které umožňují přístup k datům uloženým v databázi.

Databázový systém označuje soubor programových prostředků, které umožňují přístup k datům uloženým v databázi. Databáze Základní pojmy Pojem databáze označuje obecně souhrn informací, údajů, dat o nějakých objektech. Úkolem databáze je hlídat dodržení všech omezení a dále poskytovat data při operacích. Objekty

Více

RELAČNÍ DATABÁZOVÉ SYSTÉMY

RELAČNÍ DATABÁZOVÉ SYSTÉMY RELAČNÍ DATABÁZOVÉ SYSTÉMY VÝPIS KONTROLNÍCH OTÁZEK S ODPOVĚDMI: Základní pojmy databázové technologie: 1. Uveďte základní aspekty pro vymezení jednotlivých přístupů ke zpracování hromadných dat: Pro vymezení

Více

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS Relační databázový model Databázové (datové) modely základní dělení klasické databázové modely relační databázový model relační databázový model Základní konstrukt - relace relace, schéma relace atribut,

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

7.5 Diagram tříd pokročilé techniky

7.5 Diagram tříd pokročilé techniky 7.5 Diagram tříd pokročilé techniky Stereotypy - jeden ze základních prostředků rozšiřitelnosti UML - pro modelovací konstrukce neexistující v UML, ale podobné předdefinované v UML definované uživatelem

Více

TEORIE ZPRACOVÁNÍ DAT

TEORIE ZPRACOVÁNÍ DAT Vysoká škola báňská - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky TEORIE ZPRACOVÁNÍ DAT pro kombinované a distanční studium Jana Šarmanová Ostrava 2003 Jana Šarmanová, 2003 Fakulta

Více

Databáze v MS ACCESS

Databáze v MS ACCESS 1 z 14 19.1.2014 18:43 Databáze v MS ACCESS Úvod do databází, návrh databáze, formuláře, dotazy, relace 1. Pojem databáze Informací se data a vztahy mezi nimi stávají vhodnou interpretací pro uživatele,

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit (entitní množiny) Atributy

Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit (entitní množiny) Atributy - 2.1 - Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit Množiny vztahů Otázky návrhu Plánování mezí Klíče E-R diagram Rozšířené E-R rysy Návrh E-R databázového schématu Redukce

Více

DATABÁZE MS ACCESS 2010

DATABÁZE MS ACCESS 2010 DATABÁZE MS ACCESS 2010 KAPITOLA 5 PRAKTICKÁ ČÁST TABULKY POPIS PROSTŘEDÍ Spuštění MS Access nadefinovat název databáze a cestu k uložení databáze POPIS PROSTŘEDÍ Nahoře záložky: Soubor (k uložení souboru,

Více

Projektová dokumentace pro tvorbu internetových aplikací

Projektová dokumentace pro tvorbu internetových aplikací Projektová dokumentace pro tvorbu internetových aplikací Tomáš Kuthan PhDr. Milan Novák, Ph.D. Školní rok: 2008-09 Abstrakt Bakalářská práce stanovuje vzor pro vytváření projektové dokumentace internetových

Více

Konceptuální modelování. Pavel Tyl 21. 3. 2013

Konceptuální modelování. Pavel Tyl 21. 3. 2013 Konceptuální modelování Pavel Tyl 21. 3. 2013 Vytváření IS Vytváření IS Analýza Návrh Implementace Testování Předání Jednotlivé fáze mezi sebou iterují Proč modelovat a analyzovat? Standardizované pracovní

Více

5. Formalizace návrhu databáze

5. Formalizace návrhu databáze 5. Formalizace návrhu databáze 5.1. Úvod do teorie závislostí... 2 5.1.1. Funkční závislost... 2 5.1.2. Vícehodnotová závislost (multizávislost)... 7 5.1.3. Závislosti na spojení... 9 5.2. Využití teorie

Více

Úvod do MS Access. Modelování v řízení. Ing. Petr Kalčev

Úvod do MS Access. Modelování v řízení. Ing. Petr Kalčev Úvod do MS Access Modelování v řízení Ing. Petr Kalčev Postup při tvorbě aplikace Vytvoření tabulek Vytvoření relací Vytvoření dotazů Vytvoření formulářů Vytvoření sestav Tabulky Slouží k definování polí,

Více

Databázové systémy úvod

Databázové systémy úvod Databázové systémy úvod Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2012 BI-DBS, ZS 2012/13 https://edux.fit.cvut.cz/courses/bi-dbs/ Michal

Více

Jiří Mašek BIVŠ V Pra r ha 20 2 08

Jiří Mašek BIVŠ V Pra r ha 20 2 08 Jiří Mašek BIVŠ Praha 2008 Procesvývoje IS Unifiedprocess(UP) Iterace vývoje Rysy CASE nástrojů Podpora metodických přístupů modelování Integrační mechanismy propojení modelů Podpora etap vývoje Generování

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

Operátory ROLLUP a CUBE

Operátory ROLLUP a CUBE Operátory ROLLUP a CUBE Dotazovací jazyky, 2009 Marek Polák Martin Chytil Osnova přednášky o Analýza dat o Agregační funkce o GROUP BY a jeho problémy o Speciální hodnotový typ ALL o Operátor CUBE o Operátor

Více

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI Cyril Klimeš a) Jan Melzer b) a) Ostravská univerzita, katedra informatiky a počítačů, 30. dubna 22, 701 03 Ostrava, ČR E-mail: cyril.klimes@osu.cz b) DC Concept

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava. Úvod do databázových systémů 2012/2013 IS MHD

Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava. Úvod do databázových systémů 2012/2013 IS MHD Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava Úvod do databázových systémů 2012/2013 IS MHD Jiří Znoj, (zno0011) Ostrava, 29. listopadu 2012 I. Obsah I. Obsah...

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5 CRM SYSTÉM KORMORÁN UŽIVATELSKÁ PŘÍRUČKA Obsah 1 Základní práce se systémem 3 1.1 Práce se záznamy................................. 3 1.2 Stránka Dnes.................................... 4 1.3 Kalendář......................................

Více

Profilová část maturitní zkoušky 2013/2014

Profilová část maturitní zkoušky 2013/2014 Střední průmyslová škola, Přerov, Havlíčkova 2 751 52 Přerov Profilová část maturitní zkoušky 2013/2014 TEMATICKÉ OKRUHY A HODNOTÍCÍ KRITÉRIA Studijní obor: 78-42-M/01 Technické lyceum Předmět: TECHNIKA

Více

Kapitola 7: Návrh relačních databází. Nástrahy relačního návrhu. Příklad. Rozklad (dekompozice)

Kapitola 7: Návrh relačních databází. Nástrahy relačního návrhu. Příklad. Rozklad (dekompozice) - 7.1 - Kapitola 7: Návrh relačních databází Nástrahy návrhu relačních databází Dekompozice (rozklad) Normalizace použitím funkčních závislostí Nástrahy relačního návrhu Návrh relačních databází vyžaduje

Více

MS SQL Server 2008 Management Studio Tutoriál

MS SQL Server 2008 Management Studio Tutoriál MS SQL Server 2008 Management Studio Tutoriál Vytvoření databáze Při otevření management studia a připojením se ke konkrétnímu sql serveru mám v levé části panel s názvem Object Explorer. V tomto panelu

Více

DATABÁZE A SYSTÉMY PRO UCHOVÁNÍ DAT 61 DATABÁZE - ACCESS. (příprava k vykonání testu ECDL Modul 5 Databáze a systémy pro zpracování dat)

DATABÁZE A SYSTÉMY PRO UCHOVÁNÍ DAT 61 DATABÁZE - ACCESS. (příprava k vykonání testu ECDL Modul 5 Databáze a systémy pro zpracování dat) DATABÁZE A SYSTÉMY PRO UCHOVÁNÍ DAT 61 DATABÁZE - ACCESS (příprava k vykonání testu ECDL Modul 5 Databáze a systémy pro zpracování dat) DATABÁZE A SYSTÉMY PRO UCHOVÁNÍ DAT 62 Databáze a systémy pro uchování

Více

Databáze II. 1. přednáška. Helena Palovská palovska@vse.cz

Databáze II. 1. přednáška. Helena Palovská palovska@vse.cz Databáze II 1. přednáška Helena Palovská palovska@vse.cz Program přednášky Úvod Třívrstvá architektura a O-R mapování Zabezpečení dat Role a přístupová práva Úvod Co je databáze Mnoho dat Organizovaných

Více

11 Diagram tříd, asociace, dědičnost, abstraktní třídy

11 Diagram tříd, asociace, dědičnost, abstraktní třídy 11 Diagram tříd, asociace, dědičnost, abstraktní třídy Studijní cíl Tento studijní blok má za cíl pokračovat v základních prvcích jazyka Java. Konkrétně bude věnována pozornost diagramům tříd, asociaci,

Více

3 druhy UML diagramů

3 druhy UML diagramů UML grafický jazyk se pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů zjednodušuje komunikaci mezi zadavatelem a řešitelem projektu UML podporuje objektově orientovaný přístup

Více

2. přednáška z předmětu GIS1 Data a datové modely

2. přednáška z předmětu GIS1 Data a datové modely 2. přednáška z předmětu GIS1 Data a datové modely Vyučující: Ing. Jan Pacina, Ph.D. e-mail: jan.pacina@ujep.cz Pro přednášku byly použity texty a obrázky z www.gis.zcu.cz Předmět KMA/UGI, autor Ing. K.

Více

Databázové systémy trocha teorie

Databázové systémy trocha teorie Databázové systémy trocha teorie Základní pojmy Historie vývoje zpracování dat: 50. Léta vše v programu nevýhody poměrně jasné Aplikace1 alg.1 Aplikace2 alg.2 typy1 data1 typy2 data2 vytvoření systémů

Více

Základní datové struktury

Základní datové struktury Základní datové struktury Martin Trnečka Katedra informatiky, Přírodovědecká fakulta Univerzita Palackého v Olomouci 4. listopadu 2013 Martin Trnečka (UPOL) Algoritmická matematika 1 4. listopadu 2013

Více

2. Konceptuální model dat, E-R konceptuální model

2. Konceptuální model dat, E-R konceptuální model 2. Konceptuální model dat, E-R konceptuální model Úvod Databázový model souhrn prostředků, pojmů a metod, jak na logické úrovni popsat data a jejich strukturu výsledkem je databázové schéma. Databázové

Více

Databáze MS-Access. Obsah. Co je to databáze? Doc. Ing. Radim Farana, CSc. Ing. Jolana Škutová

Databáze MS-Access. Obsah. Co je to databáze? Doc. Ing. Radim Farana, CSc. Ing. Jolana Škutová Databáze MS-Access Doc. Ing. Radim Farana, CSc. Ing. Jolana Škutová Obsah Principy a možnosti databází. Uložení dat v databázi, formáty dat, pole, záznamy, tabulky, vazby mezi záznamy. Objekty databáze

Více

Analýza a modelování dat 2. přednáška. Helena Palovská

Analýza a modelování dat 2. přednáška. Helena Palovská Analýza a modelování dat 2. přednáška Helena Palovská Databázové modely Způsoby logické organizace dat hierarchický síťový relační objektový (objektově-relační) multidimenzionální Historie databázových

Více

Modul Konfigurace. 2006... MTJ Service, s.r.o.

Modul Konfigurace. 2006... MTJ Service, s.r.o. Modul Konfigurace Modul Konfigurace Představení Menu konfigurace sdružuje všechny konfigurační příkazy k celému systému Soft-4-Sale. Dále konfigurace kopíruje jednotlivé moduly systému tzn. že existuje

Více

45 Plánovací kalendář

45 Plánovací kalendář 45 Plánovací kalendář Modul Správa majetku slouží ke tvorbě obecných ročních plánů činností organizace. V rámci plánu je třeba definovat oblasti činností, tj. oblasti, ve kterých je možné plánovat. Každá

Více

Jeden ze způsobů zadávání dat v programu MS Access je pomocí tabulek. Ovšem mnohem výhodnější způsob je pomocí tzv. formulářů.

Jeden ze způsobů zadávání dat v programu MS Access je pomocí tabulek. Ovšem mnohem výhodnější způsob je pomocí tzv. formulářů. 10.12 TVORBA FORMULÁŘE 10.12.1 VYTVOŘENÍ JEDNODUCHÉHO FORMULÁŘE Jeden ze způsobů zadávání dat v programu MS Access je pomocí tabulek. Ovšem mnohem výhodnější způsob je pomocí tzv. formulářů. Jak jste se

Více

Databáze Bc. Veronika Tomsová

Databáze Bc. Veronika Tomsová Databáze Bc. Veronika Tomsová Databázové schéma Mapování konceptuálního modelu do (relačního) databázového schématu. 2/21 Fyzické ik schéma databáze Určuje č jakým způsobem ů jsou data v databázi ukládána

Více

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken Jazyk UML - přehled Unified Modeling Language jazyk pro popis objektově orientované analýzy a návrhu aplikací slouží k vzájemné komunikaci mezi zadavatelem a návrhářem systému má několik částí, není nutné

Více

Marketingová komunikace. 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3bph)

Marketingová komunikace. 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3bph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3bph) 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Zdroje Studijní materiály Heleny Palovské

Více

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR):

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR): Mezi příkazy pro manipulaci s daty (DML) patří : 1. SELECT 2. ALTER 3. DELETE 4. REVOKE Jaké vlastnosti má identifikující relace: 1. Je relace, která se využívá pouze v případě modelovaní odvozených entit

Více

Postupy práce se šablonami IS MPP

Postupy práce se šablonami IS MPP Postupy práce se šablonami IS MPP Modul plánování a přezkoumávání, verze 1.20 vypracovala společnost ASD Software, s.r.o. dokument ze dne 27. 3. 2013, verze 1.01 Postupy práce se šablonami IS MPP Modul

Více

Principy OOP při tvorbě aplikací v JEE. Michal Čejchan

Principy OOP při tvorbě aplikací v JEE. Michal Čejchan Principy OOP při tvorbě aplikací v JEE Michal Čejchan Témata přednášky Principy OOP - připomenutí Úvod - co nás vede k používání OOP Reálný svět - jak (ne)používáme OOP Nedostatky na úrovni programovacích

Více

37. Indexování a optimalizace dotazů v relačních databázích, datové struktury, jejich výhody a nevýhody

37. Indexování a optimalizace dotazů v relačních databázích, datové struktury, jejich výhody a nevýhody 37. Indexování a optimalizace dotazů v relačních databázích, datové struktury, jejich výhody a nevýhody Využití databázových indexů Databázové indexy slouží ke zrychlení přístupu k datům a měly by se používat

Více

Služby Microsoft Office 365

Služby Microsoft Office 365 Cena: 2000 Kč + DPH Služby Microsoft Office 365 Kurz je určen všem, kteří se chtějí ponořit do tajů Cloud služeb a chtějí naplno využít možnosti Office 365, jako komunikačního nástroje i prostředí pro

Více

Uživatelský manuál. Aplikace GraphViewer. Vytvořil: Viktor Dlouhý

Uživatelský manuál. Aplikace GraphViewer. Vytvořil: Viktor Dlouhý Uživatelský manuál Aplikace GraphViewer Vytvořil: Viktor Dlouhý Obsah 1. Obecně... 3 2. Co aplikace umí... 3 3. Struktura aplikace... 4 4. Mobilní verze aplikace... 5 5. Vytvoření projektu... 6 6. Části

Více

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná.

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná. Průběžná klasifikace Nová verze modulu Klasifikace žáků přináší novinky především v práci s průběžnou klasifikací. Pro zadání průběžné klasifikace ve třídě doposud existovaly 3 funkce Průběžná klasifikace,

Více

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např.

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např. 2 přednáška 2 října 2012 10:32 Souborově orientované uchování dat Slabý HW Není možné uchovávat "velká data" - maximálně řádově jednotky MB Na každou úlohu samostatná aplikace, která má samostatná data

Více

CATIA V5 vs CATIA V4 Martina Staňková

CATIA V5 vs CATIA V4 Martina Staňková CATIA V5 vs CATIA V4 Martina Staňková Obsah: 1) 2) 3) 4) Použití softwaru CATIA v automobilovém průmyslu Společné vlastnosti obou verzí Odlišný přístup k řešení konstrukčních úloh Zhodnocení 1) Použití

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

43 HTML šablony. Záložka Šablony v systému

43 HTML šablony. Záložka Šablony v systému 43 HTML šablony Modul HTML šablony slouží ke správě šablon pro výstupy z informačního systému modularis ve formátu HTML. Modul umožňuje k šablonám doplňovat patičku, dokumentaci a vázat šablony na konkrétní

Více

Algoritmus. Přesné znění definice algoritmu zní: Algoritmus je procedura proveditelná Turingovým strojem.

Algoritmus. Přesné znění definice algoritmu zní: Algoritmus je procedura proveditelná Turingovým strojem. Algoritmus Algoritmus je schematický postup pro řešení určitého druhu problémů, který je prováděn pomocí konečného množství přesně definovaných kroků. nebo Algoritmus lze definovat jako jednoznačně určenou

Více

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData TM DEVELOPERSKÝ PROJEKT

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData TM DEVELOPERSKÝ PROJEKT RosaData TM DEVELOPERSKÝ PROJEKT OBSAH Úvod... 4 Developerský projekt... 5 Seznam developerských projektů... 5 Základní údaje... 6 Popis... 7 Technické detaily... 8 Reality... 11 Foto... 13 Obchodní případ...

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

1.13 ACCESS popis programu

1.13 ACCESS popis programu Název školy Číslo projektu Autor Název šablony Název DUMu Tematická oblast Předmět Druh učebního materiálu Anotace Vybavení, pomůcky Střední průmyslová škola strojnická Vsetín CZ.1.07/1.5.00/34.0483 Ing.

Více

24 Uživatelské výběry

24 Uživatelské výběry 24 Uživatelské výběry Uživatelský modul Uživatelské výběry slouží k vytváření, správě a následnému používání tématicky seskupených osob a organizací včetně jejich kontaktních údajů. Modul umožňuje hromadnou

Více

Metodika návrhu databáze

Metodika návrhu databáze Metodika návrhu databáze Metodika tvorby konceptuálního datového modelu (ERA diagramu) 1 1. Zvolte jednu primární entitu ze specifikace požadavků. 2. Určete atributy, jejichž hodnoty se mají pro tuto entitu

Více

Dolování v objektových datech. Ivana Rudolfová

Dolování v objektových datech. Ivana Rudolfová Dolování v objektových datech Ivana Rudolfová Relační databáze - nevýhody První normální forma neumožňuje vyjádřit vztahy A je podtypem B nebo vytvořit struktury typu pole nebo množiny SQL omezení omezený

Více

Systém elektronického rádce v životních situacích portálu www.senorady.cz

Systém elektronického rádce v životních situacích portálu www.senorady.cz Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML

Více

Univerzita Karlova v Praze

Univerzita Karlova v Praze [Vzor: Pevná deska diplomové práce není součástí elektronické verze] [Verze 3/2013 platná od 18.3.2013 dostupná z http://www.mff.cuni.cz/studium/bcmgr/prace] Univerzita Karlova v Praze Matematicko-fyzikální

Více