UNIVERZITA PALACKÉHO V OLOMOUCI

UNIVERZITA PALACKÉHO V OLOMOUCI PEDAGOGICKÁ FAKULTA

Bakalářská práce

2014

Lenka Koutná

UNIVERZITA PALACKÉHO V OLOMOUCI PEDAGOGICKÁ FAKULTA Katedra technické a informační výchovy

Bakalářská práce Lenka Koutná

Řešení datových problémů během životního cyklu vývoje databáze

Olomouc 2014

Vedoucí práce: Mgr. Jan Kubrický, Ph.D.

Prohlášení:

Prohlašuji, že jsem zadanou bakalářskou práci vypracovala samostatně pod odborným dohledem vedoucího bakalářské práce a všechny použité informační zdroje jsem uvedla v seznamu zdrojů na konci práce. V Olomouci dne: 11.4.2014 ....................................

Motto: „Informace znamená všechno; za války jako v míru, v politice jako ve finanční sféře.“ Stefan Zweig Poděkování: Především bych chtěla poděkovat vedoucímu mé bakalářské práce panu Mgr. Janu Kubrickému, Ph.D. za ochotu, cenné rady a užitečné připomínky při psaní této práce. Dále bych chtěla poděkovat mé rodině a především mé dceři za podporu během celého studia.

Obsah: Úvod .............................................................................................................. 7 Cíle práce ..................................................................................................... 8 1

Základní pojmy .................................................................................... 9

2

Životní cyklus vývoje databáze ......................................................... 10

3

Analýza požadavků ............................................................................ 11

4

3.1

Analýza organizace .......................................................................................... 11

3.2

Definice problémů a omezení........................................................................... 12

3.3

Definice cílů a rozsahů ..................................................................................... 13

Návrh ................................................................................................... 14 4.1

Konceptuální úroveň ........................................................................................ 14

4.2

Logická úroveň ................................................................................................. 16

4.2.1 4.3

5

Normalizace databáze ............................................................................... 18

Fyzická úroveň ................................................................................................. 20

4.3.1

Datové typy a hodnota NULL ................................................................... 22

4.3.2

Klíče .......................................................................................................... 23

4.3.3

Indexy........................................................................................................ 24

4.3.4

Integrita dat ............................................................................................... 25

4.3.5

Triggery ..................................................................................................... 26

Implementace ...................................................................................... 27 5.1

Vytvoření databáze ........................................................................................... 27

5.2

Konverze a načtení dat ..................................................................................... 28

5.3

Uživatelské zabezpečení ................................................................................... 28

5.4

Zabezpečení databáze ....................................................................................... 29

5.5

Zálohování ........................................................................................................ 30

6

Testování ............................................................................................. 32

7

Operace (provoz) ................................................................................ 33 7.1

Doladění a optimalizace databáze .................................................................... 33

8

Údržba ................................................................................................. 35

9

Návrh databáze pro školní knihovnu ............................................... 36 9.1

Analýza ............................................................................................................. 36

9.2

Definice cílů ..................................................................................................... 40

9.3

Konceptuální návrh .......................................................................................... 40

9.4

Logický návrh ................................................................................................... 42

9.5

Fyzický návrh ................................................................................................... 44

Závěr ........................................................................................................... 48 Seznam použité literatury a literárních zdrojů ...................................... 49 Seznam obrázků ........................................................................................ 52 Seznam tabulek.......................................................................................... 52 Seznam příloh ............................................................................................ 52 Příloha č. 1 - Analýza - otázky ................................................................. 53 Příloha č. 2 - Návrh databáze - SQL script ............................................ 54

Úvod Data a informace - pro někoho jen dvě slova, pro jiné (věřím, že pro většinu) každodenní životní potřeba. Informace lidé vyhledávali a využívali od pradávna. Správnou informaci ve správný čas dokázali i náležitě ocenit. Potřeba shánět, třídit a vyhledávat informace byla tak veliká, že lidé začali vymýšlet, jak si tuto potřebu usnadnit a zjednodušit. Data si uchovávali v písemné formě v různých kartotékách, které sice měly svůj systém přesto získat informaci chvíli trvalo. Největší přínos v této oblasti měl rozvoj informačních technologií a následně vývoj databázových systémů. Databáze, která má plnit dobře svou funkci musí splňovat určité podmínky a především musí obsahovat dostatečné množství kvalitních dat. Dobrá analýza je často podceňována, databáze se vytváří bez potřebné přípravy, některé kroky se zjednoduší, nebo úplně vynechají. V průběhu života databáze mohou nastat v podstatě dva druhy problémů - problémy aplikační a problémy datové (6). Správně navržená databáze dokáže nejen udělat spoustu práce za obslužnou aplikaci, ale dokáže ji i velmi výrazně urychlit. Informace získané z databáze musí být srozumitelné, důvěryhodné, snadno interpretovatelné, úplné, objektivní, bezchybné a musí být včas. Tato práce je svým tématem zaměřená na předcházení a řešení datových problémů. Správný návrh databáze zahrnuje konzistenci, integritu a přesnost dat v databázi. Databáze musí být snadno udržovatelná a měla by umožnit modifikaci (14). V jednotlivých kapitolách teoretické části budu popisovat jednotlivé etapy, kterými musí databáze projít během celého svého vývoje. V každé fázi životního cyklu budu analyzovat datové problémy, které by mohly nastat a následně, jaké je jejich řešení respektive předcházení. Zároveň budu popisovat všechny nezbytné kroky pro vytvoření správně fungující databáze. Ve druhé části práce budu aplikovat navržená doporučení popsaná v teoretické části na návrhu databáze pro školní knihovnu.

7

Cíle práce

Hlavním cílem je analýza a řešení datových problémů jednotlivých etap životního cyklu vývoje databáze. Dílčím cílem je podrobná analýza všech etap tohoto cyklu a podrobný popis návrhu relační databáze tak, aby podle něj bylo možné navrhnout novou, správně fungující databázi. V praktické části bude navržena databáze pro školní knihovnu s aplikací všech poznatků z teoretické části.

8

1 Základní pojmy

V problematice databází jsou základní pojmy data, informace a databáze. Data jsou údaje, které nám samy o sobě nic neříkají, jsou to slova, čísla, nebo třeba datumové údaje. Těmito údaji je naplněná databáze. Databáze je centralizovaná a strukturovaná množina dat. Informace je údaj, který nám něco říká a je pro nás užitečný. Informaci získáme pomocí správně zvoleného dotazu z databáze. Z obrázku č. 1 je patrné, že data do databáze vstupují a informace naopak vystupují (14).

Select

Insert data

Databáze

Obr. 1 Vztah data, databáze, informace (vlastní)

9

informace

2 Životní cyklus vývoje databáze

Obr. 2 Životní cyklus databáze (10)

Životní cyklus vývoje databáze začíná ještě dlouho před jejím vytvořením. Na obrázku č. 2 je vidět celý cyklus, kterým každá databáze prochází. První etapou musí být vždy důkladná analýza požadavků a prostudování současné databáze (pokud existuje). Dalším krokem je volba vhodného datového modelu a vlastní vytvoření databáze. Databáze potřebuje data. Pokud máme elektronická data z původní databáze, můžeme je použít a naimportovat, pokud data nemáme, nebo máme jen papírová data, musíme databázi naplnit ručně. Další krátkou, nic méně důležitou, etapou je testování. Po úspěšném zvládnutí všech předchozích etap následuje etapa nejdelší a tou je provoz databáze. Během provozu databázi udržujeme, zálohujeme a podle potřeby modifikujeme. V okamžiku, kdy databáze přestane vyhovovat vývojovým změnám, bude pomalá, nespolehlivá a nebude schopna pojmout další data je její cyklus u konce a nastává první etapa nového cyklu (10).

10

3 Analýza požadavků

V prvních fází životního cyklu vývoje databáze nemohou nastat žádné datové problémy, protože databáze fyzicky neexistuje. V této fázi, už ale můžeme vymezit problémy, které by při špatném postupu mohly nastat. Jedná se především o datové problémy vzniklé nedorozuměním a špatným pochopením dané problematiky. V této fázi definujeme základní datové typy a rozsahy dat, které bude databáze obsahovat. Datový problém může nastat např. pokud do číselné položky budeme chtít vložit nenumerický znak, nebo pokud budeme potřebovat vložit větší hodnotu, než daný datový typ umožňuje. Pokud tuto fázi životního cyklu vývoje databáze provedeme opravdu pečlivě, můžeme předejít problémům s pozdější potřebou změny struktury tabulek v databázi. Fáze analýzy začíná, když vznikne požadavek vytvořit novou databázi. Většinou se tak stane, když je stávající systém nedostačující, zastaralý, nebo poruchový. Také může vzniknout potřeba úplně nového systému např. se vznikem nové firmy. Pokud existuje stávající systém - v elektronické, nebo jiné podobě - je potřeba ho také podrobit analýze. Analýza je proces zdlouhavý a někdy se může zdát i nudný. Nekonečné rozhovory s mnoha lidmi, stovky otázek a odpovědí, dlouhé hodiny přemýšlení. Ale platí zde přímá úměra, čím lépe analýzu provedeme, tím lépe bude databáze sloužit. V příloze č. 1 jsou příklady otázek používaných při analýze. Při analýze se mohou využívat i další metody například velmi efektivní, ale časově náročné je pozorování organizace za provozu, zkoumání podnikové dokumentace, nebo upřesňující dotazník (3).

3.1 Analýza organizace

Prvním krokem je důkladná analýza organizace. Pochopení organizační struktury, upřesnění hardwarového a softwarového vybavení a pochopení činností 11

organizace jsou klíčové pro další postup. Při analýze musíme správně pochopit pracovní postupy a návaznosti všech činností v organizaci (5). Kromě rozhovorů s pracovníky na různých pozicích je potřeba prostudovat veškerou dostupnou dokumentaci, která se týká dané problematiky (13).

3.2 Definice problémů a omezení

