UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE"

Transkript

1 UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Nástroj na tvorbu testovacích dat pro zátěžové testování DB Autor BP: Marek Chytrý Vedoucí BP: Ing. Miroslav Žďárský 2012 Praha

2

3

4 ČESTNÉ PROHLÁŠENÍ Prohlašuji, že svoji bakalářskou práci na téma Nástroj na tvorbu testovacích dat pro zátěžové testování DB jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních, a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V... dne.... Marek Chytrý

5 PODĚKOVÁNÍ Děkuji vedoucímu bakalářské práce Ing. Miroslavovi Žďárskému za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce. Dále chci velmi poděkovat své manželce za oporu, povzbuzení a vytvoření příjemného prostředí pro psaní této práce a rodičům, kteří mi umožnili studium a během studia mě podporovali.

6 NÁSTROJ NA TVORBU TESTOVACÍCH DAT PRO ZÁTĚŽOVÉ TESTOVÁNÍ DB TOOL FOR CREATING TEST DATA FOR STRESS TESTING DB 6

7 ABSTRAKT Cílem této bakalářské práce je navrhnout nástroj na generování dat pro zátěžové testy. Aby však tato data byla správně navržena, je potřeba porozumět databázi, jak s daty pracuje a jak můžeme na základě správného návrhu datové struktury tuto činnost co nejvíce zefektivnit. V teoretické části jsou nejprve popsány základní pojmy týkající se relačních databází a zátěžových testů. Poté jsou vysvětleny způsoby sběru dat z databáze a je ukázáno na příkladech, jak lze příkazy pro práci s daty optimalizovat. Dále navazují informace o způsobech, jak databáze volí co nejefektivnější přístup k datům za použití optimizeru a statistik databáze. Práce se nezaměřuje na konfiguraci databáze nebo hardwaru serveru, to by bylo už na téma jiné bakalářské práce. V praktické části je pak popsán navržený nástroj pro generování dat, jeho části a princip generování testovacích dat. Zde je také základně popsán jazyk PL/SQL, ve kterém je nástroj naprogramován. Klíčová slova: relační databáze, zátěžové testy, optimalizace, optimizer, statistiky, PL/SQL 7

8 ABSTRACT IN ENGLISH The aim of this bachelor thesis is to propose a tool for generating data for stress tests. In order that this data are properly designed, it is necessary to understand the database; how it works with data and how we can do this activity more effective based on right proposal of the data structure. In the theoretical section there are firstly described the basic concepts related to relational databases and stress tests. Then there is explained how we collect data from the database and shown in the examples, how the commands for working with data can be optimized. Further follow information how database chooses the most effective access to data using the optimizer and statistics database. The thesis does not focus on the configuration database or hardware; it would be the topic of another thesis. In the practical part there is described a tool designed to generate data, its parts and principles of generating test data. There is also described programming language PL/SQL, in which the tool is programmed. Keywords: relational database, stress tests, optimization, optimizer, statistics, PL/SQL 8

9 OBSAH 1. Úvod Základní pojmy k optimalizaci databází Databáze Relační databáze Zátěžové testy Získání dat pro testování Přístupy k tabulkám Exekuční plán Indexy B-Tree index Bitmap index Indexově organizované tabulky (Index organized tables) Optimizer RBO (Rule based optimizer) a CBO (Cost based optimizer) Statistiky Hinty Praktická část - Generování dat Úvod do PL/SQL Balíčky, procedury a funkce Princip generování Zdrojová data pro generování Balíček fetch_source_data

10 Balíček random_data Balíček package_random_table Pomocné balíčky, funkce a procedury Export a import velkého množství dat v databázích Oracle Závěr Conclusion Zdroje Seznam použitých symbolů a zkratek Seznam obrázků Seznam tabulek

11 1. ÚVOD Vysoká dostupnost a krátká doba odezvy informačních systémů se v dnešním světě pokládá za samozřejmost. Pokud se některá internetová stránka nenačte uživateli do tří sekund, uživatel pravděpodobně takovou stránku po této době zavře a podívá se raději po jiné stránce, která se mu dostatečně rychle zobrazí. Tím narážím na fakt, že jedním z nejdůležitějších vlastností informačního systému je jeho doba odezvy. Tato oblast informačních technologií není jednoduchá, ale dnešní uživatelé předpokládají a berou za samozřejmost, že vše probíhá bez velkých prodlev. Navíc požadavky na zajištění dostupností a zvládání zátěží v době špiček je stanoveno v provozních smlouvách a dokumentech SLA. Pokud jsou tato stanovení porušena, pak provozovatel informačního systému neplatí jen ušlé zisky společností, ale může navíc platit i smluvní pokuty. Na základě požadavků zajištění nabízeného výkonu je potřeba tyto vlastnosti systému otestovat. A testování je zapotřebí nejen při zavádění systému, ale třeba i při změně softwarových technologií. Podle internetového článku na System On-line (1) je zapotřebí testovat výkon v těchto případech: 1. Výkonnostní akceptace řešení 2. Optimalizace hardwarové a softwarové konfigurace 3. Zjištění limitů hardwarové a softwarové konfigurace 4. Hledání úzkých míst již provozovaného systému 5. Ověření výkonnosti po změně technologie, po upgradu na novou verzi (operačního systému, aplikace, databáze) nebo po významné změně konfigurace Na vysoké škole Unicorn College jsem se seznámil s databází Oracle a její administrací a také se způsoby testování. V obou kurzech byly probírány zátěžové testy, ale v každém z jiného úhlu pohledu. Velmi mě zaujala myšlenka spojit informace z těchto kurzů a vytvořit praktický nástroj pro generování dat pro zátěžové testy pro relační databáze. 11

12 2. ZÁKLADNÍ POJMY K OPTIMALIZACI DATABÁZÍ 2.1. Databáze Data v jakémkoliv systému je potřeba perzistentně ukládat, aby bylo možné je později kdykoliv opět načíst. V jednoduchých systémech nebo domácích počítačích stačí na uložení dat souborový systém, pokud ale potřebujete například: 1. Data rychle vyhledávat 2. Přistupovat k datům paralelně 3. Pokročilejší nastavení práv přístupů k datům 4. Vybírat pouze část z celé množiny dat podle potřeb uživatele systému. V těchto případech souborový systém určitě nedostačuje a je potřeba použít databázi. Databáze slouží primárně k trvalému uložení dat. Dnes navíc poskytuje mnohé pokročilé funkce. Například zabezpečení, zálohování, archivaci, analýzu dat a další. Databáze je jedna z nejdůležitějších částí systému, a proto je potřeba tuto oblast nezanedbat. Většina lidí si pod pojmem databáze představí tabulky dat, ale toto je jen jeden typ databází, relační databáze. Tyto databáze jsou tvořeny relacemi. Tento typ databází ale není jediný, můžeme se ještě setkat s databázemi objektovými nebo objektově-relačními. Objektové databáze neukládají data do tabulek, ale přímo ukládají objekty, se kterými programátor pracuje. Proto pro programátory je mnohem intuitivnější ukládat jednotlivé objekty tříd a nemuset se zamýšlet nad tabulkami nebo převodem objektů do tabulek. Dalším možným přístupem je objektově-relační databáze. V tomto případě je potřeba nejprve nadefinovat způsob převodu mezi tabulkami a objekty. Aby bylo možné objekty do tabulky namapovat, zakládají se sloupce tabulky tak, aby odpovídaly jednotlivým atributům třídy, jejichž objekty se mají do tabulky vložit. Jednotlivé řádky tabulky pak odpovídají jednotlivým objektům. Tento přístup se snaží brát přednosti z obou zvýše zmíněných typů databází, ale v konečném důsledku je náročné samotné mapování tabulek na objekty a navíc musí programátoři popsat daný způsob mapování tabulek na objekty. 12

13 Tato práce se zaměřuje pouze na relační databáze, a konkrétně na relační databázi Oracle. Pro tuto databázi jsou napsány i praktické příklady, a je pro ni primárně určen i nástroj pro generování dat. Tato databáze je zároveň nejrozšířenější na trhu komerčních databází a je používána pro rozsáhlé informační systémy. V této bakalářské práci je pojem databáze používán dvěma různými způsoby, a to jednak tento pojem je používán ve smyslu trvalého úložiště dat a jednak ve smyslu komplexního systému, který se stará o kompletní správu všech dat uložených v daném systému Relační databáze Základem relačních databází jsou tabulky. Tabulky se skládají ze sloupců, ve kterých jsou uloženy jednotlivé proměnné. Jednotlivé sloupce jsou pojmenovány tak, aby co nejlépe vystihly data v nich uložená. Pro každý sloupec je definovaný datový typ, ten určuje, jaká data jsou ve sloupci uložena. V jednotlivých řádcích jsou pak uložené jednotlivé záznamy. Pro přístup k těmto datům se používá speciálně navržený jazyk SQL. Ten se skládá z několika skupin příkazů, které jsou rozděleny podle svého účelu. Skupiny příkazů: 1. DDL (Data Definition Language) příkazy pro definice struktur databáze tabulky, indexy 2. DML (Data Manipulation Language) příkazy pro manipulaci s daty 3. DCL (Data Control Language) příkazy pro řízení kontroly nad daty 4. TCC (Transaction Control Commands) příkazy pro řízení transakcí O každé skupině jazyků by mohly být napsány celé knížky. V této práci jsou jednotlivé typy příkazů popsány pouze z pohledu optimalizace. V teoretické části práce je popisována skupina příkazů DML. Hlavně je zde popsáno, jakým způsobem databáze vrací řádky pro příkaz SELECT. Naváže kapitola o indexech, které slouží ke zrychlení přístupu do tabulek databáze a spadají do skupiny příkazů DDL. V praktické části pak bude popsáno, jakým způsobem budou generována data pro zátěžové testy a také jak jsou vkládána do tabulek. Data v tabulkách mohou mít velmi složitou strukturu a množství dat může být velmi rozsáhlé. Pro správné navržení datových struktur je potřeba zohlednit mnoho faktorů a po samotném navržení databázového systému je následně potřeba ověřit splnění požadavků. 13

