Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Student : Tomáš Grombíř Vedoucí bakalářské práce : RNDr. Helena Palovská, Ph.D. Oponent bakalářské práce : Ing. Petr Macák TÉMA BAKALÁŘSKÉ PRÁCE NÁVRH DATABÁZE PRO MŠ PASTELKA ROK : 2010

Čestné prohlášení: Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně. Veškeré použité podklady, ze kterých jsem čerpal informace, jsou uvedeny v seznamu použité literatury a citovány v textu podle normy ČSN ISO 690. V Praze dne 11.5. 2010 Podpis:...

Poděkování: Chtěl bych poděkovat RNDr. Heleně Palovské, Ph.D. za poskytnuté rady a připomínky. Dále pak mojí rodině za podporu během studií.

Abstrakt Tato práce se zabývá analýzou a návrhem databáze pro mateřskou školku Pastelka. Dále pak instalací databázového systému MySQL včetně jeho nastavení. Ověření funkčnosti navržené databáze a databázového systému proběhlo prostřednictvím aplikace vytvořené v jazyce PHP. Abstract This bachelor thesis deals with analysis, creation of database for a kindergarten and installation of the designed database into the database system MySQL. Functionality of the proposed database was verified through an application written in PHP.

OBSAH 1. Úvod... 7 2. Analyzovaná instituce... 9 2.1. Základní informace...9 2.2. Analýza aktuálního stavu uchovávání dat...9 2.3. Požadavky na databázi...10 2.4. Požadavky na aplikaci...11 2.5. Navrhnuté technologické řešení...11 3. Návrh relační databáze... 12 3.1. Relační databáze...12 3.2. Proces návrhu relační databáze...13 3.3. Tabulky...14 3.3.1. Identifikace tabulek při návrhu databáze...15 3.3.2. Normalizace...15 3.4. Pole...16 3.4.1. Obecné vlastnosti polí...17 3.4.2. Fyzické vlastnosti polí...17 3.4.3. Logické vlastnosti polí...18 3.4.4. Definice polí při návrhu databáze...18 3.5. Vztahy...19 3.5.1. Typ vztahu...20 3.5.2. Způsob a stupeň účasti...21 3.5.3. Vytváření vztahů při návrhu databáze...23 3.6. Klíče...23 3.7. Datové typy...24 3.7.1. Číselné datové typy...25 3.7.2. Datové typy pro datum a čas...25 3.7.3. Řetězcové datové typy...26 3.7.4. Použité atributy datových typů...27 3.8. Integritní omezení...27 3.8.1. Integrita tabulek...28 3.8.2. Integrita polí...28 3.8.3. Integrita vztahů...28 3.8.4. Business pravidla...29 3.9. Konceptuální modelování...30

3.9.1. Popis konceptuálního modelu...30 3.10. Fyzický model...32 3.11. Vygenerovaný SQL skript...35 3.11.1. Popis skriptu...35 3.11.2. Úpravy skriptu...36 3.11.3. Vytvoření pohledů...37 4. Instalace, nastavení a otestování databázového systému... 38 4.1. MySQL...38 4.2. Instalace MySQL...38 4.3. Prvotní konfigurace MySQL...39 4.4. Nastavení MySQL...39 4.5. Vytvoření DB...40 4.6. Zabezpečení MySQL...41 4.6.1. Přístupová oprávnění...41 4.6.2. Limity na konzumaci prostředků...42 4.7. Zálohování databáze...42 4.8. Import dat...42 4.9. Aplikace ke správě databáze...43 4.9.1. Webový server...43 4.9.2. PHP...43 4.9.3. Komunikace s databází...44 4.10. Otestování funkčnosti aplikace a databáze...44 5. Závěr... 45 6. Citovaná literatura... 46 7. Terminologický slovník... 47 8. Přílohy... 49 8.1. Upravený SQL skript...49 8.2. Nastavení výchozích identifikačních čísel...53 8.3. Pohledy...54 8.4. Vytvoření uživatelů...54 8.5. Přidělení práv...54 8.6. Vytvořená databázová struktura v mysql...55 8.7. Otestování aplikace a databáze...55 8.8. Seznam tabulek...56

1. ÚVOD Ačkoliv se vznik relačních databází datuje již od roku 1970, kdy Edgar Frank Codd publikoval článek o možnostech relačního datového modelu[2], stále se v dnešní době najdou instituce, vývojáři a aplikace, které přínosu tohoto typu databáze nevyužívají nebo s ním nejsou dostatečně seznámeni. A právě s nástupem relačních databází mnohonásobně vzrostl v 80. a 90. letech počet uživatelů databází.[1] K podpoře tohoto boomu bylo nutné přijít s RDBMS určeným pro osobní počítače. Netrvalo dlouho a společnosti začaly vyvíjet databázové systémy, které zpřístupnily databáze širším masám, usnadnily implementaci správy dat a umožnily klient/server komunikaci. Z těchto důvodů, jsem si vybral bakalářskou práci na téma návrh databáze, neboť chci využít znalostí, které jsem načerpal studiem předmětů Databáze a Tvorba webových stránek a aplikací na Vysoké škole ekonomické a získat další informace a zkušenosti ohledně návrhu databáze, manipulace s databázovými systémy a vývoje aplikací. Doufám, že nabyté zkušenosti při psaní této bakalářské práce následně využiji ve firemní praxi. Cílem této bakalářské práce je projít celým procesem návrhu databáze pro mateřskou školku, který zahrnuje analýzu aktuálního stavu nakládání s daty, včetně provádění rozhovorů za účelem zjištění požadavků na funkčnost navrhované databáze. Dále na základě získaných informací vytvořím konceptuální a fyzický model databáze, který následně zkonzultuji se zaměstnanci školky a poupravím. Diagramy budu modelovat v programu PowerDesigner 12.5 od společnosti Sybase, se kterým jsem se seznámil během studia na vysoké škole. Tento program mi umožní dle navrženého modelu vygenerovat i SQL kódy, které urychlí následnou tvorbu databáze. Navrženou databázi otestuji v jednom z vybraných databázových systémů, jehož instalaci a nastavení zde též popíši. Posledním úkolem bude vytvořit aplikaci, která bude s navrženou databází komunikovat a umožní zaměstnancům školky základní manipulaci s daty bez znalosti jazyka SQL. 7

Zvolená metodika návrhu designu databáze je kombinací zkušeností získaných z předmětů na Vysoké škole ekonomické a knihy Michaela J. Hernandéze Návrh databází.[5] Hlavním přínosem této práce by mělo být vytvoření takového databázového řešení, které usnadní zaměstnancům mateřské školky manipulaci s daty nutnými pro fungování této instituce. Rozsah bakalářské práce mi nedovoluje vytvořit kompletní řešení, a proto se zaměřím pouze na podporu hlavních procesů v mateřské školce. Rozhodující pro mě budou zejména požadavky vedení MŠ Pastelky. 8

