12. blok Fyzický návrh databáze

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "12. blok Fyzický návrh databáze"

Transkript

1 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 fyzického návrhu spolu s vysvětlením, jak mapovat získaný logický návrh na návrh fyzický. Dále budou zmíněna specifika návrhu pro různé databázové systémy. Doba nutná k nastudování 2-3 hodiny Průvodce studiem Předpokládá se, že student je obecně seznámen s jednotlivými fázemi databázového modelování, především s fází logického modelování. Dále, že je dobře seznámen s pojmy tabulka, relace, doména, integritní omezení, referenční integrita atd. 1. Úvod do fyzického modelu databáze Fyzický návrh databáze je třetí fází návrhu databáze. V podstatě je tato fáze založena na převodu logického návrhu (tabulek, sloupců a integritních omezení) na fyzický návrh, který je použitelný v rámci zvoleného databázového systému. Jelikož jednotlivé databázové systémy mají svá specifika a omezení, může existovat více postupů v rámci fyzického návrhu databáze, reflektující daná specifika jednotlivých databázových systémů. Pro fyzický návrh je tedy nutná dobrá znalost funkcí a možností cílového databázového systému. Zároveň je vždy dobré znát i vlastnosti jiných databázových systémů a při fyzickém návrhu uvažovat i o tom, zda by změna databázového systému nepřinesla některé výhody. Pokud má být srovnán logický návrh s fyzickým, tak logický návrh je sice založen na specifickém modelu dat (relační model), ale je naprosto nezávislý na podrobnostech o jakékoliv implementaci v rámci konkrétního databázového systému. Výstupem logického modelování je popsaná množina relací tabulek. Dalo by se říci, že logické modelování se zaměřuje na otázku co. Kdežto fyzický návrh spíše odpovídá na otázku jak? Důležitým úkolem pro vytvoření fyzického modelu je pochopení funkcí a možností cílového databázového systému. Fyzický model tak do značné míry odráží individuální vlastnosti cílového databázového systému. Mohlo by se zdát, že fyzické 1

2 modelování je izolovanou činností a s předchozími fázemi návrhu nikterak neinteraguje. Není tomu tak a v mnoha případech existuje zpětná vazba mezi fyzickým a logickým návrhem. Například se během fyzického návrhu zjistí, že jiné rozložení tabulek bude v rámci daného databázového systému výkonnější, proto je nutné pozměnit i logický model. Fáze fyzického modelování se skládá z následujících činností: Převod logického návrhu databáze do návrhu vyhovujícímu cílovému databázovému systému Volba organizace souborů a indexů Návrh bezpečnostních mechanismů Nasazení systému do provozu 2. Převod logického návrhu databáze do cílového DB systému. V tomto kroku dochází k překladu tabulek vytvořených při logickém návrhu databáze na tabulky, které je možné implementovat v rámci cílového relačního databázového systému. V první fázi tvorby fyzického modelu je nutné shromáždit všechny informace získané při logickém návrhu databáze. V druhé fázi jsou tyto informace využity k vytvoření podkladových tabulek. V této fázi je nutná dobra znalost cílového databázového systému, zejména je nutné zaměřit se na funkce, které cílový databázový systém nabízí. Pozornost může být zaměřena například na následující funkce: Zda je možné v cílové databázi definovat primární klíče, cizí klíče, alternativní klíče. Zda lze zavádět omezení typu NOT NULL. Zda je možné v rámci databáze definovat vlastní domény. Jestli je v systému podpora pro integritní omezení. Při převodu logického návrhu na fyzický, je nutné vypořádat se s následujícími úkoly: Návrh podkladových tabulek. Navrhnout reprezentaci odvozených dat. Dořešení zbývajících integritních omezení. 2

3 2.1. Návrh podkladových tabulek Na počátku fyzického modelování je nutné shromáždit veškeré informace o tabulkách vytvořených během logického návrhu. Každá tabulka obsažená v logickém modelu by měla minimálně obsahovat následující informace: jméno tabulky, seznam jednoduchých sloupců, primární, popřípadě alternativní klíče, cizí klíče, referenční omezení pro všechny identifikované klíče. Zároveň by pro každý sloupec tabulky měla být k dispozici následující specifikace: definice domény (typ dat, délka, omezení domény), implicitní hodnota sloupce, pokud je definována, zda se ve sloupci smí vyskytnout hodnota NULL, zda se jedná o tzv. odvozený sloupec, a pokud ano, tak jakým způsobem bude získána jeho hodnota. Pro návrh podkladové tabulky lze využít rozšíření DBDL, ve kterém se navíc uvádějí domény, implicitní hodnoty a chování vůči NULL hodnotám. Příkladem může být následující rozšířená definice tabulky Studenti: 3

4 doména student_cislo znakový řetězec pevné délky 7 doména student_jmeno znakový řetězec variabilní délky, max. 50 doména student_prijmeni znakový řetězec variabilní délky, max. 60 doména ulice_nazev znakový řetězec variabilní délky, max. 60 doména mesto_nazev znakový řetězec variabilní délky, max. 60 doména psc_cislo znakový řetězec pevné délky 5 doména narozeni_datum datum doména rodne_cislo znakový řetězec pevné délky 10 doména fakulta_cislo znakový řetězec pevné délky 3 CREATE TABLE Studenti( cislostudenta student_cislo NOT NULL, studjmeno student_jmeno NOT NULL, studprijmeni student_prijmeni NOT NULL, studulice ulice_nazev NOT NULL, studmesto mesto_nazev NOT NULL, studpsc psc_cislo NOT NULL, studdatumnarozeni narozeni_datum NOT NULL, studrodnecislo rodne_cislo NOT NULL, cislofakulty fakulta_cislo NOT NULL) PRIMÁRNÍ KLÍČ cislostudenta ALTERNATIVNÍ KLÍČ studrodnecislo CIZÍ KLÍČ cislofakulty REFERENCE Fakulta(cisloFakulty) PŘI AKTUALIZACI KASKÁDA PŘI MAZÁNÍ ŽÁDNÁ AKCE Po vytvoření definice tabulky následuje rozhodnutí, jak dle dané definice tabulku implementovat v cílovém databázovém systému. Toto rozhodnutí je velmi závislé na konkrétním databázovém systému, neboť každý ze systémů nabízí rozdílné možnosti pro definici podkladových tabulek a integritních omezení. Pokud daný databázový systém podporuje normu ISO SQL:2006, pak lze k vytvoření podkladové tabulky standardní příkaz CREATE TABLE. Pokud bude za referenční systém zvolen databázový systém Oracle, tak bude nutné reprezentovat zvolené domény pomocí vestavěných datových typů databázového systému. V samotném systému totiž není možnost vytvářet domény jako takové. Systém sice umožňuje vytvářet vlastní datové typy, ovšem jejich využití v tabulkách není tak jednoduché, jako použití základních datových typů. Navíc při velkém množství různých domén by bylo udržování daných domén velmi náročné. Proto je úkolem této fáze nalézt vhodné datové typy databázového systému, které bude možné využít pro nalezené sloupce. 4