14 Není možné zjistit až na produkci, že byla nevhodně navržena. Proto je maximálně důležité ještě před jejím zavedením do ostrého provozu ověřit pomocí zátěžových testů, že je schopna zpracovávat požadované objemy dat. (2) 14

15 2.2. Zátěžové testy Testování výkonu a možné zátěže databázového systému není jednoduchá činnost a často je zanedbávána nebo nedoceňovaná. Při práci na projektu pak bývá tato oblast nejčastěji ta, která je z nedostatku buď finančních, nebo časových zdrojů zrušena. Přesto pokud je požadován kvalitní software, má tato oblast nezastupitelné místo. Univerzální návod na testování obecně bohužel neexistuje a myslet si, že informační systémy neobsahují žádné chyby, také není správný přístup. Pokud jsme tedy již rozhodnuti, že chceme testovat, musíme se následně zamyslet, co konkrétně a jakým způsobem bude testováno. Rozhodně je také důležité vědět, z jakého důvodu budou testy prováděny. Tato bakalářská práce se zaměřuje na testování výkonu a zjišťování jeho možné optimalizace. Na základě znalostí o optimalizaci je pak navržen způsob efektivního generování dat. Aby data byla věrná datům produkčním, je potřeba je vygenerovat správným způsobem. Generování dat není jediným způsobem, jak získat data pro databázi. Data je možno získat i jinými způsoby Získání dat pro testování Jednou z možností je přímo použít produkční data. Tato varianta je někdy používána, ale není úplně vhodná kvůli velkému riziku zneužití těchto dat a musí být v takovém případě přijata zvýšená bezpečnostní opatření. Toto řešení bývá voleno z důvodu jednoduchosti a rychlosti získání dat, v případech kdy potřebujeme dodat data do druhého dne. Dalším řešením je data masking. Tímto způsobem se použijí data produkční, ale znehodnocená tak, aby nebylo možné je obnovit, ale struktura těchto dat je shodná s produkčními daty. Viz obrázek 1. Jinou možností je vlastní vygenerování dat. Takto získaná data musí odpovídat datům reálným, co se týká hodnot a pravděpodobnosti opakování. Proto jsou tato data také nejvěrnější datům reálným a navíc zde nejsou bezpečnostní rizika jako u použití produkčních dat. Jinou obrovskou výhodou těchto dat je jejich volitelný rozsah. Pokud je dat nedostatek, není problém je doplnit. Toto u předešlých způsobů není možné. Na druhou stranu někdy může být obtížné získat pravděpodobnostní rozdělení dat, abychom dokázali 15

16 vygenerovat totožná data. Pokud ale tyto pravděpodobnosti rozdělení máme, získáváme další nezanedbatelnou výhodu, a tou je možnost vygenerovat libovolně velkou množinu dat, která odpovídá produkčním datům, a tímto způsobem se můžeme připravit na budoucí zátěž databáze. Obrázek 1: Data masking LAST_NAME SSN SALARY AGUILAR BENSON D SOUSA FI ORANO LAST_NAME BIRTH_NUMBER SALARY ANSKELFD BEPFZPEFZ ERPVQAJEF GEPV Zdroj: Vlastní zpracování Visio 2007 podle zdroje: Před popisem samotného generování bude popsán způsob zpracování příkazu od uživatele přes možné teoretické optimalizace dat v databázi Přístupy k tabulkám Přístupy do tabulky jsou způsoby, jakými jsou procházeny tabulky a vracena uživateli požadovaná data. Aby bylo možné vykonávat zátěžové testy, je nutné porozumět, jak databáze vyhledává žádaná data. Přístupů máme několik: Full table scan (FTS) Tento přístup načítá najednou všechna data z tabulek a následně je prochází, zda odpovídají zadaným kritériím. Což samozřejmě představuje náročné I/O operace. Databáze naštěstí data nenačítá postupně ale po blocích, čímž je načítání podstatně zrychleno. Tento přístup je zvolen, pokud má být načtena například celá tabulka nebo pokud máme malé množství dat a je rychlejší je všechna načíst, než je procházet pomocí některého z indexů. 16

17 Pokud nebyly nad sloupci tabulky vytvořeny indexy, nebo byly vytvořeny špatným způsobem, pak se také použije tento přístup. Rowid access Tento přístup je použit v případě, když jsou rowid řádky známy a databáze načte konkrétní blok, kde se požadovaná řádka přímo nachází. Proto se nejprve zjišťují rowid řádek pomocí full table scanu nebo index scanu. Pokud by byly známy rowid řádky, mohla by být zadána v podmínce where rowid = <řádek>, a poté by nebylo zapotřebí žádné další prohledávání tabulek, ale to většinou není známo. Příklad příkazu, kdy je známa rowid a databáze může k řádku přistoupit přímo přes ně: SELECT * FROM emp WHERE rowid = chartorowid('aaaw07aaeaaaai7aaa'); V příkazu byla použita funkce chartorowid, která slouží k převodu řetězce na rowid. Index unique scan (IUS) Index unique scan je přístup, který využívá indexů (indexy budou popsány v samostatné kapitole). Tyto indexy jsou vloženy k některému ze sloupců tabulky a databáze v nich vyhledává v případech, kdy je nad tímto sloupcem WHERE podmínka a vyfiltrovaných dat je malý počet. Index range scan (IRS) Tento přístup je podobný přístupu index unique scan, jen podle indexů nevyhledáváme unikátní hodnoty, ale interval hodnot. Většinou v podmínce příkazu jsou horní a dolní omezení pro vyhledávání v indexech. Fast full index scan (FFIS) Přístup je zvolen v případě, kdy hledaná hodnota je zároveň uložena v indexu a není potřeba přistupovat do samotné tabulky. FFIS je velmi podobný přístupu Full table scan. Stejně jako FTS načítá více bloků naráz, čímž urychluje získávání dat. Pokud je zvolen tento přístup, odpadá druhá fáze rowid access, která se ve všech ostatních případech vždy vykonává. 17

18 Databáze, pokud přistupuje k datům, jen zřídka volí pouze jeden přístup. Většinou volí kombinaci dvou a více přístupů. Které přístupy a v jakém pořadí jsou zvoleny, vyhodnocuje optimizer. Toto vyhodnocování je prováděno pro každý DML příkaz. Popis přístupů a dalšího zpracování dat, které jsou vracena databází, popisuje podrobně exekuční plán Exekuční plán Tento plán se skládá z několika kroků a tyto kroky neobsahují pouhý výběr dat. Může se jednat i o filtrování, řazení, seskupování nebo spojování tabulek. Exekuční plán je velmi důležitý, abychom dokázali pochopit navržené postupy optimizerem a mohli identifikovat případná slabá místa. Možné akce vykonávané v databázi a zobrazené v exekučním plánu: Pořadí tabulek vzájemně odkazovaných, ze kterých mají být data načtena. Způsob spojení tabulek, na základě příkazu uživatele. Operace s daty, například filtrování, řazení nebo seskupování. Exekuční plán je prováděn pro příkazy INSERT, DELETE, UPDATE nebo SELECT. (3) Pro zobrazení exekučního plánu stačí před příkaz napsat EXPLAIN PLAN FOR. Například: EXPLAIN PLAN FOR SELECT last_name FROM customers; Na následujícím obrázku je příklad exekučního plánu: Obrázek 2: Exekuční plán Zdroj: Vlastní zpracování 18

19 Z uvedeného exekučního plánu vyplývají následující operace. V prvním kroku jsou tabulky spojeny, pak je použit full table access a z těchto dat je vybrána pouze určitá data podle indexu ORD_CUSTOMER_IX. V následující tabulce je uvedeno, jaké sloupce může exekuční plán obsahovat a jejich stručný význam. Tabulka 1: Popis sloupců exekučního plánu Sloupeček exekučního plánu Operation Popis Prováděná operace v rámci jednoho kroku exekučního plánu. Name Rows Bytes Odkaz na objekt, se kterým databáze v daném kroku pracuje. Počet řádek načtených v rámci daného kroku. Počet bytů načtených v rámci operace. Cost CPU Relativní náročnost dané operace, velmi užitečné pokud chceme hledat slabá místa databáze. Očekávaná náročnost operace z pohledu procesoru. Operation Prováděná operace v rámci jednoho kroku exekučního plánu. Name Rows Bytes Odkaz na objekt, se kterým databáze v daném kroku pracuje. Počet řádek načtených v rámci daného kroku. Počet bytů načtených v rámci operace. 19