Dalším krokem je analýza stávajícího systému. Je potřeba zjistit potíže a omezení, které se ve starém systému projevují. Je potřeba definovat vstupní data tzn. jaká data a odkud budou do databáze vstupovat (např. import z jiného systému, ručně, čtečkou čárových kódů apod.). Dále je potřeba definovat výstupy (export do jiného systému, tisk, nebo třeba webová stránka). Vstupní data musí mít stanovený datový typ (číslo, text, datum ….) a doménu, což je rozsah, kterého mohou nabývat (5). Vstupní a výstupní operace jsou důležitým zdrojem informací pro návrh databáze. Platí přímá úměra, čím více těchto informací budeme mít, tím lépe můžeme návrh provést (16). Dalším důležitým údajem je očekávaný objem dat a počet uživatelů, kteří budou k datům přistupovat. Ve většině případů bude potřeba definovat různé skupiny uživatelů, kteří budou mít různá přístupová práva k jednotlivým částem databáze - např. archivní data budou pro většinu jen pro čtení, nebo tabulku uživatelů bude mít přístupnou jen správce databáze. Podrobným dotazováním musíme zjistit požadavky a očekávání od nového systému. Musíme se ptát i běžných uživatelů, které činnosti by chtěli zjednodušit, nebo přizpůsobit svým potřebám. Je vhodné ptát se i na budoucí plány a požadavky kladené na databázi. Velmi důležité je zjistit a identifikovat všechny výjimky a navrhnout databázi tak, aby tyto výjimky zvládla (13). Součástí tohoto kroku je vytvoření předběžného seznamu tabulek včetně polí a přibližného počtu záznamů v každé tabulce. Každou položku tohoto seznamu pečlivě ověříme, zda není zastaralá a zda je v novém systému nezbytná. Tento seznam se bude v průběhu návrhu upravovat a dolaďovat až do konečné podoby nové databáze (11). 12

3.3 Definice cílů a rozsahů

Z předchozích informací se sestaví seznam požadavků, který je výchozí pro definování cílů. Definujeme obecné úkony , které se budou v databázi provádět. Každý cíl definuje jeden úkon. Tento seznam nemusí být konečný, v průběhu dalších činností mohou nastat další cíle, nebo se mohou ty dříve definované doladit. Nic není zadarmo, ani práce návrháře databáze. Je třeba si dopředu dohodnout rozsah práce, případně které části návrhu se nebudou nyní z finančních, nebo časových důvodů implementovat. Návrh databáze by měl být však úplný, tzn. měl by obsahovat i ty části databáze, které se nebudou ihned používat. Předejde se tím možným problémům s pozdějším doplněním databáze (5). Jednoduchým příkladem může být evidence výpočetní techniky ve firmě. Požadavek je evidence hardware, software a licencí. Projekt počítá s automatickým skenováním PC a s následným importem do evidence. Z časových i finančních důvodů se v první fázi bude implementovat jen evidence HW a evidence zakoupených licencí a evidence veškerého software se dodělá v další fázi. Z obrázku č. 3 vidíme, že modul SW (evidence SW) je propojen i na modul licence (evidence licencí). Návrh této databáze by měl tedy obsahovat i ty části, které se týkají evidence software.

Obr. 3 Stanovení rozsahů (vlastní)

13

4 Návrh

Z hlediska správné funkčnosti a eliminace datových problémů je tato fáze pro životní cyklus nejdůležitější. Správným návrhem databáze můžeme většině datových problémů předejít. Současné systémy řízení báze dat - SŘBD (vysvětleno v kapitole 4.3) nabízí dostatek nástrojů pro efektivní návrh databáze. Mezi základní vlastnosti databáze patří nezávislost dat, sdílení dat, ochrana a utajení dat, redundance, konzistence a integrita dat: •

Nezávislost dat znamená, že změna v datech nevyžaduje nutně změnu programu.

•

Sdílení dat znamená, že k datům má ve stejný okamžik přístup více uživatelů.

•

Ochrana a utajení dat znamenají zabezpečení proti zneužití dat.

•

Redundance znamená duplicitní data v různých tabulkách.

•

Konzistence znamená, že během provozu se neztratí, nebo nepoškodí žádná data a data, která do databáze nepatří, tam nebudou.

•

Integritní omezení jsou omezující pravidla podle reality.

Ve fázi návrhu databáze se vytváří modely na úrovni konceptuální, logické (technologické) a fyzické (implementační). Jednotlivé úrovně jsou na sobě nezávislé tzn. změna v jedné úrovni, nemusí nutně znamenat změnu v jiné úrovni (18).

4.1 Konceptuální úroveň

Účelem tohoto modelování je podchycení všech informací a předcházení chyb a nedorozumění mezi návrháři a budoucími uživateli databáze. Modelování je provedeno v obecné rovině, bez použití odborných a specifických pojmů pro tvorbu databáze tak, aby výslednému modelu rozuměl každý jedinec (15). 14

Pro správné konceptuální modelování je nutné pochopit základní názvosloví. Konceptuální návrh databáze obsahuje entity, které jsou popsané atributy. Entity jsou vzájemně rozlišitelné konkrétní, nebo abstraktní objekty reálného světa. Soubor vzájemně příbuzných entit je entitní množina (9). Entity mohou být lidé, místa, nebo věci. Mezi jednotlivými entitami existují (musí existovat) vztahy s příslušnou kardinalitou. Kardinalita může nabývat hodnot 1:1, 1:N, N:M. Na obrázku č. 4 je znázorněna databáze zaměstnanci. V konceptuálním modelování bude obsahovat 3 entity - Osoba, Funkce a Útvar. Entity jsou popsány svými vlastnostmi, které nabývají určitých hodnot z množin zvaných domény. Vlastnosti entit nazýváme atributy (9). Vztahy mezi entitami včetně kardinality jsou naznačeny šipkami. Tyto entity se později stanou tabulkami v databázi (3). Kardinalita vztahu je číslo, které udává počet instancí (výskytů) entity, kterými vstupuje do vztahu s instancemi druhé entity. Na obrázku č. 4 má každá osoba právě jednu funkci a pracuje právě v jednom útvaru - kardinalita 1. Stejnou funkci a stejný útvar může mít více osob - kardinalita N.

Obr. 4 Databáze zaměstnanci (vlastní)

Kardinalita N:M se musí eliminovat zařazením další entity (19). Problémy mohou nastat při výskytu 3 entit navzájem propojenými dvěma vazbami N:M. V tomto případě 15

musíme pečlivě prověřit, zda nově vzniklé vazby 1:N jsou korektní a povedou vždy k nalezení správných dat (17). Na obrázku č. 5 je znázorněn příklad konceptuálního modelování, což je například E-R diagram (entity-relationship diagram, nebo-li model vztahů entit). Je to množina pojmů, které nám pomáhají, na konceptuální úrovni popsat požadavky a následně specifikovat strukturu databáze. V diagramu musí být popsány všechny požadované procesy a musí být zohledněny všechny předpisy a zákony upravující danou problematiku. Entity jsou v diagramu pojmenovány většinou podstatným jménem a zobrazují se v obdélníku, vztahy se zobrazují v kosočtverci a bývá to většinou sloveso (15).

N vykonává mmm Osoba

N pracuje v

1

1

Funkce

Útvar

Obr. 5 Ukázkový E-R diagram (vlastní)

Konceptuální úroveň je zcela obecná, není závislá ani na datovém modelu ani na systému řízení báze dat - viz kapitola 5.3. Z hlediska eliminace budoucích problémů je v této fázi nezbytná precizní a profesionální spolupráce zadavatele a návrháře.

4.2 Logická úroveň Na této úrovni se transformuje E-R diagram na tabulky v databázi. V této fázi už musíme vědět, v jakém datovém modelu budeme databázi vytvářet. Datové modely se dělí podle vztahů na hierarchický, síťový, relační a objektový model. Tato práce se bude dále zabývat datovými problémy v relačním datovém modelu, který je v současné době nejrozšířenější. Relační model popsal v roce 1970 Dr. Cood. Základní vlastnosti, které musí relační model mít, jsou: •

Uživatel vnímá databáze jako množinu relací.

•

Uživatel má k dispozici minimálně operace selekce, projekce a spojení. 16

Dr. Cood definoval dvanáct pravidel pro relační model (4): 1. Informační pravidlo - všechny informace jsou vyjádřeny hodnotami v tabulkách. 2. Pravidlo jistoty - všechna data jsou přístupná kombinací jména tabulky s hodnotami primárního klíče a jménem sloupce. 3. Systematické

zpracování

nulových

hodnot

-

nulové

hodnoty

jsou

podporovány pro reprezentaci informace, která není definována. 4. Dynamický on-line katalog založený na relačním modelu - struktura databáze je vyjádřena stejným způsobem jako data, může se používat stejný dotazovací jazyk. 5. Obsáhlý datový podjazyk - musí být nejméně jeden dotazovací jazyk s definovanou syntaxí, který podporuje definici dat, definici pohledů, manipulaci s daty, integritní omezení, autorizovaný přístup k databázi, transakční příkazy apod. 6. Pravidlo vytvoření pohledů - všechny pohledy, které jsou teoreticky možné, jsou systémem vytvořitelné. 7. Schopnost vkládání, vytvoření a mazání - schopnost zachování relačních pravidel je zachována nejen při pohledu na data, ale i při operacích průniku, přidání a mazání dat. 8. Fyzická datová nezávislost - aplikační programy jsou nezávislé na fyzické datové struktuře. 9. Logická datová nezávislost - aplikační programy jsou nezávislé na změnách v logické struktuře databázového souboru. 10. Integritní nezávislost - integritní omezení se musí dát definovat prostředky relační databáze a musí být možnost uložení v katalogu a nikoliv v aplikačním programu. 11. Nezávislost distribuce - relační model musí být schopen implementace na jiných počítačových architekturách. 12. Pravidlo přístupu do databáze - k vytváření integritních omezení je nutno použít relační jazyk vyšší úrovně.

