UNIVERZITA PALACKÉHO V OLOMOUCI

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "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

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

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

Více

7. Integrita a bezpečnost dat v DBS

7. Integrita a bezpečnost dat v DBS 7. Integrita a bezpečnost dat v DBS 7.1. Implementace integritních omezení... 2 7.1.1. Databázové triggery... 5 7.2. Zajištění bezpečnosti dat... 12 7.2.1. Bezpečnostní mechanismy poskytované SŘBD... 13

Více

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

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

Více

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

Úvod do databází. Modelování v řízení. Ing. Petr Kalčev Úvod do databází Modelování v řízení Ing. Petr Kalčev Co je databáze? Množina záznamů a souborů, které jsou organizovány za určitým účelem. Jaké má mít přínosy? Rychlost Spolehlivost Přesnost Bezpečnost

Více

Obchodní akademie a Jazyková škola s právem státní jazykové zkoušky Jihlava

Obchodní akademie a Jazyková škola s právem státní jazykové zkoušky Jihlava Obchodní akademie a Jazyková škola s právem státní jazykové zkoušky Jihlava Šablona 32 VY_32_INOVACE_038.ICT.34 Tvorba webových stránek SQL stručné minimum OA a JŠ Jihlava, VY_32_INOVACE_038.ICT.34 Číslo

Více

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

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

Více

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

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

Více

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

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

Více

12. blok Fyzický návrh databáze

12. blok Fyzický návrh databáze 12. blok Fyzický návrh databáze Studijní cíl Tento studijní blok se zabývá metodologií fyzického návrhu databáze. Především se zabývá fází převodu logického modelu na model fyzický. Bude vysvětlen účel

Více

Inovace a zkvalitnění výuky prostřednictvím ICT. Základní seznámení s MySQL Ing. Kotásek Jaroslav

Inovace a zkvalitnění výuky prostřednictvím ICT. Základní seznámení s MySQL Ing. Kotásek Jaroslav Střední průmyslová škola a Vyšší odborná škola technická Brno, Sokolská 1 Šablona: Název: Téma: Autor: Číslo: Anotace: Inovace a zkvalitnění výuky prostřednictvím ICT Databáze Základní seznámení s MySQL

Více

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

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

Více

Základy jazyka SQL. 87 Jazyk SQL SQL je dotazovací jazyk, takže přes propojenou aplikaci se serveru odevzdá dotaz

Základy jazyka SQL. 87 Jazyk SQL SQL je dotazovací jazyk, takže přes propojenou aplikaci se serveru odevzdá dotaz Základy jazyka SQL 87 Jazyk SQL SQL je dotazovací jazyk, takže přes propojenou aplikaci se serveru odevzdá dotaz a databázový server na něj odpoví, obvykle tím, že vygeneruje nějakou množinu výstupních

Více

Použití databází na Webu

Použití databází na Webu 4IZ228 tvorba webových stránek a aplikací Jirka Kosek Poslední modifikace: $Date: 2010/11/18 11:33:52 $ Obsah Co nás čeká... 3 Architektura webových databázových aplikací... 4 K čemu se používají databázové

Více

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

Analýza a modelování dat 3. přednáška. Helena Palovská Analýza a modelování dat 3. přednáška Helena Palovská Historie databázových modelů Relační model dat Codd, E.F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM

Více

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

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

Více

Databáze v MS ACCESS

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

Více

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_33_02 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

Více

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Číslo projektu: Číslo šablony: Název materiálu: Ročník: Identifikace materiálu: Jméno autora: Předmět: Tématický celek: Anotace: CZ.1.07/1.5.00/34.0410

Více

Stěhování aplikací. Michal Tomek, Sales Manager

Stěhování aplikací. Michal Tomek, Sales Manager Stěhování aplikací Michal Tomek, Sales Manager Agenda Co míníme stěhováním Typické situace Role InterSystems Příležitosti Migrace Stěhování informačního systému Nová budova. HW a OS Získáme nové vlastnosti

Více

Bezepečnost IS v organizaci

Bezepečnost IS v organizaci Bezepečnost IS v organizaci analýza rizik Zabezpečení informačního systému je nutné provést tímto postupem: Zjistit zranitelná místa, hlavně to, jak se dají využít a kdo toho může zneužít a pravděpodobnost

Více

Database engine (databázový stroj, databázový motor, databázové jádro) Systém řízení báze dat SŘBD. Typy SŘBD podle způsobu práce s daty

