12. blok Fyzický návrh databáze

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

10. blok Logický návrh databáze

10. blok Logický návrh databáze 10. blok Logický návrh databáze Studijní cíl Tento blok je věnován převodu konceptuálního návrhu databáze na návrh logický. Blok se věnuje tvorbě tabulek na základě entit z konceptuálního modelu a dále

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

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

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

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

RELAČNÍ DATABÁZOVÉ SYSTÉMY

RELAČNÍ DATABÁZOVÉ SYSTÉMY RELAČNÍ DATABÁZOVÉ SYSTÉMY VÝPIS KONTROLNÍCH OTÁZEK S ODPOVĚDMI: Základní pojmy databázové technologie: 1. Uveďte základní aspekty pro vymezení jednotlivých přístupů ke zpracování hromadných dat: Pro vymezení

Více

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE 2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE Studijní cíl Tento blok je věnován základní syntaxi příkazu SELECT, pojmům projekce a restrikce. Stručně zde budou představeny příkazy

Více

Databáze II. 1. přednáška. Helena Palovská palovska@vse.cz

Databáze II. 1. přednáška. Helena Palovská palovska@vse.cz Databáze II 1. přednáška Helena Palovská palovska@vse.cz Program přednášky Úvod Třívrstvá architektura a O-R mapování Zabezpečení dat Role a přístupová práva Úvod Co je databáze Mnoho dat Organizovaných

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

Kapitola 6: Omezení integrity. Omezení domény

Kapitola 6: Omezení integrity. Omezení domény - 6.1 - Omezení domény Referenční integrita Aserce Spouštěče (Triggers) Funkční závislosti Kapitola 6: Omezení integrity Omezení domény Omezení integrity zabraňují poškození databáze; zajišťují, že autorizované

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

4. blok část A Logické operátory

4. blok část A Logické operátory 4. blok část A Logické operátory Studijní cíl Tento blok je věnován představení logických operátorů AND, OR, NOT v jazyce SQL a práce s nimi. Doba nutná k nastudování 1-2 hodiny Průvodce studiem Při studiu

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

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

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

Access Tabulka letní semestr 2013

Access Tabulka letní semestr 2013 MS Access Tabulka letní semestr 2013 Tvorba nové tabulky importem dat propojením externího souboru pomocí Průvodce v návrhovém zobrazení Návrh struktury tabulky Tabulka záznam pole záznamu Jmeno RodCislo

Více

Operátory ROLLUP a CUBE

Operátory ROLLUP a CUBE Operátory ROLLUP a CUBE Dotazovací jazyky, 2009 Marek Polák Martin Chytil Osnova přednášky o Analýza dat o Agregační funkce o GROUP BY a jeho problémy o Speciální hodnotový typ ALL o Operátor CUBE o Operátor

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

Informační systémy 2008/2009. Radim Farana. Obsah. Jazyk SQL

Informační systémy 2008/2009. Radim Farana. Obsah. Jazyk SQL 4 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk SQL, datové typy, klauzule SELECT, WHERE, a ORDER BY. Doporučená

Více

Kurz Databáze. Obsah. Dotazy. Zpracování dat. Doc. Ing. Radim Farana, CSc.

Kurz Databáze. Obsah. Dotazy. Zpracování dat. Doc. Ing. Radim Farana, CSc. 1 Kurz Databáze Zpracování dat Doc. Ing. Radim Farana, CSc. Obsah Druhy dotazů, tvorba dotazu, prostředí QBE (Query by Example). Realizace základních relačních operací selekce, projekce a spojení. Agregace

Více

Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hoksza, Ph.D. http://siret.cz/hoksza

Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hoksza, Ph.D. http://siret.cz/hoksza Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hksza, Ph.D. http://siret.cz/hksza Osnva Seznámení s SQL Server Management Studiem (SSMS) Základní architektura

Více

Návrh a tvorba WWW stránek 1/14. PHP a databáze

Návrh a tvorba WWW stránek 1/14. PHP a databáze Návrh a tvorba WWW stránek 1/14 PHP a databáze nejčastěji MySQL součástí balíčků PHP navíc podporuje standard ODBC PHP nemá žádné šablony pro práci s databází princip práce s databází je stále stejný opakované

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

Měřící systém se vzdáleným přístupem. Databáze

Měřící systém se vzdáleným přístupem. Databáze ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ KATEDRA MĚŘENÍ Měřící systém se vzdáleným přístupem Databáze Jiří Javůrek 2003/2005 0. Obsah 0. Obsah...1 1. Požadavky...2 2. Struktura databáze...2

Více

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky.

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Projekt ESF OP VK reg.č. CZ.1.07/2.2.00/28.0209 Elektronické opory a e-learning pro obory výpočtového

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

37. Indexování a optimalizace dotazů v relačních databázích, datové struktury, jejich výhody a nevýhody

37. Indexování a optimalizace dotazů v relačních databázích, datové struktury, jejich výhody a nevýhody 37. Indexování a optimalizace dotazů v relačních databázích, datové struktury, jejich výhody a nevýhody Využití databázových indexů Databázové indexy slouží ke zrychlení přístupu k datům a měly by se používat

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

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

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