Respektováním těchto pravidel je zajištěna efektivnost práce návrhářů a programátorů relačních databázových systémů. I v této části návrhu můžeme správným postupem 17

předcházet mnohým datovým problémům, které by mohly nastat během provozu databáze, především při vkládání a modifikaci dat. Struktura databáze musí být navržena podle pravidel normalizace, pomocí kterých definujeme jednotlivé tabulky, určujeme jejich atributy, primární i cizí klíče a integritní omezení.

Pro tabulky musí platit následující pravidla (10): •

Nesouvisející data by měla být v různých tabulkách.

•

Data, která lze vypočítat, neukládáme.

•

Návrh musí odpovídat všem procesům, které byly definovány při analýze.

•

Sloupce musí mít jedinečné názvy v rámci jedné tabulky.

•

Není vhodné vytvářet příliš mnoho vztahů, ale je potřeba pokrýt vztahy tak, aby bylo možné dohledat veškeré spojitosti.

•

Kardinalita M:N se musí vyjádřit pomocí vazební tabulky.

•

Je vhodné definovat rozsahy povolených hodnot.

•

Je nutné dodržet normalizační formy - každá tabulka musí být minimálně ve třetí normalizační formě.

•

Není vhodné vytvářet primární klíč kombinací více sloupců.

•

Každé tabulce je vhodné nastavit přístupová práva uživatelů.

Logická úroveň je stěžejní fází pro eliminaci možných datových problémů během provozu databáze, nebo při pozdějších úpravách databáze. Dodržování výše uvedených pravidel a jistá logika v názvosloví jsou téměř nutností. Například stejné názvy sloupců v různých tabulkách, které nejsou klíčem a jejichž obsah vyjadřuje různé informace, mohou způsobit nekorektnosti při získávání informací. Naopak stejné názvy sloupců, které jsou klíčem, příkazy pro manipulaci s daty podstatně zefektivní.

4.2.1

Normalizace databáze

Normalizace databáze je postupný proces nahrazování dané množiny relací souhrnem relací, které mají jednodušší a regulérnější strukturu. Cílem normalizace je zajištění integrity a konzistence dat (21). U tabulky, která není normalizovaná, mohou nastat anomálie aktualizací, což jsou anomálie vkládání, anomálie vymazávání 18

a anomálie modifikace. Důsledkem těchto anomálií je pomalá databáze, může dojít ke ztrátě dat, nebo k získání nekorektních informací. K předcházení těchto anomálií je nutné pečlivé dodržování normalizace databáze. Datové problémy mohou nastat, pokud bude databáze obsahovat např.: •

Opakující se pole tabulky.

•

Tranzitivní závislosti - jedno, nebo více polí tabulky bude záviset na jiném poli, než je celý primární klíč.

•

Redundantní data.

Je definováno šest normálních forem, přičemž každá vyšší forma v sobě zahrnuje formy nižší (5). •

1. normální forma - 1.NF Tabulka je v 1.NF pokud jsou všechna data atomická, to znamená, že data v jednom poli už nejdou dále dělit. Každá tabulka má definován primární klíč a všechny ostatní sloupce v tabulce jsou na tomto klíči závislé (5).

•

2. normální forma - 2.NF Tabulka je ve 2.NF pokud jsou všechna neklíčová pole závislá na celém primárním klíči. Pokud je primární klíč složeny z více polí a nějaké další pole v tabulce je závislé jen na některém z těchto polí, může nastat redundance dat. Mnohem vhodnější je místo složeného primárního klíče použít nově vytvořený číselný sloupec, který nám poslouží jako primární klíč a tabulku rozdělit tak, aby se zamezilo duplicitním hodnotám (5).

•

3. normální forma - 3.NF Tabulka je ve 3.NF pokud neobsahuje žádné tranzitivní závislosti. Všechny sloupce tabulky musí být závislé přímo na primárním klíči. Pokud tabulka obsahuje sloupec, který je závislý na jiném neklíčovém sloupci, musíme tabulku opět rozdělit (5). 19

•

Boyce-Coddova normální forma - BCNF Tabulka je v BCNF pokud je každý determinant kandidátním klíčem. Determinantem je pole, které určuje hodnotu jiného pole. Kandidátním klíčem je pole, které může být klíčem pro danou tabulku. Pokud se v tabulce vyskytuje klíčové pole, které je závislé na neklíčovém poli a toto neklíčové pole nemůže být klíčem, musíme tabulku opět rozdělit (5).

•

4. normální forma - 4.NF Tabulka je ve 4.NF pokud neobsahuje více než jednu vícehodnotovou závislost. Vícehodnotová závislost vznikne mezi poli, když v rámci jedné tabulky hodnotě jednoho pole odpovídá více hodnot z jiného pole (5).

•

5. normální forma - 5.NF Tabulka je v 5.NF pokud ji nelze rozdělit na další tabulky s odlišnými klíči (5).

Pro eliminaci možných datových problémů je nutné, aby každá tabulka databáze vyhovovala nejméně 3 normální formě. Logická úroveň je navrhována na konkrétní datový model, ale není ještě závislá na konkrétním systému řízení báze dat, což znamená, že správně vytvořený logický návrh databáze lze opakovaně použít při přechodu na jiný SŘBD.

4.3 Fyzická úroveň Softwarový systém, který umožňuje efektivně pracovat s databází, se nazývá Systém řízení báze dat (SŘBD). Tento systém umožňuje vytvářet jednotlivé části databáze, vkládat, aktualizovat, mazat a vyvolávat data z databáze prostřednictvím dotazovacího jazyka (16). Další vlastností SŘBD je poskytnutí systémového katalogu, který uchovává informace o datových položkách, integritním omezení a přístupových právech uživatelů. Další důležitou službou SŘBD je podpora transakcí a služby řízení sdílení (3). Z hlediska bezpečnosti dat SŘBD umožňuje použití hesel, definování 20

přístupových práv, rozlišení práv pro zápis, čtení a modifikaci (16). Všechny tyto nástroje jsou mocným pomocníkem při předcházení pozdějších datových problémů. Databázový systém zahrnuje databázi, systém řízení báze dat a databázovou aplikaci, což je počítačový program vytvořený dle požadavků pro práci uživatelů s databází (20). V této fázi musíme vybrat systém řízení báze dat a nainstalovat jej. Při výběru se řídíme několika různými hledisky. K nejpodstatnějším patří (19): •

Současný přístup k datům pro více uživatelů.

•

Zajištění ochrany a integrity dat.

•

Prostředky pro centrální správu dat a uživatelů.

•

Podpora transakcí, triggerů a uložených procedur.

•

Vyhledávací mechanizmy.

•

Profilování, nebo-li logování.

Mezi nejrozšířenější SŘBD patří: Oracle, Informix, Microsoft Access, Microsoft SQL Server, Microsoft Visual FoxPro, MySQL, PostgreSQL, Progress a další. Při fyzickém navrhování tabulek už musíme znát funkčnost SŘBD abychom mohli logický návrh danému systému přizpůsobit. Pro tabulky, které se nyní mohou začít fyzicky vytvářet, platí (3): •

Každá tabulka musí mít unikátní jméno v rámci databáze.

•

Každý sloupec ( pole) tabulky musí mít unikátní jméno v rámci tabulky.

•

Tabulka nemůže mít duplicitní řádky (záznamy).

•

Každá tabulka musí mít primární klíč.

•

V tabulce nezáleží na pořadí sloupců.

•

V tabulce nezáleží na pořadí řádků.

•

Všechny hodnoty daného sloupce musí být stejného datového typu.

Moderní SŘBD tato pravidla hlídají automaticky. Pokud při fyzickém návrhu databáze tato pravidla dodržíme, vyhneme se problémům při vlastním vytváření databáze a následně při plnění databáze daty.

21

4.3.1

Datové typy a hodnota NULL Datový typ je jedna ze základních vlastností každého sloupce tabulky. Správně,

nebo naopak špatně vybraný datový typ může výrazně ovlivnit budoucí rychlost a funkčnost databáze. Musíme pečlivě zvážit, jaký typ dat budou hodnoty ve sloupci nabývat, jaký budou mít rozsah hodnot, zda budeme podle tohoto sloupce záznamy vyhledávat, třídit a seskupovat, a v neposlední řadě zda tento sloupec bude určený pro matematické operace. Při špatné volbě může nastat problém s uložením hodnoty, který definovaný datový typ nepodporuje, nebo s rychlostí databáze. Zvolení nesprávného typu vede k přenosu zbytečně velkých datových toků a tím k zatížení sítě (10). Základní datové typy jsou (10): •

Znakový - může obsahovat jakýkoliv znak, špatně zvolená velikost se může projevit na rychlosti zpracování. Tento typ nelze použít pro matematické operace. Při vkládání čísel, nebo datumových údajů do textového pole může nastat problém při třídění dat. Čísla nebudou řazena matematicky, ale znakově.

•

Numerický - může obsahovat čísla, nelze vložit nenumerický znak. Pokud zvolíme špatný typ (celá čísla, počet desetinných míst apod.) může dojít ke ztrátě části dat.

•

Datumový - může obsahovat datumové a časové údaje. Údaje se vkládají podle zadané masky většinou „DD.MM.RRRR“. Jednotlivé části mají omezení rozsahu. Pokud zadáme datumový údaj v jiném pořadí, než je definovaná maska, dostaneme při dotazu nekorektní informace.

•

Logický - může nabývat hodnot 0/1 - True/False (pravda/nepravda).

Každý z těchto základních typů je v daném SŘBD rozšířen a další datové typy, které jsou podmnožinou základního typu. Kromě datového typu se u sloupců určuje, zda mohou nebo nemohou být NULL. Null je doslova prázdná hodnota - nereprezentuje žádný datový typ. Proto pozor u sloupců určených k matematickým operacím (19).

22