Database engine (databázový stroj, databázový motor, databázové jádro) Systém řízení báze dat SŘBD. Typy SŘBD podle způsobu práce s daty Systém řízení báze dat SŘBD programový systém umožňující vytvoření, údržbu a použití báze dat databáze program Database engine (databázový stroj, databázový motor, databázové jádro) funkce: přenos (načítání)

Více

01. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980

01. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980 01. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980 02. Kdy přibližně vznikly první komerční relační databázové servery?

Více

Databázové a informační systémy Jana Šarmanová

Databázové a informační systémy Jana Šarmanová Databázové a informační systémy Jana Šarmanová Obsah Úloha evidence údajů, způsoby evidování Databázové technologie datové modely, dotazovací jazyky. Informační systémy Datové sklady Metody analýzy dat

Více

Microsoft Access. Typy objektů databáze: Vytvoření a návrh nové tabulky. Vytvoření tabulky v návrhovém zobrazení

Microsoft Access. Typy objektů databáze: Vytvoření a návrh nové tabulky. Vytvoření tabulky v návrhovém zobrazení Microsoft Access Databáze je seskupení většího množství údajů, které mají určitou logiku a lze je určitým způsobem vyhodnocovat, zpracovávat a analyzovat Access je jedním z programů určených pro zpracování

Více

Hierarchický databázový model

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

Více

Databáze ArcView) Databázový systém

Databáze ArcView) Databázový systém Databázový systém Databáze (pro začínaj nající uživatele ArcView) Přednáška. Datová základna: soubor všech uživatelských dat uložených v databázi Databázový systém = data + nástroje pro práci s daty. Access.

Více

Databázové systémy I

Databázové systémy I Databázové systémy I Přednáška č. 8 Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky jiri.zechmeister@upce.cz Skupinové a souhrnné dotazy opakování Obsah Pohledy syntaxe použití význam Vnořené

Více

5. Formalizace návrhu databáze

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

Více

InnoDB transakce, cizí klíče, neumí fulltext (a nebo už ano?) CSV v textovém souboru ve formátu hodnot oddělených čárkou

InnoDB transakce, cizí klíče, neumí fulltext (a nebo už ano?) CSV v textovém souboru ve formátu hodnot oddělených čárkou MySQL Typy tabulek Storage Engines MyISAM defaultní, neumí transakce, umí fulltext InnoDB transakce, cizí klíče, neumí fulltext (a nebo už ano?) MEMORY (HEAP) v paměti; neumí transakce ARCHIVE velké množství

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Základní principy XML

Informační systémy 2008/2009. Radim Farana. Obsah. Základní principy XML 10 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Export a import dat Formát XML a SQL server Zálohování a obnova

Více

Databáze Bc. Veronika Tomsová

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

Více

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

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

Více

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19 3 Obsah Novinky v tomto vydání 10 Význam základních principů 11 Výuka principů nezávisle na databázových produktech 12 Klíčové pojmy, kontrolní otázky, cvičení, případové studie a projekty 12 Software,

Více

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

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

Více

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

KATALOG SLUŽEB NÁSLEDNÉ PODPORY KATALOG SLUŽEB NÁSLEDNÉ PODPORY Společnost WEBCOM a. s. Vám nabízí kompletní pokrytí Vašich požadavků na zajištění služeb technické podpory Microsoft Dynamics přesně podle Vašich potřeb a v požadovaném

Více

Práva a role. Martin Polák. NDBI013 Administrace Oracle

Práva a role. Martin Polák. NDBI013 Administrace Oracle Práva a role Martin Polák NDBI013 Administrace Oracle Práva a role Práva slouží k omezení možností uživatele právě tak, aby mohl provádět úkoly jemu svěřené. Role jsou pojmenované skupiny práv a slouží

Více

Databáze s tisíci uložených procedur. Pavel Bláhovec, DiS www.blahovec.cz pavel@blahovec.cz

Databáze s tisíci uložených procedur. Pavel Bláhovec, DiS www.blahovec.cz pavel@blahovec.cz Databáze s tisíci uložených procedur Pavel Bláhovec, DiS www.blahovec.cz pavel@blahovec.cz Kdo jsem 1/2 Vývojem software se zabývám přes 15 let Mobilní aplikace pro obchodníky Wella PageMaker plug in pro

Více