2. ANALYZOVANÁ INSTITUCE 2.1. Základní informace Jedná se o typickou mateřskou školku se sídlem v Praze, která se zabývá výchovou předškolních dětí. Školka má 4 třídy, kde každou vyučují 2 učitelky. Děti jsou rozděleny podle věku a vyspělosti. Školka poskytuje výuku cizích jazyků, pořádá školky v přírodě a poskytuje i několik zájmových kroužků, např. plavání, keramiku. Dalšími zaměstnanci ve školce jsou uklízečky a kuchařky, které se starají o provoz jídelny, skladu a o úklid. Potencionálními uživateli databáze jsou ředitelka a zástupkyně školky, které mají na starost komunikaci se státní správou a personální zajištění chodu školky. Na druhé straně ekonomka a hospodářka školky mají na starost finanční a účetní aspekty ve školce jako je uchovávání faktur, informace o hmotném majetku a o stavu zásob na skladě. Tito zaměstnanci jsou klíčoví při zjišťování aktuálního stavu nakládání s daty ve školce a následných požadovaných funkčnostech aplikace a databáze. 2.2. Analýza aktuálního stavu uchovávání dat Analýzu jsem provedl na základě několika návštěv dané školky, kde mi byly poskytnuty veškeré materiály, které jsem si vyžádal. Provedl jsem též oddělené rozhovory s několika klíčovými zaměstnanci mateřské školky. Pokládal jsem otázky, které jsem si dopředu připravil a dbal jsem na to, aby měly otevřený konec, abych svou otázkou nijak neovlivnil odpověď dotazovaného. Ptal jsem se na způsob jejich práce, na údaje, které ke své práci potřebují, operace, které nejčastěji provádějí a dále na věci, které jim při práci s daty nevyhovují. Hlavním úkolem bylo vypátrat všechny budoucí entity, dle kterých budu modelovat konceptuální model databáze v nástroji PowerDesigner. Též mi bylo umožněno pořídit snímky výstupů z používaných programů, což mi velmi usnadnilo identifikovat tabulky a pole (atributy), které v navrhované databázi nesmí chybět. Na obrázku je uveden jeden z mnoha pořízených snímků a zapůjčených papírových vzorků databáze. 9

Obr. 1 Snímek stávající DB Ve školce panuje značná nejednotnost ve formátu ukládaných dat. Mnoho informací, zejména pak o rodičích je ukládáno pouze v listinné formě v kartotékách, což znemožňuje jejich efektivní vyhledávání. Tyto data se získávají vyplněním formuláře, který je pak pouze vložen do desek a uskladněn v archivu. Důležitější data jsou uchovávány na počítačích ředitelky, zástupkyně a ekonomky a to nejčastěji v tabulkových procesorech nebo již v datových souborech. Data jsou následně čteny z nejrůznějších softwarových produktů, mezi kterými není žádná vazba. Školka tak nakupuje a instaluje pro každý typ dat (pro každou entitu) jiný počítačový program, který umožňuje jejich čtení a manipulaci. Toto řešení ve výsledku zvyšuje pořizovací náklady a zároveň zvyšuje redundanci dat a nepodporuje žádané vazby mezi ukládanými daty. 2.3. Požadavky na databázi Hlavním cílem bude navržení jednotné databáze, která bude obsahovat tabulky vycházející ze stávajících databázových struktur. Dále by měla obsahovat nové tabulky pro uchovávání dat, které byly do této doby ukládány pouze v papírové podobě. Jedná se o informace o rodičích dětí, doplňující informace o zaměstnancích, komunikace se státní správou (podací deník) a probíhajících školeních zaměstnanců. Výsledná databáze by dále měla uchovávat komplexnější informace o všech osobách v rámci školky (zaměstnanci, děti, rodiče), údaje o majetku, fakturách a zásobách na skladě a v neposlední řadě doplňující údaje jako je seznam tříd a programy pro děti. 10

2.4. Požadavky na aplikaci Úkolem aplikace je jednoduchá administrace navržené databáze. Jde především o možnost zobrazování, vkládání a mazání dat v databázi bez znalosti jazyka SQL. Tato navržená aplikace poslouží i k otestování funkčnosti navržené databáze a nainstalovaného databázového systému. Uživatelské rozhraní aplikace by mělo být intuitivní a nenáročné. Jednoduchost ovládání a přehlednost je podmínkou. 2.5. Navrhnuté technologické řešení Na základě provedené analýzy a zjištěných požadavků jsem navrhl technologické řešení, známé pod zkratkou AMP. Jde o kombinaci serveru Apache, databázového systému MySQL a použití jazyka PHP pro aplikaci, tedy PHP skripty. Obr. 2 Technologické řešení Rozhodl jsem se zvolit relační typ databáze. Jedná se o momentálně nejpoužívanější typ, který odstraňuje nedokonalosti předešlé síťové a hierarchické struktury. Pro MŠ ho považuji za nejvhodnější. Následuje samotný proces návrhu. 11

3. NÁVRH RELAČNÍ DATABÁZE V této kapitole jsou rozebrány hlavní prvky relační databáze, jako jsou tabulky, pole, vazby a klíče, jejichž znalost je nezbytná pro konzistentní návrh databáze. Na konci každé podkapitoly je uveden konkrétní postup, který byl použit v rámci návrhu databáze pro MŠ Pastelka. Aby se předešlo budoucím problémům v databázi, je u každého z pojmů uveden také seznam doporučených vlastností, jež by jednotlivé pojmy měly splňovat. Nejprve uvedu stručnou charakteristiku relační databáze, následně rozeberu postup při jejím návrhu. 3.1. Relační databáze Relační databáze je implementace modelů reálného světa, vytvořeného podle pravidel relačního modelu. Relační model navrhnul a jeho pravidla publikoval Dr. E. F. Codd (pracovník firmy IBM) v r. 1970 v článku: "A relational model of data for large shared databanks." 1 Vychází z matematické teorie množin a predikátové logiky. Základním kamenem relačního modelu je databázová relace (množina) obsahující data. Hlavním prvkem relační databáze jsou pak databázové tabulky. Jejich sloupce se nazývají pole (atributy) a řádky jsou záznamy tabulky. Tabulka pak realizuje množinu kartézského součinu všech dat ve všech sloupcích, tedy relaci. V článku o relačním modelu byly mimo jiné specifikovány tyto ideje, jež uvádí nejvýznamnější rozdíl oproti předchozím datovým modelům[2][3]: Relační model odděluje data, která jsou chápana jako relace od jejich implementace. Pro práci s daty je k dispozici relační kalkul a algebra. Neboli matematické aparáty k popisu sémantiky relačních jazyků. Pro omezení redundance dat jsou k dispozici pojmy pro normalizaci relací. 2 Všechny hodnoty v databázi jsou skalární. 3 1 Dostupný z WWW: <http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf> 2 Podkapitola normalizace. 3 Obsahují jednu jedinou hodnotu, kterou může být číslo, řetězec. 12

3.2. Proces návrhu relační databáze Následující Business Process model popisuje můj postup při návrhu databáze. Namodelován byl v programu PowerDesigner. Při modelování procesu jsem se musel řídit jistou mírou abstrakce, neboť ve skutečnosti se jedná o činnost skládající se z mnoha podprocesů. Ve stručnosti by se dal rozložit na 3 části. Analýzu stávající databáze a vytvoření požadavků na novou. Identifikace všech entit, včetně polí a způsobu propojení. Následné modelování v CASE nástroji, volba datových typů a nastavení integrit. Obr. 3 Proces návrhu relační databáze 13