20 Exekuční plán je velmi komplexní popis operací prováděných databází. V příkladu a popisu uvedeného exekučního plánu jsem uvedl nejzákladnější informace, abych alespoň stručně nastínil jeho možnosti. Díky exekučnímu plánu dokážeme analyzovat všechny provedené operace k danému příkazu a dokážeme zjistit, která z operací je nejnáročnější, na tu se zaměřit a vyřešit dané slabé místo databáze. Proto pokud děláme výkonnostní testy, jedním ze základních nástrojů pro zjišťování průběhu je právě exekuční plán. 20

21 2.4. Indexy Indexy jsou pomocné databázové objekty, které zrychlují přístup k tabulkám. Nejjednodušší vysvětlení je na příkladu rejstříku knihy. Pokud čtenář hledá v knize pojem, podívá se do rejstříku, než aby pročítal řádek po řádku celou knihu a hledal daný pojem. Na úplně stejném principu fungují i indexy. Indexy jsou také seřazeny a neobsahují odkaz na stránku, ale odkaz na rowid. Indexy nám umožňují zrychlovat vyhledávání v tabulkách, ale bohužel na úkor vkládání, úprav a mazání dat, protože nemanipulujeme pouze s daty, ale zároveň i s indexy. Indexy jsou přiřazeny vždy k jednomu nebo více sloupcům a je důležité se zamýšlet, nad kterými sloupci vytvoříme index. Pokud bychom vytvářeli indexy automaticky nad každým sloupcem, vedlo by to ke zpomalení databáze, ne k jejímu zrychlení. Indexy jsou logicky i fyzicky odděleny od dat tabulky, proto je možné je vytvářet nebo mazat aniž bychom změnili data databáze. Pokud ale smažeme index, který databáze používala k přístupu k datům, pak se prodlouží přístupová doba k těmto datům. Společnost Oracle doporučuje vytvářet indexy nad primárními klíči tabulky a nad klíči, které odkazují na jiné tabulky. Obecné doporučení zní, aby indexy byly vytvořeny nad těmi sloupci, které často používáme pro prohledávání dat v tabulce. (4) Je důležité si uvědomit, že i v případě, kdy máme index nad tabulkou vytvořený, nemusí se využít pro přístup k datům. Proto bezhlavé přidávání indexů do tabulky není žádoucí B-Tree index Tento typ indexu je nejčastějším typem a je doporučováno ho používat pro sloupce v tabulce, které obsahují velký počet řádků a mají velkou kardinalitu dat (pojem kardinality bude popsán níže). Ideální případ použití je u tabulky, která obsahuje velký počet řádků, ale na základě dotazu do této tabulky je vybrán relativně malý počet dat. V takovém případě je index efektivně využit. Nad tímto typem sloupců se doporučuje indexy vytvářet. Pro který sloupec tabulky index použít? Jednak pro sloupec, který je často používán pro prohledávání dat a jednak na základě určení selektivnosti. Pojem selektivnosti velmi úzce souvisí s pojmem kardinality. 21

22 Nejprve bude vysvětlen pojem kardinality. Ta určuje, jak různorodá data databáze obsahuje. Typickým příkladem dat s nízkou kardinalitou je určení pohlaví, kde jsou pouhé dva typy hodnot - muž a žena. Na druhou stranu typickým příkladem dat s vysokou kardinalitou je unikátní primární klíč tabulky, který jednoznačně určuje jednotlivé řádky. V takovém případě je kardinalita vysoká a počet řádek udává počet hodnot typů dat. Proto se indexy nad primárními klíči vytváří v databázovém systému Oracle automaticky. Pojem selektivita udává procentuálně, kolik je vráceno dat pro jednu unikátní hodnotu vzhledem k celkovému počtu dat v tabulce. Tedy čím je vyšší kardinalita větší rozrůznění dat, tím je menší selektivita menší počet dat, které lze dostat pro jednu hodnotu. (5) Nejlépe pojem selektivity popíše definice: počet unikátní hodnoty selektivita= celkový počet záznamů Pokud toto pravidlo je použito na výše zmíněný příklad pohlaví a pokud je předpoklad rozdělení mužů a žen 50 na 50, pak je pro muže i ženy selektivita 50 %. Pro takto vysokou selektivitu rozhodně nelze doporučit vytvoření indexu. Druhým příkladem je unikátní primární klíč, zde za předpokladu že tabulka obsahuje 100 řádků, pak selektivita vychází na 1 %. Obecně pokud má být vytvořen b-tree index, pak selektivita daného sloupce by měla být maximálně 10 %. Pro zjištění selektivity daného sloupce tabulky může být použit tento příkaz: SELECT COUNT (DISTINCT first_name) / COUNT (first_name) * 100 selectivita FROM emp; V uvedeném příkladu je selektivita počítána na sloupci first_name tabulky emp. Je patrné, že při generování dat je důležité zachovat pravděpodobnost výskytů jednotlivých hodnot. Proto pokud jsou vygenerována data, kde jsou pouze 3 typy hodnot a navíc každá hodnota má pravděpodobnost výskytu 1/3, žádný hodnověrný výkonnostní test s takovými daty nelze provést. 22

23 Bylo vysvětleno, kdy je či není vhodné b-tree index použít. V následující kapitole bude popsán způsob uložení b-tree indexu v databázi, který je důležitý pro pochopení nutnosti přepočítávání indexů. Jak název napovídá, tento index je založen na principu b-stromu. Tento typ datové struktury se skládá z kořene (root), uzlů (node) a listů (leaf). Viz obrázek 3 níže. Obrázek 3: B - tree index kořen 122 uzly listy 16 Rowid 35 Rowid 65 Rowid 66 Rowid 97 Rowid 122 Rowid 123 Rowid 135 Rowid 136 Rowid 139 Rowid 150 Rowid 151 Rowid 160 Rowid 190 Rowid 650 Rowid Zdroj: Vlastní zpracování Visio 2007 podle zdroje: Jak kořen, tak uzly mohou obsahovat větší počet hodnot. Tyto hodnoty jsou seřazeny, a pokud má kořen (uzel) n hodnot, pak má vazby na n+1 uzlů (listů). (Obrázek b-tree indexu je trochu zjednodušený, b-tree index může obsahovat větší počet vrstev uzlů.) Hodnoty v dětech (podřízených uzlech/listech) mají stejnou nebo nižší hodnotu, pokud jsou vlevo a vyšší hodnotu pokud jsou vpravo oproti svému předchůdci (uzlu/kořenu, ze kterého vazby vycházejí). Na základě těchto pravidel se vytváří datová struktura b-strom. Výpočet hloubky jednotlivých větví (počet zanoření od kořene k listu) je trochu složitější a není předmětem této bakalářské práce. Jen pro úplnost doplním, že pro efektivní vyhledávání v b-stromu je potřeba, aby hloubka stromu jednotlivých větví se vzájemně lišila maximálně o 1. Pokud tento rozdíl hloubky v jednotlivých větvích b-stromu je výrazně větší, pak je potřeba indexy přepočítat. Jednotlivé hodnoty se v b-stromu vyhledávají tak, že se strom postupně prochází od kořene a porovnávají se jednotlivé hodnoty s hodnotou hledanou. V momentě kdy se dojde do 23

24 nejnižší části b-stromu do listů, tak se zde hledaná hodnota buďto nenachází nebo nachází a v listě je odkaz na rowid řádku, kde je hodnota uložena. Teď je možné si uvědomit, proč je neefektivní vytvářet b-tree index nad sloupci s nízkou kardinalitou. Pokud by se nad sloupcem pohlaví vytvořil b-tree index, pak by v tomto b- stromu byl pouze kořen a dva listy, viz obrázek 4. Každý z těchto listů by obsahoval polovinu řádků tabulky, které by vraceli při zvolení dané hodnoty. Ve výsledku by tedy byl zvolen nejprve přístup indexový a následně by byla data postupně procházena. V takovém případě by bylo buď vhodnější nepoužít index žádný, pak by databáze k datům přistupovala přes full table scan nebo by byl použít bitmap index (popsán v následující kapitole). Tento příklad je pouze hypotetický, protože pokud by byl vytvořen index nad těmito daty, optimizer by spočítal neefektivnost indexového přístupu a použil by rovnou full table scan. Obrázek 4: B - strom s nízkou kardinalitou Pohlaví Muž Žena Zdroj: Vlastní zpracování Visio 2007 B-tree indexy můžeme vytvářet různými způsoby. Jedním ze způsobů je kompozitní index. Kompozitní index Tento typ indexu se vztahuje ke dvěma sloupcům. Je vhodný pro případy, kdy často používáme kombinaci dvou sloupců současně pro vyhledávání. Ale pozor, na druhou stranu je mylné se domnívat, že pokud je zvolen kompozitní index, tak že může být použit stejně, jako dva nezávislé indexy nad dvěma sloupci. Navíc při volbě sloupců záleží na tom, v jakém pořadí je zvolíme. (6) Uvedu a popíšu příklad kompozitního indexu: CREATE INDEX composite_index ON emp (surname, first_name); 24