Další problémy, které mohou nastat zvolením špatného datového typu, jsou např.:

4.3.2

•

Nelze vložit nenumerický znak do numerického typu.

•

Nelze vložit delší řetězec do špatně zvoleného znakového typu.

•

Matematická operace nevrací výsledek - null hodnota.

Klíče Tabulky mohou obsahovat velmi mnoho záznamů - řádků. Každý záznam

v tabulce musí být unikátní (jedinečný) a musí být zajištěná jeho jednoznačná identifikace pro výběr. Pokud by nebyla tato podmínka splněná, databáze by vracela nesmyslné, nebo neúplné informace. Tuto identifikaci zajišťuje primární klíč. Primární klíč může reprezentovat jeden sloupec, nebo skupina sloupců. Každá tabulka musí mít definovaný právě jeden primární klíč. Primární klíč nesmí být NULL, pokud je primární klíč složený z více sloupců, nesmí být NULL žádný ze sloupců (19). Hodnota primárního klíče je po celou dobu neměnná, tzn. jednou uložená hodnota primárního klíče nejde v žádném případě změnit. Sloupec, nebo sloupce, které jsou vybrány jako primární klíč, musí obsahovat smysluplné údaje. Pokud by bylo nutné vytvořit primární klíč příliš složitý, je vhodnější použít jako primární klíč číslo, které vkládanému záznamu přiděluje SŘBD (12). Databáze obsahuje většinou více tabulek, které mají mezi sebou určité vztahy. Vztahy mezi tabulkami zajišťují primární a cizí klíče. Cizích klíčů může mít tabulka více, záleží s kolika dalšími tabulkami má vztah (19). Cizí klíč v jedné tabulce musí být primární klíč v tabulce druhé, přičemž mohou, ale nemusí mít stejný název (12). Na obrázku č. 6 vidíme tři tabulky, každá má právě jeden primární klíč - PK primary key. Cizí klíče - FK foreign key má pouze tabulka „Osoba“, která obsahuje dva cizí klíče. Cizí klíč na rozdíl od primárního klíče může nabývat hodnoty NULL.

23

Obr. 6 Primární a cizí klíče (vlastní)

4.3.3

Indexy Důvodem proč sbíráme a uchováváme data je především vyhledání

a zpracování informací. Některé tabulky v databázi mohou ovšem obsahovat velmi velké množství dat. Vyhledání informace v takové tabulce by mohlo trvat příliš dlouhou dobu. Pro efektivnější a hlavně rychlejší vyhledávání slouží indexy. Index je pomocná tabulka, která obsahuje jen sloupce, podle kterých potřebujeme vyhledávat a odkaz na skutečné uložená data v tabulce. Volbu a použití indexů řídí SŘBD. Vytvoření indexů se provádí při tvorbě tabulek v databázi tak, aby se předpokládané příkazy zpracovávaly co nejefektivněji. Při vytváření indexů musíme brát v úvahu, že při vkládání a mazání je třeba provést i opravu indexu (21). U velkých archivních tabulek, kde je zákaz modifikace, můžeme využít velké množství indexů, které nám mnohonásobně zrychlí vyhledávání požadovaných dat, naopak u často modifikovaných tabulek vytváření velkého množství indexů pečlivě zvážíme (13).

24

Základní pravidla pro vytvoření indexu (2): •

Index se vytváří pro primární i cizí klíče.

•

Index pokryje více dotazů.

•

Index bude používán pro nalezení malého počtu záznamů.

Indexy nám neřeší ani neeliminují žádné datové problémy, ale ovlivňují rychlost databáze a tím i její životnost. Během provozu databáze se mohou indexy podle potřeby vytvářet, nebo naopak rušit.

4.3.4

Integrita dat Pravidla, vymezující korektnost uložených dat a rozhodující o proveditelnosti

aktualizačních operací, které by mohly tento stav narušit, se označují pojmem integritní omezení. Výstupem, v případě chybné definice integritních omezení, by mohly být nesmyslné a nekorektní informace. Centrálně definovaná a spravovaná omezení, by měla být přímou součástí databáze, s tím, že vytvořená databázová aplikace musí být na jejich úpravách zcela nezávislá (21). V praxi definujeme tři druhy integritních omezení: •

Entitní integrita - každá tabulka má primární klíč, který nesmí být NULL. Toto zabezpečení zajistí jednoznačnou identifikaci každého řádku tabulky, nebo-li nepřipustí uložení řádku bez správně naplněného primárního klíče (21).

•

Doménová integrita - definuje množinu přípustných hodnot, které může určitý sloupec tabulky nabývat (21). U sloupců nastavujeme tyto parametry: •

Datový typ.

•

Povinnost hodnoty (NOT NULL).

•

Jedinečnost hodnoty (UNIQUE).

•

Rozsah hodnot.

•

Implicitní hodnotu (DEFAULT).

•

Masku pro vkládání dat.

•

Seznam přípustných hodnot. 25

•

Referenční integrita - cizí klíč má buď hodnotu NULL, nebo hodnotu. Pokud má hodnotu, musí se tato hodnota vyskytovat v primárním klíči spojené tabulky (19). Toto omezení garantuje korektnost vztahů mezi souvisejícími tabulkami. Při modifikaci záznamu respektive mazání záznamu jsou aktualizovány respektive vymazány všechny údaje mající vztah k danému záznamu ve všech souvisejících tabulkách (21).

Dodržování těchto integritních omezení lze zajistit třemi způsoby (4): •

Ochranné mechanismy na straně databázového serveru - nejlepší způsob, nevýhodou může být delší odezva.

•

Ochranné mechanismy na straně klienta - náročné na údržbu.

•

Samostatné programové moduly na straně databázového serveru - triggery.

Ideálním řešením je kombinace všech způsobů. Kontroly integrity dat se provádí po každé operaci, čímž je stoprocentně zajištěná korektnost dat (4).

4.3.5

Triggery

Triggery jsou velmi užitečné nástroje pro zajištění korektnosti dat v databázi. Trigger, nebo-li spouštěč, je procedura, která je automaticky spuštěna SŘBD jako reakce na specifikovanou akci v databázi. Touto akcí je vkládání, modifikace, nebo mazání dat v databázi (7). Triggery přenáší část práce za obslužnou aplikaci na server. Konzistence dat tak je zajištěna bez ohledu na chyby v aplikaci. Typickým příkladem a nejčastěji používaným triggerem je zajištění smazání všech souvisejících dat v dalších tabulkách při příkazu DELETE. Takto zajištěná databáze nemůže obsahovat nekorektní vztahy mezi tabulkami (22).

26

5 Implementace V rámci implementace vytváříme databázi a optimalizuje ji pro nejvýkonnější provoz, nahráváme do ní data, definujeme zabezpečení databáze a přístupová práva jednotlivých uživatelů (10). Fyzická implementace řeší uložení dat na nejnižší úrovni databáze (1). Při fyzickém vytváření jednotlivých objektů mohou nastat problémy vzniklé syntaktickou chybou, nebo překlepem. Tyto problémy se mohou projevit ihned při implementaci, nebo později při testování a někdy až při provozu databáze.

5.1 Vytvoření databáze Databáze se vytváří pomocí jazyka DDL (Data Definition Language) pro definici dat zvoleného SŘBD. Příkazy jazyka DDL se používají k vytvoření prázdných databázových struktur a indexů. Základní příkazy jazyka DDL jsou CREATE (vytvoření), ALTER (změna) a DROP (rušení). S implementací databáze by se měla implementovat i databázová aplikace, prostřednictvím které budou uživatelé k databázi přistupovat (2). Přesto, že databázové systémy používají standardizovaný jazyk SQL, mohou mít drobné odlišnosti, které mohou působit problémy při migraci mezi různými SŘBD. V tomto případě může fyzický návrh obsahovat syntaktické chyby, které způsobí problémy při vytváření databáze v novém prostředí. Pro implementaci databáze v jiném SŘBD, než byla původně navržena, je nezbytná dokonalá znalost nového systému a úprava fyzického návrhu pro nový SŘBD.

27

5.2 Konverze a načtení dat Konverze a načtení dat jsou nutné, když máme data v elektronické podobě. Současné SŘBD obsahují utility (pomocné nástroje) pro načtení existujícího souboru do databáze. Tento proces musí být řádně naplánován, aby se zajistil hladký a bezchybný přenos. V rámci této konverze musíme správně specifikovat zdrojový i cílový objekt. V této fázi nastávají datové problémy dané rozdílnou definicí typů a domén (3). Pro manipulaci s daty se používají příkazy jazyka DML (Data Manipulation Language). Základní příkazy jsou SELECT (výběr), INSERT (vkládání), UPDATE (změna) a DELETE (mazání) (8). I v této části implementace databáze mohou nastat problémy s migrací dat způsobené drobnými odlišnostmi různých SŘBD. Migrace dat znamená převod dat mezi různými SŘBD. Problémy mohou nastat s různými datovými typy jednotlivých sloupců tabulky, nebo s různým ukládáním stejného datového typu např. datumový typ. Při migraci je vždy důležitá fáze testování, aby se včas odhalily problémy, které by při ostrém provozu mohly mít velmi negativní dopad (2).

5.3 Uživatelské zabezpečení Data a informace jsou existenční nutností pro všechny majitele databáze. Ochrana a zabezpečení dat jsou prioritní otázkou během provozu databáze. Zatímco většině datových problémů lze předejít správným návrhem databáze, ztrátě, zničení a zneužití se předchází až během provozu (10). Relační modely nabízí dva typy uživatelského zabezpečení: •

Zabezpečení systému

•

Zabezpečení dat

Zabezpečení systému se týká přístupu a používání databáze pomocí uživatelských jmen a hesel. Každý uživatel má přidělenou autorizační identitu. Tím je dáno zabezpečení dat 28

tzn. ke kterým objektům databáze může přistupovat a jaké operace s nimi může provádět (10). Každý uživatel může být navíc členem jedné, nebo několika skupin. Přístupy a oprávnění jsou potom dány členstvím ve skupině. Pokud bude s databází pracovat