2. blok část A Jazyk SQL, datové typy

2. blok část A Jazyk SQL, datové typy 2. blok část A Jazyk SQL, datové typy Studijní cíl Tento blok je věnován jazyku SQL, jeho vývoji, standardizaci a problémy s přenositelností. Dále je zde uveden přehled datových typů dle standardu SQL

Více

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

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

Více

Registr rizik. Dopad kvantifikujeme podle matice níže. 2 Malý dopad. 3 Střední dopad. 4 Vysoký dopad. 5 Velmi vysoký dopad. malý dopad.

Registr rizik. Dopad kvantifikujeme podle matice níže. 2 Malý dopad. 3 Střední dopad. 4 Vysoký dopad. 5 Velmi vysoký dopad. malý dopad. Registr rizik Co je Registr rizik a k čemu slouží S každým projektem jsou spojena určitá rizika, tedy nejisté události, které mohou nastat a ovlivnit (zpravidla negativně) průběh. Analýza rizik je samostatnou

Více

Koncepce jazyka SQL Co je SQL

Koncepce jazyka SQL Co je SQL Koncepce jazyka SQL Tato kapitola obsahuje základní informace o jazyku SQL, na kterých budeme stavět ve zbývající části knihy. Jazyk SQL se prosadil jako univerzální jazyk relačních databází a podporují

Více

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

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

Více

Indexace pro souborová uložiště a Vyhledávací centrum

Indexace pro souborová uložiště a Vyhledávací centrum Indexace pro souborová uložiště a Vyhledávací centrum Obsah I. Úvod... 2 II. Cíl dokumentu... 2 III. Fáze projektu... 2 IV. Popis jednotlivých fází projektu... 2 1. Fáze 1. - Analýza... 2 2. Fáze 2. -

Více

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

Marketingová komunikace. 1. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3aph) 1. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Co nás čeká I. Úvod do teorie DB systémů

Více

Terminologie v relačním modelu