25 V tomto příkladě je vytvořen index, který je nad sloupci surname a first_name a pokud je použit příkaz: SELECT * FROM emp WHERE surname='novak' AND first_name='jan'; je použit index tak, jak předpokládáno. V případě, že by bylo potřeba vyhledávat pouze podle jména, například takto: SELECT * FROM emp WHERE first_name='jaroslav'; index nebude použit! Index nebo spíše jeho část se použije pouze v případě, kdy je v tabulce vyhledáváno pouze podle příjmení. Kompozitní indexy se mohou skládat i z více než dvou hodnot a to tak, aby tyto skupiny sloupců co nejvíce usnadňovaly vyhledávání. Proto se doporučuje používat kompozitní indexy tak, aby sloupce v nich obsažené byly řazeny sestupně podle důležitosti (četnosti použití). Indexovaná funkce Dalším způsobem jak vytvořit b-tree index je indexovaná funkce, která umožňuje vytvořit index nad hodnotou vrácenou z funkce. Příklad: CREATE INDEX function_index ON emp(lower(surname)); V tomto příkladě se vytváří index nad funkcí lower, díky které se zjednoduší vyhledávání příjmení. Lze vynechat kontrolu, zda nebyla příjmení zadána s velkým písmenem. Ukázka dotazu nad tabulkou: SELECT first_name, surname FROM emp WHERE lower(surname) = 'muller'; Obecně indexové funkce zjednodušují používání funkcí v rámci dotazů nad tabulkami. Mohou se tak jednoduše třídit data, dále se nemusí řešit velká a malá písmena v zadaných datech nebo se mohou přidat vlastní funkce, které zjednoduší zpracování dat. Používání indexů má jeden háček, a tím je hledání řádků, které obsahují hodnotu null. Pokud se zadá příkaz, který má vrátit všechny řádky, kde v některém ze sloupců je 25

26 podmínka null, vždy databáze k tabulce přistoupí přes full table scan. Tento háček lze jednoduše řešit pomocí indexových funkcí. Tato funkce nahradí null hodnotu řetězcem 'null', následně jsou pak hledány v tabulce řetězce null. Předpokladem je, že se jedná o proměnnou typu řetězec. U sloupců s jinými datovými typy by bylo řešení analogické. Toto nahrazení můžeme provést pomocí funkce nvl, která vrací předdefinovanou hodnotu, pokud jí nebyla předána žádná jiná hodnota. Ukázka použití pomocí index funkce: CREATE INDEX indx_find ON emp(nvl(degree, 'null')); Díky takto použité indexové funkci je možné za pomocí indexů najít uživatele, kteří nedosáhli žádného titulu (degree). Příklad: SELECT first_name, surname FROM emp WHERE nvl(degree, 'null') = 'null'; I když je vytvořen index nad sloupcem správným způsobem, nemusí být použit pro vrácení dat. Databáze přístupy k datům vyhodnocuje a vrátí vždy data předpokládaným nejefektivnější způsobem. Výběr nejefektivnějšího přístupu k datům obstarává optimizer (popsán v samostatné kapitole). Proč databáze nevolí přístup přes b-tree indexy, i když se to může zdát výhodné? Důvody: 1. Malé množství řádků je rychlejší přistupovat k malému množství dat přes full table scan než přes index scan 2. Velké množství řádků, ale načítání velkého množství dat i v tomto případě je výhodnější použít full table scan, protože FTS načítá data po blocích na rozdíl od IRS, který načítá data sekvenčně Ze zmíněných důvodů je zřejmé, že je důležité nejen volit indexy pro správné sloupce, popřípadě kombinace sloupců, ale i správně psát dotazovací příkazy pro databázi. Dále je velmi důležité nepodceňovat správu a údržbu databáze, díky které ji pak můžeme snadněji optimalizovat nebo odstraňovat vzniklé problémy Bitmap index Dalším typem indexu je bitmap index. Tento typ indexu je stejně jako b-tree index uložen v b-stromu. Tento index je vhodný pro tyto typy dat: 26

27 Data s nízkou kardinalitou. Data, kde převládají read-only operace nebo úpravy dat jsou jen výjimečné. Data, kde často vyhledáváme pomocí OR podmínek. Jak bylo uvedeno, bitmapové indexy jsou uloženy také v b-stromu. To zaručuje rychlé vyhledávání jednotlivých hodnot. V čem je ale tento index od b-tree indexu odlišný, je způsob uložení hodnot v listech b-stromu. V listu je uložena bitmapa hodnot místo seznamu rowid. Tato bitmapa se vztahuje k zadanému rozsahu řádků, které jsou uloženy v paměti. V bitmapě má nastavený bit na 1 ten řádek, který zadanou hodnotu obsahuje a 0 ten řádek, který zadanou hodnotu neobsahuje. Princip bitmap indexu viz Obrázek 5. Obrázek 5: Bitmap index Zdroj: Vysvětlení principu tohoto indexu bude nejjednodušší na příkladu. Snažíme se najít všechny muže v naší firmě. Průchod b-stromem bude rychlý, jsou v něm pouze dva listy. V listu s hodnotou muže bude bitmapa mapující hodnoty v paměti a bude obsahovat jedničky tam, kde se hodnota muž nachází a nuly, kde se nenachází. Bitmapa nám vrátí sadu řádek, které obsahují hledanou hodnotu. Jak tento index vypadá, je možno se podívat 27

28 na obrázku níže, kde je podrobně rozkreslen. Díky tomuto nízko úrovňovému přístupu k datům (přístup přes bitmapu) je načítání dat rychlejší. Způsob uložení a pracování s bitmapou je speciálně navržen společností Oracle a patentově chráněn. (4) Jediným háčkem bitmapových indexů je jejich případná úprava. Sice není tak velký problém data měnit z jedné hodnoty na jinou. To znamená pouhou změnu bitů z nuly na jedničku. Ale pokud bude potřeba přidat novou hodnotu do sloupce, pak se musí přepočítat úplně celá indexová struktura. To není jednoduchá operace. Z tohoto vyplývá nemožnost použití těchto indexů v OLTP databázích, které jsou zaměřeny na snadnou modifikaci dat Indexově organizované tabulky (Index organized tables) Indexově organizovaná tabulka se vzdáleně týká indexů a jedná se o speciální strukturu dat, kam se ukládá tabulka. Ale na základě principu indexů byla vyvinuta. Tento typ tabulky vznikl na základě těchto myšlenek: Je neefektivní vytvářet index nad každým sloupcem tabulky Zároveň byl využit koncept FFIS (Fast full index scan), kdy přístup přes indexy k datům je velmi rychlý. Tak vznikl koncept index organized table, kdy řádky tabulky nejsou uspořádány podle rowid, ale jsou vloženy do b-stromu, kde jsou uspořádány podle primárních klíčů. Zároveň v každém listě jsou uloženy i neklíčové hodnoty řádku, proto přes primární klíč přistupujeme rovnou ke všem hodnotám. To zaručuje velmi rychlý a efektivní přístup. Bohužel tento koncept má i nějaké nedostatky. Například tento typ tabulek nelze ukládat do clusterů. (4) Pokud by se měřila rychlost přístupů, mohlo by být na první pohled zarážející, že tabulky s indexy oproti index organized table nejsou zas o tolik pomalejší. Pak by jejich jedinou praktickou výhodou byla úspora místa. Protože indexově organizovaným tabulkám stačí ukládat jedinou strukturu dat oproti ukládání samotných dat a navíc jejich indexů. Ovšem index organized table lze dále optimalizovat, a to následujícími způsoby: 28

29 Dodefinováním overflow area (oblast přetečení), díky které je v listě uloženo jen omezené množství dat a data, která se do listu nevejdou, jsou uložena na jiném místě. Přidáním sekundárních indexů, které nám dále zrychlují přístup k datům. Využití tohoto typu tabulek je doporučováno pouze pro kratší řádky, kde v jednotlivých řádcích není uloženo větší množství dat. Částečně lze toto optimalizovat pomocí overflow area, ale i přesto je lepší používat tyto tabulky spíše pro ukládání krátkých řádků. Dalším omezením je nemožnost ukládat datové proměnné typu long, místo něj musíte použít datový typ lob. (7) 29

