UNIVERZITA PALACKÉHO V OLOMOUCI

Transkript

1 UNIVERZITA PALACKÉHO V OLOMOUCI PEDAGOGICKÁ FAKULTA Bakalářská práce 2014 Lenka Koutná

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

3 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:

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

5 Obsah: Úvod... 7 Cíle práce Základní pojmy Životní cyklus vývoje databáze Analýza požadavků Analýza organizace Definice problémů a omezení Definice cílů a rozsahů Návrh Konceptuální úroveň Logická úroveň Normalizace databáze Fyzická úroveň Datové typy a hodnota NULL Klíče Indexy Integrita dat Triggery Implementace Vytvoření databáze Konverze a načtení dat Uživatelské zabezpečení Zabezpečení databáze Zálohování Testování Operace (provoz) Doladění a optimalizace databáze Údržba Návrh databáze pro školní knihovnu Analýza Definice cílů... 40

6 9.3 Konceptuální návrh Logický návrh Fyzický návrh Závěr Seznam použité literatury a literárních zdrojů Seznam obrázků Seznam tabulek Seznam příloh Příloha č. 1 - Analýza - otázky Příloha č. 2 - Návrh databáze - SQL script... 54

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

8 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

9 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). data Insert Databáze Select informace Obr. 1 Vztah data, databáze, informace (vlastní) 9

10 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

11 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

12 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

13 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

14 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

15 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

16 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 1 Funkce Osoba N pracuje v 1 Ú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

17 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

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

19 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

20 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

21 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

22 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

23 Další problémy, které mohou nastat zvolením špatného datového typu, jsou např.: 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

24 Obr. 6 Primární a cizí klíče (vlastní) 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

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

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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 V současné době knihovna obsahuje asi 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ů ID Název identifikační číslo knihy celý název díla Autor ID autora tabulka Autoři ISBN Rok ISBN rok vydání Nakladatel nakladatelství číselník nakladatelství Jazyk ID jazyka číselník jazyků Žánr ID žánru číselník žánrů Pořízeno Typ Poznámka datum evidence kniha, DVD textové pole pro doplňující informaci 37

38 Uživatelé - počet záznamů ID Typ Příjmení Jméno Třída Platnost od Platnost do Poznámka identifikační číslo čtenáře čtenář / knihovník příjmení jméno třída datum platnosti od datum platnosti do textové pole pro doplňující informaci Zápůjčky - počet záznamů ID Kniha Čtenář Datum od Poznámka identifikační číslo záznamu zápůjčky ID knihy ID čtenáře datum zápůjčky textové pole pro doplňující informaci Zápůjčky archív - počet záznamů ID Kniha Čtenář Datum od Datum do Poznámka identifikační číslo záznamu v archívu ID knihy ID čtenáře datum zápůjčky datum vrácení textové pole pro doplňující informaci 38

39 Číselníky: Autoři - počet záznamů ID příjmení jméno ID autora příjmení jméno Jazyky - počet záznamů 10 ID Jazyk ID jazyka jazyk Žánry - počet záznamů 50 ID Žánr ID žánru popis žánru Nakladatelství - počet záznamů 500 ID Nakladatel ID nakladatelství název nakladatelství 39

40 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

41 Autoři Žánry Jazyky Nakladatel má má má má Spojovací tabulka N N 1 N má Knihy 1 N Je půjčena 1 Uživatelé 1 Půjčí si N Zápůjčky vráceno Archív Obr. 7 Konceptuální návrh (vlastní) 41

42 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í logického návrhu se provede 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

43 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

44 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 popis typ null unsigned unique klíč kniid ID knihy SMALLINT N A A PK kninaz celý název knihy VARCHAR(50) N nakid ID nakladatelství SMALLINT A A FK jazid ID jazyka TINYINT N A FK zanid ID žánru TINYINT N A FK kniisbn ISBN VARCHAR(25) A knirok rok vydání YEAR A knidatod datum zařazení do evidence DATE A knityp kniha/ DVD TINYINT(1) N A knipozn poznámka VARCHAR(50) A Zdroj: vlastní 44

45 Knityp: 1 - kniha 2 - DVD Tab. č. 2 Autor - evidence autorů název popis typ null unsigned unique klíč autid ID autora SMALLINT N A A PK autjmeno jméno autora VARCHAR(15) A autprijm příjmení autora VARCHAR(50) N Zdroj: vlastní Tab. č. 3 Nakladatel - číselník nakladatelství název popis typ null unsigned unique klíč nakid ID nakladateství TINYINT N A A PK naknaz název nakladatelství VARCHAR(50) N Zdroj: vlastní Tab. č. 4 Jazyk - číselník jazyků název popis typ null unsigned unique klíč jazid ID jazyka TINYINT N A A PK jaznaz název jazyka VARCHAR(20) N Zdroj: vlastní Tab. č. 5 Zanr - číselník žánrů název popis typ null unsigned unique klíč zanid ID žánru TINYINT N A A PK zannaz název žánru VARCHAR(20) N Zdroj: vlastní Tab. č. 6 Napsal - vazební tabulka název popis typ null unsigned unique klíč autid ID autora SMALLINT N A PK kniid ID knihy SMALLINT N A PK Zdroj: vlastní 45