Terminologie v relačním modelu 3. RELAČNÍ MODEL Relační model reprezentuje databázi jako soubor relací. Každá relace představuje tabulku nebo soubor ( ve smyslu soubor na nosiči dat ). Terminologie v relačním modelu řádek n-tice ( n-tuple,

Více

13. blok Práce s XML dokumenty v databázi Oracle

13. blok Práce s XML dokumenty v databázi Oracle 13. blok Práce s XML dokumenty v databázi Oracle Studijní cíl Tento blok je věnován práci s XML dokumenty, možnostmi jejich uložení a práce s nimi v databázi Oracle a datovému typu XMLType. Doba nutná

Více

SKLAD ODPADŮ modul EKO-KOM

SKLAD ODPADŮ modul EKO-KOM SKLAD ODPADŮ modul EKO-KOM Obsah dokumentu Tento dokument popisuje funkcionalitu modulu EKO-KOM v programu Sklad odpadů 8 (dále jen SKLAD). Cílová skupina komu je modul EKO-KOM v programu SKLAD určen Modul

Více

RELAČNÍ DATABÁZE ACCESS

RELAČNÍ DATABÁZE ACCESS RELAČNÍ DATABÁZE ACCESS 1. Úvod... 2 2. Základní pojmy... 3 3. Vytvoření databáze... 5 4. Základní objekty databáze... 6 5. Návrhové zobrazení tabulky... 7 6. Vytváření tabulek... 7 6.1. Vytvoření tabulky

Více

J. Zendulka: Databázové systémy 4 Relační model dat 1

J. Zendulka: Databázové systémy 4 Relační model dat 1 4. Relační model dat 4.1. Relační struktura dat... 3 4.2. Integritní pravidla v relačním modelu... 9 4.2.1. Primární klíč... 9 4.2.2. Cizí klíč... 11 4.2.3. Relační schéma databáze... 13 4.3. Relační algebra...

Více

Po registraci modulu E-SHOPY se v programu DUEL zpřístupní nabídky Seznam e-shopů a Objednávky přijaté - e-shop.

Po registraci modulu E-SHOPY se v programu DUEL zpřístupní nabídky Seznam e-shopů a Objednávky přijaté - e-shop. Modul E-SHOP Jedním z doplňků ke skladům v programu DUEL je modul E-SHOPY, který umožňuje synchronizaci mezi databází programu DUEL a fyzickým e-shopem. Synchronizace dat je optimalizována pro použití

Více

DATABÁZE MS ACCESS 2010

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

Více

Semestrální práce z DAS2 a WWW

Semestrální práce z DAS2 a WWW Univerzita Pardubice Fakulta elektrotechniky a informatiky Semestrální práce z DAS2 a WWW Databázová část Matěj Trakal 8.12.2009 Kapitola 1: Obsah KAPITOLA 1: OBSAH 2 KAPITOLA 2: ZÁKLADNÍ CHARAKTERISTIKA

Více

Backup & recovery, SQL Server Agent, Alerts Jiří Tomeš

Backup & recovery, SQL Server Agent, Alerts Jiří Tomeš Backup & recovery, SQL Server Agent, Alerts Jiří Tomeš Administrace MS SQL Serveru (NDBI039) Úvodní motivace O čem to dnes bude Strategie zálohování Typy zálohování SQL Server Agent Modely pro obnovení

Více

Jak efektivně ochránit Informix?

Jak efektivně ochránit Informix? Jak efektivně ochránit Informix? Jan Musil jan_musil@cz.ibm.com Informix CEE Technical Sales Information Management Jsou Vaše data chráněna proti zneužití? 2 Ano, pokud... 3 Nepoužitelné Steve Mandel,

Více

Relační model reprezentuje databázi jako soubor relací. Kaţdá relace představuje tabulku nebo soubor (ve smyslu soubor na nosiči dat).

Relační model reprezentuje databázi jako soubor relací. Kaţdá relace představuje tabulku nebo soubor (ve smyslu soubor na nosiči dat). 3. Relační model Relační model reprezentuje databázi jako soubor relací. Kaţdá relace představuje tabulku nebo soubor (ve smyslu soubor na nosiči dat). Příklad 3.1: Filmová databáze relace: FILM REŢISÉR

Více

Vyšší odborná škola a Střední průmyslová škola, Šumperk, Gen. Krátkého 1

Vyšší odborná škola a Střední průmyslová škola, Šumperk, Gen. Krátkého 1 Vypracovala: Dům u Černé Matky Boží v Praze Šárka Štolcová Nejstarší stavba kubistického slohu v Praze. Počítačový model byl vytvořen v programu 3D Studio Max. Sloup nejsvětější Trojice v Olomouci Jan

Více

Databáze. Velmi stručný a zjednodušený úvod do problematiky databází pro programátory v Pythonu. Bedřich Košata

Databáze. Velmi stručný a zjednodušený úvod do problematiky databází pro programátory v Pythonu. Bedřich Košata Databáze Velmi stručný a zjednodušený úvod do problematiky databází pro programátory v Pythonu Bedřich Košata K čemu jsou databáze Ukládání dat ve strukturované podobě Možnost ukládat velké množství dat

Více

Technologické postupy práce s aktovkou IS MPP

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

Více

Principy UML. Clear View Training 2005 v2.2 1

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

Více

2. blok Zabezpečení a ochrana dat

2. blok Zabezpečení a ochrana dat 2. blok Zabezpečení a ochrana dat Studijní cíl Tento blok je věnován základům zabezpečení a ochrany dat uložených v relačních databázích, tj. uživatelským účtům, systémovým a objektovým oprávněním a rolím.

Více

5 Požadavky a jejich specifikace

5 Požadavky a jejich specifikace 5 Požadavky a jejich specifikace 5.1 Inženýrství (requirements engineering) - proces stanovení služeb, které by měl vyvíjený systém poskytovat a omezení, za nichž musí pracovat - CO má systém dělat, ne

Více

Zkouškový příklad 4IT218 Rezervační systém zážitkové agentury. Karel Kohout karel@kohout.se FIS VŠE

Zkouškový příklad 4IT218 Rezervační systém zážitkové agentury. Karel Kohout karel@kohout.se FIS VŠE Zkouškový příklad 4IT218 Rezervační systém zážitkové agentury karel@kohout.se 25. února 2011 Obsah 1 Zadání 2 2 SQL 6 2.1 Definice tabulek............................ 6 2.2 Definice indexů............................

Více

Novinky v aplikaci. Nový modul Trasy Nové ceny GPS jednotek Security. Rychlý průvodce Administrátora, Alerty, Autopůjčovnou

Novinky v aplikaci. Nový modul Trasy Nové ceny GPS jednotek Security. Rychlý průvodce Administrátora, Alerty, Autopůjčovnou Nový modul Trasy Nové ceny GPS jednotek Security v aplikaci V Security funkcích, které jsou nově ve verzích Car Control Basic a Standard, vás seznámíme s možností využití alertů například pro dohled nad

Více

BrightStor ARCserve Backup r11.5. - Michal Opatřil - Consultant - michal.opatril@ca.com

BrightStor ARCserve Backup r11.5. - Michal Opatřil - Consultant - michal.opatril@ca.com BrightStor ARCserve Backup r11.5 - Michal Opatřil - Consultant - michal.opatril@ca.com Co je ARCserve Backup? -Spolehlivý a jednoduchý Backup a Restore -S podporou široké škály hardwaru -S managementem

Více

Nastavení propojení s eshopem

Nastavení propojení s eshopem Nastavení propojení s eshopem Vytvoření párovacích polí na databázi eshopu! Není nutné upravovat databázi pro použití zkušební verze programu. Tento krok můžete při použití zkušební verze přeskočit. Pro

Více

Projekt informačního systému pro Eklektik PRO S EK. Řešitel: Karolína Kučerová

Projekt informačního systému pro Eklektik PRO S EK. Řešitel: Karolína Kučerová Projekt informačního systému pro Eklektik PRO S EK Řešitel: ÚVODNÍ ZPRÁVA ZADÁNÍ PROJEKTU Zefektivnění komunikace ve firmě Eklektik, a to především v oblasti informací o klientech a o tištěných materiálech

Více

Stručný obsah. část III Aktualizace dat Kapitola 10: Aktualizace databáze 257 Kapitola 11: Integrita dat 275 Kapitola 12: Zpracování transakcí 307

Stručný obsah. část III Aktualizace dat Kapitola 10: Aktualizace databáze 257 Kapitola 11: Integrita dat 275 Kapitola 12: Zpracování transakcí 307 Stručný obsah část I Přehled jazyka SQL Kapitola 1: Úvod 27 Kapitola 2: Stručný úvod do jazyka SQL 37 Kapitola 3: Jazyk SQL z širšího pohledu 45 Kapitola 4: Relační databáze 69 Část II Získávání dat Kapitola

Více

Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní. Studijní opory k přednáškám a cvičení z předmětu. Databázové systémy

Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní. Studijní opory k přednáškám a cvičení z předmětu. Databázové systémy Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní Studijní opory k přednáškám a cvičení z předmětu Databázové systémy Ing. Lukáš OTTE, Ph.D. Ostrava 2012 Anotace Cílem předkládaných studijních

Více

Datové modelování II

Datové modelování II Datové modelování II Atributy Převod DM do schématu SŘBD Dotazovací jazyk SQL Multidimenzionální modelování Principy Doc. Miniberger, BIVŠ Atributy Atributem entity budeme rozumět název záznamu či informace,

Více

Popis programu EnicomD

Popis programu EnicomD Popis programu EnicomD Pomocí programu ENICOM D lze konfigurovat výstup RS 232 přijímačů Rx1 DIN/DATA a Rx1 DATA (přidělovat textové řetězce k jednotlivým vysílačům resp. tlačítkům a nastavovat parametry

Více

Edu-learning pro školy

Edu-learning pro školy Edu-learning pro školy ONLINE VARIANTA Příručka pro instalaci a správu EDU 2000 s.r.o. Počítačové vzdělávání a testování Oldřichova 49 128 00 Praha 2 www.edu2000.cz info@edu2000.cz www.edu-learning.cz

Více

Semestrální práce 4IT450

Semestrální práce 4IT450 Předmět: 4IT450 Den a čas cvičení: Út 9.15 10.45 Zimní semestr 2010/2011 Semestrální práce 4IT450 Podpora CASE při vytváření databází Jméno: Veronika Honová Tomáš Jedlička Martin Potančok Jan Pávek 1 Obsah

Více

2 Konceptuální modelování a návrh databáze

2 Konceptuální modelování a návrh databáze 2 Konceptuální modelování a návrh databáze 2.1. Úloha konceptuálního modelování v procesu návrhu databáze... 2 2.2. E - R modely... 6 2.3. Doporučení pro modelování a tvorbu ER diagramu... 22 2.4. Transformace

Více

Data x Informace x Znalosti

Data x Informace x Znalosti Ing. Jan Král Jak to vidíme Program MS Excel je rozšířen a běžně dostupný bez dalších nákladů na převážné většině pracovišť, i pracovišť zabývajících se řízením jakosti a spolehlivosti, zpracovávajících

Více

Databázové systémy 1 KIV/DB1

Databázové systémy 1 KIV/DB1 Databázové systémy 1 KIV/DB1 Celá kniha je exportem z wikipedie, ale spolehlivě pokrývá rozsah znalostí pro tento předmět. Obsah Články Systém řízení báze dat 1 Databáze 2 Relační databáze 5 Relační model

Více

2 Konceptuální modelování a návrh databáze

2 Konceptuální modelování a návrh databáze 2 Konceptuální modelování a návrh databáze 2.. Úloha konceptuálního modelování v procesu návrhu databáze... 2 2.2. E - R modely... 6 2.3. Doporučení pro modelování a tvorbu ER diagramu... 22 2.4. Transformace

Více

WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK

WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK Systém WorkWatch je určen pro malé a střední firmy, které se zabývají službami nebo zakázkovou výrobou. Zajistí dokonalý přehled o všech zakázkách a jejich rozpracovanosti.

Více

Databáze pro evidenci výrobků

Databáze pro evidenci výrobků Databáze pro evidenci výrobků Databáze ve formátu Microsoft Access je součástí systému, který řídí automatizovanou výrobní linku. Tabulka tblcharge obsahuje data o výrobcích a je plněna automaticky řídicím

Více

Popisné systémy a databáze

Popisné systémy a databáze Popisné systémy a databáze Databáze v archeologii přístup k použití databází - dva způsoby aplikace databáze - databázové programy (jejich přednosti a omezení) databáze v archeologii - databáze jako výstup

Více

Databázové systémy. Tomáš Skopal. - úvod do relačního modelu. - převod konceptuálního schématu do relačního

Databázové systémy. Tomáš Skopal. - úvod do relačního modelu. - převod konceptuálního schématu do relačního Databázové systémy - úvod do relačního modelu Tomáš Skopal - převod konceptuálního schématu do relačního Osnova přednášky relační model převod ER diagramu do relačního modelu tvorba univerzálního relačního

Více

IntraDoc. Řešení pro státní správu a samosprávu. http://www.inflex.cz

IntraDoc. Řešení pro státní správu a samosprávu. http://www.inflex.cz Motivace IntraDoc Řešení pro státní správu a samosprávu http://www.inflex.cz Naším cílem je nabídnout pracovníkům úřadu efektivní a do detailu propracovanou podporu procesů a správu dokumentů spojených

Více

Úvod. Boj se zavlečeným impedančním nesouladem na úrovni databáze

Úvod. Boj se zavlečeným impedančním nesouladem na úrovni databáze Boj se zavlečeným impedančním nesouladem na úrovni databáze ABSTRACT: Impedanční nesoulad může být zmírněn správnou volbou databázové technologie. Článek vysvětluje, co to impedanční nesoulad je a uvádí

Více

Více úrovňové informační systémy a jejich certifikace podle zákona č.412/2005 Sb., ve znění pozdějších předpisů

Více úrovňové informační systémy a jejich certifikace podle zákona č.412/2005 Sb., ve znění pozdějších předpisů Více úrovňové informační systémy a jejich certifikace podle zákona č.412/2005 Sb., ve znění pozdějších předpisů Vyhláška č. 523/2005 Sb., o bezpečnosti informačních a komunikačních systémů a dalších elektronických

Více

Kapitola 4: SQL. Základní struktura

Kapitola 4: SQL. Základní struktura - 4.1 - Kapitola 4: SQL Základní struktura Množinové operace Souhrnné funkce Nulové hodnoty Vnořené poddotazy (Nested sub-queries) Odvozené relace Pohledy Modifikace databáze Spojené relace Jazyk definice

Více

Téma 9 Databáze úvod, modelovánídat

Téma 9 Databáze úvod, modelovánídat Téma 9 Databáze úvod, modelovánídat Obsah 1. Základní pojmy databází 2. Abstrakce, schémata, pohledy 3. Databázové modely 4. Modelování reálného světa 5. Entity a vztahy 6. Entity-Relationship (E-R) model

Více

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

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

Více

Střední odborná škola stavební Karlovy Vary Sabinovo náměstí 16, 360 09 Karlovy Vary Autor: Ing. Hana Šmídová Název materiálu:

Střední odborná škola stavební Karlovy Vary Sabinovo náměstí 16, 360 09 Karlovy Vary Autor: Ing. Hana Šmídová Název materiálu: Název školy: Střední odborná škola stavební Karlovy Vary Sabinovo náměstí 16, 360 09 Karlovy Vary Autor: Ing. Hana Šmídová Název materiálu: VY_32_INOVACE_01_ACCESS_P2 Číslo projektu: CZ 1.07/1.5.00/34.1077

Více

Microsoft Access tvorba databáze jednoduše

Microsoft Access tvorba databáze jednoduše Microsoft Access tvorba databáze jednoduše Časový rozsah: 2 dny (9:00-16:00) Cena: 3300 Kč + DPH Úvod do relačních databází. Funkce databázových objektů Microsoft Access. Návrh tabulek, definice základních

Více

OBJEDNÁVÁNÍ DÁRCŮ KRVE PŘES INTERNET Naděžda Kalužová, Zdeněk Slanina

OBJEDNÁVÁNÍ DÁRCŮ KRVE PŘES INTERNET Naděžda Kalužová, Zdeněk Slanina OBJEDNÁVÁNÍ DÁRCŮ KRVE PŘES INTERNET Naděžda Kalužová, Zdeněk Slanina 60 Anotace Ve spolupráci FNO Ostrava a VŠB-TU vzniká informační systém pro krevní centra, jehož hlavní úlohou je nabídka jednoduchého

Více

NÁVRH DATABÁZE PRO NEZISKOVOU ORGANIZACI

NÁVRH DATABÁZE PRO NEZISKOVOU ORGANIZACI VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA PODNIKATELSKÁ ÚSTAV INFORMATIKY FACULTY OF BUSINESS AND MANAGEMENT INSTITUTE OF INFORMATICS NÁVRH DATABÁZE PRO NEZISKOVOU ORGANIZACI

Více

Typické problémy řešené informačními systémy

Typické problémy řešené informačními systémy Informační systémy Informační systém systém umožňující komunikaci a transformaci informací časově, prostorově i co do formy tak, aby byly lépe využity než v původním stavu (systém, který přidává hodnotu

Více

Monitoring SQL Server, Resource Governor, Tracing SQL Server

Monitoring SQL Server, Resource Governor, Tracing SQL Server Monitoring SQL Server, Resource Governor, Tracing SQL Server 1. Monitoring Monitoring cíl Zrychlení odezvy. Hledání úzkého hrdla. Identifikace často prováděných dotazů. Úprava dotazu, změna indexu, Sledování

Více

Univerzita Hradec Králové. Filozofická fakulta. Katedra pomocných věd historických a archivnictví

Univerzita Hradec Králové. Filozofická fakulta. Katedra pomocných věd historických a archivnictví Univerzita Hradec Králové Filozofická fakulta Katedra pomocných věd historických a archivnictví Databáze soupisu duší s historicko-demografickými výstupy Diplomová práce Autor: Bc. Jiří Kudr Studijní program:

Více

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko Obsah Kvalita SW, jak zajistit kvalitu SW a jak ji ověřit Zabezpečení kvality, techniky řízení kvality SW. Potřeba kultivovat kvalitu, Cena za jakost Procesy pro řízení kvality, harmonogram řízení kvality

Více

4IT218 Databáze. 4IT218 Databáze

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

Více

Nemocnice. Prvotní analýza a plán projektu

Nemocnice. Prvotní analýza a plán projektu Nemocnice Projekt do předmětu AIS Prvotní analýza a plán projektu Lukáš Pohl, xpohll00, xkosti03 Jan Novák, xnovak79 2009/2010 1 Neformální specifikace FN potřebuje informační systém, který bude obsahovat

Více

Zpracování informací

Zpracování informací Ústav automatizace a informatiky Fakulta strojního inženýrství Vysoké učení technické v Brně Přednáška č. 6 z předmětu Zpracování informací Ing. Radek Poliščuk, Ph.D. Tato publikace vznikla jako součást

Více

Zhodnocení architektury podniku. Jiří Mach 28. 8. 2014

Zhodnocení architektury podniku. Jiří Mach 28. 8. 2014 Zhodnocení architektury podniku Jiří Mach 28. 8. 2014 Obsah Zhodnocení architektury podniku Zahájení projektu Metodika/framework Harmonogram projektu 1. fáze: vytvoření popisu AS-IS stavu 2. fáze: analýza

Více