30 2.5. Optimizer Aby byla jasná úloha optimizeru v rámci zpracování sql příkazu, bude nejprve popsán obecný popis komponent, které s optimizerem souvisí. Nejprve uživatel zadá sql dotaz, ten je zkontrolován parserem z hlediska korektnosti syntaxe, zda dotaz obsahuje všechny povinné položky a zda mají korektní formu. Pak přichází na řadu optimizer, který vybere způsob optimalizace vykonání dotazu na základě toho, zda existují statistiky nebo ne. Pokud statistiky vygenerovány v databázi jsou, použije se výpočet optimální cesty pomocí CBO (Cost-Based Optimizer) přes statistiky. Pokud ne, CBO použije dynamic sampling pro dopočítání chybějících nebo neúplných statistik. V případě požadavku na zpětnou kompatibilitu může být zvolen i druhý typ optimizeru RBO (Rule Based Optimizer). (8) Obrázek 6: Diagram zpracování sql dotazu Zdroj: 30

31 Optimizer vrací návrh nejefektivnějšího způsobu jak načíst data z databáze. Následující komponenta Row Source Generator na základě tohoto vygenerovaného postupu vrací exekuční plán. Exekuční plán popisuje podrobně načítání a zpracování dat. Posledním logickým krokem je vykonání příkazu podle exekučního plánu pomocí SQL Execution Engine ( stroje pro vykonání sql ). Postupné kroky tohoto procesu je možné si prohlédnout na obrázku 6 diagramu zpracování sql dotazu. Databáze může volit různé přístupy k tabulkám. Může být zvolen přístup full table scan nebo některý z indexových přístupů. Optimizer volí na základě znalosti tabulek z těchto přístupů ten nejefektivnější. V jeho konfiguraci můžeme zvolit jeden ze dvou modů cílů optimalizace. A to buď nejlepší propustnost (the best throughput) nebo nejlepší dobu odezvy (the best response time). Na příkladech bude vysvětlen rozdíl těchto dvou modů. (9) Pokud zvolíme nejlepší propustnost, optimizer volí takové přístupy, aby všechna data dostal uživatel co nejdříve. Tento model je volen tehdy, kdy uživatel požaduje ihned načíst všechna data z databáze v nejkratším možném intervalu. Typickým a často voleným přístupem v tomto modu je full table scan, který dokáže data načítat po blocích, a tím načíst velmi rychle velké množství dat. Druhý mode (nejlepší doba odezvy) je volen tehdy, kdy uživatel systému chce mít k dispozici co nejdříve první řádek nebo prvních pár řádků. Typickým přístupem, který je volen v tomto modu, je index scan. Tento přístup je schopen velmi rychle vrátit první požadovaný řádek. Z řádků napsaných výše by mohlo vyplývat, že přístup full table scan je výhradně volen v modu optimizeru nejlepší propustnost a index scan v modu nejlepší doba odezvy. Takto přístupy voleny nejsou. Optimizer má nastaveny určité preference, díky kterým volí jednotlivé přístupy, ale rozhodně nejsou v jednotlivých modech voleny pouze některé přístupy, to by databázový přístup k datům nebyl dostatečně flexibilní a optimalizovatelný RBO (Rule based optimizer) a CBO (Cost based optimizer) Jak bylo zmíněno výše, Rule based optimizer je volen z důvodu požadavku zpětné kompatibility. Naproti tomu Cost based optimizer je novější a technologicky vyspělejší. I společnost Oracle doporučuje používat CBO. RBO by měl být použit pouze ve 31

32 výjimečných případech a můžeme očekávat, že v budoucích verzích bude z databáze odstraněn. Navíc Cost based optimizer podporuje rozdělené tabulky, materializované pohledy a další. Krátce k Rule based optimizeru: Tento typ optimizeru je založen na pravidlech. Jednotlivé přístupy jsou vybírány podle pořadí, a zda je možné je nad tabulkou vykonat. Tedy pokud je možné zvolit více přístupů, je zvolen ten, který je v pořadí dříve. Část seřazeného seznamu přístupů, tak jak jej využívá RBO: Tabulka 2: Pořadí přístupů, které jsou voleny v RBO Pořadí Přístup 1. Jednotlivé řádky přes Rowid Jednotlivé řádky přes unikátní hodnotu nebo primární klíč Přes kompozitní indexy 9. Indexový přístup Přes full table scan Z tabulky je tedy patrné, že pokud bude možné zvolit přístup přes index, bude vždy zvolen, a to i v případě, kdy by byl přístup přes full table scan efektivnější. Proto je doporučováno tento typ optimalizátoru nepoužívat. (10) 32

33 Cost based optimizer je založen na ohodnocování jednotlivých přístupů do databáze na základě statistik tabulek, sloupců, indexů a dalších (statistiky popsány v samostatné kapitole). Na základě hodnot těchto statistik CBO navrhne exekuční plány a zároveň je ohodnotí. Databáze pak z plánů vybere ten nejvýhodnější, který je proveden pro zpracování zadaného příkazu. Součástí hodnocení statistik není jen složitost datové struktury databáze, ale i možnosti jednotlivých zdrojů hardwaru serveru, například propustnost I/O nebo výkonnost CPU. (8) Samotný CBO se skládá z několika částí, které si vzájemně dělí jednotlivé činnosti zpracování hodnocení přístupů. Popis těchto částí je však nad rozsah této práce. 33

34 2.6. Statistiky Statistiky jsou pomocná data, která podrobně popisují strukturu databáze. Popisují tabulky, sloupce, indexy atd. Na základě těchto dat, je pak optimizer (konkrétně CBO) schopen najít nejefektivnější exekuční plán. Statistiky popisují různé objekty v databázi a podle toho se dělí na: statistiky tabulek (table statistics), statistiky sloupců (column statistics), statistiky indexů (index statistics), statistiky výpočetních možností serveru (System statistics). Ke spravování statistik se používá balíček DBMS_STATS. Tento balíček neslouží jen ke sběru statistik, ale také k importu, exportu popřípadě i jejich smazání nebo zamknutí, pro nemožnost jejich úpravy. Jednoduchý export nebo import statistik je umožněn díky tomu, že statistiky jsou uloženy v databázových slovnících (11). Je zřejmé, že data se v databázi často mění a pokud by jednou vygenerované statistiky měly být používány delší dobu, ztratila by se jejich schopnost optimalizovatelnosti. Proto je důležitá jejich pravidelná správa. O tu nejzákladnější se stará automatic optimizer statistics collection. Tato funkcionalita se aktivuje následujícím příkazem: EXECUTE DBMS_AUTO_TASK_ADMIN.ENABLE( client_name => 'auto optimizer stats collection', operation => NULL, window_name => NULL); Tato komponenta monitoruje počet operací INSERT, UPDATE, DELETE a pokud je vyhodnoceno, že statistiky již neodpovídají datům, jsou přepočítány. Většinou se statistiky přepočítávají, pokud se změní víc jak 10 % dat v tabulce. Tato automatická detekce je postačující, pokud není databáze z velké části neustále modifikována. Pokud ano, je pak důležité statistiky aktualizovat navíc manuálně. Manuální sběr statistik je nutný v případě, kdy třeba změníme podstatnou část tabulky pomocí bulk operací. (Pojem bulk operace je vysvětlen v kapitole 3.1. Úvod do PL/SQL.) Proto je nutné 34

35 při těchto operacích nezapomínat na statistiky. Vynucení přepočítání statistik způsobí následující příkaz: EXECUTE DBMS_STATS.GATHER_TABLE_STATS(ownname=>tableowner, tabname=>'tablename', method_opt=>'for ALL INDEXED COLUMNS'); Na základě tohoto příkazu jsou přepočítány statistiky nad tabulkou tablename vlastněnou uživatelem tableowner. Statistická data jsou posbírána ze všech jejích sloupců. Tento příkaz patří do skupiny statistiky tabulek. V příkladu je volána metoda GATHER_TABLE_STATS. Pokud by byla použita jiná procedura balíčku DBMS_STATS, například procedura GATHER_SYSTEM_STATS, pak by došlo k vygenerování systémových statistik. U této procedury by samozřejmě byly nastaveny jiné parametry (11). V ukázkových příkladech byl vždy použit balíček dbms_stats, který ale není jediný, který můžeme pro práci se statistikami volat. Ale jeho používání je doporučováno společností Oracle. Kromě tohoto balíčku lze například použít příkaz ANALYZE, který je v databázovém systému udržován již jen z důvodů zpětné kompatibility. Na konci této kapitoly jsou zmíněny funkcionality, které se statistikami souvisí už jen okrajově, ale jsou důležité pro pochopení souvislostí. Jedná se o dynamic sampling a histogramy. Dynamic sampling Tato funkcionalita byla zavedena od verze 10g a vyřešila velký problém optimalizace pro tabulky, kde nejsou vygenerované statistiky. Do této verze v takovém případě byl použit RBO, který nemusel vrátit optimální exekuční plán. Dynamic sampling umožňuje dopočítat chybějící data statistik a poskytnout tak v každém případě co možná nejvíce optimální exekuční plán. CBO se během každé kompilace dotazu rozhoduje, do jakého stupně použije dynamic sampling. Toto rozhodování je založeno na mnoho faktorech. Ale hlavním důvodem proč optimizer volí tuto metodu, jsou zastaralé nebo chybějící statistiky. (8) 35