3.3. Tabulky Tabulky jsou základní strukturou v databázi, které reprezentují entity reálného světa. Entita reprezentovaná tabulkou může být buď objekt, nebo událost. V případě entity typu objekt se jedná o něco hmatatelného. Příkladem mohou být údaje o osobě či věci, jejichž vlastnosti se dají uložit jako data, která pak následně slouží jako zdroj informací. Příkladem entit, které popisují nějakou událost, která nastala v určitém čase, jsou například výsledky analýz, testů a nejrůznější průzkumy. Nehledě na výše zmíněné druhy entit, které tabulky reprezentují, rozlišujeme 4 typy tabulek na základě povahy ukládaných dat[5]: Datová tabulka, která ukládá dynamická data určená k získávání informací a reprezentuje entity důležité pro organizaci. Jedná se o nejčastější typ tabulky v prostředí relačních databází. Vazební tabulka, která slouží k vytvoření vazby mezi tabulkami spojenými relací M:N. Obsahuje kopie primárních klíčů z tabulek, které propojuje. Podmnožinová tabulka reprezentuje podřízenou entitu některé z datových tabulek. Obsahuje pole, která jsou podřízena vlastní entitě, a zároveň obsahuje pole z datové tabulky, které slouží k vytvoření vazby. Validační tabulka často označovaná jako číselník uchovává statická data, která slouží k implementaci integrity dat. Reprezentuje entity, jako například jména měst a jejich poštovní směrovací čísla. Při prvotním návrhu databáze byla většina tabulek datových, neboť ostatní typy vznikaly až na základě nastavování integrity nebo při řešení problémů s redundantními daty 4. O tvorbě vazebních tabulek se zmiňuji v kapitole věnující se vazbám a k nahlédnutí jsou ve fyzickém modelu databáze pro MŠ. 4 Redundantní data: Hodnota, která je opakovaná v poli jako výsledek spoluúčasti pole při spojování dvou tabulek, nebo jako výsledek anomálie některého pole či tabulky. [5] 14

3.3.1. Identifikace tabulek při návrhu databáze Proces nalezení tabulek začíná identifikováním všech entit v organizaci. Entitou bývají z pravidla podstatná jména, která se v prostředí dané firmy nejčastěji vyskytují nebo vyplynou z prováděných rozhovorů. V mém příkladě mateřské školky jimi jsou děti, učitelé, rodiče, třídy. Pokud navrhujeme databázi, jak se říká, na zelené louce, je potřeba identifikovat co největší počet podstatných jmen (budoucích entit), a to na základě vlastních domněnek o organizaci a z informací poskytnutých vedením. Já jsem již při návrhu vycházel z jednodušších databázových struktur, takže identifikace nebyla problém. Všechny stávající entity je potřeba překontrolovat, neboť pokud jen slepě použijeme starou databázi jako zdroj pro tu novou, nejspíše přeneseme všechny chyby a omezení staré databáze i do té nové. Výsledný seznam entit, na základě kterých se vytvoří tabulky je potřeba zkonzultovat s vedením a také s budoucími uživateli databáze. Důležitým nástrojem při návrhu a konzultaci tabulek s klientem je vytvoření seznamu takových tabulek 5, včetně jejich typu a stručného popisu. Můj seznam je ve formátu jméno tabulky, typ tabulky a stručný popis tabulky. Navrhované tabulky by měly splňovat několik vlastností[5]: Jedna tabulka reprezentuje jednu entitu, kterou může být věc nebo událost Obsahuje primární klíč, který identifikuje všechny hodnoty tabulky. Neobsahuje vícehodnotová, vypočítaná a vícesložková pole. Obsahuje nejmenší možné množství redundantních dat. 6 3.3.2. Normalizace Navrženou strukturu tabulek a všech jejich polí lze zkontrolovat i na základě procesu normalizace, kdy se navržená tabulka podrobí tzv. normálním formám. Obecně platí, že čím je tabulka ve vyšší normální formě, tím kvalitněji je navržena. 5 Viz. Přílohy 6 V relační databázi se v několika případech redundaci nevyhneme, proto je zmíněno nejmenší možné množství. 15

Většina navržených tabulek splňuje 3. normální formu, pro kterou je podmínkou nezávislost neklíčových dat mezi sebou. Tím je zajištěna postačující úroveň konzistence a zároveň nedochází k rozkladu tabulek do příliš složitých databázových struktur, které považuji za nevhodné pro databázi MŠ. Důvodem byla i stávající databáze, ve které se tabulky nacházely mnohdy v nižší normální formě, a přechod k příliš dekomponovaným tabulkám by jistě zaměstnancům školky nevyhovoval. Obr. 4 Nedodržení NF Často je výhodnější použít nižší normální formu z důvodu menší zátěže pro server a přehlednější struktury celé databáze. Na obrázku tabulky FAKTURA je prezentováno nerespektování 3NF, kdy by údaje ohledně dodavatele a symbolů měly být v nové tabulce. To jsem neudělal z toho důvodu, že jsou ve školce již zvyklí na tuto strukturu tabulky FAKTURA a nemají potřebu evidovat další informace o dodavatelích. 3.4. Pole Jedná se o nejmenší strukturu v databázi, která se též označuje jako atribut. Reprezentuje určitou vlastnost entity, do které patří. Jsou to struktury, které slouží k uchovávání dat. Pokud je databáze správně navržena, tak pole ukládá pouze jednu hodnotu a název pole přesně identifikuje povahu této hodnoty. Pokud je název pole například jméno zaměstnance, je hned jasná povaha hodnoty tohoto pole a uživateli databáze nedělá problém zadat správnou hodnotu. To vše usnadňuje následné vyhledávání, třídění a veškeré ostatní úkony prováděné nad daty v databázi. Veškeré vlastnosti polí lze zařadit do 3 kategorií. Jedná se o obecné, logické a fyzické vlastnosti pole. Každé z těchto kriterií hraje svou roli v jiné fázi procesu návrhu databáze. 16

3.4.1. Obecné vlastnosti polí Mezi obecné vlastnosti patří název daného pole, ale i například jeho popis, který jasně definuje, co se do pole ukládá za hodnoty a jaké nabývají povahy. Obzvláště popis pole je velmi důležitý při komunikaci se zákazníkem, který by z popisu měl ihned pochopit, jaká data jsou zde ukládána. Já jsem v případě vytváření názvů polí vycházel co nejvíc ze stávající databáze a snažil se pro pojmenování nepoužít více jak dvě slova. Zde jsou uvedena doporučení tykající se pojmenovávání polí (atributů) [5]: Jedinečná jména srozumitelná všem v organizaci. Jasně charakterizuje obsah ukládaných dat. Co nejkratší název, ale vyvarovat se zkratkám a akronymům. Používat jednotné číslo. 3.4.2. Fyzické vlastnosti polí Tato kategorie obsahuje strukturální vlastnosti pole. Nelze přesně určit, které aspekty pole spadají pod fyzické vlastnosti, neboť se to liší v implementacích jednotlivých databázových systémů. Správný návrh těchto vlastností při procesu návrhu databáze je nesmírně důležitý vzhledem k výsledné konzistenci dat. Neboť sem spadají vlastnosti, jako jsou: Datový typ pole Délka pole Formát, povolené znaky O datových typech se zmiňuji v samotné kapitole 3.7.1. Další důležitou vlastností pole je délka. Ta udává celkový počet povolených znaků v rámci pole, čímž zabraňuje, aby databáze při nevhodné manipulaci zabírala enormní místo na discích a klesal výkon databáze. Délka pole je často závislá na zvoleném datovém typu, a tak zvolený databázový systém nemusí uživateli tuto volbu nabízet k dispozici. 17

