Databázové systémy I. 7. Přednáška
Co nás dnes čeká Uživatelské pohledy (Views) Optimalizace SQL dotazů Zpracování dotazu Naplnění tabulek daty (DML) Sekvence Transakce Indexy
Pohledy (views) představují zobecnění tabulek jde o virtuální tabulky definované pomocí dotazů nad jinými tabulkami nebo pohledy (nazýváme je základními tabulkami) neobsahují vlastní data obvykle jen pro čtení (read only), protože nelze jasně definovat zpětný rozpad na původní sloupce) při dodržení určitých pravidel můžeme vytvořit zapisovatelný (updatable) pohled
Proč používat pohledy? omezují přístup k datům základní tabulky, protože pohled může zobrazovat selektivní sloupce či řádka z původní tabulky v případě často opakovaných spojení usnadní uživateli dotazování poskytují uživatelům (skupinám uživatelů) přístup k údajům podle jejich konkrétních oprávnění
Jak na pohledy v SQL CREATE OR REPLACE VIEW jméno (definice pohledu) AS dotaz Definice pohledu představuje přehled sloupců, integritních omezení těchto sloupců a vícesloupcových integritních omezení na pohled Lze užít přejmenování sloupců dotazu V rámci dotazu nelze použít klauzuli ORDER BY Část s definicí pohledu vč. () lze vypustit
Vytvoření pohledu CREATE [OR REPLACE] [FORCE NOFORCE] VIEW view_name [(alias [, alias]...)] AS subquery [WITH CHECK OPTION [CONSTRAINT constraint]] [WITH READ ONLY [CONSTRAINT constraint]];
Typy pohledů Vlastnost Jednoduchý pohled Komplexní pohled Počet tabulek z nichž jsou získávána data Jedna Jedna nebo více Smí obsahovat funkce Ne Ano Smí obsahovat seskupování Lze provádět DML operations (INSERT, UPDATE, DELETE) prostřednictvím pohledu Ne Ano Ano Ne vždy
Modifikace pohledu K modifikaci pohledu dochází prostřednictvím přetvoření pohledu Použitím klauzule OR REPLACE při vytváření pohledu dojde k nahrazení staré verze nově definovaným pohledem
Omezení DML operací Nelze použít: víceřádkové funkce (D, U, I) GROUP BY (D, U, I) DISTINCT (D, U, I) pseudosloupec ROWNUM (D, U, I) sloupce definované pomocí výrazů (U, I) Neosahuje NOT NULL sloupce ze zdrojové tabulky (I)
Optimalizace dotazů Optimalizace de facto znamená nalezení optimální strategie zpracování dotazu Relační SŘBD je tak dobrý, jak je dobrý jeho optimalizátor dotazů. Optimalizace je vedena ve dvou krocích: Konstrukce alternativních plánů vyhodnocení. Odhad ceny alternativních plánů a volba plánu s nejnižší odhadnutou cenou. Optimalizaci provádí SŘBD, má více informací než programátor
Strategie optimalizace dotazů Algebraická optimalizace Indexy a velikost relace Řízené cenou operace Syntaxí řízená optimalizace
Algebraická optimalizace Nahrazuje jeden relační výraz druhým za účelem efektivnějšího přímého vyhodnocení. Zásada zmenši před operací spojení co nejvíce řádků a sloupců. Optimalizátor vyžaduje jisté informace o databázi. Je vhodná znalost, jak jsou podmínky omezující.
Algebraická optimalizace Prakticky se provádí transformacemi stromů dotazů. Listy jsou tvořeny základními relacemi, ostatní uzly reprezentují operace relační algebry Pravidla pro převod vycházejí z komutativních a distributivních zákonů vyplývajících z definice relačních operací.
Zákony
Zákony
Příklad Nalezněte jména filmů, u nichž existují kopie, které mají být vráceny do 30. 9. 2007. Pokorný (2007)
Příklad Použitím pravidel 1 a 2 rozdělíme čtyři spojení do dvou, nahradíme je kartézskými součiny a použijeme přejmenování atributů. Pokorný (2007)
Příklad Poslední výskyt spojení přepíšeme také pomocí kartézského součinu. Pokorný (2007)
Příklad Aplikací zákona 3 na selekci (DATUM_V > 30. 9. 2007) obdržíme záměnu selekční podmínky projekcí [K.JMÉNO_F, REŽISÉR, ROK, JMÉNO, ADRESA, V.Č_KOPIE, V.ROD_Č, DATUM_V], následně zaměníme danou selekci se selekcí V.Č_KOPIE=K. Č_KOPIE a po použití zákona 4 dostaneme danou selekci až k levému kartézskému součinu. Další aplikací zákona 3 a ze zákona 4 dostaneme tutéž selekci do kartézského součinu VÝPŮJČKY ZÁKAZNÍCI. Zároveň také podle 8 se zredukovaly po sobě jdoucí závěrečné projekce v jednu. Pokorný (2007)
Příklad Výsledek předchozích operací Pokorný (2007)
Příklad Další aplikací zákona 3 dostaneme před podmínku V.Č_KOPIE=K. Č_KOPIE projekci [K.Č_KOPIE, K.JMÉNO]. Pokorný (2007)
Příklad Nakonec je patrné, že první argument vnějšího kartézského součinu lze zjednodušit na VÝPŮJČKY (DATUM_V<30.9.2007)[V.Č_KOPIE] J. Pokorný. Databázové systémy 2. Praha: ČVUT, 2007. ISNB 978-80-01-03797-3.
Optimalizace založená na indexech a velikostech relací Problém bývá určit optimální pořadí operací spojení. Většina SŘBD používá jako základní algoritmy pouze binární spojení => vícenásobné spojení je nutné rozložit na posloupnost binárních. Řešení pomocí technik dynamického programování případně heuristických přístupů
Optimalizace řízená cenou Jedná se o jeden z heuristických přístupů pro spojení n relací, kde n > 2, generuje plány ve tvaru (((R 1 R 2 ) R 3 ) R n ). Vybere nejlepší plán pro spojení dvou relací, potom plám pro spojení třetí atd. Mají-li podmínky realizující spojení dvou relací R 1 a R 2 resp. R 3 a R 4 nízké ceny, je vhodnější zvolit způsob zpracování (R 1 R 2 )* (R 3 R 4 ).
Syntaxí řízená optimalizace Zde se předpokládá, že uživatel zahrne informaci pro optimalizaci od textu dotazu. SELECT * FROM zaměstnanci WHERE plat > 6700 AND adresa= 'Zemědělská 1 SELECT * FROM zaměstnanci WHERE adresa= 'Zemědělská 1' AND plat > 6700
Optimalizace v Oracle Oracle disponuje vlastním optimalizátorem dotazů Nastavení režimu optimalizace ALTER SESSION SET OPTIMIZER_MODE = {FIRST_ROWS FIRST_ROWS_ n ALL_ROWS RULE CHOOSE } Volíme Cíle optimalizace Minimální doba odezvy Maximální propustnost Přístup k optimalizaci Založený na statistikách (doporučený) Založený pouze na pravidlech
Data modification language Prostředek pro zanášení změn do databáze (modifikace relací) Nemůže ovlivnit datový slovník Musí realizovat tři základní operace: INSERT DELETE UPDATE Provádění operace musí být atomické, konzistentní a nesmí porušit integritu
Úplná kopie tabulky Je realizováno kombinací příkazů CREATE a SELECT CREATE TABLE copy_názevtabulky AS (SELECT * FROM názevtabulky) Omezení, příkaz nekopíruje primární klíče a IO cizího klíče Pro kontrolu takto zkopírovaných dat provedeme DESCRIBE copy_názevtabulky; SELECT * FROM copy_názevtabulky;
Vkládání nových záznamů Je realizováno přidáváním nových řádků do tabulky příkazem INSERT Existují dvě varianty vkládání: jeden řádek specifikovaný hodnotami více řádků určených dotazem Při vkládání se kontrolují integritní podmínky tabulky (definovanost, implicitní hodnoty, omezení, klíče) a provádí se současně potřebné definované indexování
Vkládání nových záznamů
Jak na to v SQL INSERT INTO tabulka [ (sloupce) ] VALUES (hodnoty) dotaz Počet hodnot musí odpovídat počtu sloupců (včetně domén), analogicky počet sloupců dotazu musí odpovídat počtu sloupců v definici INSERT Než začneme vkládat, zkontrolujeme si cílovou tabulku (DESCRIBE) Neuvedením sloupců se uvažují všechny sloupce z tabulky v pořadí odpovídající definice
Kontrola tabulky
Jak na NULL Při vkládání je nutné uvést hodnoty všech sloupců pro které vkládáme hodnoty Pro vložení nedefinovaných hodnot, lze použít NULL, pro chybějící údaje se používá prázdný řetězec ( )
Vkládání speciálních hodnot Typicky se jedná o hodnoty jako SYSDATE nebo USER SYSDATE, vloží aktuální datum a čas USER, vloží jméno uživatele aktuální session U APEXu to bude OAE_PUBLIC_USER
Vkládání speciálních hodnot Kromě funkcí (př. SYSDATE), lze vkládat rovněž výrazy
Použití zanořených dotazů Pro vkládání více údajů z jiné tabulky je možné požít vnořeného dotazu Představte si přesun banned uživatelů na fóru Namísto 100 samostatných insertů tak spustíme jeden Při tomto způsobu není potřeba uvádět VALUES klauzuli
CREATE TABLE lidi (id NUMBER(5) NOT NULL PRIMARY KEY, jmeno VARCHAR2(50) NOT NULL, login VARCHAR2(8) UNIQUE, vek NUMBER(3) CHECK (vek > 0)); INSERT INTO lidi (id,jmeno,vek) VALUES (1, Metuzalém,784) INSERT INTO lidi VALUES (1, Metuzalém, xmetuz,784) Příklad použití INSERT
Problém primárního klíče Často řešený problém co je primárním klíčem redukuje se na tvorbu sloupce ID Tento sloupec je číselný, vždy definovaný a označený jako primární klíč (a tedy automaticky také indexovaný) Jak zajistit přidělování čísel záznamům? Problém MAX(id) při kolizi dvou uživatelů Řešením jsou sekvence
Sekvence Představují jediný nástroj nezávislý na transakcích a relacích uživatele Jdou napříč celým DBS Sekvence na zavolání vždy vrátí další číslo v řadě (podle stanovených podmínek) V jednom SQL příkazu vrátí sekvence vždy jen jedno číslo (tzv. nextval) Nelze získat aktuální stav sekvence
Práce se sekvencí v SQL Součást datového slovníku (DDL): CREATE SEQUENCE jméno Pro získání nové hodnoty slouží funkce sekvence.nextval Pro získání hodnoty již jednou vytvořené v SQL příkazu slouží sekvence.currval Příklad použití: INSERT INTO lidi (id,jmeno) VALUES (lidi_seq.nextval, Eva )
Rušení záznamů Je realizováno vyhledáním a rušením existujících řádků tabulky příkazem DELETE Existují dvě varianty rušení: vybraných řádků určených podmínkou všech řádků tabulky Při rušení se kontroluje konzistence integritních omezení, rušení tak může být zakázáno nebo vyvolá kaskádové rušení Co se stane když vynecháme podmínku WHERE?
Jak na to v SQL DELETE [ FROM ] tabulka [ WHERE podmínka ] Neuvedením části WHERE dojde k vymazání celé tabulky (ovšem pouze obsahu, vlastní tabulka je součástí datového slovníku nemůže jí zrušit DML) Klíčové slovo FROM je nepovinné pouze v Oracle
Neopomenout IO
Určení podmínky v DELETE Lze užít část dotazovacího jazyka SQL Kombinujeme sloupce z příslušné tabulky, relační operátory, konstanty, závorky a logické spojky (AND, OR, NOT) Můžeme použít množinový vnořený dotaz pomocí operátoru IN (ptáme se, zda je hodnota obsažena v množině) Můžeme použít množinový poddotaz o jedné hodnotě místo konstanty v relaci
Použití zanořených dotazů v DELETE
DELETE FROM lidi DELETE FROM lidi WHERE vek < 18 DELETE FROM lidi WHERE vek < 18 OR vek > 62 DELETE FROM lidi WHERE vek IN (15,18,21) DELETE FROM lidi WHERE vek < (SELECT prah FROM limity WHERE typ = plnoletost ) Příklad použití DELETE
Změna (modifikace) záznamů Je realizováno vyhledáním a změnou existujících řádků tabulky příkazem UPDATE Existují dvě varianty rozsahu změn: vybraných řádků určených podmínkou všech řádků tabulky Při modifikaci se též kontroluje veškerá konzistence integritních omezení a všechny podmínky jako při vkládání nových záznamů
Který z řádků bude změněn? Kontrolní otázka?
Jak na to v SQL UPDATE tabulka SET změnový seznam [ WHERE podmínka ] Neuvedením části WHERE dojde ke změně v celém rozsahu tabulky Změnový seznam je čárkou oddělená posloupnost údajů tvaru jméno sloupce = hodnota Podmínka se určuje stejným způsobem jako u DELETE
Použití vnořeného dotazu
Update 2 sloupců 2 vnořenými dotazy
MERGE Umožňuje provést současně INSERT i UPDATE a to ve 2 případech Chybí-li vkládaná hodnota, pak je vložena nová Je-li nutné aktuální hodnotu nahradit novou Pro provedení těchto změn je nutné disponovat právy pro pro příkazy INSERT a UPDATE MERGE umožňuje použití aliasů
MERGE v příkladu
Datové typy Znakové typy CHAR(n), pevný počet znaků, až do 2000 znaků VARCHAR2(n), variabilní počet znaků, až do 4000 znaků CLOB, variabilní počet znaků, až do 128 TB Číselné typy NUMBER(prec, scale), variabilní počet číslic, až do 38 desetinných míst Typ datum a čas DATE, TIMESTAMP, INTERVAL Binární objekty (jako JPG, WAV, MP3 atd.) RAW(n), variabilní délka, až do 2000 bytů BLOB, variabilní délka, až do 128 TB
Datové typy Best practices Pro znakové typy je lepší použití VARCHAR2 nebo CLOB na místo CHAR (úspora místa) NUMBER ukládá kladná i záporná čísla, např. NUMBER(6,2) > uloží +9999,99 i -9999,99 TIMESTAMP WITH LOCAL TIME ZONE uloží hodiny včetně odchylky od Universal Coordinated Time (UCT), dříve GMT Při použití v SELECT je čas automaticky převeden na aktuální čas v dané časové zóně
CREATE TABLE time_example (first_column TIMESTAMP WITH TIME ZONE, second_column TIMESTAMP WITH LOCAL TIME ZONE); INSERT INTO time_example (first_column, second_column) VALUES ('15-NOV-2007 08:00:00 AM -05:00, '15-NOV-2007 08:00:00'); Uživatel v Istanbulu provede: a uvidí... LOCAL TIME ZONE TIMESTAMP WITH
Intervalové datové typy Pro uchování uběhlého času, nebo intervalu času mezi dvěma dny-časovými hodnotami INTERVAL YEAR TO MONTH, uloží časovou periodu měřenou rokem a měsícem INTERVAL DAY TO SECOND, uloží časovou periodu měřenou ve dnech, hodinách, minutách a sekundách
Intervalové datové typy
Co si představíte pod pojmem transakce?
Transakce provedení, uzavření obchodu, převod (http://slovnik-cizich-slov.abz.cz/web.php/slovo/transakce) je dohoda, komunikace, přenos nebo výměna čehokoliv mezi dvěma samostatnými entitami nebo objekty. (http://cs.wikipedia.org/wiki/transakce)
Bankovní transakce
Databázová transakce Databázová transakce je skupina příkazů, které převedou databázi z jednoho konzistentního stavu do druhého. (http://cs.wikipedia.org/wiki/databázová_transakce)
Bankovní transakce http://docs.oracle.com/
Vlastnosti transakcí Atomicity (atomičnost) Consistency (zajištění konzistence) Isolation (izolovanost) Durability (trvalost)
Atomičnost transakce Databázová transakce je jako operace dále nedělitelná (atomární). Provede se buď jako celek, nebo se neprovede vůbec. Při neprovedení transakce dochází zpravidla k chybovému hlášení
Konzistence Databáze zůstává neustále konzistentní. Při a po provedení transakce nesmí být porušeno žádné integritní omezení.
Izolovanost Transakce musí být vzájemně nezávislé, dílčí efekty transakce neovlivní jiné transakce. Operace uvnitř transakce jsou skryty před vnějšími operacemi. Vrácením transakce není zasažena jiná transakce, jinak i tato musí být vrácena. V důsledku tohoto chování může dojít k tzv. řetězovému vrácení.
Trvalost Změny, které se provedou jako výsledek úspěšných transakcí, jsou skutečně uloženy v databázi a již nemohou být ztraceny. Efekt celé transakce je trvalý perzistentní.
Způsoby ukončení transakce COMMIT veškeré změny transakce jsou přijaty, od okamžiku potvrzení se stávají viditelné pro všechny ostatní transakce v databázovém systému ROLLBACK situace se vrací do okamžiku před zahájením transakce, všechny změny jsou označeny za neplatné
Příkazy pro řízení transakce SAVEPOINT: Vytvoří značku v transakci, která rozděluje transakci na menší kousky. ROLLBACK TO SAVEPOINT: Umožňuje uživateli vrátit zpět aktuální transakci do zadaného bodu. Byla-li k chybě, uživatel může použít příkaz ROLLBACK TO SAVEPOINT, čímž zahodí pouze ty změny, které byly provedeny poté, co byl založen SAVEPOINT.
Co se stane v této transakci?
Dva režimy práce s databází Sekvence transakcí první transakce je zahájena operací BEGIN TRANSACTION, poté probíhají jednotlivé transakce zakončené COMMIT či ROLLBACK, přičemž ukončení jedné transakce má za následek začátek další transakce Tzv. autocommit režim každá operace je chápána za samostatnou transakci, která implicitně končí COMMIT, pokud nenastala chyba
Aktualizace aplikace App1 je ztracena, jakmile aplikace App2 provede svou aktualizaci, proto se takovému problému říká Ztráta aktualizace. Ztráta aktualizace IBM DB2 Express-C
App2 čte nepotvrzená, neplatná data. Této situaci se také říká nepotvrzené čtení. Nepotvrzené čtení IBM DB2 Express-C
V tomto případě nemůže být znovu reprodukována původní datová sada, App1 nedostane stejná data při čtení; těmto problémům se říká neopakovatelné čtení. Neopakovatelné čtení IBM DB2 Express-C
V tomto případu App1 nedostane stejná data při opakovaném čtení, získá jich více, proto je tento problém nazývaný fantomové čtení. Fantomové čtení IBM DB2 Express-C
Řešení uvedených problémů Definujme pojem rozvrh jako celkový plán posloupnosti všech operací v rámci všech uvažovaných transakcí Řešení uvedených problémů pak spočívá v tzv. uspořádatelnosti rozvrhu Hledáme takový způsob uspořádání operací v jednotlivých transakcích, aby byly všechny stanovené ACID vlastnosti (zejména izolace) z vnějšího úhlu pohledu zachovány
Konkrétní řešení Pro uvedené problémy je jediné možné uspořádání serializace rozvrhu spojení operací odečtení a přičtení N v T1 do jedné posloupnosti nepřerušené jinou transakcí Serializace potláčí paralelní zpracování transakcí snižuje tedy významně výkon databázového serveru
Jiné způsoby uspořádání rozvrhu Mimo serializaci (vysoce neefektivní způsob) by hledání jiných způsobů uspořádatelnosti rozvrhů bylo časově velmi neefektivní (iterativní úloha) Využívá se konstrukcí rozvrhů podle předem stanovených pravidel soubor těchto pravidel označujeme jako protokol Nejčastěji se tyto protokoly konstruují na základě zamykání a odemykání objektů K zamčenému objektu (LOCK) nemá jiná transakce přístup (ochrana izolace)
Dobře formovaná transakce před přístupem k objektu provádí jeho uzamknutí (LOCK) neprovádí LOCK na objekty, které už zamkla neprovádí UNLOCK na objekty, které nezamkla před koncem provede UNLOCK na všechny objekty, které ve svém průběhu zamkla a jsou dosud zamčené
Dvoufázový uzamykací protokol Dvoufázová transakce v první fázi uzamyká vše, co bude potřebovat při svém průběhu Druhá fáze začíná okamžikem prvního odemknutí Ve druhé fázi se zamčené objekty pouze odemykají, tj. nelze již použít žádné operace LOCK Tedy transakce musí mít všechny objekty uzamčené před tím, než nějaký objekt odemkne
Uspořádatelnost 2F protokolu Pokud všechny transakce ve vstupní množině transakcí jsou současně: dobře formované transakce dvoufázové transakce pak každý jejich rozvrh je uspořádatelný Stále ovšem existuje nebezpečí tzv. deadlocku vzájemného uváznutí, tj. vzájemné čekání na dokončení některé operace druhé transakce
Uváznutí http://csunplugged.org/sites/default/files/cartoons/deadlock.jpg
Definice uváznutí Uváznutí (deadlock) je situace, kdy pro každou transakci ze skupiny transakcí jsou splněny následující podmínky: každá transakce ze skupiny je blokována čekáním na objekt databáze (na jeho odemknutí) ukončení všech transakcí mimo uvedenou skupinu transakcí neumožní odblokování žádné transakce ve skupině
Uváznutí (deadlock) Jedná se o situaci, kdy jednotlivé transakce nekonečně dlouho čekají na uvolnění zamknutého objektu http://docs.oracle.com/
Problémy souběhu transakcí Definujme si následující zjednodušené operace: read(x) načtení hodnoty X z databáze write(x) zápis hodnoty X do databáze commit potvrzení transakce rollback odmítnutí transakce Zkusme porovnat souběh dvou transakcí užívajících zjednodušené operace
Řešení problému uváznutí Protože uváznutí je stav, který neumožňuje úspěšně pokračovat v korektním plnění požadavků, je nutné zabránit vzniku uváznutí nebo toto uváznutí detekovat a odstranit ho detekci uváznutí a následné odstranění užíváme při uzamykacím protokolu předcházení uváznutí řešíme metodou časových razítek
Metoda časových razítek I Metoda zajišťující uspořádatelnost rozvrhu Ke každému objektu jsou přiřazena dvě tzv. časová razítka: čas posledního čtení (TSR) čas posledního zápisu (TSW) Každá transakce T dostane na svém začátku svou vlastní hodnotu TS(T), která je unikátní a stále roste (např. pořadové číslo transakce razítko)
Metoda časových razítek II Pokud transakce T volá operaci write(x) jestliže TSR(X) > TS(T), zruš transakci T a proveď rollback(t) (nějaká transakce s razítkem větším než TS(T) již četla X před tím, než T mělo šanci provést zápis) jestliže TSW(X) > TS(T), zruš operaci write(x)a pokračuj (nějaká transakce s razítkem větším než TS(T) již zapisovala X, náš zápis by byl přepsán) jinak proveď write(x), TSW(X) := TS(T)
Metoda časových razítek III Pokud transakce T volá operaci read(x) jestliže TSW(X) > TS(T), zruš transakci T a proveď rollback(t) (nějaká transakce s razítkem větším než TS(T) již zapisovala X před tím, než T mělo šanci číst) jinak proveď read(x), TSR(X) := max(ts(t),tsr(x)) Metoda časových razítek umožňuje rozšíření na metodu nezpůsobující uváznutí (deadlock)
Detekce uváznutí Využívá teorie grafů (předmět v navazujícím stupni studia) Při zamykání vytváří tzv. čekací graf (která transakce čeká na kterou) Pokud v grafu vznikne cyklus, došlo k uváznutí a je nutné cyklus přerušit (ukončit některou transakci obvykle nejstarší nebo nejnovější) Oracle využívá detekce uváznutí
Předcházení uváznutí Některé metody umožňují zabránit vzniku uváznutí Obvykle se jsou tyto metody charakteristické nepovolením přístupu k objektu, se kterým pracuje jiná transakce Významným způsobem redukují paralelizaci rozvrhů a tedy snižují výkon databázového systému Nepodporuje sdílení objektů (např. pro čtení) více různými transakcemi
Implementace v Oracle Základní systém transakcí podporuje ACID, využívá dvoufázového zamykání a provádí detekci uváznutí (deadlocků) s jejich přerušením formou výjimky Implicitní režim transakcí bývá dán aplikací (dbman autocommit, SQL*Plus transakční režim) Existuje možnost stanovení úrovně izolace transakcí pro operace čtení (DQL)
Stanovení úrovně izolace Pomocí parametru relace (session) ALTER SESSION SET ISOLATION LEVEL režim Podporované režimy: READ COMMITED běžný režim (není žádná izolace v rámci DQL) READ UNCOMMITED nepotvrzené čtení REPEATABLE READ čtecí stabilita SERIALIZABLE vytváří větší prostor pro deadlock
Porovnání úrovní izolace Oracle, PgSQL, MSSQL, MySQL IBM DB2 Nepotvrzené čtení Neopakovatelné čtení Fantomové čtení Read uncommitted Read committed Uncommited Read možné možné možné Cursor Stability - možné možné Repeatable read ReadStability - - možné Serializable Repeatable Read - - -
Indexy Index je seřazená sada klíčů, které vedou k řádku v tabulce. Index bere v potaz jedinečnost a také vylepšuje výkon. Index může být řazen vzestupně nebo sestupně Indexové klíče mohou být unikátní nebo neunikátní Pro index může být použito několik sloupců Pokud jsou index a fyzická data klastrovány v podobné indexové sekvenci, jsou klastrovaným indexem CREATE UNIQUE INDEX artno_ix ON artists (artno)
Typy indexů Unique index definován automaticky při použití PRIMARY KYE nebo UNIQUE KEY Nonuniquie index pro rychlejší přístup k řádkům např. FOREIGN KEY Function based index použití UPPER nebo LOWER v klauzuli WHERE CREATE INDEX d_evnt_dt_indx ON d_events (to_char(event_date, mon ))
Kdy použít indexy Rozsáhlé hodnoty ve sloupci Sloupec obsahuje vysoký počet NULL hodnot Jeden nebo více sloupců jsou často využívány dohromady v klauzuli WHERE nebo JOIN Velká tabulka ze které chceme dotazem vrátit méně než 2-4% z celkového počtu řádků K zapamatování: každá DML operace (INSERT, UPDATE, DELETE) nad tabulkou s indexem znamená, že také index musí být přepočítán!
B-stom je druh stromu. Je specifický tím, že má řád n a limity na maximální (n), i minimální (n/2) počet potomků vrcholu. B-strom je díky této vlastnosti vyvážený, operace přidání, vyjmutí i vyhledávání tedy probíhají v logaritmickém čase. (http://cs.wikipedia.org/wiki/b-strom)
Projekt 2 Odevzdat do 19. 4. 2016 17:00 Samostatná práce Převod do fyzického modelu Vytvoření tabulek a integritních 18 dotazů zajímají mě pouze výsledky