větší

množství

uživatelů,

je

tato

možnost

mnohem

efektivnější

a přehlednější (13). Pro nastavení přístupových oprávnění se používají příkazy jazyka DCL (Data Control language). Základními příkazy jsou GRANT (nastav) a REVOKE (odeber) (2).

5.4 Zabezpečení databáze

Databáze představuje velmi významný zdroj a měla by být řádně zabezpečena proti těmto situacím (3): •

Krádež a zpronevěra.

•

Ztráta utajení.

•

Ztráta soukromí.

•

Ztráta integrity.

•

Ztráta dostupnosti.

Krádež a zpronevěra je záležitost čistě uživatelů. Stejně jako při ztrátě utajení a ztrátě soukromí nedochází ke ztrátě nebo zničení dat, ale ke zneužití dat jinou osobou. Zabezpečení těchto oblasti je zaměřené na redukci příležitostí. Zvláštní důraz je kladen na bezpečnou politiku hesel. Heslo by mělo splňovat určitou míru bezpečnosti např. délka hesla, velká, malá písmena a číslice v hesle apod. Dalším bezpečnostním prvkem je doba platnosti hesla. Systém automaticky hlídá poslední změnu a sám vyzve uživatele ke změně po nastaveném časovém intervalu. Ztráta integrity dat má za následek znehodnocení dat ztráta dostupnosti znamená, že s databází nelze pracovat. Zabezpečení těchto oblastí řeší zálohování databáze (3).

29

5.5 Zálohování Ani sebelépe navržená databáze není odolná proti poruchám hardwaru a omylům uživatelů. Zálohování a následně i obnova dat je tedy životně důležité pro minimalizaci rizika ztráty dat. Zálohování se provádí v denních, týdenních, nebo měsíčních intervalech. Mezi nejčastější příčiny, vedoucí k potřebě obnovy patří (10): •

Výpadek elektrického proudu.

•

Výpadek záložního zdroje.

•

Vadný HW.

•

Chyba v aplikaci - vedoucí k nekonzistenci dat.

•

Chyba způsobená uživatelem - omylem vymazaná data.

Z důvodu zajištění použitelné zálohy je potřeba dodržovat tato pravidla (10): •

Zálohovat pravidelně.

•

Zálohovat jinam, než je provozována databáze - např. externí disk, vyměnitelné medium, záložní server apod.

•

Zálohovat v době nejmenšího provozu.

•

Zálohy si zpětně uchovávat v rámci nějakého systému.

Zálohování může probíhat ve dvou režimech: Off-line - zálohování probíhá mimo provoz databáze na vhodné datové medium On-line - zálohování provádí tzv. zálohovací agenti, záloha se provádí za provozu databáze. Integrita dat je zajištěna zálohováním logických i žurnálových souborů spolu s daty. Zálohovat i obnovovat lze celou databázi, nebo jen vybrané objekty. On-line zálohy jsou trojího typu: •

Úplná záloha - zálohuje se vše.

•

Inkrementální záloha - zálohují se jen změny od poslední zálohy.

•

Kumulativní inkrementální záloha - zálohují se jen změny od poslední úplné zálohy. 30

Při obnově je velice důležité zajistit integritu databáze. Jednou z metod pro zajištění logické integrity je žurnálování. V žurnálovém souboru se ukládají informace o všech krocích probíhajících v transakci. Pokud transakce nedojede do konce, tak právě informace v žurnálovém souboru slouží pro obnovu dat do původního stavu (před transakcí). Další metodou je stínování, které umožňuje zálohování změn na stejném, nebo i jiném serveru. Stínování aktualizuje zálohu po každé úspěšné transakci. Pokud dojde k poruše původní databáze, je možné pokračovat v práci na této záložní databázi. Bohužel tato metoda nezajišťuje stoprocentní integritu. Další metodou zálohování je zrcadlení disků. Pokud dojde k fyzické poruše prvního disku, je možné v podstatě ihned pokračovat v práci právě na zrcadleném disku. Tato metoda je ideální pro zajištění proti fyzickým poruchám, ale proti chybám uživatelů je bezcenná. V případě, že někdo omylem smaže data, projeví se tato skutečnost i na zrcadle (10).

31

6 Testování Testování je nezbytné pro odhalení chyb a nedostatků vzniklých při návrhu a implementaci databáze. Testování se provádí na skutečných datech, aby simulace provozu databáze byla reálná. Během testování se odhalují datové problémy, aplikační chyby a výkonnostní nedostatky. Navíc výsledky testování poskytují i měřítko spolehlivosti a kvality použitého softwaru (3).

Mezi základní typy testování patří (5):

•

Testování výkonnosti - výkonnost databáze se testuje za různých podmínek. Při tomto testování se zpracovává velká množství operací, nebo více souběžných spojení. Obvyklé je, aby malý počet uživatelů začal pracovat s databází a pomohl tak odstranit případné chyby - datové i aplikační. Následně se připojí k databázi co největší počet uživatelů a provádí se zátěžový test. Na výkon databáze mají asi největší vliv indexy, které se ještě doplní nebo upraví na základě výsledků testování.

•

Testování zabezpečení - testují se jednotlivé skupiny uživatelů, zda mají přístup jen k požadovaným údajům a zda mohou vykonávat jen stanovené činnosti. V rámci tohoto testování se zálohují data a následně i obnovují.

•

Testování integrity dat - testují se logické nedostatky, které mají za následek ztrátu nebo nepřesnost dat. Do databáze se zkouší úmyslně vkládat chybná data, která nesmí integritní zabezpečení databáze (integritní omezení) propustit a uložit do databáze.

Testování by mělo odhalit všechny datové problémy, které se během návrhu nespecifikovaly a kterým se vhodným opatřením nepodařilo předejít.

32

7 Operace (provoz)

Jde o proces předání databáze uživateli (zadavateli). Databáze je vystavena každodennímu ostrému nasazení. V případě výskytu nových požadavků se tyto implementují během sjednané údržby (10). Provoz databáze je nejdelší etapou životního cyklu vývoje databáze. Během této etapy mohou nastat veškeré datové problémy popsané v ostatních kapitolách. Pokud jsou však dodržena všechna pravidla a doporučení je jejich eliminace opravdu výrazná.

7.1 Doladění a optimalizace databáze Po implementaci databáze je potřeba monitorovat systém a vyladit ho na základě pozorované výkonnosti. Mnoho SŘBD má utility na toto monitorování a vyladění systému za provozu. Tuto činnost je dobré provádět po celou dobu životnosti databáze (3). Faktory, které se mohou použít k měření efektivity: •

Propustnost transakcí - počat zpracovaných transakcí za časový interval.

•

Doba odezvy - čas na dokončení jedné transakce.

•

Diskový prostor - potřebné místo na uložení databáze.

Vyladění databáze přináší řadu výhod (3): •

Prodlouží životnost databáze.

•

Předejde se nákladům na pořízení dalšího hardware (disky apod.).

•

Zvyšuje produktivitu uživatelů - rychlejší odezvy, větší počet transakcí.

•

Zvyšuje spokojenost uživatelů.

33

Doba odezvy je jedním z faktorů efektivnosti databáze. Aby doba odezvy byla co nejkratší, je potřeba občas optimalizovat databázi. Optimalizace znamená zrušit a znovu vytvořit indexy. U databázových serverů to znamená spustit systémovou utilitu pro optimalizaci (například UPDATE STATISTICS). Výsledkem optimalizace je více či méně pozorovatelné urychlení aplikace. Tuto optimalizaci se doporučuje provádět po náročnějších datových operacích, například po hromadném převodu dat na začátku implementace systému, po měsíční závěrce a podobně (10).

34

8 Údržba

V této fázi se provádí monitorování výkonu, průběžná optimalizace tabulek a indexů. Aktualizuje se číselník uživatelů. Pokud je požadavek na zrušení uživatele, v žádném případě by neměl být definitivně smazán. Výhodnější je pouze ukončit platnost, tím zůstane zajištěná referenční integrita (13). V rámci bezpečnosti dat se provádí pravidelné zálohování a případná obnova. Pokud je požadavek na úpravu tabulek (tvorba nových tabulek, nebo atributů) provádí se také v rámci této fáze (10). Při návrhu databáze vzniká dokumentace, která obsahuje jednotlivé části celého návrhu. Tato dokumentace je důležitá pro pozdější změny, doplňky, nebo pro návrh nové databáze. V případě, že databázi upravujeme, musíme tuto úpravu zaznamenat i v dokumentaci. Existují dva způsoby aktualizace dokumentace (13): •

Oprava stávající dokumentace - nahradíme upravovanou část aktualizovanou verzí.

•

Změnovými listy - doplníme návrh o změnové listy.

Jedním z nejdůležitějších pravidel této části je zajištění, aby se vždy používala aktuální verze dokumentace (13).

35

9 Návrh databáze pro školní knihovnu V praktické části bakalářské práce budu aplikovat pravidla a doporučení z teoretické části a vypracuji návrh databáze pro školní knihovnu. Pro tento návrh jsem si vybrala obchodní akademii v Olomouci, především pro vstřícný přístup současné vedoucí knihovny. Školní knihovny vždy byly součástí každé školy. S rozvojem informačních technologií se začala měnit i skladba informačních zdrojů. Kromě klasických tištěných publikací, kterých je stále většina, knihovny obsahují i díla v elektronické podobě. Četba a znalost základních světových i českých autorů patří neodmyslitelně k maturitnímu vzdělání. Školní knihovny obsahují základní díla spojená s výukou, ale i rozšiřující díla sloužící především k pobavení a relaxaci. Základní potřebou každé knihovny je kvalitní databáze, ve které si mohou čtenáři filtrovat a vyhledávat požadované tituly a knihovník evidovat veškeré knihy a DVD a především jejich zapůjčování.