5 Databázový systém Oracle poskytuje následující základní datové typy: Typ VARCHAR2(velikost) CHAR(velikost) NUMBER(p,s) DATE INTERVAL DAY TO SECOND CLOB BLOB Popis Řetězec variabilní délky. Maximální počet znaků, které řetězec bude obsahovat, se nastaví atributem velikost. Velikost může obsahovat celé číslo od 1 do Řetězec fixní délky. Ideální pro reprezentaci krátkých řetězců. Maximální počet znaků je Číselný datový typ. Datový typ pro reprezentaci data. Datový typ vyjádření časového intervalu. Datový typ pro velmi dlouhé texty. V nejnovější verzi databázového systému pojme text o velikosti až 128 TB. Datový typ pro uložení binárního obsahu, např.: soubory. Maximalní velikost souboru je 128 TB. Tabulka 1- Datové typy databázového systému Oracle 5

6 Kompletní přehled použitelných datových typů v rámci databázového systému Oracle najdete: Příkaz pro vytvoření tabulky může mít tedy následující podobu: CREATE TABLE Studenti( cislostudenta CHAR(7) NOT NULL PRIMARY KEY, studjmeno VARCHAR2(50) NOT NULL, studprijmeni VARCHAR2(60) NOT NULL, studulice VARCHAR2(60) NOT NULL, studmesto VARCHAR2(60) NOT NULL, studpsc CHAR(5) NOT NULL, studdatumnarozeni DATE NOT NULL, studrodnecislo CHAR(10) NOT NULL, cislofakulty CHAR(3) NOT NULL) Z výše uvedeného příkladu je zřejmé, že vestavěné datové typy databázového systému Oracle jsou více než dostačující. Pokud by se musely definovat i samotné domény, znamenalo by to značnou režii spojenou s vytvářením a udržováním domén. Nyní je nutné definovat sloupec cislofakulty jako cizí klíč a určit jeho vazbu na primární klíč tabulky Fakulta. K tomu slouží následující příkaz: 6

7 ALTER TABLE Studenti ADD CONSTRAINT FK_FAKULTA FOREIGN KEY (cislofakulty) REFERENCES Fakulta (cislofakulty) Výše uvedený příklad říká, že sloupec cislofakulty v tabulce Student odkazuje na sloupec cislofakulty tabulky Fakulty Reprezentace odvozených dat Nejprve připomenutí definice odvozeného sloupce: Sloupec, jehož hodnoty se zjišťují pomocí hodnot jiných sloupců, se nazývá odvozený, alternativně vypočítaný sloupec. Příkladem odvozeného sloupce může být například: Počet zaměstnanců/studentů dané fakulty. Počet zapsaných předmětů daného studenta. Studentova průměrná známka. Tyto sloupce se spíše než v ER modelu častěji vyskytují v dokumentaci, přesněji v slovníku dat příslušnému danému projektu. Pokud se odvozený sloupec přeci jen vyskytne v ER modelu, jeho jméno začíná znakem /, čím se identifikuje, že se jedná o odvozený sloupec. Při návrhu reprezentace odvozených dat se nejprve prozkoumá logický model dat a vytvoří se seznam všech nalezených odvozených sloupců. Následuje fáze, ve které se musí zvážit výhodnost či nevýhodnost uložení odvozeného sloupce do databáze. Alternativně se zvažuje, zda není výhodnější údaj vypočítávat dynamicky, kdykoliv k němu bude přistupováno. V zásadě se musí zvážit následující: Jaké jsou dodatečné náklady na uložení sloupce databáze a jak je náročné udržovat konzistenci s daty, z nichž se odvozuje. Jaké jsou náklady na výpočet při přístupu. Měla by být zvolena méně nákladná volba, za předpokladu, že splňuje výkonnostní požadavky. Příklad odvozeného sloupce může být demonstrován na následném modelu. V modelu existuje tabulka Fakulta. Zároveň existuje tabulka Student. Mezi oběma tabulkami existuje vztah, který říká, na které fakultě student studuje. V tabulce Fakulta může být uložen dodatečný sloupce pocetstudentu, který bude říkat, kolik studentů na dané fakultě studuje. cislofakulty pocetstudentu f1 2 f2 1 7