Mezi vlastnosti dále patří povolené znaky a formát hodnoty pole. Jejich správné nadefinování zvyšuje stupeň integrity na úrovni pole, o které se zmiňuji dále v práci. Dále zabraňuje uživatelům databáze, aby ukládali nesmyslné a nevhodné hodnoty, které by celkovou integritu databáze snižovaly. Všechny fyzické vlastnosti polí jdou dnes jednoduše navrhnout v modelovacích programech, ať už se jedná o datový typ, limitní délku nebo povolené znaky. Dané vlastnosti jsou k nahlédnutí v podkapitolách věnovaným konceptuálnímu modelu a datovým typům. 3.4.3. Logické vlastnosti polí Kategorie se zabývá převážně vlastnostmi hodnot polí. Zda je ukládaná hodnota unikátní, nebo se dokonce jedná o primární klíč tabulky a je tedy unikátnost přímo podmínkou. Nebo jestli na druhou stranu může hodnota pole nabývat prázdných hodnot a nemusí být tedy vůbec vyplněna, případně je zobrazená hodnota null. Stejně tak sem patří povolený rozsah hodnot a tím nemám na mysli počet znaků. Rozsahem se zamýšlí předem definované hodnoty, kterých dané pole podle návrhu musí nabývat. Pokud například při návrhu databáze nastavím rozsah hodnot na vytvořenou množinu (modrá, červená, zelená), tak dané pole může nabývat pouze jednu z těchto tří hodnot a pokud se uživatel pokusí vložit jinou hodnotu, tak mu databázový systém nevyhoví. 3.4.4. Definice polí při návrhu databáze Při návrhu polí bychom se měli v první řadě vyvarovat vytvoření jakéhokoliv z následujících polí, neboť ve velké míře ovlivňují výslednou celkovou integritu databáze. Jedná se o vícesložkové, vícehodnotové a vypočítané pole. Příkladem vícesložkového pole může být celý název zaměstnance. Jednalo by se o pole, které by jako hodnotu ukládalo jednak jméno, ale i příjmení namísto použití dvou polí pro jednotlivé hodnoty. Vícehodnotové pole podobně jako předešlé obsahuje několik hodnot v rámci jednoho pole, ale nemusí se jednat o hodnoty, které spolu nějak souvisí, jako tomu je u jména. Příkladem může být pole, které obsahuje výčet všech cizích jazyků, kterými se zaměstnanec dorozumí. 18

Poslednímu ze zmíněných polí bychom se při návrhu měli vyvarovat z toho důvodu, že se k výpočtu jeho hodnot používá jazyka SQL a je tedy zbytečné provádět výpočty manuálně a taková pole vůbec definovat. Vícesložkových polí se zbavíme tak, že pro jednotlivé složky daného pole vytvoříme nové pole. V mém případě je adresa všech osob ve školce rozdělena na ulici, město a směrovací číslo. Správně bych měl od názvu ulice separovat i číslo bytu, ale to jsem považoval již za zbytečné. Vícehodnotových polí se ve stávajících databázích zbavuje obtížněji. Jednou z možností je vytvoření úplně nové tabulky, se kterou je původní tabulka ve vztahu. Taková tabulka se nazývá vazební a je výsledkem vztahu M:N mezi dvěma tabulkami. Při samotném návrhu databáze se vytvoření takových polí vyhneme, pokud se budeme řídit doporučenými vlastnostmi ideálního pole podle [5]: Obsahuje jen jednu hodnotu Není možné jej dekomponovat do menších částí Je unikátní v rámci celé databázové struktury Reprezentuje charakter tabulky Neobsahuje vypočítaná data Ačkoliv jsou v tomto případě veškeré vlastnosti polí nastavovány v modelovacím programu, který pak následně vygeneruje SQL skript, stejně je nezbytné si promyslet všechny pole ještě před samotným modelováním a zkonzultovat je s klientem. V případě školky jsem veškeré mnou navržené tabulky, pole a vazby dopředu konzultoval s vedením školky, než jsem se pustil do finálního návrhu výsledné databáze, kde už jsem pouze dolaďoval veškerá integritní omezení. 3.5. Vztahy Právě vztahy jsou tou jedinečnou vlastností relační databáze, které ji odlišují od předešlých typů databází. Umožňují uživateli vytvářet pohledy na několik tabulek najednou a jsou též nezbytné pro zajištění integrity dat, protože napomáhají redukovat nadbytečná data a eliminovat data duplicitní.[5] 19

Ve stručnosti se pojmem vztah myslí propojení záznamů mezi dvěma tabulkami. Zřizuje se prostřednictvím množiny primárních a cizích klíčů, nebo v ojedinělých případech za použití podmnožinové vazební tabulky. Každý vztah je možno definovat na základě 3 vlastností. Typem vztahu, který existuje mezi tabulkami. Dále pak způsobem a stupněm účasti tabulky ve vztahu. 3.5.1. Typ vztahu Definujeme 4 typy vztahů (často označované jako kardinality) mezi tabulkami: Vztah 1:1 Vztah 1:N Vztah M:N Samoreferenční vztah [5] Vztahem 1:1 definujeme takový typ vztahu, ve kterém je záznam v první tabulce ve vztahu pouze s jedním záznamem v druhé tabulce a naopak. Nejčastěji se jedná o tabulky, kde jedna funguje jako rodič a druhá jako potomek. Obr. 5 Vztah 1:1 Vztah 1:N existuje mezi dvěma tabulkami v případě, že záznam z jedné tabulky odkazuje na více záznamů v druhé tabulce a všechny tyto záznamy odkazují pouze na jeden záznam v první tabulce. Jedná se o nejčastější typ vztahu v relačních databázích. Klíčovým je i z pohledu datové integrity, protože napomáhá minimalizovat nadbytečná data. Výstupem takového vztahu je vytvoření cizího klíče v tabulce s N prvky odkazujících na primární klíč v protější tabulce. Obr. 6 Vztah 1:N 20

Vztah M:N je nejsložitější, neboť záznamy z obou tabulek jsou ve vztahu s libovolným počtem záznamů z protější tabulky. Tento typ vztahu se následně řeší za pomoci vazební tabulky, která tento vztah rozdělí na dva vztahy typu 1:N. Vazební tabulka poté obsahuje kopie primárních klíčů z obou tabulek a dohromady tvoří složený primární klíč. Zvlášť pak fungují jako cizí klíče odkazující na primární klíče v tabulkách, mezi kterými byla vytvořena vazební tabulka. Obr. 7 Původní vztah M:N Obr. 8 Rozložení vztahu M:N Samoreferenční typ vztahu nespojuje dvě tabulky, neboť spojuje záznamy z téže tabulky. Tabulka je sama se sebou svázána tímto typem vztahu, pokud je záznam ve vztahu (1:1, 1:N, M:N) s jiným záznamem téže tabulky. 3.5.2. Způsob a stupeň účasti Účast tabulky ve vztahu není povinná, proto definujeme dva typy účasti, též nazývány jako parcialita vztahu: Povinná účast Volitelná účast Tabulka má povinnou účast ve vztahu, pokud před vložením záznamu musí být v druhé tabulce alespoň jeden záznam, se kterým vytvoří vazbu. 21

V rámci modelovacího programu PowerDesigner je tato vlastnost řešena pomocí upravení základních 3 typů vztahů. Výsledkem jsou pak další kombinace vztahů, které definují způsob účasti jako volitelný, pokud na straně vybraného záznamu začíná interval, určující počet odkazovaných záznamů, nulou. Lze si tedy u každého z dvou záznamů vytvářejících vazbu vybrat mezi kardinalitami (0,1), (1,1), (0,N) a (1,N). Výsledná vazba je pak vypočítána na základě kardinalit obou záznamů. Obr. 9 Nastavování způsobu účasti v PD Stupeň účasti definuje minimální a maximální počet záznamů tabulky, které mohou být ve vztahu se záznamem z tabulky druhé. Stupně účasti v rámci návrhu databáze jsou spíše doplňující. Při špatném nastavení by znemožňovali například přidání dalšího záznamu, jež by byl ve vztahu, neboť by už byl překročen maximální povolený počet odkazujících záznamů na daný záznam z druhé tabulky. Pro databázi mateřské školky jsem nedefinoval u žádných vztahů stupeň účasti, ačkoliv každou třídu smějí vyučovat nanejvýš dvě učitelky. 22