9.1 Analýza Obchodní akademie je střední odborná škola nabízející dva čtyřleté studijní obory zakončené maturitní zkouškou. Studijní obory jsou zaměřené na ekonomiku, účetnictví, výuku cizích jazyků a výuku práce na počítači. Škola má 38 pedagogů a studuje zde každý rok kolem 450 studentů. Školní knihovna obsahuje beletrii, odbornou literaturu, cizojazyčnou literaturu, slovníky, poezii a filmy na DVD. Čtenářem knihovny může být každý pedagog s neomezenou platností a každý student s platností do konce aktuálního školního roku. Knihy se půjčují automaticky na jeden měsíc, DVD se automaticky půjčují na jeden týden. Identifikací studenta je studijní průkaz. Studenti se evidují podle jména a příjmení, v případě shodných údajů ještě podle třídy.

36

V současné době knihovna obsahuje asi 5 500 tištěných publikací a 300 DVD nosičů. Školní knihovna má roční dotaci na nákup nových knih 5 000,- Kč. Knihy se pořizují i ve více výtiscích. Zastaralé, nebo poničené knihy i DVD se vyřazují. Databáze bude obsahovat tři moduly - evidenci čtenářů, evidenci publikací a DVD a evidenci zápůjček. Uživatelé mohou být ve skupině čtenář - omezená práva jen na čtení, nebo ve skupině knihovník - úplná práva do všech tabulek (zápis, oprava, mazání).

Z dostupných informací vytvořím předběžný seznam tabulek: Knihy - počet záznamů 10 000 ID

identifikační číslo knihy

Název

celý název díla

Autor

ID autora

ISBN

ISBN

Rok

rok vydání

Nakladatel

nakladatelství

číselník nakladatelství

Jazyk

ID jazyka

číselník jazyků

Žánr

ID žánru

číselník žánrů

Pořízeno

datum evidence

Typ

kniha, DVD

Poznámka

textové pole pro doplňující informaci

tabulka Autoři

37

Uživatelé - počet záznamů 5 000 ID

identifikační číslo čtenáře

Typ

čtenář / knihovník

Příjmení

příjmení

Jméno

jméno

Třída

třída

Platnost od

datum platnosti od

Platnost do

datum platnosti do

Poznámka

textové pole pro doplňující informaci

Zápůjčky - počet záznamů 5 000 ID

identifikační číslo záznamu zápůjčky

Kniha

ID knihy

Čtenář

ID čtenáře

Datum od

datum zápůjčky

Poznámka

textové pole pro doplňující informaci

Zápůjčky archív - počet záznamů 50 000 ID

identifikační číslo záznamu v archívu

Kniha

ID knihy

Čtenář

ID čtenáře

Datum od

datum zápůjčky

Datum do

datum vrácení

Poznámka

textové pole pro doplňující informaci

38

Číselníky: Autoři - počet záznamů 5 000 ID

ID autora

příjmení

příjmení

jméno

jméno

Jazyky - počet záznamů 10 ID

ID jazyka

Jazyk

jazyk

Žánry - počet záznamů 50 ID

ID žánru

Žánr

popis žánru

Nakladatelství - počet záznamů 500 ID

ID nakladatelství

Nakladatel

název nakladatelství

39

9.2 Definice cílů 1. Evidence nových knih a DVD. 2. Evidence autorů. 3. Evidence žánrů. 4. Evidence jazyků. 5. Evidence nových uživatelů - čtenáři a knihovníci. 6. Prodloužení platnosti registrace stávajících čtenářů. 7. Evidence zápůjček. 8. Vrácení knihy - převod do archívu zápůjček. 9. Vyřazení knihy a DVD. 10. Kontrola zápůjček podle data zápůjčky. 11. Vyhledávání dle různých podmínek (název, autor, žánr, ISBN). 12. Statistiky - zápůjček, autorů, žánrů….

9.3 Konceptuální návrh Na obrázku č. 7 je grafické znázornění konceptuálního návrhu. Jsou zde znázorněny všechny entity (budoucí tabulky) a vazby mezi nimi. Mezi entitami „Knihy“ a „Autoři“ je vzájemná kardinalita M:N, protože jedna kniha může mít více autorů a každý autor může napsat více knih. Tuto kardinalitu musí být nahrazena spojovací (vazební) tabulkou. Mezi entitami „Zápůjčky“ a „Archív“ není vyjádřena žádná kardinalita, protože záznamy v těchto tabulkách nebudou mít spolu žádný vztah. V tabulce „Zápůjčky“ budou jen záznamy o vypůjčených titulech a po vrácení se celý záznam přesune do „Archívu“ s datem vrácení.

40

Žánry

Autoři

1

1 má

N

N

N

1 Knihy

má

N 1 Je půjčena

1 1 Uživatelé

N Půjčí si

Zápůjčky

vráceno

Archív

Obr. 7 Konceptuální návrh (vlastní)

41

Nakladatel

1

má

má Spojovací tabulka

Jazyky

1 má

9.4 Logický návrh Databáze „knihovna“ bude vytvořena v relačním databázovém modelu. Entity z konceptuálního návrhu se převedou na tabulky, nadefinují se jejich atributy a určí se primární i cizí klíče. Každá tabulka bude obsahovat jednoznačný celočíselný atribut ID, který bude primárním klíčem tabulky. Po vytvoření normalizace databáze. Název každé tabulky bude: •

Jednoznačný a bude vystihovat obsah.

•

V jednotném čísle.

•

Bez diakritiky.

•

Bez mezer a jen z písmenných znaků.

Název každého sloupce bude: •

Jednoznačný.

•

Bez diakritiky.

•

Bez mezer a jen z písmenných znaků.

•

První tři znaky jsou shodné s názvem tabulky.

•

Primární a cizí klíče (relace) mají stejné názvy.

42

logického návrhu se provede

Obr. 8 Logický návrh (vlastní)

Na obrázku č. 8 je vypracovaný logický návrh databáze „knihovna“. Logický návrh databáze byl vytvořen v „MySQL Workbench“. Databáze bude obsahovat 9 tabulek. Atributy tabulek jsou popsány základními datovými typy, konečný datový typ bude stanoven podle zvoleného SŘBD.

43

Kontrola normalizace databáze: 1.NF - všechny tabulky mají primární klíč, tabulky neobsahují vícesložková ani vícehodnotová pole - podmínka je splněná. 2.NF - žádná tabulka nemá složený primární klíč - podmínka je splněná. 3.NF - všechny sloupce jsou závislé na primárním klíči - podmínka je splněná. Všechny tabulky databáze jsou ve 3.NF tzn. , že databáze je normalizovaná.

9.5 Fyzický návrh Na základě logického návrhu můžeme nyní navrhnout fyzický model databáze. Databázový systém pro školní knihovnu patří svým rozsahem k těm menším systémům, u kterého je jedním z nejdůležitějších požadavků cena. Pro tuto databázi je tedy vhodnou volbou některý z volně dostupných SŘBD. Fyzický návrh bude vypracován pro MySQL. V příloze č. 2 je úplný script pro vytvoření databáze „knihovna“, který byl automaticky vygenerován z MySQL Workbench. Popis tabulek: Tab. č. 1 Kniha - evidence knih název kniid kninaz nakid jazid zanid kniisbn knirok

popis ID knihy celý název knihy ID nakladatelství ID jazyka ID žánru ISBN rok vydání datum zařazení do knidatod evidence knityp kniha/ DVD knipozn poznámka Zdroj: vlastní

typ null unsigned unique klíč SMALLINT N A A PK VARCHAR(50) N SMALLINT A A FK TINYINT N A FK TINYINT N A FK VARCHAR(25) A YEAR A DATE TINYINT(1) VARCHAR(50)

44

A N A

A

Knityp:

1 - kniha 2 - DVD

Tab. č. 2 Autor - evidence autorů název popis autid ID autora autjmeno jméno autora autprijm příjmení autora Zdroj: vlastní

typ null unsigned unique klíč SMALLINT N A A PK VARCHAR(15) A VARCHAR(50) N

Tab. č. 3 Nakladatel - číselník nakladatelství název popis nakid ID nakladateství naknaz název nakladatelství Zdroj: vlastní

typ null unsigned unique klíč TINYINT N A A PK VARCHAR(50) N

Tab. č. 4 Jazyk - číselník jazyků název popis jazid ID jazyka jaznaz název jazyka Zdroj: vlastní

typ null unsigned unique klíč TINYINT N A A PK VARCHAR(20) N

Tab. č. 5 Zanr - číselník žánrů název popis zanid ID žánru zannaz název žánru Zdroj: vlastní

typ null unsigned unique klíč TINYINT N A A PK VARCHAR(20) N

Tab. č. 6 Napsal - vazební tabulka název popis autid ID autora kniid ID knihy Zdroj: vlastní

typ SMALLINT SMALLINT

45

null unsigned unique klíč N A PK N A PK

Tab. č. 7 Uzivatel - evidence uživatelů název popis uziid ID uživatele uziname jméno uziprijm příjmení uzityp typ uživatele uzitrida třída uziplod datum platnosti od uzipldo datum platnosti do uzipozn poznámka Zdroj: vlastní Uzityp:

typ null unsigned unique klíč SMALLINT N A A PK VARCHAR(15) N VARCHAR(30) N TINYINT(1) N A VARCHAR(10) A DATE N DATE N VARCHAR(50) A

1 - knihovník 2 - čtenář

Tab. č. 8 Zapujcka - evidence zápůjček název popis zapid ID zápůjčky uziid ID uživatele kniid ID knihy zapplod datum zápůjčky zappozn poznámka Zdroj: vlastní

typ null unsigned unique klíč INT N A A PK SMALLINT N A FK SMALLINT N A FK DATE N VARCHAR(50) A

Tab. č. 9 Archiv - archivace zápůjček název popis zapid ID zápůjčky uziid ID uživatele kniid ID knihy zapplod datum zápůjčky zappldo datum vrácení zappozn poznámka Zdroj: vlastní