8 V tomto případě by dodatečné náklady na uložení odvozeného sloupce nebyly nikterak závratné. Ale bylo nutné stále aktualizovat tento sloupec, kdykoliv by došlo ke změně (vložení, aktualizace, smazání) v tabulce Student. Jakékoli porušení tohoto pravidla by vedlo k nekonzistenci databáze. Tzn., že sloupec pocetstudentu by nereflektoval skutečný počet studentů na dané fakultě. Pokud bude tedy zvoleno řešení s implementací odvozeného sloupce přímo do tabulky, bude daná hodnota vždy okamžitě dostupná a nebude jí nutné vždy znovu a znovu vypočítavá. Pokud by sloupec pocetstudentu nebyl uložen přímo v tabulce Fakulta, bylo by ho nutné vždy vypočítávat. V tomto případě by se jednalo o velmi jednoduchý dotaz: SELECT COUNT(*) FROM Fakulta WHERE cislofakulty = zvolena fakulta V tuto chvíli je nutné určit, zda by se potenciálně tento dotaz spouštěl mnohokrát či by bylo nutné danou informaci získávat velmi rychle. Pokud ano, je implementace odvozeného sloupce do tabulky na místě. Pokud ne, je lepší zjišťovat danou hodnotu, až když je tato hodnota potřeba, neboť s udržováním konzistence v odvozeném sloupci je spojena dodatečná režie Návrh zbývajících integritních omezení Aktualizace hodnot v tabulce může být podmíněna určitými omezeními, která mohou být aplikována na podkladová data. V tomto kroku budou již nastavena všechna omezení dat a domén spolu s relačními integritními omezeními. Nyní je nutné promyslet, zda existují ještě další implementovatelná integritní omezení a zároveň je nutné zvážit, jak nalezená integritní omezení implementovat v rámci cílového databázového systému. Některé systémy poskytují více možností pro definování integritních omezení než jiné. Opět platí, že v systémech, které plně respektují SQL normu, bude možné zavést integritní omezení poměrně snadno. Při definici tabulky v rámci databázového systému Oracle, můžeme použít následující omezení (pro přehlednost nejsou uvedeny všechny sloupce tabulky): 8

9 CREATE TABLE Student( cislostudenta CHAR(7) NOT NULL PRIMARY KEY CHECK (cislostudenta LIKE 'ST%'), studjmeno VARCHAR2(50) NOT NULL, studpsc CHAR(5) NOT NULL, studdatumnarozeni DATE NOT NULL CHECK(studDatumNarozeni < SYSDATE), studrodnecislo CHAR(10) NOT NULL CHECK(LENGTH(studRodneCislo) >= 9), cislofakulty CHAR(3) NOT NULL) Omezení definované nad atributem cislostudenta říká, že tento sloupec smí obsahovat jen hodnoty začínající prefixem ST. Omezení definované nad sloupcem studdatumnarozeni stanovuje podmínku, že nově vkládané datum narození musí být nižší, než je aktuální datum. Pro sloupec studdatumnarozeni je definováno omezení, které nepovolí vložení rodného čísla kratšího než 9 znaků. Toto je jen několik málo příkladů, jak převést nalezená integritní omezení do jazyka cílového databázového systému. 3. Volba organizace souborů a indexů Návrhář zodpovědný za fyzický návrh musí ve svém fyzickém modelu zohlednit i údaje o cílovém databázovém systému spolu s informacemi o operačním systému, ve kterém bude databázový systém provozován. V případě databázového systému je nutné zaznamenat i organizaci souborů, které budou sloužit pro reprezentaci tabulek. Zároveň by mělo dojít i k zaznamenání specifik cílového operačního systému, například by měly být evidovány údaje týkající se umístění a ochrany důležitých souborů. Typické databázové systémy mají pevnou organizaci souborů definovanou při instalaci či databázovým administrátorem, ale existují i druhy databázových systémů, které umožňují nastavit individuální organizaci souborů. Ovšem z hlediska koncového uživatele databáze by tato interní reprezentace uložení tabulek měla být neviditelná. Uživatel musí mít možnost přistupovat k tabulkám bez nutnosti znalosti jejich fyzického umístění. Organizace souborů tedy může být definována jako způsob uspořádání záznamů do souborů při uložení na disk. S organizací souborů souvisí i pojem index. Indexem se rozumí datová struktura, která databázovému systému umožňuje rychleji lokalizovat konkrétní záznamy v souboru a tím celkově zlepšit rychlost odezvy na uživatelské dotazy. Jistá analogie indexu je k nalezení v indexu knihy, kde je možné najít klíčová slova spolu se seznamem stránek, na kterých se tato slova vyskytují. 9

10 Pro dobré rozhodnutí o organizaci souborů a volbě indexů je nutné velmi dobře porozumět tomu, jak bude vypadat typické provozní zatížení databáze. Tyto údaje se zjistí důkladnou analýzou transakcí čtení a zápisu spolu s informací o jejich frekvenci a výkonnostních požadavcích transakcí. Volba organizace souborů a indexů se tedy dá rozdělit na následující úkoly: Analýza transakcí. Volba organizace souborů. Volba indexů Analýza transakcí V tomto kroku je nutné analyzovat jednotlivé transakce, které budou databázovým systémem prováděny, aby se identifikovaly ty transakce, které mohou významně ovlivnit výkonnost databáze. Analyzovat všechny potencionální transakce v systému by mohlo být časově velmi náročné, pro to se analýza musí soustředit minimálně na ty nejdůležitější transakce. Mezi takové transakce můžou být zahrnuty ty transakce, které jsou prováděny velmi často, či je jejich provádění z pohledu databázového systému kritické. Všeobecně se tvrdí, že 20 % nejdůležitějších uživatelských dotazů představuje 80 % přístupů k datům. Je tedy nutné identifikovat následující: Transakce, které se provádějí velmi často a mohou potenciálně ovlivnit výkon celého databázového systému. Transakce, které jsou pro chod systému klíčové. Identifikovat hodinu a den, kde se předpokládá, že databázový systém bude enormně zatížen (špička zatížení). Proto je nutné zaznamenat nejen průměrné a maximální počty spouštění jednotlivých transakcí, ale také den a čas, kdy ke spouštěním dochází. Určité výkonnostně náročné transakce se totiž mohou vyskytovat jen v určité dny a hodiny, proto je nutné je uvažovat jen v tyto časy. Díky této analýze jsou nalezeny potenciálně slabá místa databázového návrhu, místa, která by značně mohly ohrozit výkonnost databáze. Na základě těchto informací se stanoví vhodná organizace souborů a indexů. 10