3.5.3. Vytváření vztahů při návrhu databáze Pokud jsme se při návrhu databáze dostali do fáze, kdy vytváříme vztahy mezi tabulkami, je důležité si dát pozor na několik věcí, neboť špatně navržené vztahy v modelech následně povedou k větším problémům s integritou ve vytvořené databázi. Při určování typu vztahu je důležité si položit správně formulované otázky, díky kterým lze typ zjistit. Pokud mám například tabulku Děti a tabulku Třídy, můžou otázky znít následovně. Do kolika tříd může chodit jedno dítě? Kolik dětí může navštěvovat jednu třídu? Z takto položených otázek vyplívá, že typ vztahu bude N:1, neboť dítě může chodit pouze do jedné třídy, ale do třídy dochází hned několik dětí. Poté, co máme určen typ vztahu, je důležité určit ještě způsob účasti tabulky Děti. Pokud každé dítě evidované v databázi musí chodit do nějaké třídy, pak se jedná o typ vztahu (1,N):1 a je tedy způsob účasti povinný, ale pokud v databázi potřebuji evidovat i děti, co už do žádné třídy nechodí, poté musím způsob účasti označit jako volitelný a vztah nastavit jako (0,N):1. Stejně tak je potřeba určit povinnost účasti záznamu ve vztahu pro tabulku třídy, kde je na výběr mezi (0,1) a (1,1). 3.6. Klíče Klíče v relačních databázích vykonávají hned několik funkcí. Zabezpečují, že každý záznam v tabulce je přesně identifikován. Napomáhají stanovit a dodržovat různé druhy integrit a hlavně slouží jako prostředek pro vytváření vztahů mezi tabulkami. Rozlišujeme dva základní typy klíče: Primární klíč (PK) je pole, nebo soustava polí, jejichž hodnoty tvoří jednoznačnou identifikaci řádků relace. Cizí klíč (FK), jež se odkazuje na primární klíč v druhé tabulce a vytváří tak spojení (vazbu) mezi tabulkami. Při návrhu pole, které má zastat funkci primárního klíče musíme dodržovat několik pravidel, které zabezpečí, že primární klíč bude identifikovat hodnotu všech ostatních polí a zabezpečovat integritu na úrovni tabulky. Doporučené vlastnosti primárního klíče podle[5]: 23

Nesmí to být vícesložkové pole. Musí obsahovat jedinečné hodnoty. Hodnota musí být v rámci celé tabulky jedinečná. Skládá se z nejmenšího možného počtu polí. Nesmí obsahovat hodnoty null. Hodnota PK musí jednoznačně identifikovat hodnoty všech polí dané tabulky. Poslední zmíněná vlastnost nám též umožňuje identifikovat nadbytečná pole v tabulce, na která přijdeme, pokud si pro každé další pole v tabulce položíme otázku, zda je toto pole jednoznačně identifikováno primárním klíčem. Pokud tomu tak není, je potřeba se zamyslet, zda je vhodné mít takové pole v tabulce a není-li lepší ho vyřadit, či přemístit do jiné tabulky.[5] Při návrhu databáze jsem u některých tabulek nebyl schopen vybrat vhodné pole pro primární klíč, a proto jsem vytvořil umělé pole (identifikační číslo), které tyto vlastnosti splní. Ke vkládání hodnot do těchto polí se nejčastěji používají sekvence 7 (v případě DBMS Oracle) nebo další funkce, které automaticky vkládají číselné hodnoty. Na druhé straně cizí klíče (FK) se při konceptuálním návrhu databáze nenavrhují. Ty vznikají až na základě vytvořených vazeb mezi tabulkami, kde primární klíč jedné tabulky odkazuje na cizí klíč tabulky druhé a tím zajišťuje jejich vazbu. 3.7. Datové typy Ačkoliv je datový typ fyzickou vlastností databázového pole, o kterém jsem se již zmínil, přesto jsem pro datové typy vyhradil vlastní podkapitolu, neboť jejich správné zvolení považuji za velmi důležitý aspekt v rámci návrhu designu databáze, protože zajišťuje konzistentnost definice polí v rámci celé databáze. Z důvodu odlišné implementace datových typů v prostředí jednotlivých databázových systému, budu nadále zmiňovat datové typy používané v databázovém systému MySQL, který jsem si vybral pro použití na příkladu MŠ Pastelka, a o kterém se zmiňuji v kapitole 4. 7 Sekvence je objektem aplikace sloužícím ke generování posloupnosti celočíselných hodnot (v rozsahu 64 bitů), zejména unikátních klíčů. [7] 24

Datový typ popisuje povahu dat, které pole ukládá. Určuje tedy, jak bude sloupec v tabulce interpretovat svůj obsah. V MySQL definujeme tři skupiny datových typů podobně jako u většiny databázových systémů.[4] 3.7.1. Číselné datové typy MySQL umí pracovat jak s celými čísly, tak i s čísly, které mají desetinnou čárku. Proto je důležité si při návrhu databáze uvědomit, zda v daném sloupci budeme pracovat s celými čísly, nebo budeme požadovat čísla desetinná. Celočíselné datové typy se často používají pro ukládání identifikačních čísel, které tvoří primární klíče tabulek, a jsou přiřazovány sekvenčně nebo v případě MySQL funkcí AUTO_INCREMENT[4]. Název Použití Rozsah čísel Místo v paměti SMALLINT Malá celá čísla. 32768 až 32767 nebo 0 až 65535 (16 bitů) 2 bajty INT Středně velká celá čísla. 2147483648 až 2147483647 nebo 0 až 4294967295 (32 bitů) 4 bajty BIGINT Velká celá čísla. -9223372036854775808 až 9223372036854775807 (64 bitů) 8 bajtů FLOAT Plovoucí desetinná čárka. ±1,175494351E 38; ±3,402823466E+38 4 bajty Velká čísla v pohyblivé DOUBLE řádové čárce; větší přesnost než u FLOAT. Velká čísla v pohyblivé DECIMAL řádové čárce ukládané jako řetězec Tab. 1 Číselné datové typy [4][5] ±2,2250738585072014E-308; ±1,17976931348623157E+308 ±2,2250738585072014E-308; ±1,17976931348623157E+308 8 bajtů 10 bajtů + 2 (čárka, znaménko) 3.7.2. Datové typy pro datum a čas Slouží k uchovávání dat, časů nebo jejich kombinací. Existuje i speciální typ časové značky, který si do databáze vždy ukládá aktuální datum a čas, kdy byl daný řádek aktualizován. K nahlédnutí je v následující tabulce pod názvem TIMESTAMP.[4] Já jsem pro většinu polí, které mají uchovávat časový údaj, použil datový typ DATE, neboť nebylo zapotřebí uchovávat i konkrétní čas. Pouze v případě kroužků je použit typ TIME, protože je zapotřebí evidovat konkrétní rozvrh a čas, kdy kroužek začíná a končí. Časová značka je použita v tabulce s materiálem na skladě, kdy je potřeba evidovat, ke kterému datu je množství potravin v databázi aktuální. 25