PRŮBĚHOVÝ TEST Z PŘEDNÁŠEK

PRŮBĚHOVÝ TEST Z PŘEDNÁŠEK PRŮBĚHOVÝ TEST Z PŘEDNÁŠEK listopad 2009 souhrn v1 Červené dobře (nejspíš), modré možná Oracle Internet Directory OID: Databáze nemůže z OID přebírat seznam uživatelů *Databáze může získat z OID seznam

Více

Databázové systémy. Cvičení 6: SQL

Databázové systémy. Cvičení 6: SQL Databázové systémy Cvičení 6: SQL Co je SQL? SQL = Structured Query Language SQL je standardním (ANSI, ISO) textovým počítačovým jazykem SQL umožňuje jednoduchým způsobem přistupovat k datům v databázi

Více

Maturitní otázky z předmětu PROGRAMOVÁNÍ

Maturitní otázky z předmětu PROGRAMOVÁNÍ Wichterlovo gymnázium, Ostrava-Poruba, příspěvková organizace Maturitní otázky z předmětu PROGRAMOVÁNÍ 1. Algoritmus a jeho vlastnosti algoritmus a jeho vlastnosti, formy zápisu algoritmu ověřování správnosti

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

Databázové systémy trocha teorie

Databázové systémy trocha teorie Databázové systémy trocha teorie Základní pojmy Historie vývoje zpracování dat: 50. Léta vše v programu nevýhody poměrně jasné Aplikace1 alg.1 Aplikace2 alg.2 typy1 data1 typy2 data2 vytvoření systémů

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

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

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3aph) 2. a 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Co nás čeká: 2. soustředění 16.1.2009

Více

Administrace Oracle Práva a role, audit. Kukhar Maria 29.10.2012

Administrace Oracle Práva a role, audit. Kukhar Maria 29.10.2012 Administrace Oracle Práva a role, audit Kukhar Maria 29.10.2012 Ve výchozím nastavení, uživatel Oracle nemůže nic dělat, ani připojit se k databázi. Aby uživatele měli přistup k DB, je třeba vytvořit uživatelské

Více

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

Úvod do MS Access. Modelování v řízení. Ing. Petr Kalčev Úvod do MS Access Modelování v řízení Ing. Petr Kalčev Postup při tvorbě aplikace Vytvoření tabulek Vytvoření relací Vytvoření dotazů Vytvoření formulářů Vytvoření sestav Tabulky Slouží k definování polí,

Více

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) Marketingová komunikace Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) 2. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Minulé soustředění úvod

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

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

UNIVERZITA PALACKÉHO V OLOMOUCI

UNIVERZITA PALACKÉHO V OLOMOUCI UNIVERZITA PALACKÉHO V OLOMOUCI PEDAGOGICKÁ FAKULTA Bakalářská práce 2014 Lenka Koutná UNIVERZITA PALACKÉHO V OLOMOUCI PEDAGOGICKÁ FAKULTA Katedra technické a informační výchovy Bakalářská práce Lenka

Více

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS Relační databázový model Databázové (datové) modely základní dělení klasické databázové modely relační databázový model relační databázový model Základní konstrukt - relace relace, schéma relace atribut,

Více

O Apache Derby detailněji. Hynek Mlnařík

O Apache Derby detailněji. Hynek Mlnařík O Apache Derby detailněji Hynek Mlnařík Agenda Historie Vlastnosti Architektura Budoucnost Historie 1997 Cloudscape Inc. - JBMS 1999 Informix Software, Inc. odkoupila Cloudscape, Inc. 2001 IBM odkoupila

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

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

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

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

5. Směrování v počítačových sítích a směrovací protokoly

5. Směrování v počítačových sítích a směrovací protokoly 5. Směrování v počítačových sítích a směrovací protokoly Studijní cíl V této kapitole si představíme proces směrování IP.. Seznámení s procesem směrování na IP vrstvě a s protokoly RIP, RIPv2, EIGRP a

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

Databáze SQL SELECT. David Hoksza http://siret.cz/hoksza

Databáze SQL SELECT. David Hoksza http://siret.cz/hoksza Databáze SQL SELECT David Hoksza http://siret.cz/hoksza Osnova Úvod do SQL Základní dotazování v SQL Cvičení základní dotazování v SQL Structured Query Language (SQL) SQL napodobuje jednoduché anglické

Více

6. SQL složitější dotazy, QBE

6. SQL složitější dotazy, QBE 6. SQL složitější dotazy, QBE Příklady : Veškeré příklady budou dotazy nad databází KONTAKTY nebo KNIHOVNA nebo FIRMA Databáze KONTAKTY OSOBA (Id_osoba, Příjmení, Jméno, Narození, Město, Ulice, PSČ) EMAIL

Více

Základní informace: vysoce komfortnímu prostředí je možné se systémem CP Recorder efektivně pracovat prakticky okamžitě po krátké zaškolení.