11 Dotaz Student Prům. 500 Max.1100 Studenti (12 000) Studuje Prum. 200 Max. 500 Dotaz Fakulta Prům. 500 Max.1100 Fakulty (15) Programy (300) 1..1 Nabízí 1..* 1..1 Má 1..* Obory (1 200) Obrázek 1 - Analýza prováděných transakcí Na zjednodušeném modelu je ukázka, jak je možné jednotlivé transakce zaznamenat do modelu. Je dobré například odhadnout průměrný počet záznamů v tabulkách či průměrné (a maximální) počty dotazů do těchto tabulek, či průměrné využiti relací mezi jednotlivými tabulkami Volba organizace souborů Cílem fyzického návrhu databáze je efektivní uložení dat. Pokud by byl například často vyvoláván seznam studentů podle jejich abecedního pořadí, pak by zajisté bylo efektivní organizovat soubory tak, aby bylo pro provedení této operace co nejjednodušší. Na druhou stanu se může objevit požadavek na získávání seznamů studentů např. dle věku, v tomto případě by byla výše uvedená organizace souborů pravděpodobně neefektivní. Další komplikací může být to, že určitá konfigurace souborů může být velice efektivní pro ukládání dat, ale nemusí už být tolik vhodná pro ostatní účely. Cílem tohoto kroku je zvolit optimální organizaci souboru pro každou tabulku, pokud to daný databázový systém podporuje. V případě velkých modelů, by bylo volit organizaci souborů pro každou tabulku nesmírně pracné a náročné. Proto se pro specifickou organizaci souboru vybírají jen tabulky, které mají zásadní vliv na výkon celého systému. Ostatní tabulky zdědí základní organizaci souboru nastavenou pro daný databázový systém. Některé databázové systémy nepodporují volbu organizace souboru, ale například systém Oracle podporuje indexově organizované tabulky a klastrované tabulky. Indexově organizovaná tabulka. Od běžné tabulky se liší tím, že data jsou tabulky udržované v asociovaných indexech. Změna dat v tabulce (aktualizace, přidání, smazání) způsobí aktualizaci pouze indexu. Indexová organizace tabulky umožňuje velmi rychlý přístup k jednotlivým záznamům tabulky pomocí klíčů. 11

12 Klastry. Klastr je skupina tabulek více tabulek fyzicky uložených společně, protože mají sdílené sloupce a jsou společně často používány. Uložení souvisejících záznamů společně zlepšuje přístupovou dobu na disk. Související sloupce tabulek v klastru se nazývají klastrové klíče. Klastrový klíč je fyzicky uložen pouze jednou, což zvyšuje efektivitu při ukládání dat. Klastrovaní může být velice efektivní, když jsou tabulky často využívány společně. Naopak je to velmi neefektivní způsob organizace souborů, když se bude plně procházet jen jedna z tabulek klastru. Dalším možným přístupem je ponechat tabulky nesetříděné a vybudovat nad nimi podle potřeby tzv. sekundární indexy Volba indexů V tomto kroku se musí určit, zda vytvoření indexů přispěje k celkovému zvýšení výkonu vytvářeného systému. Index je mechanismus, jenž dovoluje do tabulky přidat dodatečný klíč, sloužící pro rychlejší a efektivnější přístup k datům. Index je obvykle definován nad určitou tabulkou a jedním či více sloupci dané tabulky. Implementace indexů se v rámci databázových systémů různých výrobců mohou lišit, proto je jejich vytváření závislé na konkrétní verzi a výrobci daného systému. Typicky se index vytváří nad sloupce (sloupci) tabulky, přes který se do dané tabulky velmi často přistupuje (ať už přímo dotazem SELECT, ve WHERE klauzuli či se daný sloupec účastní spojení tabulek). Indexy je tedy výhodné vytvářet nad sloupci, které tvoří primární nebo cizí klíč, nebo nad sloupci, podle kterých se velmi často v dané tabulce vyhledává. Například, pokud analýza určí, že častou operací bude vyhledávání studenta dle jeho příjmení, určitě se vyplatí daný index nad příjmením studenta vytvořit. Indexy tedy značně urychlují procházení a prohledávaní tabulek. Ovšem s používáním indexů nejsou spojena jen samá pozitiva. Existují i negativa: Index je nutné aktualizovat kdykoliv dojde ke změně (přidání, mazání, aktualizace) hodnoty indexovaného sloupce (sloupců). Tím může utrpět výkon operací UPDATE a DELETE. Pro index je nutné alokovat dodatečný diskový prostor. Při nadměrném užívání indexů může dojít naopak k celkovému snížení výkonu aplikace, protože optimalizátor může začít upřednostňovat jen přístupy na základě indexu a vyloučí všechny ostatní přístupové metody. Nový index v tabulce může sice zrychlit operace prováděné jednou aplikací, ale zároveň může mít nepříznivý vliv na výkonnost jiné aplikace přistupující k tabulce. 12

13 4. Návrh bezpečnostních mechanismů Jelikož jsou v rámci databáze často uchovávána velmi citlivá data, je zabezpečení databázového systému velmi důležité. Během různých fází návrhu databázového systému vyvstanou požadavky na různá bezpečnostní pravidla. V tomto kroku se rozhoduje o fyzické implementaci těchto pravidel do systému. Opět zde významnou roli hraje výběr databázového systému. Různé databázové systémy poskytují různé úrovně zabezpečení. V zásadě se ale vždy o bezpečnosti uvažuje ve dvou rovinách: Zabezpečení systému. Zabezpečení dat. Zabezpečení systému se týká samotného přístupu do databázového systému. Zde se především rozhoduje o uživatelských účtech a jejích rolích v rámci databázového systému (běžný uživatel/administrátor). Naopak zabezpečení dat se dotýká přístupu k samotným databázovým objektům (tabulky, pohledy, funkce) a činnostem, které daní uživatelé s objekty můžou provádět. Jednou z často používaných metod k zabezpečení dat uvnitř databáze je použití kontroly přístupu pomocí SQL. Pomocí SQL se vytvoří pohledy, přes které budou uživatelé k datům přistupovat. Díku tomu mohou mít uživatelé přístup jen k pohledu, ale samotné podkladové tabulky jim zůstanou skryté. Tento mechanismus navíc poskytuje velký stupeň nezávislosti dat. Uživatelé jsou odstíněni od případných změn podkladových tabulek. Každý uživatel databáze dostane od databázového administrátora přiděleny přihlašovací údaje. Obvykle se jedná o přihlašovací jméno a heslo. Jistou výjimku tvoří anonymní uživatelé. Ovšem zásadně se nedoporučuje tyto anonymní účty vytvářet. Představují totiž značné bezpečnostní riziko. Každý provedený příkaz v rámci databáze je proveden identitou přihlášeného uživatele. Identita uživatele jasně určuje, ke kterým objektům má právo přistupovat a jaké operace nad těmito objekty může provádět. U většiny standardních databázových systémů platí, že vlastník objektu smí vědět o existenci objektu a může provádět nad ním všechny operace. K ostatním objektům databáze (ale i k vlastním) potřebuje každý uživatel tzv. přístupová práva. Pokud daný databázový systém respektuje normu ISO SQL:2006, využívá se k přidělování těchto práv příkaz GRANT. A naopak k jejich odebírání příkaz REVOKE. V rámci přidělování přístupových práv k objektům existuje ještě klauzule WITH GRANT OPTION, která říká, že dané právo na daném objektu smí uživatel přidělovat i jiným uživatelům databáze, ačkoliv sám není vlastníkem objektu. 13