Název Použití Rozsah Nulová hodnota Místo v paměti DATE TIME Datum ve formátu 'CCYY-MM-DD' Čas ve formátu 'hh:mm:ss' Datum a DATETIME čas ve formátu 'CCYY- MM-DD hh:mm:ss' Časová TIMESTAMP značka ve formátu DATETIME. Tab. 2 Datové typy pro datum a čas [4][5] 3.7.3. Řetězcové datové typy 1000-01-01 až 9999-12-31-838:59.59 až 838:59:59 1000-01-01 00:00:00 až 9999-12-31 23:59:59 19700101000000 až do roku 2037 0000-00-00 3 bajty 00:00:00 3 bajty 0000-00-00 00:00:00 8 bajtů 00000000000000 4 bajty Tato skupina datových typů se používá převážně pro ukládání textu, ale je možné do nich ukládat i čísla. Všechny mají stanovenou maximální délku řetězce a při návrhu databáze je důležité si tuto vlastnost pohlídat, neboť by následně mohly nastat problémy s konzistencí.[4] Název Použití Povolená délka Místo v paměti CHAR Řetězec pevně dané délky. 0 až 255 znaků Co znak to 1 bajt VARCHAR TEXT Řetězec měnící se délky. Při ukládání do DB se odstraňují koncové mezery. Textový typ, který se na rozdíl od CHAR a VARCHAR ukládá do jednotlivých souborů. 0 až 255 znaků 0 až 65535 bajtů BLOB Binárně citlivá obdoba TEXT. 0 až 65535 bajtů Výčet hodnot; hodnoty ze ENUM sloupce mohou mít přiřazeny právě jednu hodnotu ze seznamu Tab. 3 Řetězcové datové typy [4][5] Co znak to 1 bajt + 1 bajt pro zaznamenání délky Co znak to 1 bajt + 2 bajty pro zaznamenání délky Co znak to 1 bajt + 2 bajty pro zaznamenání délky 1 bajt pro výčty s členy 1 až 255; 2 bajty pro výčty s členy 256 až 65535 Obzvláště poslední typ v tabulce velmi dobře posloužil při návrhu databáze, neboť mi pomohl vyřešit problém, kdy DBMS MySQL ignoruje funkci CHECK v definici tabulky. Pro pole, které mají mít výčet specifických hodnot, se jednoduše tyto hodnoty vloží do množiny přípustných. 26

3.7.4. Použité atributy datových typů U každého z datových typů lze nastavit atributy, které jim přidávají další vlastnosti. Konkrétní atribut nelze použít pro všechny datové typy. Proto uvádím pouze atributy, kterých jsem využil pro navrženou databázi. AUTO_INCREMENT Díky tomuto atributu, který se přiřazuje k číselným datovým typům, lze zautomatizovat proces přidělování identifikačních čísel. Ke každému novému záznamu je automaticky přidělena do určitého sloupce následující celočíselná hodnota v pořadí. V navrhované databázi jsem tento atribut použil u všech identifikačních čísel. Při vkládání hodnoty null či 0 do pole s tímto atributem se automaticky přiřadí počáteční hodnota nebo hodnota o jedno vyšší než ta u minulého záznamu. NOT NULL Tímto atributem se zabraňuje do konkrétního pole vložení hodnoty null, případně nevyplnění tohoto pole. To nutí uživatele vkládat pouze relevantní a úplné údaje. PRIMARY KEY Jak již napovídá název, jedná se o atribut, který definuje primární klíč tabulky. Tím se zaručuje jedinečnost hodnot. Polím s atributem PRIMARY KEY se často přiřazuje i atribut AUTO_INCREMENT a vzniká tak jednoznačný identifikátor. 3.8. Integritní omezení V terminologii relačních databází se rozdělují integritní omezení na entitní, doménové a referenční. Já však v této práci popisuji omezení z pohledu vycházejícího z názvu předešlých kapitol a místo těchto názvů tedy uvádím integritu tabulek, polí a vztahů, což je vlastně to samé. V následujících podkapitolách zmiňuji doplňující omezení a nastavení databáze, která nejsou patrná z konceptuálního a fyzického modelu. U každé z integrit je uveden pouze jeden příklad vycházející z návrhu databáze pro MŠ, ačkoliv je v navrhované databázi integritních omezení více. 27

3.8.1. Integrita tabulek V první řadě se kontrola integrity tabulek neboli entitní omezení kontroluje na základě vlastností ideální tabulky, které zmiňuji v kapitole, která se zabývala specifikací tabulek. Důležité je prověřit i primární klíč tabulky, zda též splňuje doporučené vlastnosti a identifikuje všechny hodnoty polí v dané tabulce. Jinak řečeno, každý řádek v tabulce musí obsahovat primární klíč, jenž bude nabývat unikátních hodnot a bude tak rozlišovat jednotlivé záznamy (řádky).[3] 3.8.2. Integrita polí Rovněž nazývaná jako doménová integrita se zabývá ideálními vlastnostmi polí. Integritu polí lze též zkontrolovat na základě procesu normalizace, kdy tabulku podrobíme normálním formám, jež jsou uvedeny v podkapitole normalizace. Důležité je pro jednotlivá pole při návrhu nastavit vhodný datový typ, který umožňuje ukládat data v požadovaném formátu. Výčet možných datových typů je k nahlédnutí v kapitole o datových typech. Použité datové typy pro MŠ jsou zobrazeny v konceptuálním modelu. Ke kontrole doménové integrity v rámci SQL kódů se používá funkce CHECK při tvorbě tabulky, která zajišťuje, že vkládané hodnoty do polí jsou správného formátu, či případně spadají do povolené množiny hodnot. Avšak v rámci databázového systému MySQL není funkce CHECK podporována, a tak nezbývá nic jiného než použít při složitější definici doménové integrity Triggery 8 nebo vhodně nastavit datový typ pole. [10] 3.8.3. Integrita vztahů K aplikování referenčních omezení dochází v případě, kdy manipulujeme se záznamy, které jsou ve vztahu se záznamy s jiné tabulky. K bezchybnému nastavení integrity na úrovni vztahů je tedy zapotřebí správně nastavit typy vztahů a způsob jejich účasti. Momentálně jsou nejpoužívanější 3 druhy omezení, které se používají při manipulaci se záznamy, které odkazují na záznamy z jiné tabulky. 8 TRIGGER - Podmínka definující v databázi činnosti, které se mají provést v případě definované události nad databázovou tabulkou. Definovanou událostí může být například vložení nebo smazání dat.[4] 28