36 Histogramy Histogramy jsou speciálním druhem statistik a jsou zde uvedeny pro úplné doplnění výčtu. Histogramy jsou důležité pro případy, kdy potřebujeme zjistit přesnější rozmístění dat v databázi. Tento typ statistik nám dává přehled, jak jsou data asymetricky rozložena a na základě těchto dat se optimizer rozhoduje, který přístup zvolí. 36

37 2.7. Hinty Hinty nám umožňují ovlivňovat běh exekučního plánu. Je možné tak databázi nadefinovat, který přístup má zvolit. Vychází z předpokladu, že uživatel má více informací o databázi než optimizer, proto může zvolit efektivnější přístup. Například máte podrobnější informace o selektivnosti indexů pro určitý SQL příkaz. Hinty mohou být vyvolány jen v případě, kdy používáte CBO a pokud je zadáte v příkazu ve špatném formátu, pak budou ignorovány a neprovedou se. Pozor, optimizer neupozorňuje na to, že nebyly použity. Hinty se zadávají do SQL příkazů za příkazy UPDATE, SELECT nebo DELETE. Přes hinty lze ovlivnit: Přístup k tabulkám. Jakým způsobem se mají tabulky spojit. Určit pořadí spojení tabulek. Nastavení optimalizačních parametrů. Příklad použití hintu: SELECT /*+ FULL(users) */ firstname, surname FROM users WHERE firstname = 'Hana'; O tabulce users víme, že obsahuje velký počet uživatelů s křestním jménem Hana, proto pomocí hintu optimizer nastavíme tak, aby k této tabulce přistoupil přes FTS, který v tomto konkrétním případě bude nejrychlejší. (12) 37

38 3. PRAKTICKÁ ČÁST - GENEROVÁNÍ DAT Praktická část bakalářské práce se zaměřuje na samotný popis Nástroje na tvorbu testovacích dat pro zátěžové testování DB. V této části bude popsán jazyk PL/SQL, ve kterém je nástroj napsán. Dále zde je zmíněno, odkud byla získána zdrojová data a jak byla upravena. A v neposlední řadě bude rozebrán princip, jakým nástroj generuje náhodná data pro zátěžové testy. Vysvětlení principů je doplněno o ukázky zdrojového kódu nástroje Úvod do PL/SQL V kapitole Relační databáze byl zmíněn jazyk SQL a skupiny příkazů, které obsahuje. Díky tomuto jazyku je možné navrhnout i spravovat databáze. Pokročilejší programování nebo práce s větším množstvím dat ale není možná. Pro tyto případy společnost Oracle vyvinula procedurální nadstavbu jazyka SQL, PL/SQL. Jiné databázové technologie mají také své procedurální jazyky, například Microsoft SQL server má Transact SQL neboli T-SQL. (13) Tento krátký úvod se zaměřuje na základy programovacího jazyka PL/SQL, které jsou nutné pro následné pochopení principu generátoru dat pro zátěžové testy Balíčky, procedury a funkce Program v PL/SQL je složen z bloků, které mohou být vnořeny jeden do druhého. Každý blok spouští jednu logickou akci v programu. Blok se skládá z následujících částí: a) DECLARE v této části bloku jsou definovány jednotlivé proměnné a jejich datové typy b) BEGIN výkonná sekce v této části se vykonávají funkce, procedury a SQL příkazy (tato jediná část je v bloku povinná) c) EXCEPTION v této části se zpracovávají výjimky, ke kterým došlo ve výkonné části Ve výkonné části je povolena skupina příkazů DML, to znamená SELECT, INSERT, 38

39 UPDATE, DELETE a další příkazy pro správu transakcí. Příkazy pro definování struktury databáze (příkazy DDL) například CREATE, ALTER nejsou ve výkonném bloku povoleny. (14) Tímto způsobem jsou definovány tak zvané anonymní bloky, které jsou zpravidla vykonány pouze jedenkrát. Dalším typem bloků jsou pojmenované bloky. Pojmenované bloky je možné opakovaně používat a tyto bloky jsou procedurami a funkcemi, které jsou známy ze strukturovaného programování. Jen pro zpřesnění: rozdíl mezi funkcí a procedurou je ten, že funkce na rozdíl od procedury vrací výsledek. V dalším textu jsou zmiňovány jen funkce, ale jsou tím míněny funkce i procedury. (15) Příklad jedné funkce z praktické části práce: CREATE OR REPLACE FUNCTION my_divide (n1 IN number, n2 IN number) RETURN NUMBER IS BEGIN n3 NUMBER; n4 NUMBER; n4 := MOD(n1,n2); n3 := (n1-n4)/n2; IF n4 > 0 THEN n3 := n3+1; END IF; RETURN n3; EXCEPTION END; WHEN ZERO_DIVIDE THEN RETURN n1; V praktické části práce byla potřeba funkce, která by dělila dvě čísla tak, aby vrácený výsledek byl vždy zaokrouhlen nahoru. Standardní funkce pro dělení výsledek automaticky zaokrouhluje nahoru nebo dolů, podle hodnoty za desetinnou čárkou. Funkce my_divide převezme dva parametry n1 a n2. Nejprve zjistí celočíselný zbytek po dělení n1, n2. Tento zbytek je poté odečten od n1 a upravená hodnota n1 je dělena hodnotou n2, pokud byl celočíselný zbytek větší než jedna, je k výsledku přičtená jednička. 39

40 Tento příklad obsahuje všechny možné části, které byly pro blok definovány, a je na něm vidět způsob použití jednotlivých bloků. Další výhodou definovaných funkcí je možnost jejich použití přímo v SQL příkazech. Například: SELECT CONCAT (first_name, surname) whole name FROM employees; Tento příkaz vrátí místo dvou sloupců jména a příjmení sloupec jeden, který obsahuje celé jméno. Jiným způsobem je použití funkcí v rámci indexů. Příklady, jak použít funkce v indexech, byly popsány v kapitole Indexovaná funkce. Bylo popsáno, jak vypadají anonymní a pojmenované bloky používané v programovacím jazyce PL/SQL. Pokud by byly používány buď jen funkce, nebo dokonce pouze anonymní bloky, bylo by náročné se v kódu vyznat. Proto jsou v tomto jazyce zavedeny balíčky, které obsahují logicky související funkce a procedury. Balíčky se skládají z hlavičky a těla. V hlavičce se deklarují veřejné funkce a v těle jsou pak definovány funkce soukromé. Soukromé funkce jsou deklarované i definované v jeho těle a nejsou přístupné z vnějšku. Veřejné funkce pak mohou být volány uživatelem nebo funkcemi i z jiného balíčku. Příklad jednoduché definice hlavičky a těla: CREATE PACKAGE my_package IS FUNCTION sum (number1 NUMBER, number2 NUMBER, number3 NUMBER); END my_package; CREATE PACKAGE BODY my_package IS FUNCTION sum (number1 NUMBER, number2 NUMBER, number3 NUMBER) IS BEGIN RETURN number1 + number2 + number3; END; END my_package; 40

41 Uvedený balíček obsahuje jedinou veřejnou funkci, která slouží pro sečtení tří čísel. Tento balíček neobsahuje žádnou soukromou funkci. Tento příklad je pouze názorný, a pokud by měla být v balíčku pouze jedna veřejná funkce, nemělo by význam balíček zakládat. Generátor náhodných dat, který je předmětem této bakalářské práce, je napsán pomocí funkcí, které jsou vloženy do balíčků. Jejich přehled: 1. fetch_source_data_package balíček sloužící k načtení zdrojových dat, na základě kterých se generují náhodná data, 2. log_package balíček sloužící k logování událostí vzniklých během procesu generování dat, 3. random_data_package balíček ke generování specifických dat, která mají specifické omezující parametry (například generování rodného čísla), 4. random_table_package balíček, který slouží k vytvoření tabulky a následnému jejímu naplnění generovanými daty, tento balíček je stěžejním a jednotlivé funkce a procedury z ostatních balíčků jsou volány odsud. Pro zrychlení operací s velkým množstvím dat nabízí PL/SQL bulk operace. Tyto operace snižují počet přepínání mezi enginem pro SQL a enginem pro PL/SQL. Jednotlivé enginy slouží k vykonávání buď SQL nebo PL/SQL kódu. Princip přepínání enginů viz obrázek 7. Obrázek 7: PL/SQL a SQL engine Zdroj: 41

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

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

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

Ú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

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

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

Databáze Bc. Veronika Tomsová

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

Více

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

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

Více

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

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

Více

Databá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

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

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

Více

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

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

Více

DATABÁZE MS ACCESS 2010

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

Více

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

Použití databází na Webu

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

Více

Databázové systé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

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

Příprava dat v softwaru Statistica

Příprava dat v softwaru Statistica Příprava dat v softwaru Statistica Software Statistica obsahuje pokročilé nástroje pro přípravu dat a tvorbu nových proměnných. Tyto funkcionality přinášejí značnou úsporu času při přípravě datového souboru,

Více

Semestrální práce z DAS2 a WWW

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

Více

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

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