14 5. Kontrolované zavedení redundance Jeden z bloků kurzu byl věnován tzv. normalizaci. Normalizace je technika, při které se rozhoduje, které sloupce do dané tabulky patří a naopak které sloupce do tabulky není vhodné umisťovat. Výsledkem procesu normalizace je logický návrh databáze, jehož struktura je konzistentní a obsahuje minimální množství redundancí. Hlavní předností normalizovaného modelu tedy je, že se v něm prakticky nevyskytují redundance. Na druhou stranu normalizovaný návrh databáze nemusí vždy poskytovat maximální provozní výkon. V takových případech je vhodné uvažovat o jisté formě de-normalizace, jejím cílem je zvýšení celkové výkonnosti systému. O de-normalizaci by se ovšem mělo uvažovat jen v případech, kdy systém nesplňuje výkonnostní požadavky. Při zvažování zavedení denormalizace by mělo být uváženo následující: Denormalizace komplikuje implementaci. Denormalizace ve většině případů snižuje flexibilitu systému. Zvýšení výkonu při čtení může způsobit snížení výkonu při aktualizaci dat. Formální definice termínu denormalizace říká, že denormalizace způsobí změnu struktury podkladové tabulky tak, že nová tabulka má nižší formu než tabulka původní. Obecně je nejvhodnější uvažovat o denormalizaci ve chvíli, kdy je výkon neuspokojivý a daná tabulka má nízkou frekvenci aktualizace spolu s vysokou frekvencí přístupů. V tomto případě je zavedení denormalizace přijatelné. Při kontrolovaném zavedení redundance je nutné zvážit, jaké následky bude mít její zavedení na předchozí kroky v metodologii. Například bude nutné znovu zvážit zavedení některých indexů nebo některých omezení. Je nutné zvážit, zda zavedení denormalizace nenaruší integritu dat. Zároveň je nutné integritu dat důsledně kontrolovat. Obecně lze využít následující řešení: Spouště (triggery) dají se využít k automatické aktualizaci odvozených dat nebo k aktualizaci duplikovaných dat. Dávkové zpracovaní spouštění dávek v pravidelných intervalech umožňuje uvést denormalizovaná data do konzistentního stavu. 14

15 6. Monitorování systému v provozu Cílem fyzického návrhu je efektivní ukládání dat v rámci databázového systému. K posouzení efektivnosti lze využít následujících atributů. Rychlost odezvy. Jedná se o čas, který je nutný pro dokončení dané transakce. Propustnost transakcí. Tento atribut udává, kolik souběžných transakcí může databázový systém zpracovat. Diskový prostor. Velikost databázových souborů, které je nutné pro uložení databázových souborů. V zásadě nelze určit, který z atributů je ten rozhodující. Velmi záleží na typu dané aplikace. Ve většině případů lze zlepšit některé z uvedených atributů na úkor atributů jiných. První fyzický návrh by nikdy neměl být považován za návrh konečný. Spíše by na něj mělo být nahlíženo jako na počáteční odhad podoby systému, po jehož implementaci je nutné provoz systému monitorovat a systém dle pozorovaného výkonnostního měření vyladit. Mnoho databázových systémů poskytuje svým administrátorům značné množství nástrojů pro monitorování výkonnosti databáze. Ladění výkonů může přinést následné výhody: Snížení nákladů na hardware. Vyladěný systém má rychlejší odezvu a větší propustnost. Ladění výkonu databázového systému je činnost, o které není možné prohlásit, že je dokončena. Po celou dobu životnosti databázového systému je nutné stále sledovat jednotlivé výkonnostní ukazatele a ladění stále provádět. Důležitě je si zapamatovat, že většina zisků ve výkonnosti pochází z dobrého návrhu databáze, kvalitní analýzy transakcí či výběru správných indexů. Může být sice velmi lákavé některé z optimalizačních kroků vynechat či jim věnovat jen zanedbatelný čas, ale důrazně se to nedoporučuje. Čas věnovaný kvalitnímu návrhu databáze se později určitě vyplatí. 15