Restriktivní omezení Pokud při pokusu o smazání záznamu z rodičovské tabulky dojde k zjištění, že odkazuje na záznam v tabulce potomka, tak RDBMS odmítne provést tuto akci. Nejprve je nutné smazat záznam z tabulky potomka a poté je možno smazat záznam z rodičovské tabulky. Kaskádové omezení V tomto případě proběhne při smazání záznamu v rodičovské tabulce zároveň k výmazu záznamu z tabulky potomka. Smazání záznamu v tabulce potomka dojde automaticky. Set Null V případě, že dojde ke smazání záznamu z rodičovské tabulky, nastaví se hodnota cizího klíče v podřízené tabulce na null. To lze pouze v případě, že tento cizí klíč může nabývat prázdné hodnoty. Veškerou integritu vztahů jsem nastavoval v rámci fyzického modelu databáze v programu PowerDesigner. Je důležité si integritu vztahů rozmyslet dopředu, neboť při špatném nastavení by mohlo následně dojít k fatálním následkům. Například při nastavení všech vztahů na CASCADE (kaskádové omezení) by po smazání některého záznamu mohlo dojít k výmazu mnoha jiných důležitých záznamů, což by vedlo k neúmyslné ztrátě dat. 3.8.4. Business pravidla Jedná se o formulace, které určují dodatečná omezení na určité součásti databáze. Tyto pravidla se vytvářejí na základě způsobu, jakým daná organizace pracuje. Rozlišují se 2 typy takových pravidel. První z nich jsou orientovaná čistě na databázi, druhá jsou orientovaná aplikačně.[5] Databázově orientovaná pravidla určují omezení, které lze zavést v rámci návrhu databáze. Příkladem takového business pravidla může být nastavení rozsahu hodnot některého pole na určitou množinu povolených. Například do pole s funkcí zaměstnance lze zadat hodnoty z množiny (kuchařka, uklízečka, učitelka, ředitelka). Aplikačně orientovaná pravidla určují omezení, která nejsou nastavena v rámci procesu návrhu databáze, ale nastavují se až při návrhu databázové aplikace, která je též předmětem této bakalářské práce. 29

3.9. Konceptuální modelování Poté, co jsem zkonzultoval seznam tabulek a všech jeho polí s vedením, je na řadě modelování samotné databáze a tedy možnost využití předešlých teoretických poznatků ohledně relačních databází. K samotnému modelování je vhodné použít některý z dostupných CASE nástrojů. Zde je použit a popsán modelovací nástroj PowerDesigner. Konceptuální model je databázový model, který umožňuje popsat objekty v databázi a vztahy mezi nimi. Výhodou konceptuálního modelu je jeho implementační nezávislost, tudíž by se v této fázi návrhu databáze nemělo přihlížet na budoucí zvolený databázový systém, případně aplikace.[5] V průběhu konceptuálního modelování se vybírají vhodné datové typy pro jednotlivá pole, vytváří se vazby mezi tabulkami včetně způsobu účasti a nastavují se primární klíče jednotlivých tabulek. Cizí klíče, jak již bylo zmíněno v kapitole jim určené, se nemodelují, neboť vznikají na základě nadefinovaných vazeb. V konceptuálním modelu se též uplatňují entitní a doménová integritní omezení. 3.9.1. Popis konceptuálního modelu V záhlaví každé tabulky je její název. První sloupec obsahuje názvy všech polí. V druhém sloupci (pouze první řádek) je hodnotou <pi> definován primární klíč tabulky. Následují zkratky používaných datových typů pro jednotlivé atributy. Značka <M> v posledním sloupci označuje atribut jako povinný, nemůže tedy nabývat hodnoty null. Každá z vazeb mezi tabulkami má svůj název a symboliku. Za zmínku stojí tabulka DENIK, která od prvního pohledu nemusí naznačovat svůj účel. Jak je zmíněno v požadavcích na budoucí databázi, jedná se o tabulku, která uchovává komunikaci se státní správou neboli podací deník, který musí všechny školky ze zákona spravovat. Konkrétní popis veškerých tabulek a jejich typ je k nahlédnutí v příloze 8.8. Obr. 10 Podací deník 30

Obr. 11 Konceptuální model Všechny osoby v rámci školky mají stejné základní údaje (jméno, příjmení, adresu), a proto jsem využil dědičnosti (specializace) a vytvořil rodičovskou tabulku, do které jsem vložil všechny společné údaje a vytvořil identifikační číslo. Jelikož rodičovská tabulka není ve vztahu s žádnou jinou tabulkou, je typ specializace nastaven pouze na GENERATE CHILDREN. Při generování fyzického modelu tak dojde k zániku tabulky OSOBA a k přenesení všech údajů z této tabulky do podmnožinových. 31

Obr. 12 Využití dědičnosti V případě, kdy by tabulka OSOBA byla zároveň ve vztahu s jinou tabulkou, bylo by vhodné generovat i tuto tabulku a dědit pouze primární klíče. K zobrazení kompletních údajů o osobách by poté posloužily pohledy. Speciální druh vztahu byl použit i mezi tabulkou FAKTURA a POLOZKA (faktury), kde jsou veškeré položky identifikovány číslem, ale zároveň dědí primární klíč z tabulky FAKTURA, což všechny položky propojuje s konkrétní vystavenou fakturou. Tím je vytvořena závislost jedné entity na druhé, neboť položky nemohou existovat bez faktur. Obr. 13 Závislost na 2 PK 3.10. Fyzický model Fyzický model databáze se získá jednoduchým vygenerováním z konceptuálního modelu, kdy všechny hlavní kroky provede CASE nástroj automaticky, avšak je nezbytné na modelu provést další úpravy, které jsou zmíněny dále. Tento model je již ovlivněn databázovým systémem, který je zapotřebí vybrat ve fázi generování. Ten je nutno dopředu rozmyslet, neboť databázové systémy často podporují rozlišné funkce. V mém případě je použit DBMS MYSQL 5.0, proto SQL skripty neobsahují CHECK konstrukce a indexy. Tento problém jsem nucen řešit dodatečnými úpravami kódů. 32

Při vygenerování modelu dojde automaticky k vytvoření cizích klíčů a vazebních tabulek na základě nadefinovaných vztahů v konceptuálním modelu. Ačkoliv se jedná o automatický proces, neznamená to, že tím všechna práce končí. Často je například nezbytné přejmenování cizích klíčů a vazebních tabulek, jež mají nevhodný název. Nejdůležitějším krokem, ke kterému nedochází automaticky, je nastavení integrit veškerých vztahů, neboť výchozí volba RESTRICT není ve všech případech vhodná, protože mnohdy zpomaluje a znesnadňuje manipulaci s databází. V případě vazeb směřujících k vazebním tabulkám jsem zvolil typ CASCADE a zautomatizoval tak manipulaci s daty ve vazebních tabulkách, při změnách vykonaných v tabulkách, které propojuje. Obr. 14 Nastavení referenční integrity V případě tabulek s nepovinnou účastí ve vztahu jsem volil omezení SET NULL, čímž je automaticky nastavena tato hodnota, pokud dojde ke smazání odkazovaného záznamu. Při smazání některého z kroužků tak automaticky dojde k nastavení cizího klíče na prázdnou hodnotu u všech dětí, které jej navštěvovaly. To na jednu stranu zrychluje manipulaci, ale na druhou zvyšuje riziko ztráty údajů, pokud se kroužek smaže nechtěně. Na fyzickém modelu je již patrný vznik cizích klíčů označených značkou <fk>, která je v některých tabulkách hned několikrát. Označení <pk,fk> se týká primárních klíčů, které jsou zároveň cizími klíči. Ty vznikají v případech dědičnosti, řešení vztahů M:N a závislosti jedné tabulky na druhé. 33

Obr. 15 Fyzický model DB 34