Více

Popis ovládání. Po přihlášení do aplikace se objeví navigátor. Navigátor je stromově seřazen a slouží pro přístup ke všem oknům celé aplikace.

Popis ovládání. Po přihlášení do aplikace se objeví navigátor. Navigátor je stromově seřazen a slouží pro přístup ke všem oknům celé aplikace. Popis ovládání 1. Úvod Tento popis má za úkol seznámit uživatele se základními principy ovládání aplikace. Ovládání je možné pomocí myši, ale všechny činnosti jsou dosažitelné také pomocí klávesnice. 2.

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

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

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

Více

Využití OOP v praxi -- Knihovna PHP -- Interval.cz

Využití OOP v praxi -- Knihovna PHP -- Interval.cz Page 1 of 6 Knihovna PHP Využití OOP v praxi Po dlouhé teorii přichází na řadu praxe. V následujícím textu si vysvětlíme možnosti přístupu k databázi pomocí různých vzorů objektově orientovaného programování

Více

Roman Dušek http://dusek.vysokeskoly.cz

Roman Dušek http://dusek.vysokeskoly.cz Optimalizace Roman Dušek http://dusek.vysokeskoly.cz SQL je velmi flexibilní jazyk. Dvěma či více různými dotazy je možno obdržet stejná data. Rychlost různých dotazů ovšem nemusí být stejná i přesto,

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

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

RELAČNÍ DATABÁZE ACCESS

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

Více

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

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

Více

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

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

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

POPIS TECHNICKÉHO ŘEŠENÍ INFORMAČNÍHO SYSTÉMU PRO SBĚR DAT V PROJEKTU SLEDOVÁNÍ DEKUBITŮ JAKO INDIKÁTORU KVALITY OŠETŘOVATELSKÉ PÉČE NA NÁRODNÍ ÚROVNI

POPIS TECHNICKÉHO ŘEŠENÍ INFORMAČNÍHO SYSTÉMU PRO SBĚR DAT V PROJEKTU SLEDOVÁNÍ DEKUBITŮ JAKO INDIKÁTORU KVALITY OŠETŘOVATELSKÉ PÉČE NA NÁRODNÍ ÚROVNI POPIS TECHNICKÉHO ŘEŠENÍ INFORMAČNÍHO SYSTÉMU PRO SBĚR DAT V PROJEKTU SLEDOVÁNÍ DEKUBITŮ JAKO INDIKÁTORU KVALITY OŠETŘOVATELSKÉ PÉČE NA NÁRODNÍ ÚROVNI Vypracoval Bc. Petr Suchý Dne: 20.1.2009 Obsah Úvod...

Více

ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ

ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ RELATIONAL AND OBJECT DATABASES DESIGN DIFFERENCES AND IT S IMPLICATIONS TO MODEL TRANSFORMATION Vít Holub

Více

Vstupní požadavky, doporučení a metodické pokyny

Vstupní požadavky, doporučení a metodické pokyny Název modulu: Základy PHP Označení: C9 Stručná charakteristika modulu Modul je orientován na tvorbu dynamických stánek aktualizovaných podle kontextu volání. Jazyk PHP umožňuje velmi jednoduchým způsobem

Více

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

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

Více

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

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

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

Více

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

Přehledy pro Tabulky Hlavním smyslem této nové agendy je jednoduché řazení, filtrování a seskupování dle libovolných sloupců.

Přehledy pro Tabulky Hlavním smyslem této nové agendy je jednoduché řazení, filtrování a seskupování dle libovolných sloupců. Přehledy pro Tabulky V programu CONTACT Professional 5 naleznete u firem, osob a obchodních případů záložku Tabulka. Tuto záložku lze rozmnožit, přejmenovat a sloupce je možné definovat dle vlastních požadavků

Více

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

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

Více

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

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

Manuál pro mobilní aplikaci Patron-Pro. verze pro operační systém Symbian

Manuál pro mobilní aplikaci Patron-Pro. verze pro operační systém Symbian Manuál pro mobilní aplikaci Patron-Pro verze pro operační systém Symbian 1 1. Popis Aplikace je určena pro mobilní telefony NOKIA s operačním Symbian a vybavené technologií NFC. Slouží pro správu identifikačních

Více

Databáze pro evidenci výrobků

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

Více

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu VÝUKOVÝ MATERIÁL Identifikační údaje školy Vyšší odborná škola a Střední škola, Varnsdorf, příspěvková organizace Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632

Více

Popisné systémy a databáze

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

Více

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

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

Více

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

PHP a Large Objecty v PostgreSQL

PHP a Large Objecty v PostgreSQL PHP a Large Objecty v PostgreSQL Pavel Janík ml. http://www.janik.cz PHP a Large Objecty v PostgreSQL 1 Jazyk PHP je velmi mocným jazykem pro vývoj webových aplikací. Má podporu snad všech velkých i menších

Více

Bohemius, k.s. www.bohemius.cz

Bohemius, k.s. www.bohemius.cz Bohemius, k.s. www.bohemius.cz Modul je součástí administrativní i manažerské kalkulačky Formulář Malé DPH: Dále následuje : FORMULÁŘ - VLASTNÍ KALKULAČKA o produktu KDO BUDE S FORMULÁŘEM PŘEDEVŠÍM PRACOVAT

Více

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

Marketingová komunikace. 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3bph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3bph) 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Zdroje Studijní materiály Heleny Palovské

Více

Stručný obsah. K2118.indd 3 19.6.2013 9:15:27

Stručný obsah. K2118.indd 3 19.6.2013 9:15:27 Stručný obsah 1. Stručný obsah 3 2. Úvod 11 3. Seznamy a databáze v Excelu 13 4. Excel a externí data 45 5. Vytvoření kontingenční tabulky 65 6. Využití kontingenčních tabulek 81 7. Kontingenční grafy

Více

Materializované pohledy

Materializované pohledy Materializované pohledy Pavel Baroš, 2010 Obsah Materializované pohledy Co přináší? Řešení ostatních DBS syntaxe a semantika pro: Oracle, MS SQL, DB2 ostatní Možné řešení pro PostgreSQL PostgreSQL 2 Materializované

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

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

Typy souborů ve STATISTICA. Tento článek poslouží jako přehled hlavních typů souborů v programu

Typy souborů ve STATISTICA. Tento článek poslouží jako přehled hlavních typů souborů v programu StatSoft Typy souborů ve STATISTICA Tento článek poslouží jako přehled hlavních typů souborů v programu STATISTICA, ukáže Vám jejich možnosti a tím Vám dovolí využívat program efektivněji. Jistě jste již

Více

Tvorba internetových aplikací s využitím framework jquery

Tvorba internetových aplikací s využitím framework jquery Tvorba internetových aplikací s využitím framework jquery Autor Michal Oktábec Vedoucí práce PaedDr. Petr Pexa Školní rok: 2009-10 Abstrakt Tato práce se zabývá využití frameworku jquery pro vytváření

Více

E-learningovýsystém Moodle

E-learningovýsystém Moodle E-learningovýsystém Moodle Jan Povolný Název projektu: Věda pro život, život pro vědu Registrační číslo: CZ.1.07/2.3.00/45.0029 Co je to Moodle? - systém pro tvorbu a správu elektronických výukových kurzů

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

Úvod. Program ZK EANPRINT. Základní vlastnosti programu. Co program vyžaduje. Určení programu. Jak program spustit. Uživatelská dokumentace programu

Úvod. Program ZK EANPRINT. Základní vlastnosti programu. Co program vyžaduje. Určení programu. Jak program spustit. Uživatelská dokumentace programu sq Program ZK EANPRINT verze 1.20 Uživatelská dokumentace programu Úvod Základní vlastnosti programu Jednoduchost ovládání - umožňuje obsluhu i málo zkušeným uživatelům bez nutnosti většího zaškolování.

Více

SKLAD ODPADŮ modul MOBILNÍ ZAŘÍZENÍ Vedení evidence MOBILNÍCH ZAŘÍZENÍ K VYUŽÍVÁNÍ NEBO ODSTRAŇOVÁNÍ ODPADŮ

SKLAD ODPADŮ modul MOBILNÍ ZAŘÍZENÍ Vedení evidence MOBILNÍCH ZAŘÍZENÍ K VYUŽÍVÁNÍ NEBO ODSTRAŇOVÁNÍ ODPADŮ SKLAD ODPADŮ modul MOBILNÍ ZAŘÍZENÍ Vedení evidence MOBILNÍCH ZAŘÍZENÍ K VYUŽÍVÁNÍ NEBO ODSTRAŇOVÁNÍ ODPADŮ Obsah dokumentu Tento dokument popisuje a vysvětluje specifické činnosti vedení evidence v programu

Více

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

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

Více

Program a životní cyklus programu

Program a životní cyklus programu Program a životní cyklus programu Program algoritmus zapsaný formálně, srozumitelně pro počítač program se skládá z elementárních kroků Elementární kroky mohou být: instrukce operačního kódu počítače příkazy

Více

Individuální projekt z předmětu webových stránek 2012/2013 - Anketa