typ null unsigned unique klíč INT N A A PK SMALLINT N A FK SMALLINT N A FK DATE N DATE N VARCHAR(50) A

Indexy: Indexy jsou navrženy na všechny sloupce, které jsou primárními a cizími klíči, a dále na sloupce pro předpokládané časté vyhledávání - kniha.kninaz, kniha.kniisbn, autor.autprijm, uzivatel.uziprijm

46

Integrita: Entitní integrita - každá tabulka má primární klíč, který není NULL Doménová integrita - každý sloupec má určený datový typ, stanoveno zda může být NULL a stanoveno zda hodnoty jsou unikátní. Rozsahy hodnot (domény) jsou stanoveny datovým typem, sloupce „kniha.knityp“ a „uživatel.uzityp“ mají stanovený výčet hodnot (1,2). Referenční integrita - při vyřazení (vymazání) knihy se musí vymazat všechny související odkazy z archívu zápůjček. Při vyřazování kniha nesmí být půjčena (nesmí mít odkaz v tabulce zápůjčky). Studenti (čtenáři) mají platnost na dobu určitou, pokud se bude záznam o studentovi mazat, musí se vymazat i související odkazy v archívu zápůjček. Při odstraňování záznamu o studentovi, nesmí mít student zapůjčenou knihu (nesmí mít záznam v tabulce zápůjčky). Referenční integritu zajišťují částečně triggery a částečně ji zajistí obslužná aplikace (není součástí této práce).

Navržené triggery: Odstranění záznamu z tabulky „Kniha“ CREATE TRIGGER `kniha_BDEL` BEFORE DELETE ON kniha FOR EACH ROW BEGIN DELETE FROM archiv WHERE kniid = OLD.kniid; END

Odstranění záznamu z tabulky „Uzivatel“ CREATE TRIGGER `uzivatel_BDEL` BEFORE DELETE ON uzivatel FOR EACH ROW BEGIN DELETE FROM archiv WHERE uziid = OLD.uziid; END

47

Závěr Cílem práce bylo analyzovat datové problémy, které mohou nastat během životního cyklu vývoje databáze. Z práce jednoznačně vyplývá, že většině datových problémů lze předcházet, nebo výrazně zmírnit jejich negativní následky. Existuje několik databázových modelů. Všechny musí projít během svého životního cyklu stejnými etapami. Datové problémy mohou nastat jedině ve fázi provozu, ale v každé etapě celého životního cyklu vývoje databáze je možné správným postupem a správnými činnostmi eliminovat datové problémy, které by mohly během provozu databáze nastat. V teoretické části práce jsou analyzovány jednotlivé etapy životního cyklu vývoje relační databáze. V každé etapě jsou podrobně popsány postupy, kterými je možné budoucím datovým problémům předcházet. Zároveň je popsán podrobný postup návrhu relační databáze, který je aplikován v praktické části. Data a informace jsou v dnešní době velmi ceněny. Jejich ztráta, nebo zničení znamená pro většinu firem konec existence. Bezproblémový provoz databáze je zajištěn ve dvou fázích. První je pečlivý a zodpovědný návrh databáze a druhá fáze znamená zajištění bezpečnosti během provozu. Databáze většinou potřebuje ke svému provozu obslužnou aplikaci. Další problémy, které mohou během provozu databáze nastat, jsou problémy aplikační. Analýza řešení respektive předcházení těchto problémů může navázat na tuto práci.

48

Seznam použité literatury a literárních zdrojů 1. BAČA,

Radim.

Database

[email protected].

VŠB

-

TECHNICKÁ

UNIVERZITA OSTRAVA. Database Education [online]. [cit. 2014-01-13]. Dostupné z: http://dbedu.cs.vsb.cz:8080/courses/2009-2010/sd/doc/

2. BRYLA, Bob a LONEY, Kevin. Mistrovství v Oracle Database 11g. Vyd.1. Brno: Computer Press, 2009. 700 s. ISBN 978-80-251-2189-4 3. CONOLLY a Richard HOLOWCZAK. Mistrovství - databáze: profesionální průvodce tvorbou efektivních databází. Vyd. 1. Brno: Computer Press, 2009, 584 s. ISBN 978-80-251-2328-7.

4. Databáze [online]. 2010 [cit. 2014-02-18]. Dostupné z: http://www.databaze.chytrak.cz/ 5. GILFILLAN, Ian. Myslíme v MySQL 4: knihovna programátora. 1. vyd. Praha: Grada Publishing, 2003, 750 s. ISBN 80-247-0661-X.

6. HERNANDEZ, Michael J. Návrh databází. 1. vyd. Praha: Grada, 2006, 408 s. ISBN 80-247-0900-7.

7. Interval.cz: SQL - jak na triggery. [online]. [cit. 2014-01-13]. Dostupné z: http://interval.cz/clanky/sql-jak-na-triggery/

8. KOZLOVSKÝ, Pavel a TELNAROVÁ, Zdeňka. Relační databáze - jazyk SQL: učební text pro distanční formu vzdělávání. Vyd. 1. Orlová: Obchodní akademie Orlová, 2006 (i.e. 2007). 74 s. Informatika v ekonomice v distanční formě vzdělávání na středních školách. ISBN 978-80-87113-25-7. 9. LUKASOVÁ, Alena. Úvod do databázové technologie: Určeno pro posl. 2. roč. oboru Informatika. 1. vyd. Ostrava: Ostravská univerzita, 1993, 127 s. Učební texty Ostravské univerzity. ISBN 80-704-2708-6.

49

10. OTTE, Lukáš. Databázové systémy: Studijní opory k přednáškám a cvičení z předmětu. 2012 [cit. 2013-09-25]. Dostupné z: http://homel.vsb.cz/~ott007/Predmety/databaze/Doprovodny_text_DB.pdf

11. Relační databáze - Typy relací, RDBMS, SQL, Návrh databáze: Metodologie návrhu relační databáze - první kroky [online]. 2009 [cit. 2013-09-09]. Dostupné z: http://www.managed-dedicated-servery.net/metodologie-navrhurelacni-databaze.html

12. Relational Database Design: Data Analysis | Normalization | Oracle Databases | SQL [online]. [cit. 2013-09-09]. Dostupné z: http://www.relationaldbdesign.com/relational-database-analysis/module1/introrelational-data-analysis.php 13. RIORDAN, Rebecca M. Vytváříme relační databázové aplikace. Vyd. 1. Praha: Computer Press, 2000, xiv s., 280 s. Databáze. ISBN 80-722-6360-9.

14. SCHNEIDER, Robert D. MySQL: oficiální průvodce tvorbou, správou a laděním databází. Praha: Grada Publishing, 2006, 372 s. ISBN 80-247-1516-3. 15. SPŠE INFORMATIKY A ŘEMESEL FRENŠTÁT P.R. Databázový design: Podpora výuky databázových systémů na SOŠ, založené na technologiích společnosti

ORACLE.

[online].

2011

[cit.

2013-10-13].

Dostupné

z: http://ucimedatabaze.cz/

16. ŠARMANOVÁ, J. Teorie zpracování dat [online]. Ostrava, 2003, 76 s. [cit. 2014-01-13]. Dostupné z: http://www.miroslavkrupa.cz/download/TZD_dist.pdf 17. ŠEDA, M. Databázové systémy [online]. Brno, 2002, 75 s. [cit. 2014-01-13]. Dostupné z: http://www.uai.fme.vutbr.cz/~mseda/DBS02_BS.pdf

18. TELNAROVÁ, Zdeňka. Návrh databází. Vyd. 1. Ostrava: Ostravská univerzita, 2003.

78

s.

Systém

celoživotního

ISBN 80-7042-863-5. 50

vzdělávání

Moravskoslezska.

19. TELNAROVÁ, Zdeňka. Úvod do databází. Vyd. 1. Ostrava: Ostravská univerzita, 2003. 65 s. Systém celoživotního vzdělávání Moravskoslezska. ISBN 80-7042-847-3.

20. TELNAROVÁ, Zdeňka. Vývoj databázových aplikací. Vyd. 1. Ostrava: Ostravská

univerzita,

2003.

85

s.

Systém

celoživotního

vzdělávání

Moravskoslezska. ISBN 80-7042-866-X. 21. VOSTROVSKÝ, Václav. Relační databázové systémy. Vyd. 1. Praha: ČZU PEF Praha ve vydavatelství Credit, 2001, 95 s. ISBN 80-213-0753-6.

22. 602SQL Server - Úplná dokumentace: Triggery (SQ). [online]. [cit. 2014-01-13]. Dostupné z: http://www.602.cz/602sql/wb80/napoveda/html/HE_SQL2_TRIGGERY.htm

51

Seznam obrázků Obr. 1 Vztah data, databáze, informace ........................................................................... 9 Obr. 2 Životní cyklus databáze ...................................................................................... 10 Obr. 3 Stanovení rozsahů ............................................................................................... 13 Obr. 4 Databáze zaměstnanci ......................................................................................... 15 Obr. 5 Ukázkový E-R diagram....................................................................................... 16 Obr. 6 Primární a cizí klíče ............................................................................................ 24 Obr. 7 Konceptuální návrh ............................................................................................. 41 Obr. 8 Logický návrh ..................................................................................................... 43

Seznam tabulek Tab. č. 1 Kniha - evidence knih ...................................................................................... 44 Tab. č. 2 Autor - evidence autorů .................................................................................... 45 Tab. č. 3 Nakladatel - číselník nakladatelství ................................................................. 45 Tab. č. 4 Jazyk - číselník jazyků ..................................................................................... 45 Tab. č. 5 Zanr - číselník žánrů......................................................................................... 45 Tab. č. 6 Napsal - vazební tabulka .................................................................................. 45 Tab. č. 7 Uzivatel - evidence uživatelů ........................................................................... 46 Tab. č. 8 Zapujcka - evidence zápůjček .......................................................................... 46 Tab. č. 9 Archiv - archivace zápůjček ............................................................................. 46