16 Pojmy k zapamatování Příkazy: CREATE TABLE, ALTERTABLE, PRIMARY KEY, CHECK, FOREIGN KEY, GRANT, REVOKE, WITH GRANT OPTION Pojmy: fyzický model, podkladová tabulka, primární klíč, cizí klíč, odvozená data, integritní omezení, doména, datový typ, index, zabezpečení dat, zabezpečení systému. Problém: Převod logického modelu dat na fyzický model dat, definice podkladových tabulek (specifikace jména, názvu sloupců, datových typů), identifikace primárních a cizích klíčů, definice ostatních integritních omezení, volba vhodné organizace souborů, volba indexů, celkové zabezpečení databáze, monitorování výkonu databáze v provozu. Shrnutí Cílem fyzického návrhu databáze je převod logického návrhu databáze na popis implementace v rámci vnějších paměťových zařízení. Fyzický návrh tedy popisuje podkladové tabulky, fyzickou organizaci souborů, využití indexů. K dobrému návrhu podkladových tabulek je nutné dobré porozumění cílovému databázovému systému. V rámci prvního kroku fyzického modelování je nutné převést logický návrh do takové podoby, která je reprezentovatelný v rámci cílového databázového systému. Dále fyzický návrh analyzuje transakce, na jejímž základě je navržena fyzická organizace databázových souborů společně návrhem indexů. Fyzický návrh se rovněž zabývá zabezpečením databázového systému. Stanovuje, jací uživatelé mají právo k databázi přistupovat a jaké role v rámci daného databázového systému budou vykonávat. Součástí fyzického návrhu je i monitorování a ladění výkonu systému za jeho provozu. 16

17 Otázky na procvičení 1. Jaký je základní rozdíl mezi fyzickým a logickým modelováním. 2. Co je vstupem a co je výstupem fyzického modelování. 3. Jaké jsou základní kroky fyzického modelování. 4. Co jsou odvozená data a jakým způsoby se reprezentují. 5. Jaký je hlavní význam denormalizace. 6. K čemu slouží indexy. Odkazy a další studijní prameny Odkazy a další studijní prameny 1. CONOLLY, Thomas, Carolyn BEGG a Richard HOLOWCZAK. Mistrovství - databáze: profesionální průvodce tvorbou efektivních databází. Brno: Computer Press, ISBN KYTE, Thomas. Oracle - Návrh a tvorba aplikací. Brno: Computer Press, ISBN LACKO, Luboslav. Oracle - Správa, programování a použití databázového systému. Brno: Computer Press, 2007, 576 s. ISBN

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

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

6. blok část B Vnořené dotazy

6. blok část B Vnořené dotazy 6. blok část B Vnořené dotazy Studijní cíl Tento blok je věnován práci s vnořenými dotazy. Popisuje rozdíl mezi korelovanými a nekorelovanými vnořenými dotazy a zobrazuje jejich použití. Doba nutná k nastudování

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

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

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

9. blok Fáze návrhu databáze, konceptuální modelování

9. blok Fáze návrhu databáze, konceptuální modelování 9. blok Fáze návrhu databáze, konceptuální modelování Studijní cíl Tento blok je věnován základům databázového modelování. V základu budou probrány jednotlivé fáze návrhu databáze. Dále bude student tohoto

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

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

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

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

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

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

1. Databázové systémy (MP leden 2010)

1. Databázové systémy (MP leden 2010) 1. Databázové systémy (MP leden 2010) Fyzickáimplementace zadáníaněkterářešení 1 1.Zkolikaajakýchčástíseskládáčasprovstupněvýstupníoperaci? Ze tří částí: Seektime ječas,nežsehlavadiskudostanenadsprávnou

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

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

Ú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

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

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

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

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

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

9. Systém DNS. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si problematiku struktury a tvorby doménových jmen.

9. Systém DNS. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si problematiku struktury a tvorby doménových jmen. 9. Systém DNS Studijní cíl Představíme si problematiku struktury a tvorby doménových jmen. Doba nutná k nastudování 1,5 hodiny Uvedená kapitola vychází ze zdroje [1]. Celý Internet je z hlediska pojmenovávání

Více

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

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

Více

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

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

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

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

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

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

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

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

Více

Dotazovací jazyky I. Datová krychle. Soběslav Benda

Dotazovací jazyky I. Datová krychle. Soběslav Benda Dotazovací jazyky I Datová krychle Soběslav Benda Obsah Úvod do problematiky Varianty přístupu uživatelů ke zdrojům dat OLTP vs. OLAP Datová analýza Motivace Vytvoření křížové tabulky Datová krychle Teorie

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

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

6. Fyzická (interní) úroveň databázového systému

6. Fyzická (interní) úroveň databázového systému 6. Fyzická (interní) úroveň databázového systému 6.1. Struktura databázového systému... 2 6.2. Přístup k datům v databázi... 3 6.3. Struktura souborů... 4 6.4. Správa vyrovnávací paměti... 8 6.5. Podstata

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

STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE

STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE WEBOWÉ STRÁNKY TŘÍD KAMIL POPELKA ZÁVĚREČNÁ MATURITNÍ PRÁCE BRNO 2011 Prohlášení Prohlašuji, že maturitní práce je mým původním autorským dílem, které

Více

Optimalizace plnění a aktualizace velkých tabulek. Milan Rafaj, IBM

Optimalizace plnění a aktualizace velkých tabulek. Milan Rafaj, IBM Optimalizace plnění a aktualizace velkých tabulek Milan Rafaj, IBM Agenda OLTP vs DSS zpracování Optimalizace INSERT operací Optimalizace DELETE operací Optimalizace UPDATE operací Zdroje Dotazy OLTP vs

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

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

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

Více

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

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

VYTVÁŘENÍ DATABÁZÍ, VKLÁDÁNÍ ÚDAJŮ

VYTVÁŘENÍ DATABÁZÍ, VKLÁDÁNÍ ÚDAJŮ Úvod do problematiky VYTVÁŘENÍ DATABÁZÍ, VKLÁDÁNÍ ÚDAJŮ Databáze je uspořádaná množina velkého množství informací (dat). Příkladem databáze je překladový slovník, seznam PSČ nebo telefonní seznam. Databáze

Více

Instalace. Produkt je odzkoušen pro MS SQL server 2008 a Windows XP a Windows 7. Pro jiné verze SQL server a Windows nebyl testován.