Individuální projekt z předmětu webových stránek 2012/2013 - Anketa Individuální projekt z předmětu webových stránek 2012/2013 - Anketa Daniel Beznoskov, 2 IT A Skupina 1 Úvod Prohlášení o autorství Prohlašuji, že jsem individuální projekt z předmětu webových stránek na

Více

Čteme EXPLAIN. CSPUG, Praha. Tomáš Vondra (tv@fuzzy.cz) 21.6.2011. Czech and Slovak PostgreSQL Users Group

Čteme EXPLAIN. CSPUG, Praha. Tomáš Vondra (tv@fuzzy.cz) 21.6.2011. Czech and Slovak PostgreSQL Users Group Čteme EXPLAIN CSPUG, Praha Tomáš Vondra (tv@fuzzy.cz) Czech and Slovak PostgreSQL Users Group 21.6.2011 Agenda K čemu slouží EXPLAIN a EXPLAIN ANALYZE? Jak funguje plánování, jak se vybírá optimální plán?

Více

OPTIMALIZÁTOR SQL DOTAZŮ - ÚVOD DO PROBLEMATIKY

OPTIMALIZÁTOR SQL DOTAZŮ - ÚVOD DO PROBLEMATIKY OPTIMALIZÁTOR SQL DOTAZŮ - ÚVOD DO PROBLEMATIKY Dušan Kajzar, Magdaléna Chmelařová Slezská univerzita v Opavě, Filozoficko - přírodovědecká fakulta, Bezručovo nám. 13, 746 01 Opava Abstract The article

Více

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

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

Více

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

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

Více

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

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

Více

POSTUP PRO VYTVOŘENÍ STRUKTUR PRO UKLÁDÁNÍ RDF DAT V ORACLE

POSTUP PRO VYTVOŘENÍ STRUKTUR PRO UKLÁDÁNÍ RDF DAT V ORACLE POSTUP PRO VYTVOŘENÍ STRUKTUR PRO UKLÁDÁNÍ RDF DAT V ORACLE Upozornění: Pro práci s RDF Oracle daty je třeba mít nainstalován Oracle Spatial Resource Description Framework (RDF). 1. Vytvoření tabulkového

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 23. Otázka : Datový model XML, dotazovací jazyky nad XML daty Obsah : 1 Úvod o XML 2 Vztah XML a databáze 2.1 Databázové systémy s podporou XML 2.2

Více

Úvod do email systému

Úvod do email systému Úvod do email systému Základní informace Toto emailové prostředí je rozloženo do tří hlavních částí - rámců. Levý rámec zobrazuje aktuálně přihlášené složky. V pravé části strany se realizuje veškerá činnost

Více

Monitoring SQL Server, Resource Governor, Tracing SQL Server

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

Více

Experimentální systém pro WEB IR

Experimentální systém pro WEB IR Experimentální systém pro WEB IR Jiří Vraný Školitel: Doc. RNDr. Pavel Satrapa PhD. Problematika disertační práce velmi stručný úvod WEB IR information retrieval from WWW, vyhledávání na webu Vzhledem

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_05 Škola Střední průmyslová škola Zlín Název projektu, reg. č. Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávací oblast Vzdělávání v informačních a komunikačních

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

Návrh a prototypová implementace databáze pro

Návrh a prototypová implementace databáze pro Návrh a prototypová implementace databáze pro snadnější práci se strukturami nukleových kyselin Bc. Ondřej Čečák Fakulta elektrotechnická České vysoké učení technické v Praze 10. června 2011 10. června

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

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

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

Více

BAKALÁŘSKÁ PRÁCE. Optimalizace SQL dotazů v databázi Oracle. SQL query optimization in Oracle database. Bohdan Blaha

BAKALÁŘSKÁ PRÁCE. Optimalizace SQL dotazů v databázi Oracle. SQL query optimization in Oracle database. Bohdan Blaha BAKALÁŘSKÁ PRÁCE Optimalizace SQL dotazů v databázi Oracle SQL query optimization in Oracle database Bohdan Blaha Unicorn College 2010 Unicorn College, V Kapslovně 2767/2, Praha 3, 130 00 Název práce v

Více

MySQLi (objektově) Příklad vytvoření instance třídy včetně parametrů pro připojení: $mysqli = new mysqli('localhost', 'login', 'heslo', 'databaze');

MySQLi (objektově) Příklad vytvoření instance třídy včetně parametrů pro připojení: $mysqli = new mysqli('localhost', 'login', 'heslo', 'databaze'); MySQLi (objektově) Rozšíření PHP MySQL - základní rozšíření umožňující práci s MySQL. Doporučuje se ho používat pouze do verze MySQL 4.1.3. I když je funkční i u novějších verzí, neumožňuje využití nových

Více

Aplikace vytěžování dat

Aplikace vytěžování dat Aplikace vytěžování dat Funkcionalita aplikace Tato sekce popisuje stavájící funkcionalitu aplikace. Stav projektu Aplikace je v současnosti ve fázi prototypu, který lze v relativně krátkém čase 2 měsíců

Více

Administrace webu Postup při práci

Administrace webu Postup při práci Administrace webu Postup při práci Obsah Úvod... 2 Hlavní menu... 3 a. Newslettery... 3 b. Administrátoři... 3 c. Editor stránek... 4 d. Kategorie... 4 e. Novinky... 5 f. Produkty... 5 g. Odhlásit se...

Více

Bibliografických manažerů je celá řada. Tento materiál popisuje práci s nástrojem zvaným EndNote Basic.

Bibliografických manažerů je celá řada. Tento materiál popisuje práci s nástrojem zvaným EndNote Basic. ENDNOTE BASIC Bibliografické, nazývané také citační nebo referenční, manažery jsou užitečné nástroje sloužící k vytváření osobních bibliografií, a to především pomocí jednoduchého stažení vybraných záznamů

Více

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

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

Více

Novinky verze 2.3.0 systému Spisové služby (SpS) e-spis LITE

Novinky verze 2.3.0 systému Spisové služby (SpS) e-spis LITE ICZ a.s. Správa a řízení dokumentů Na hřebenech II 1718/10 147 00 Praha 4 Tel.: +420-222 271 111 Fax: +420-222 271 112 Internet: www.i.cz Novinky verze 2.3.0 systému Spisové služby (SpS) e-spis LITE Vypracoval

Více

Kapitola 4: SQL. Základní struktura

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

Více

Zátěžové testy aplikací

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

Více

Systém elektronického rádce v životních situacích portálu www.senorady.cz

Systém elektronického rádce v životních situacích portálu www.senorady.cz Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML

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

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

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

Více

CSPUG 2011-květen. GridSQL a pg-pool II. Vratislav Beneš benes@optisolutions.cz

CSPUG 2011-květen. GridSQL a pg-pool II. Vratislav Beneš benes@optisolutions.cz GridSQL a pg-pool II Vratislav Beneš benes@optisolutions.cz Agenda 1. Datové sklady a datová tržiště 2. pg-pool II 1. Infrastrukutra 2. Využití pro datové sklady 3. GridSQL 1. Infrastuktura 2. Vytvoření

Více

Pavel Martinec 4.A 2011/2012

Pavel Martinec 4.A 2011/2012 Pavel Martinec 4.A 2011/2012 Tato úloha se skládala z několika částí: 1) Získávání informací 2) Instalace operačního systému 3) Konfigurace serverů 4) Testování propojení Bod 1: Získávání informací I když

Více

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

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

Více

Průvodce Vyúčtování s přehledem

Průvodce Vyúčtování s přehledem Děkujeme, že jste se rozhodli používat službu Vyúčtování s přehledem a jsme rádi, že jste si ji aktivovali. Než začneme s Vyúčtováním s přehledem pracovat, je potřeba si nejprve stáhnout z Vaší Internetové

Více

Popis modulu... 2. Přístup k modulu... 2. Popis rozhraní... 2. Práce s rozhraním... 3. Selektor událostí... 3. Události na zařízení...

Popis modulu... 2. Přístup k modulu... 2. Popis rozhraní... 2. Práce s rozhraním... 3. Selektor událostí... 3. Události na zařízení... Modul Události Obsah Popis modulu... 2 Přístup k modulu... 2 Popis rozhraní... 2 Práce s rozhraním... 3 Selektor událostí... 3 Události na zařízení... 3 Události na vstupu zařízení... 3 Události v rozhraní...

Více

1 Příručka pro práci s kostrou dokumentu v L A TEX 3 1.1 Úvod... 4 1.2 Kostra dokumentu... 4 1.2.1 Patitul... 4. 1.2.3 Anotace a abstract...

1 Příručka pro práci s kostrou dokumentu v L A TEX 3 1.1 Úvod... 4 1.2 Kostra dokumentu... 4 1.2.1 Patitul... 4. 1.2.3 Anotace a abstract... Příručka pro práci s dokumenty Obsah 1 Příručka pro práci s kostrou dokumentu v L A TEX 3 1.1 Úvod................................ 4 1.2 Kostra dokumentu........................ 4 1.2.1 Patitul...........................

Více