Seznam příloh

Příloha č. 1 : Analýza - otázky Příloha č. 2: Návrh database - SQL script 52

Příloha č. 1 - Analýza - otázky Dotazy na organizaci • • • • • • •

Jaký je účel dané organizace? Jaký je hlavní záměr organizace? Jaká je hlavní funkce organizace? Jak je možné popsat, co dělá organizace? Jaká je organizační struktura v organizaci? Kolik máte zaměstnanců? Jakou mají zaměstnanci pracovní náplň?

Dotazy na existující databázi • • • • •

Proč je potřeba nová databáze? Jaká data se budou do databáze ukládat? Jaká data a odkud budou do databáze vstupovat? Jaké informace a v jakém formátu budou z databáze vystupovat? Jaký systém v současné době organizace používá?

Dotazy na použití databáze (ve vztahu rozhovoru s uživateli a managementem) • • • • • • • • • •

Jak s databází pracují jednotlivé skupiny uživatelů? Jaké aplikace přistupují k databázi? Jaké jsou požadavky jednotlivých skupin uživatelů na informace? Jaká omezení se rýsují? Jak je definován popis práce jednotlivých uživatelů? Jakou práci denně vykonávají? S jakým typem dat pracují? Jaké věci se sledují a zaznamenávají a jaké druhy zpráv a hlášení jsou vyžadovány? Existují ještě nějaké další věci, které by bylo dobré do databáze implementovat? Jaký je výhled na budoucí rozšíření organizace a tím i rozšíření databáze?

Příloha č. 2 - Návrh databáze - SQL script SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0; SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0; SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES'; DROP SCHEMA IF EXISTS `knihovna` ; CREATE SCHEMA IF NOT EXISTS `knihovna` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ; SHOW WARNINGS; USE `knihovna` ;

-- Table `jazyk` DROP TABLE IF EXISTS `jazyk` ; SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `jazyk` ( `jazid` TINYINT UNSIGNED NOT NULL AUTO_INCREMENT , `jaznaz` VARCHAR(20) NOT NULL , PRIMARY KEY (`jazid`) ) ENGINE = InnoDB; SHOW WARNINGS; CREATE INDEX `jaznaz` ON `jazyk` (`jaznaz` ASC) ; SHOW WARNINGS;

-- Table `nakladatel` DROP TABLE IF EXISTS `nakladatel` ; SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `nakladatel` ( `nakid` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT , `naknaz` VARCHAR(50) NOT NULL , PRIMARY KEY (`nakid`) ) ENGINE = InnoDB; SHOW WARNINGS; CREATE INDEX `naknaz` ON `nakladatel` (`naknaz` ASC) ;

SHOW WARNINGS;

-- Table `zanr` DROP TABLE IF EXISTS `zanr` ; SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `zanr` ( `zanid` TINYINT UNSIGNED NOT NULL AUTO_INCREMENT , `zannaz` VARCHAR(20) NOT NULL , PRIMARY KEY (`zanid`) ) ENGINE = InnoDB;

SHOW WARNINGS; CREATE INDEX `zannaz` ON `zanr` (`zannaz` ASC) ; SHOW WARNINGS;

-- Table `napsal` DROP TABLE IF EXISTS `napsal` ; SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `napsal` ( `autid` SMALLINT UNSIGNED NOT NULL , `kniid` SMALLINT UNSIGNED NOT NULL , PRIMARY KEY (`autid`, `kniid`) ) ENGINE = InnoDB; SHOW WARNINGS;

-- Table `kniha` DROP TABLE IF EXISTS `kniha` ; SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `kniha` ( `kniid` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT , `kninaz` VARCHAR(50) NOT NULL , `nakid` SMALLINT UNSIGNED NULL , `jazid` TINYINT UNSIGNED NOT NULL , `zanid` TINYINT UNSIGNED NOT NULL , `kniisbn` VARCHAR(25) NULL ,

`knirok` YEAR NULL , `knityp` TINYINT(1) UNSIGNED NOT NULL DEFAULT 1 , `knidatod` DATE NULL , `knipozn` VARCHAR(50) NULL , PRIMARY KEY (`kniid`) ) ENGINE = InnoDB;

SHOW WARNINGS; CREATE INDEX `kniisbn` ON `kniha` (`kniisbn` ASC) ; SHOW WARNINGS; CREATE INDEX `zanid` ON `kniha` (`zanid` ASC) ; SHOW WARNINGS; CREATE INDEX `jazid` ON `kniha` (`jazid` ASC) ; SHOW WARNINGS; CREATE INDEX `nakid` ON `kniha` (`nakid` ASC) ; SHOW WARNINGS; CREATE INDEX `kninaz` ON `kniha` (`kninaz` ASC) ; SHOW WARNINGS;

-- Table `autor` DROP TABLE IF EXISTS `autor` ; SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `autor` ( `autid` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT , `autjmeno` VARCHAR(15) NULL , `autprijm` VARCHAR(50) NOT NULL , PRIMARY KEY (`autid`) ) ENGINE = InnoDB; SHOW WARNINGS; CREATE INDEX `autprijm` ON `autor` (`autprijm` ASC) ; SHOW WARNINGS;

-- Table `uzivatel` DROP TABLE IF EXISTS `uzivatel` ;

SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `uzivatel` ( `uziid` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT , `uziname` VARCHAR(15) NOT NULL , `uziprijm` VARCHAR(30) NOT NULL , `uzityp` TINYINT(1) NOT NULL DEFAULT 2 , `uzitrida` VARCHAR(10) NULL , `uziplod` DATE NOT NULL , `uzipldo` DATE NOT NULL , `uzipozn` VARCHAR(50) NULL , PRIMARY KEY (`uziid`) ) ENGINE = InnoDB; SHOW WARNINGS; CREATE INDEX `uziprijm` ON `uzivatel` (`uziprijm` ASC, `uziname` ASC) ; SHOW WARNINGS;

-- Table `zapujcka` DROP TABLE IF EXISTS `zapujcka` ; SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `zapujcka` ( `zapid` INT UNSIGNED NOT NULL AUTO_INCREMENT , `uziid` SMALLINT UNSIGNED NOT NULL , `kniid` SMALLINT UNSIGNED NOT NULL , `zapplod` DATE NOT NULL , `zappozn` VARCHAR(50) NULL , PRIMARY KEY (`zapid`) ) ENGINE = InnoDB;

SHOW WARNINGS; CREATE INDEX `uziid` ON `zapujcka` (`uziid` ASC) ;

SHOW WARNINGS; CREATE INDEX `kniid` ON `zapujcka` (`kniid` ASC) ;

SHOW WARNINGS;

-- Table `archiv` DROP TABLE IF EXISTS `archiv` ; SHOW WARNINGS; CREATE TABLE IF NOT EXISTS `archiv` ( `zapid` INT UNSIGNED NOT NULL AUTO_INCREMENT , `uziid` SMALLINT UNSIGNED NOT NULL , `kniid` SMALLINT UNSIGNED NOT NULL , `zapplod` DATE NOT NULL , `zappldo` DATE NOT NULL , `zappozn` VARCHAR(50) NULL , PRIMARY KEY (`zapid`) ) ENGINE = InnoDB;

SHOW WARNINGS; CREATE INDEX `uziid` ON `archiv` (`uziid` ASC) ; SHOW WARNINGS; CREATE INDEX `kniid` ON `archiv` (`kniid` ASC) ; SHOW WARNINGS; USE `knihovna` ; USE `knihovna`; DELIMITER $$

USE `knihovna`$$ DROP TRIGGER IF EXISTS `kniha_BDEL` $$ SHOW WARNINGS$$

USE `knihovna`$$ CREATE TRIGGER `kniha_BDEL` BEFORE DELETE ON kniha FOR EACH ROW BEGIN DELETE FROM archiv WHERE kniid = OLD.kniid; END

$$ SHOW WARNINGS$$ DELIMITER ; DELIMITER $$

USE `knihovna`$$ DROP TRIGGER IF EXISTS `uzivatel_BDEL` $$ SHOW WARNINGS$$ USE `knihovna`$$

CREATE TRIGGER `uzivatel_BDEL` BEFORE DELETE ON uzivatel FOR EACH ROW BEGIN DELETE FROM archiv WHERE uziid = OLD.uziid; END $$ SHOW WARNINGS$$ DELIMITER ;

SET SQL_MODE=@OLD_SQL_MODE; SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS; SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

ANOTACE Jméno a příjmení:

Lenka Koutná

Katedra:

Katedra technické a informační výchovy

Vedoucí práce:

Mgr. Jan Kubrický, Ph.D.

Rok obhajoby:

2014

Název práce:

Řešení datových problémů během životního cyklu vývoje databáze

Název v angličtině:

Solution of data problems during the life cycle of database development

Anotace práce:

Bakalářská práce se zabývá životním cyklem vývoje databáze. V každé etapě tohoto cyklu jsou analyzovány datové problémy, které by mohly nastat a zároveň činnosti návrháře, kterými jsou tyto problémy eliminovány. V teoretické části je také podrobně popsán návrh relační databáze. V praktické části je tento návrh realizován v podobě databáze pro školní knihovnu.

Klíčová slova:

Data, informace, databáze, relační databáze, SŘBD-systém řízení báze dat, integrita, normalizace

Anotace v angličtině:

The Bachelor Thesis deals with the life cycle of a database development. At each stage of this cycle data problems, which could arise, and at the same time the activities of the designer, which eliminate these problems, are analysed. In the theoretical part the design of the relational database is described in detail, too. In the practical part of this proposal the design in form of a database for a school library is implemented.

Klíčová slova v angličtině:

Data, information, databases, relational database, DBMSdata base management system, integrity, standardisation

Přílohy vázané v práci:

Příloha č. 1 : Analýza - otázky Příloha č. 2: Návrh database - SQL script

Rozsah práce:

52 s.

Jazyk práce:

český jazyk