Z modelu je patrné vytvoření dvou nových tabulek, které realizují vztahy M:N. Jedná se o tabulky DOCHAZI a ZASTUPUJE, které obsahují pouze zděděné primární klíče z rodičovských tabulek. V upraveném fyzickém modelu poté v CASE nástroji stačí najít volbu, která automaticky vygeneruje SQL kód. Ten je popsán v následující podkapitole a celý je k nahlédnutí v přílohách. 3.11. Vygenerovaný SQL skript 3.11.1. Popis skriptu Výsledný SQL skript vytvořený na základě notace MYSQL 5.0 obsahuje příkazy na vytvoření tabulek včetně primárních klíčů, nastavení vztahů a následně příkazy pro smazání tabulek. Nejprve je tedy popsán SQL kód vytvářející tabulky. Z kódu je patrný název vytvářené tabulky a polí, kde u každého pole je dále zmíněn datový typ (INT, CHAR, VARCHAR ). Dále je určen primární klíč ID_OS a též je pro některá pole specifikováno, jakých musí nabývat hodnot. /* Table: ZASTUPCE */ CREATE TABLE ZASTUPCE ( ID_OS INT NOT NULL, JMENO VARCHAR(30) NOT NULL, PRIJMENI VARCHAR(30) NOT NULL, MESTO VARCHAR(30) NOT NULL, ULICE VARCHAR(40) NOT NULL, PSC CHAR(5) NOT NULL, TELEFON CHAR(9) NOT NULL, NAROZEN DATE, ZAST_ZAMESTNANI VARCHAR(30), TYP ENUM('otec', 'matka', 'jiné') NOT NULL, PRIMARY KEY (ID_OS) ); Pro tvorbu vztahů je použit příkaz začínající ALTER TABLE, jehož součástí je i definování referenční integrity v případě mazání a upravování záznamů v tabulkách. Dále je součástí kódu název cizího klíče jedné tabulky, který odkazuje na primární klíč druhé tabulky, a dochází tedy k propojení tabulek a ke vzniku vazby. 35

ALTER TABLE DITE ADD CONSTRAINT FK_VYUCOVANO FOREIGN KEY (OZNACENI) REFERENCES TRIDA (OZNACENI) ON DELETE RESTRICT ON UPDATE RESTRICT; ALTER TABLE DOCHAZI ADD CONSTRAINT FK_DOCHAZISKOL FOREIGN KEY (SKOLENI_NAZEV) REFERENCES SKOLENI (SKOLENI_NAZEV) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE DITE ADD CONSTRAINT FK_NAVSTEVUJE FOREIGN KEY (KROUZEK_NAZEV) REFERENCES KROUZEK (KROUZEK_NAZEV) ON DELETE SET NULL ON UPDATE RESTRICT; Pro smazání vytvořených databázových struktur slouží příkaz DROP TABLE. DROP TABLE IF EXISTS DITE; Administrační SQL příkazy jsou k nahlédnutí v přílohách 8.4 a 8.5. 3.11.2. Úpravy skriptu Nepodařilo se mi najít v CASE nástroji přidělování atributu AUTO_INCREMENT, proto jsem jej musel ke všem identifikačním číslům přidělit ručně podle manuálu [9]. CREATE TABLE DITE ( ID_OS INT NOT NULL, -> ID_OS INT NOT NULL AUTO_INCREMENT, Dále jsem musel pro jednotlivá identifikační čísla s tímto atributem nastavit počáteční hodnoty, neboť všechny začínají od jedné. ALTER TABLE DITE AUTO_INCREMENT = 2000; ALTER TABLE FAKTURA AUTO_INCREMENT = 10000; K vyřešení složitější doménové integrity jsem byl nucen pro některá pole změnit ve fyzickém modelu datový typ na ENUM a obejít tak neschopnost DBMS MYSQL aplikovat funkci CHECK. Tudíž v konceptuálním modelu mají nastavený jiný datový typ (CHAR, VARCHAR), než který je následně použit. Takto nadefinovaná pole zabraňují uživatelům vkládat libovolné hodnoty a zvyšují relevantnost ukládaných dat. 36

POHLAVI ENUM ('M', 'Ž') OZNACENI ENUM ('SKLAD1', 'SKLAD2', 'ŘEDITELNA', 'KUMBÁL1', 'KUMBÁL2', 'KUCHYŇ', 'KUCHYŇKA1', 'KUCHYŇKA2', 'BERUŠKY', 'KUŘÁTKA', 'MEDVĚDI', 'MYŠKY', 'KANCELÁŘ1', 'KANCELÁŘ2', 'DÍLNA', 'ZAHRADA', 'PRÁDELNA') POJISTOVNA_KOD ENUM ('207', '213', '201', '209', '227', '211', '217', '228', '222', '205', '111') KROUZEK_NAZEV ENUM ('KERAMIKA','ANGLIČTINA','PLAVÁNÍ') JEDNOTKA ENUM ('kg','l','ks') DOCHAZKA ENUM ('CELO', 'POLO') TYP ENUM ('otec', 'matka', 'jiné') FUNKCE ENUM ('učitelka', 'uklízečka', 'kuchařka', 'hospodářka', 'ekonomka', 'zástupkyně', 'ředitelka') V případě, že v budoucnu dojde k vytvoření např. dalšího kroužku, je možné změnit hodnoty jakéhokoliv datového typu ENUM prostřednictvím příkazu ALTER TABLE MODIFY COLUMN. Stejně tak se dá k jakékoliv tabulce dodatečně přidat sloupec, pokud bude chtít školka uchovávat doplňující informace. 3.11.3. Vytvoření pohledů Jedná se o stejné objekty, jako jsou tabulky, s tím rozdílem, že neobsahují skutečná data, nýbrž odkazy na tabulky, ze kterých data získávají. Pohledy mohou zobrazovat údaje z několika tabulek zároveň, čímž usnadňují manipulaci s databází. Pro mateřskou školku jsem vytvořil pohled, který bude zobrazovat děti, včetně jejich zástupců a kontaktu v případě úrazu. CREATE VIEW DITE_KONTAKT as SELECT DITE.ID_OS, DITE.JMENO, DITE.PRIJMENI, TRIDA, ALERGIE, PECE, TELEFON, TYP from DITE join ZASTUPUJE on (DITE.ID_OS = DITE) join ZASTUPCE on (ZASTUPCE = ZASTUPCE.ID_OS); Obr. 16 Pohled propojující 3 tabulky 37

4. INSTALACE, NASTAVENÍ A OTESTOVÁNÍ DATABÁZOVÉHO SYSTÉMU V tuhle chvíli je již navržena budoucí databáze včetně vygenerovaných SQL skriptů na základě vytvořeného fyzického modelu databáze v PowerDesigneru. V této kapitole je popsán následující krok nezbytný pro splnění cílů bakalářské práce a naplnění požadavků mateřské školky. Následující podkapitoly se zabývají instalací mnou vybraného databázového systému MySQL, který považuji vhodný k použití v tomto konkrétním příkladě. Po instalaci se dále zmiňuji o doplňujících nastaveních, která jsou nutná pro správné fungování DBMS. Do připraveného databázového systému jsou následně vkládány vygenerované SQL příkazy, které vytvoří databázové struktury, včetně kódů zajišťující integritu databáze a propojení tabulek. Nejprve jsou uvedeny stručné informace o vybraném systému. 4.1. MySQL MySQL je databázový systém, vytvořený švédskou firmou MySQL AB, nyní vlastněný společností Sun Microsystems. Jedná se o multiplatformní databázi, komunikace s ní probíhá prostřednictvím jazyka SQL. Tento databázový systém je volně ke stažení a je k dispozici pod licencí GPL. [4][8] 4.2. Instalace MySQL Databázový systém byl nainstalován na notebook Sony Vaio model VGN-CR21Z/R s následujícím nastavením: Operační systém: Windows Vista Home Premium Service Pack 2 Operační paměť: DDR2 2 GB RAM Procesor: Intel Core Duo 2,00 GHz 38