Instalace. Produkt je odzkoušen pro MS SQL server 2008 a Windows XP a Windows 7. Pro jiné verze SQL server a Windows nebyl testován. Instalace Produkt se neinstaluje. Stačí soubor uložit na libovolné místo na Vašem počítací (klikněte pravým tlačítkem a dejte 'uložit cíl jako ), pak jen spustit. Požadavky na software Produkt je odzkoušen

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

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

30 APZ Klienti. Popis modulu

30 APZ Klienti. Popis modulu 30 APZ Klienti Uživatelský modul APZ Klienti náleží k modulům řešícím agendu agentury podporovaného zaměstnávání se zaměřením na osoby se zdravotním postižením. Modul umožňuje evidenci klientů agentury

Více

TEORIE ZPRACOVÁNÍ DAT

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

Více

Databáze Databázové systémy MS Access

Databáze Databázové systémy MS Access Databáze Databázové systémy MS Access Nasazení databází Databáze evidence nějakých údajů Databázové aplikace obsahují konkrétní specifické funkce pro práci s určitými daty (tyto funkce jsou v jiných DB

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

Maturitní témata Školní rok: 2015/2016

Maturitní témata Školní rok: 2015/2016 Maturitní témata Školní rok: 2015/2016 Ředitel školy: Předmětová komise: Předseda předmětové komise: Předmět: PhDr. Karel Goš Informatika a výpočetní technika Mgr. Ivan Studnička Informatika a výpočetní

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

7 Formátovaný výstup, třídy, objekty, pole, chyby v programech

7 Formátovaný výstup, třídy, objekty, pole, chyby v programech 7 Formátovaný výstup, třídy, objekty, pole, chyby v programech Studijní cíl Tento studijní blok má za cíl pokračovat v základních prvcích jazyka Java. Konkrétně bude věnována pozornost formátovanému výstupu,

Více

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

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

Více

INOVACE PŘEDMĚTŮ ICT. MODUL 11: PROGRAMOVÁNÍ WEBOVÝCH APLIKLACÍ Metodika

INOVACE PŘEDMĚTŮ ICT. MODUL 11: PROGRAMOVÁNÍ WEBOVÝCH APLIKLACÍ Metodika Vyšší odborná škola ekonomická a zdravotnická a Střední škola, Boskovice INOVACE PŘEDMĚTŮ ICT MODUL 11: PROGRAMOVÁNÍ WEBOVÝCH APLIKLACÍ Metodika Zpracoval: Jaroslav Kotlán srpen 2009s Úvod Modul Programování

Více

Zátěžové testy aplikací

Zátěžové testy aplikací Zátěžové testy aplikací Obsah Zátěžové testy v životním cyklu vývoje software Kdy a proč provádět zátěžové testy Projekt zátěžového testu Fáze zátěžového testu Software pro zátěžové testy Zátěžové testy

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

Ukládání a vyhledávání XML dat

Ukládání a vyhledávání XML dat XML teorie a praxe značkovacích jazyků (4IZ238) Jirka Kosek Poslední modifikace: $Date: 2014/12/04 19:41:24 $ Obsah Ukládání XML dokumentů... 3 Ukládání XML do souborů... 4 Nativní XML databáze... 5 Ukládání

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

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

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

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

Více

Téma 12: Správa diskových jednotek a system souborů. Téma 12: Správa diskových jednotek a systémů souborů

Téma 12: Správa diskových jednotek a system souborů. Téma 12: Správa diskových jednotek a systémů souborů Téma 12: Správa diskových jednotek a systémů souborů 1 Teoretické znalosti V tomto cvičení se podíváte na práci s diskovými jednotkami. Naučíte se používat nástroj správy disků, který se poprvé objevil

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

Materiál ke cvičením - SQL

Materiál ke cvičením - SQL Materiál ke cvičením - 1. Stručná syntaxe vybraných příkazů jazyka (detailní syntaxe příkazů je uvedena on-line manuálech přístupných z prostředí sítě VŠE) SELECT výběr a zobrazení hodnot z databáze: SELECT

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

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

Popis produktu IDFU. Řešení součinnosti s oprávněnými osobami verze 2. Aegis s.r.o.

Popis produktu IDFU. Řešení součinnosti s oprávněnými osobami verze 2. Aegis s.r.o. Popis produktu IDFU Řešení součinnosti s oprávněnými osobami verze 2 Obsah Produkt IDFU...3 K čemu slouží...3 Historie IDFU...3 IDFU dnes...3 Generování odpovědí...4 Pozice produktu...5 Hlavní přínosy...5

Více

Program vyhodnocení rizik a stavu pro službu Active Directory a Microsoft Online Services

Program vyhodnocení rizik a stavu pro službu Active Directory a Microsoft Online Services DATASHEET Program vyhodnocení rizik a stavu pro službu Active Directory a Microsoft Online Services Získejte klíčový náhled do zdraví vaší adresářové služby a maximalizujte výkonnost vašich IT zařízení

Více

1 Administrace systému 3. 1.3 Moduly... 3 1.4 Skupiny atributů... 4 1.5 Atributy... 4 1.6 Hodnoty atributů... 4

1 Administrace systému 3. 1.3 Moduly... 3 1.4 Skupiny atributů... 4 1.5 Atributy... 4 1.6 Hodnoty atributů... 4 CRM SYSTÉM KORMORÁN PŘÍRUČKA ADMINISTRÁTORA Obsah 1 Administrace systému 3 1.1 Uživatelské účty.................................. 3 1.2 Přístupová práva................................. 3 1.3 Moduly.......................................

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

Ú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ývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

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

Více

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

Základní datové struktury

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

Více

Bezpečná výměna souborů mezi vnitřní a vnější sítí organizace. Autor: Martin Hanzal, CTO SODATSW spol. s r. o., Horní 32, Brno, Czech Republic

Bezpečná výměna souborů mezi vnitřní a vnější sítí organizace. Autor: Martin Hanzal, CTO SODATSW spol. s r. o., Horní 32, Brno, Czech Republic Bezpečná výměna souborů mezi vnitřní a vnější sítí organizace Autor: Martin Hanzal, CTO SODATSW spol. s r. o., Horní 32, Brno, Czech Republic Shrnutí Nejstřeženější data a informace jsou odděleny od vnějšího

Více

1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam.

1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam. 10.6.7 POSTUP TVORBY KOMBINOVANÉHO SEZNAMU 1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam. 2. V rozbalovací nabídce se seznamem datových typů vyberte volbu

Více

Příloha č. 12. Systém společného přihlašování, tzv. Single Sign On, ochrana dat

Příloha č. 12. Systém společného přihlašování, tzv. Single Sign On, ochrana dat Název projektu: Redesign Statistického informačního systému v návaznosti na zavádění egovernmentu v ČR Příjemce: Česká republika Český statistický úřad Registrační číslo projektu: CZ.1.06/1.1.00/07.06396

Více

FIO API PLUS. Verze 1.1.1

FIO API PLUS. Verze 1.1.1 FIO API PLUS Verze 1.1.1 www.fio.cz Verze 29. 5. 2015 OBSAH: 1 FUNKČNÍ POPIS... 2 2 INSTALACE APLIKACE... 2 3 ZÍSKÁNÍ TOKENU... 2 4 PŘIDÁNÍ ÚČTU / TOKENU DO APLIKACE... 3 5 STAŽENÍ DAT... 3 Periodické

Více

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

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

Více

OZD. 2. ledna 2013. Logický (Objekty, atributy,...) objekty stejného typu.

OZD. 2. ledna 2013. Logický (Objekty, atributy,...) objekty stejného typu. OZD 2. ledna 2013 1 Paměti Hierarchie: Registry Cache (nejsou viditelné) Primární pamět (RAM) Pamět druhé úrovně (Disky, trvalá úložiště), pomalá Pamět třetí úrovně (CD, pásky) 1.1 Paměti druhé úrovně

Více

KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ

KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ KLÍČOVÉ POJMY Internet World Wide Web FTP, fulltext e-mail, IP adresa webový prohlížeč a vyhledávač CÍLE KAPITOLY Pochopit, co je Internet

Více

ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ. MEIV - 2.3.1.1 Windows server 2003 (seznámení s nasazením a použitím)

ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ. MEIV - 2.3.1.1 Windows server 2003 (seznámení s nasazením a použitím) Object 12 3 Projekt: ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ Téma: MEIV - 2.3.1.1 Windows server 2003 (seznámení s nasazením a použitím) Obor: Mechanik Elektronik Ročník: 4. Zpracoval(a): Bc. Martin Fojtík Střední

Více

Tiskové sestavy. Zdroj záznamu pro tiskovou sestavu. Průvodce sestavou. Použití databází

Tiskové sestavy. Zdroj záznamu pro tiskovou sestavu. Průvodce sestavou. Použití databází Tiskové sestavy Tiskové sestavy se v aplikaci Access používají na finální tisk informací z databáze. Tisknout se dají všechny objekty, které jsme si vytvořili, ale tiskové sestavy slouží k tisku záznamů

Více

44 Organizace akcí. Popis modulu. Záložka Seznam akcí

44 Organizace akcí. Popis modulu. Záložka Seznam akcí 44 Organizace akcí Modul Organizace akcí slouží k přípravě a plánování různých společenských, sportovních, kulturních, apod. akcí. Tyto akce je možné dále dělit do částí (ve stromové struktuře) a plánovat

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

51 Docházka externistů

51 Docházka externistů 51 Docházka externistů Uživatelský modul Docházka externistů slouží ke zpracování podkladu pro výpočet mzdy všem externím zaměstnancům. Za externí zaměstnance jsou považováni ti, kteří nemají účet v informačním

Více

Aplikace pro srovna ní cen povinne ho ruc ení

Aplikace pro srovna ní cen povinne ho ruc ení Aplikace pro srovna ní cen povinne ho ruc ení Ukázkový přiklad mikroaplikace systému Formcrates 2010 Naucrates s.r.o. Veškerá práva vyhrazena. Vyskočilova 741/3, 140 00 Praha 4 Czech Republic tel.: +420

Více

Rezervační systém Tvorba WWW stránek

Rezervační systém Tvorba WWW stránek 2012 Rezervační systém Tvorba WWW stránek Vytvoření rezervačního systému pro rezervaci motokár,ubytování a atrakcí Marek Svoboda Motokáry Motobydlo 30.12.2012 Obsah 1.Základní charakteristika... 3 a) Téma

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

Sázková kancelář Z pekla štěstí

Sázková kancelář Z pekla štěstí Sázková kancelář Z pekla štěstí Řešitelský tým Michal Pfeifer, Martin Halamíček, Jan Blaško, Zdeněk Křepela, Jan Popelka, Jan Mach Úvod Sázková kancelář Z pekla štěstí je malá společnost s několika malými

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

Pomůcka/manuál pro redakční systém http://helpdesk.remax-czech.cz verze 1.0

Pomůcka/manuál pro redakční systém http://helpdesk.remax-czech.cz verze 1.0 Pomůcka/manuál pro redakční systém http://helpdesk.remax-czech.cz verze 1.0 Přihlášení do systému Na adrese http://helpdesk.remax-czech.cz, viz. obr., vyplněním příslušného uživatelského jména a hesla.

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

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

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

Bezpečnostní politika společnosti synlab czech s.r.o.

Bezpečnostní politika společnosti synlab czech s.r.o. Bezpečnostní politika společnosti synlab czech s.r.o. Platnost dokumentu: 14. ledna 2015 Datum vypracování: 8. ledna 2015 Datum schválení: 13. ledna 2015 Vypracoval: Schválil: Bc. Adéla Wosková, Ing. Jaroslav

Více

10 Balíčky, grafické znázornění tříd, základy zapozdření

10 Balíčky, grafické znázornění tříd, základy zapozdření 10 Balíčky, grafické znázornění tříd, základy zapozdření Studijní cíl Tento studijní blok má za cíl pokračovat v základních prvcích jazyka Java. Konkrétně bude věnována pozornost příkazům balíčkům, grafickému

Více

Tvorba kurzu v LMS Moodle

Tvorba kurzu v LMS Moodle Tvorba kurzu v LMS Moodle Před počátkem práce na tvorbě základního kurzu znovu připomínám, že pro vytvoření kurzu musí být profil uživatele nastaven administrátorem systému minimálně na hodnotu tvůrce

Více