Základní informace: vysoce komfortnímu prostředí je možné se systémem CP Recorder efektivně pracovat prakticky okamžitě po krátké zaškolení. Základní informace: CP Recorder je v Čechách vyvíjený systém pro sofistikované zaznamenávání telefonních hovorů. V prvé řadě je určen pro optimalizaci služeb, které poskytují u nás stále více populární

Více

13 Barvy a úpravy rastrového

13 Barvy a úpravy rastrového 13 Barvy a úpravy rastrového Studijní cíl Tento blok je věnován základním metodám pro úpravu rastrového obrazu, jako je např. otočení, horizontální a vertikální překlopení. Dále budo vysvětleny různé metody

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

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

SQL - trigger, Databázové modelování

SQL - trigger, Databázové modelování 6. přednáška z předmětu Datové struktury a databáze (DSD) Ústav nových technologií a aplikované informatiky Fakulta mechatroniky, informatiky a mezioborových studií Technická univerzita v Liberci jan.lisal@tul.cz

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

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

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

Ú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

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

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

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

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

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

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

Algoritmizace a programování

Algoritmizace a programování Algoritmizace a programování Vyhledávání, vkládání, odstraňování Vyhledání hodnoty v nesetříděném poli Vyhledání hodnoty v setříděném poli Odstranění hodnoty z pole Vkládání hodnoty do pole Verze pro akademický

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

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

DJ2 rekurze v SQL. slajdy k přednášce NDBI001. Jaroslav Pokorný

DJ2 rekurze v SQL. slajdy k přednášce NDBI001. Jaroslav Pokorný DJ2 rekurze v SQL slajdy k přednášce NDBI001 Jaroslav Pokorný 1 Obsah 1. Úvod 2. Tvorba rekurzívních dotazů 3. Počítaní v rekurzi 4. Rekurzívní vyhledávání 5. Logické hierarchie 6. Zastavení rekurze 7.

Více

Databázové a informační systémy Informační systém prodejny nábytku. Jakub Kamrla, KAM087

Databázové a informační systémy Informační systém prodejny nábytku. Jakub Kamrla, KAM087 Databázové a informační systémy Informační systém prodejny nábytku Jakub Kamrla, KAM087 1. část Funkční a nefunkční požadavky 1. K čemu má systém sloužit Jedná se o informační systém pro jednu nejmenovanou

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

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

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

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

Směrování. static routing statické Při statickém směrování administrátor manuálně vloží směrovací informace do směrovací tabulky.

Směrování. static routing statické Při statickém směrování administrátor manuálně vloží směrovací informace do směrovací tabulky. Směrování Ve větších sítích již není možné propojit všechny počítače přímo. Limitujícím faktorem je zde množství paketů všesměrového vysílání broadcast, omezené množství IP adres atd. Jednotlivé sítě se

Více

Objektově relační databáze a ORACLE 8

Objektově relační databáze a ORACLE 8 Objektově relační databáze a ORACLE 8 Ludmila Kalužová VŠB - TU Ostrava, Ekonomická fakulta, Katedra informatiky v ekonomice, Sokolská 33, 701 21 Ostrava 1 Abstrakt V současné době existuje velký počet

Více

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např.

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např. 2 přednáška 2 října 2012 10:32 Souborově orientované uchování dat Slabý HW Není možné uchovávat "velká data" - maximálně řádově jednotky MB Na každou úlohu samostatná aplikace, která má samostatná data

Více

12. blok Pokročilé konstrukce SQL dotazů - část II

12. blok Pokročilé konstrukce SQL dotazů - část II 12. blok Pokročilé konstrukce SQL dotazů - část II Studijní cíl Tento blok je věnován pokročilým konstrukcím SQL dotazů, které umožní psát efektivní kód. Pozornost je věnována vytváření pohledů v rámci

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

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

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

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

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

Informační systémy 2008/2009. Radim Farana. Obsah. Dotazy přes více tabulek

Informační systémy 2008/2009. Radim Farana. Obsah. Dotazy přes více tabulek 5 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk SQL, Spojení tabulek, agregační dotazy, jednoduché a složené

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

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

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

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

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná.

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná. Průběžná klasifikace Nová verze modulu Klasifikace žáků přináší novinky především v práci s průběžnou klasifikací. Pro zadání průběžné klasifikace ve třídě doposud existovaly 3 funkce Průběžná klasifikace,

Více

RELAČNÍ DATABÁZE. Cíl:

RELAČNÍ DATABÁZE. Cíl: Cíl: Cílem tohoto předmětu je získat praktické znalosti a dovednosti v oblasti relačních databází, jakož i seznámit se s novými trendy v objektově relačních a objektových databázích. Podstatná část je

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

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

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

Maturitní projekt do IVT Pavel Doleček

Maturitní projekt do IVT Pavel Doleček Maturitní projekt do IVT Pavel Doleček CO FILMBOOK JE Filmbook je uzavřená webová aplikace pro celkovou správu informací a dat souvisejících se sledováním filmů. Primárně je zaměřen na uchovávání a spravování

Více