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