1. blok Systémový katalog

1. blok Systémový katalog Studijní cíl Tento blok je věnován seznámení se systémovým katalogem z pohledu ANSI/ISO SQL2, ale i s reálným řešením systémového katalogu v databázích Oracle. Doba nutná k nastudování 2-3 hodiny Průvodce studiem Při studiu tohoto bloku se předpokládá, že čtenář je obeznámen se základy jazyka SQL a různými druhy databázových objektů. 1. Systémový katalog Pro správné fungování databáze a provádění jednotlivých funkcí je třeba velké množství informací. Tyto informace o struktuře databáze jsou uloženy v systémovém katalogu. Systémový katalog je souborem všech tabulek a pohledů nad nimi, které databáze jednak udržuje pro svou vlastní potřebu, ale také zpřístupňuje uživatelům databáze prostřednictvím standardních SQL dotazů. Údaje systémového katalogu také používají různé aplikace pro zadávání dotazů a komunikaci s databázovým serverem, které na pozadí volají dotazy do systémového katalogu a výsledky vizualizují ve formě tabulek, stromových struktur, předvyplněných formulářů a podobně. Takto využívá systémový katalog i SQL Developer. V systémovém katalogu můžeme například zjistit informace o existujících databázových objektech, jejich vlastnících, datech vytvoření a posledních změnách, seznamy tabulek, jejich sloupců, použitých datových typů, omezeních, právech, ale i spoustu informací souvisejících s fyzickým uložením tabulek a podobně. IDAS2/1 Systémový katalog 1

1.1 Co je systémový katalog Systémový katalog (někdy nazývaný také jako Datový slovník Data Dictionary) je soubor speciálních tabulek v databázi, které vytváří, aktualizuje a vlastní sám databázový systém obvykle prostřednictvím některého ze systémových uživatelů pod identifikátory SYSTEM, SYS nebo DBA. Tyto tabulky obsahují data, která popisují strukturu databáze. Abychom pochopili smysl údajů ze systémového katalogu, podívejme se na zpracování následujícího dotazu: Zjistěte dodavatele a produkty, které dodávají: SELECT nazev, oznaceni, cena FROM PRODUKTY JOIN DODAVATELE ON PRODUKTY.dodavatel_id = DODAVATELE.dodavatel_id; V systémovém katalogu bude třeba ověřit Existenci názvů uvedených tabulek či pohledů PRODUKTY a DODAVATELE ve schématu uživatele, který zadal dotaz, pokud zde nebudou, pak ověřit, zda neexistuje synonyma ukazující na objekt s jiným názvem či v jiném schématu Ověření, že uživatel má právo pro SELECT těchto tabulek Zkontrolovat, zda uvedené sloupce v daných databázových objektech existují a zda neexistuje konflikt v názvech požadovaných sloupců v uvedených databázových objektech Určit datové typy pro požadované sloupce Jak již bylo uvedeno, databázový systém také zpřístupňuje obsah systémových tabulek uživatelům a to buď přímo, nebo prostřednictvím pohledů. Samozřejmě jsou tyto přístupy určeny pouze pro čtení z důvodu zachování integrity dat. Aktualizaci zajišťuje sama databáze na základě uživatelem prováděných akcí přímo v databázových objektech. Lze říci, že každá DDL operace provede kromě vlastních změn (vytvoření, úprava či odstranění) databázového objektu také aktualizaci dat v systémovém katalogu. IDAS2/1 Systémový katalog 2

1.2 Systémový katalog dle standardu ANSI/ISO SQL1 a SQL2 Standard ANSI/ISO SQL1 nespecifikoval strukturu a obsah systémového katalogu, proto se v různých databázích značně liší struktura katalogu a obsah jeho tabulek. V době přijetí standardu SQL2 již nebylo možné dosáhnout shody, neboť jednotlivé komerční produkty se již značně v této části lišily. Místo toho byl alespoň definován idealizovaný systémový katalog (ve standardu nazýváno jako definiční schéma), který by mohl výrobce databáze použít, kdyby začínal tzv. na zelené louce. Místo toho ale standard SQL2 definuje pohledy na tabulky systémového katalogu, jež identifikují objekty databáze, ke kterým má uživatel přístup (těmto pohledům se ve standardu říká informační schéma). Pro střední a plnou podporu standardu SQL2 musí databáze tyto pohledy podporovat. V praxi to znamenalo, že většina výrobců databází implementovala nad vlastní strukturou tabulek systémového katalogu toto jednotné informační schéma. My se však nebudeme zabývat pohledy definovanými v informačním schématu standardu SQL2 a v další kapitole se podíváme na systémový katalog databáze Oracle. 1.3 Systémový katalog v databázích Oracle Systémový katalog (Oracle Data Dictionary) se skládá z tabulek a pohledů poskytujících informace o databázi a její struktuře, ty jsou uloženy v tabulkovém prostoru SYSTEM. Slovník se skládá ze: základních tabulek (typicky označované x$ ) pohledy uchovávají informace o databázi pouze Oracle by měl zapisovat a číst do/z těchto tabulek jsou důležité pro správnou funkčnost databáze tyto pohledy shromažďují a zobrazují v čitelné podobě informace uložené v základních tabulkách katalogu (např. DBA_TABLES) Všechny tabulky i pohledy vlastní uživatel SYS. systémový katalog je složen z množin pohledů. V mnoha případech mají množiny tři podobné pohledy lišící se v názvu prefixem: USER_ všechny objekty, které uživatel vlastní ALL_ všechny objekty, ke kterým má uživatel přístup IDAS2/1 Systémový katalog 3

DBA_ všechny objekty (pohledy pro databázové administrátory) sloupce v každé množině jsou identické s následujícími výjimkami: pohledy s prefixem USER_ většinou nemají sloupce OWNER (očekává se, že vlastníkem je uživatel, který dotaz spustil) některé DBA_ pohledy mají další sloupce navíc s informacemi užitečnými pro DBA Jelikož počet pohledů systémového katalogu je obrovský počet, nemůžeme se zabývat všemi, ale ukážeme si nejdříve, jak je zjistit: Zjištění různých pohledů systémového katalogu a jejich významu: SELECT * FROM dictionary ORDER BY table_name; Rozsah výsledku lze omezit např. pokud hledáme pohledy pojednávající o tabulkách: SELECT table_name, comments FROM dictionary WHERE table_name LIKE '%TABLE%' ORDER BY table_name Popisy sloupců jednotlivých pohledů systémového katalogu lze najít takto, uveden příklad pro pohled ALL_TAB_COLUMNS: SELECT column_name, comments FROM dict_columns WHERE table_name = 'ALL_TAB_COLUMNS' IDAS2/1 Systémový katalog 4

Pro získání základní přehledu uveďme aspoň základní pohledy (tučně uvedené slovo se může vyskytovat se v závorce uvedenými předponami, pokud je uveden v druhé závorce ještě zkrácený název, může být použit i jen tento samostatně bez předpony), příklad: SELECT * FROM USER_CATALOG; -- jen objekty vlastníka SELECT * FROM CAT; -- shodné s USER_CATALOG SELECT * FROM ALL_CATALOG; -- všechny uživateli přístupné objekty SELECT * FROM DBA_CATALOG; -- jen pro administrátory databáze A nyní výběr několika základních pohledů systémového katalogu: CATALOG (ALL_, DBA_, USER_, (CAT)) Informace o databázových tabulkách, pohledech, synonymech a sekvencích OBJECTS (ALL_, DBA_, USER_, (OBJ)) Informace o databázových objektech TABLES (ALL_, DBA_, USER_, (TABS)) Informace o tabulkách v databázi TAB_COLUMNS (DBA_, ALL_, USER_, (COLS)) Informace o sloupcích tabulek a pohledů, jejich datových typech, atd. TAB_PRIVS (DBA_, ALL_, USER_) Informace o objektových právech přidělených uživateli nebo přidělených uživatelem (dílčí pak TAB_PRIVS_MADE a TAB_PRIVS_RECD) CONSTRAINTS (ALL_, DBA_, USER_) Informace o integritních omezeních databáze INDEXES (ALL_, DBA_, USER_, (IND)) Informace o indexech v databázi VIEWS (ALL_, DBA_, USER_) Informace o pohledech v databázi IDAS2/1 Systémový katalog 5

SEQUENCES (ALL_, DBA_, USER_, (SEQ)) Informace o sekvencích v databázi PROCEDURES (ALL_, DBA_, USER_) Informace o procedurách a funkcích v databázi TRIGGERS (ALL_, DBA_, USER_) Informace o triggerech v databázi SOURCE (ALL_, DBA_, USER_) Zdrojové texty uložených procedur, funkcí, specifikací a těl balíků v databázi DEPENDENCIES (ALL_, DBA_, USER_) Informace o závislostech mezi objekty v databázi USERS (ALL_, DBA_, USER_) Informace o uživatelích v databázi ROLE_PRIVS (DBA_, USER_) Informace o rolích přidělených uživateli TABLESPACES (DBA_, USER_) Informace o tabulkových prostorech databáze DATA_FILES (DBA_) Informace o datových souborech databáze LOCKS (DBA_) Informace o DLL a DML uzamčeních v databázovém serveru V$TRANSACTION Informace o aktuálně prováděných databázových transakcích IDAS2/1 Systémový katalog 6

Tak jako jiné pohledy, i pohledy informačního schématu systémového katalogu je možné spojovat. To si můžeme ukázat na následujícím příkladu: Zjištění názvů sloupců ve schématu A_HR, které jsou typu NUMBER a jsou součástí primárních klíčů tabulek. SELECT column_name, table_name, data_type FROM all_constraints JOIN all_cons_columns USING (constraint_name, owner, table_name) JOIN all_tab_cols USING (owner, table_name, column_name) WHERE owner='a_hr' AND constraint_type='p' AND data_type = 'NUMBER'; Pojmy k zapamatování Příkazy a funkce: CREATE ROLE GRANT, REVOKE, CREATE/ALTER/DROP USER, Problém: zabezpečení, práva, role, přidělování a odejímání oprávnění, využití pohledů pro zabezpečení, správa uživatelů, bezpečnostní mechanismy Oracle databáze Shrnutí V této lekci jste se seznámili se systémovým katalogem databáze, zejména Oracle databáze. Systémový katalog obsahuje každá relační databáze, vlastní tabulky systémového katalogu tvoří definiční schéma, to se však mezi databázemi obvykle liší. Mnohem standardnější jsou již pohledy nad tabulkami systémového katalogu, které tvoří informační schéma. Produkty se střední a plnou podporu standardu SQL2 musí standardní názvy pohledů podporovat. Pohledy systémového katalogu je možné (a často účelné) spojovat, aby byly nalezeny požadované informace. Protože pohledů systémového katalogu je velice mnoho, je dobré znát název pohledu DICTIONARY, kde lze zjistit seznam pohledů. Prefixy názvů pohledů USER_, ALL_ a DBA_ určují rozsah výstupních dat, zda se vztahují k objektům o vlastněným uživatelem (USER_), o přístupným uživateli (ALL_) či o data o všech objektech určená pro administrátora databáze (DBA_). IDAS2/1 Systémový katalog 7

Otázky na procvičení 1. K čemu slouží systémový katalog? 2. Jak se liší jednotlivé databázové produkty pokud jde o strukturu systémového katalogu? 3. Čím je tvořeno informační schéma systémového katalogu? 4. Jak se liší pohledy podle prefixu USER_, ALL_ a DBA_? 5. Jak se aktualizují data v tabulkách systémového katalogu? Odkazy a další studijní prameny http://www.oracle.com/technetwork/database/enterpriseedition/documentation (dokumentace k databázové platformě Oracle) Odkazy a další studijní prameny GROFF, J.R., WEINBERG, P.N. SQL - kompletní průvodce.. Praha: Computer Press, 2005. ISBN 80-251-0369-2. LACKO, L. Oracle Správa, programování a použití databázového systému. Praha: Computer Press, 2007. ISBN 978-80-251-1490-2. STEPHENS, K.R., PLEW, R.R. Naučte se SQL za 21 dní. Praha: Computer Press, 2004. ISBN 80-7226-870-8. IDAS2/1 Systémový katalog 8

2. blok Zabezpečení a ochrana dat Studijní cíl Tento blok je věnován základům zabezpečení a ochrany dat uložených v relačních databázích, tj. uživatelským účtům, systémovým a objektovým oprávněním a rolím. Dále jsou zde uvedeny i příklady pro uložení hesel v tabulkách. Doba nutná k nastudování 2-3 hodiny Průvodce studiem Při studiu tohoto bloku se předpokládá, že čtenář je obeznámen se základy jazyka SQL a databázovými objekty typu tabulka a pohled. 1. Zabezpečení dat V předchozích lekcích jsme se zabývali zejména prací s daty v tabulkách a vytvářením databázových objektů. Stále více se seznamujeme s tím, že databáze není jen úložiště dat, ale ucelené řešení, které se stará nejen o jejich uložení a rychlé zpřístupňování, ale také o jejich konzistenci a to za libovolných okolností. Samozřejmostí pak musí být i řízení přístupu uživatelů k datům v databázi. Typickými požadavky jsou: Data v konkrétní tabulce by měla být přístupná pouze některým uživatelům. Někteří uživatelé mohou tato data aktualizovat, zatímco jiní je mohou pouze číst. Některým uživatelům chceme zpřístupnit t pouze vybrané sloupce tabulky. Některým uživatelům chceme zpřístupnit pouze vybrané řádky tabulky. Před některými uživateli chceme skrýt skutečnou strukturu dat v tabulkách. Jednotlivým uživatelům chceme umožnit vytváření pouze určitých druhů databázových objektů. Systém řízení báze dat musí být tedy odpovědný za implementaci a kontrolu bezpečnostních omezení. Pro nastavení bezpečnostních omezení jsou využívány příkazy SQL. IDAS2/2 Zabezpečení a ochrana dat 1

Systém zabezpečení je založen na těchto třech prvcích: Uživatelé každá činnost v databázi je spojena s konkrétním uživatelem a systém umožňuje nebo zamezuje konkrétní akci v závislosti na tom, který uživatel akci požaduje Databázové objekty zabezpečení se vztahuje i na konkrétní databázové objekty, tedy například tabulky, pohledy, funkce, procedury. Zatímco uživatelé mají většinou plný přístup k objektům jimi vytvořeným, přístupy k objektům ostatních uživatelů jsou defaultně zakázány a musí být explicitně nastaveny. Práva akce, které může uživatel provádět na konkrétním databázovém objektu. 1.1 Účet uživatele Každý uživatel je identifikován krátkým jménem. Každý příkaz prováděný databázovým systémem se provádí jménem konkrétního uživatele a podle tohoto jména je operace povolena nebo zamítnuta. Maximální délka identifikátoru uživatele (často hovoříme o takzvaném uživatelském účtu) se v jednotlivých implementacích databázových abázových systémů liší a pohybuje se od 8 do 30 znaků. Ve standardu ANSI/ISO se namísto identifikátoru uživatele hovoří o autorizačním identifikátoru. Smyslem identifikátoru je zjistit autorizaci nebo práva v databázi. V provozní databázi se často používají í autorizační identifikátory nikoli pro konkrétní osoby, ale pro programy nebo skupiny programů. Vlastní autorizace uživatelů pracujících s těmito programy se řeší v rámci těchto programů samotných. Při vytvoření relace (session) databázový systém vyžaduje identifikátor uživatele a heslo. Databázový systém heslo poté zkontroluje. Uživatelský účet se vytvoří příkazem CREATE USER <identifikator_uzivatele> IDENTIFIED BY <heslo>; Příklad CREATE USER jnovak IDENTIFIED BY w25sqx; Příkaz vytvořil v databázi uživatele s identifikátorem JNOVAK, který bude mít heslo "w25sqx". IDAS2/2 Zabezpečení a ochrana dat 2

Uživatel nebo administrátor databáze může změnit heslo příkazem ALTER USER. ALTER USER <identifikator_uzivatele> IDENTIFIED BY <heslo>; Příklad ALTER USER JNOVAK IDENTIFIED BY sdf45t; Odstranění účtu uživatele z databázového systému provedeme příkazem DROP USER <identifikator_uzivatele>; Databáze Oracle neodstraní účet uživatele, jehož schéma obsahuje nějaké databázové objekty, pokud nedoplníte kluazuli CASCADE. V takovém případě pak je nezbytné zadat příkaz ve tvaru: DROP USER <identifikator_uzivatele> CASCADE; 1.2 Skupiny uživatelů Dle standardu zabezpečení ANSI/ISO SQL můžeme pracovat se skupinami uživatelů s podobnými potřebami jedním z těchto způsobů: Všem přiřadíme stejný identifikátor uživatele, bohužel v takovém případě uživatelé nemohou být odlišeni jeden od druhého ve zprávách databáze. Každému uživateli přiřadíme samostatný identifikátor, práva pro každého uživatele zadáváme individuálně. Jednotlivé databázové systémy nabízí další možnosti, jak zařadit jednotlivé uživatele do skupin a využít práva definovaná pro skupiny nebo role. 1.3 Práva Skupina akcí, které lze provádět na databázovém objektu, se nazývá práva pro daný objekt. Standard SQL1 specifikuje 4 základní práva pro tabulky a pohledy: SELECT - umožňuje načítání dat z tabulky nebo pohledu INSERT - umožňuje vkládat nové řádky do tabulky nebo pohledu IDAS2/2 Zabezpečení a ochrana dat 3

UPDATE - umožňuje upravovat řádky v tabulce nebo pohledu, právo UPDATE může být omezeno na konkrétní sloupce tabulky nebo pohledu DELETE - umožňuje odstraňovat řádky tabulky nebo pohledu Standard SQL2 přidal: právo REFERENCES, které umožňuje vytvářet odkazy na tabulku z cizího klíče v jiné tabulce, dále přidal právo USAGE, které řídí přístup k databázovým strukturám domén, znakových sad, způsobům řazení a překladů u práva INSERT je možné omezit sloupce, které je možné zadávat, ostatní sloupce u nově zadaného řádku budou mít hodnotu NULL, případně defaultní hodnotu dle definice tabulky u práva SELECT připouští (nicméně nedefinuje) možnost omezení na vybrané sloupce, proto to některé databázové systémy mají implementováno Vlastník tabulky má automaticky práva SELECT, INSERT, UPDATE a DELETE (a případná další práva poskytovaná použitou databází) nad touto tabulkou. Ostatní uživatelé obvykle nemají k této tabulce žádná práva a v případě potřeby jsou jim práva explicitně přidělena pomocí příkazu GRANT. U vytvořeného pohledu má vlastník pohledu automaticky právo SELECT, které vychází z toho, že aby pohled mohl vytvořit, musí mít právo SELECT na všechny zdrojové tabulky pohledu. U ostatních práv (INSERT, UPDATE a DELETE) obdržíte právo pouze v případě, že stejné právo máte na všechny zdrojové tabulky pohledu. Jak již bylo řečeno, jednotlivé databázové systémy mohou nabízet další práva k databázovým objektům. Například Oracle nabízí k tabulkám právo ALTER a INDEX. Jejich smysl je zřejmý z názvů těchto práv. Pro procedury a funkce se používají práva EXECUTE a DEBUG. 1.4 Pohledy Dalším klíčovým prvkem při řízení přístupu uživatelů k datům jsou pohledy. Správnou definicí pohledů a přiřazením práv uživatelů k pohledům a nikoli k jejich zdrojovým tabulkám můžeme omezit přístup uživatele pouze k vybraným sloupcům a řádkům. Pohledy tedy nabízí velmi přesnou kontrolu nad tím, co může vidět konkrétní uživatel. Při bližším přemýšlení je možné dokonce filtrovat zdrojová data na základě identity uživatele, neboli různí uživatelé mohou vidět různý obsah pohledu. IDAS2/2 Zabezpečení a ochrana dat 4

Kromě objektových práv SELECT, INSERT, UPDATE a DELETE nabízí pohledy ještě další omezení pro aktualizace dat. Kromě varianty READ ONLY pohledů jde o to, že pomocí klauzule WITH CHECK OPTION mohu vyžadovat, aby aktualizované a vkládané řádky splnily určitou podmínku. Bližší informace o pohledech je možné najít v jedné z předešlých lekcí. 1.5 Přidělování práv Pro přidělování práv slouží příkaz GRANT. Obecnou syntaxi příkazu GRANT nad databázovými objekty můžeme zapsat takto: GRANT <seznam_práv> ON <databázový_objekt> TO <identifikatory_uzivatelů> [WITH GRANT OPTION]; Příklad GRANT SELECT, INSERT ON PRODUKTY TO JNOVAK; GRANT UPDATE(NAZEV, DODAVATEL_ID) ON PRODUKTY TO KSVOBODA; První příkaz slouží k předání práv SELECT a INSERT tabulky PRODUKTY uživateli JNOVAK, druhý příklad předává práva pro aktualizaci sloupců NAZEV a DODAVATEL_ID uživateli KSVOBODA. Klauzule WITH GRANT OPTION umožňuje předat uživateli také právo přidělovat dalším uživatelům ta práva, která sám k danému databázovému objektu má přidělena. Pokud chceme určitá práva předat všem uživatelům, uvedeme namísto identifikátoru uživatele klíčové slovo PUBLIC. Příklad GRANT SELECT ON DODAVATELE TO PUBLIC; IDAS2/2 Zabezpečení a ochrana dat 5

1.6 Odebírání práv Pro odebírání již přidělených práv slouží příkaz REVOKE. Obecná syntaxe příkazu REVOKE nad databázovými objekty je velice podobná příkazu GRANT a můžeme ji zapsat takto: REVOKE <seznam_práv> ON <databázový_objekt> FROM <identifikatory_uzivatelů>; Příklad pro odebrání dříve přiděleného práva uživateli JNOVAK: REVOKE INSERT ON FROM JNOVAK; PRODUKTY Příklad pro odebrání všech práv k tabulce DODAVATELE všem uživatelům: REVOKE ALL PRIVILEGES ON DODAVATELE FROM PUBLIC; 1.7 Systémová oprávnění V předchozích kapitolách jsme hovořili o objektových oprávněních. Kromě objektových oprávnění existují ještě systémová oprávnění, která definují činnosti, které daný uživatel může v databázi dělat. Databázový administrátor například musí mít tato systémová oprávnění vytváření a rušení uživatelů, přidělování systémových oprávnění těmto uživatelům, odstraňování tabulek v libovolných schématech a podobně. Například v databázích Oracle jsou desítky systémových oprávnění, která je možné uživatelům přidělovat. Systémová oprávnění přidělujeme obdobně jako oprávnění k databázovým objektům pomocí příkazu GRANT a odebíráme pomocí příkazu REVOKE. GRANT <seznam_oprávnění> TO <identifikatory_uzivatelů> [WITH GRANT OPTION]; Příklad GRANT CREATE TABLE, CREATE SEQUENCE, CREATE VIEW TO JNOVAK, KSVOBODA; REVOKE CREATE SEQUENCE FROM KSVOBODA; IDAS2/2 Zabezpečení a ochrana dat 6

1.8 Role V mnoha případech potřebujeme více uživatelům poskytnout stejná objektová, případně i systémová práva. Role umožňují sdružovat uživatele do skupin. Mezi uživateli a rolemi je vztah M:N, tedy jeden uživatel může mít více rolí a jedna role může být přiřazena více uživatelům. Příklad CREATE ROLE REFERENT; GRANT CREATE TABLE, CREATE VIEW TO REFERENT; GRANT SELECT ON DODAVATELE TO REFERENT; GRANT SELECT ON PRODUKTY TO REFERENT; GRANT REFERENT TO AMALA, BSTASTNA; V databázi Oracle jsou vytvořeny implicitně role CONNECT pro připojení k databázi a RESOURCE pro vytváření základních databázových objektů. Každý uživatel, který se může k databázi připojit, musí mít minimálně roli CONNECT. Tyto role je třeba po vytvoření nového uživatele tomuto uživateli přiřadit. 1.9 Schéma Schéma je množina databázových objektů, které spolu souvisejí. Databázovými objekty mohou být tabulky, pohledy, indexy, clustery, sekvence, synonyma, uložené procedury, uložené triggery, databázové linky, snapshoty (používané pro repliky vzdálených tabulek). Při vytvoření uživatele správcem se implicitně vytvoří databázové schéma uživatele v definovaném tabulkovém prostoru. Ve svém databázovém schématu vlastní uživatel všechny objekty. IDAS2/2 Zabezpečení a ochrana dat 7

2. Bezpečnostní mechanismy Oracle Databáze Oracle je robustní architektura a používaná bankami, pojišťovnami, velkými společnostmi a jinými významnými klienty. Proto je problematika bezpečnosti dat jedním ze základních cílů vývojářů a vznikají různé nástroje na usnadnění správy bezpečnostních pravidel, které rozšiřují vlastnosti implementované dle standardu SQL. Z uplatněných a principů můžeme uvést například: Zajištění principu minimálních nutných práv Mechanismus řízení přístupu pomocí systémových i objektových práv Řízení přístupu na úrovni záznamů Transparentní šifrování dat Šifrování záloh Šifrování komunikace Detailní audit operací Centrální správa uživatelů - spolupráce s LDAP Bezpečnostní certifikace V následujících odstavcích budou krátce charakterizovány některé mechanismy, které slouží ke zvýšení bezpečnosti uložených dat a usnadnění řízení přístupu. 2.1 Mechanismus Secure Application Role Uživatel může určité operace provádět, jen pokud přistupuje z dané aplikace a nikoliv, pokud k přístupu použije třeba databázovou konzoli. Tyto role jsou pevně svázány s určitým databázovým balíčkem (knihovnou uložených procedur) a mohou být aktivovány pouze z tohoto balíčku. 2.2 Mechanismus Virtual Private Database (VPD) VPD zajišťuje automatické a transparentní doplnění jakéhokoliv dotazu o bezpečnostní podmínku. Ta pak omezuje data, se kterými uživatel může pracovat. I když tedy dva uživatelé zadají stejný dotaz (například výpis celé tabulky), může každý získat jiná data. Např. uživatelé z různých oddělení mohou pracovat pouze se svými daty, i když jsou data celého podniku ve stejné tabulce. IDAS2/2 Zabezpečení a ochrana dat 8

2.3 Mechanismus Oracle Label Security Option Každý záznam je označen štítkem určujícím jeho citlivost. Každý uživatel má na druhé straně definovány bezpečnostní úrovně, se kterými může pracovat. Databáze Oracle pak zajistí, že uživatel může pracovat pouze s těmi daty, jejichž citlivost odpovídá jeho úrovni. 2.4 Mechanismus Oracle Advanced Security Option (ASO) V rámci ASO je možné využít pokročilé metody ověřování, jako jsou třeba klientské SSL certifikáty, nebo využití různých autentizačních služeb postavených na standardech Kerberos či RADIUS. Pomocí těchto služeb lze například zajistit ověřování pomocí různých elektronických karet nebo biometrických údajů. 2.5 Mechanismus Proxy Authentication Problém s identifikací uživatelů však může nastat u webových aplikací, kdy se aplikace do databáze přihlašuje stále pod stejným jménem a heslem. Databáze totiž neví, kdo s ním skutečně pracuje, což blokuje řadu jejích bezpečnostních funkcí. Mechanismus Proxy Authentication aplikaci sice umožní přistupovat do databáze stále pod stejným jménem a heslem (a ušetřit tak čas na vytvoření spojení), avšak zároveň dovoluje předat informace o skutečném uživateli, který s aplikací pracuje. Databázový systém pak tuto informaci využije při řízení přístupu i auditování. 2.6 Mechanismus Advanced Security Option pro šifrování Šifrování přenosu dat má za cíl zabránit odposlechnutí či dokonce pozměnění komunikace. Šifrování komunikace je přitom transparentní pro samotnou aplikaci neznamená nutnost zásahu do kódu aplikace. Kromě SSL existují i další techniky. Nástroje pro výběrové programové šifrování a dešifrování dat pomocí standardních algoritmů (DES, 3DES, AES a MD5) umožňují zašifrovat obzvláště citlivá data (rodná čísla, čísla kreditních karet). Možnost šifrování dat v tabulkách, které je transparentní z pohledu aplikace, nastavuje se deklarativně při definici tabulky. Tento mechanismus chrání před unikem dat při přístupu obcházejícím databázový server např. kopírováním datových souborů, nebo zcizením záložních médií. IDAS2/2 Zabezpečení a ochrana dat 9

2.7 Mechanismus Fine Grained Auditing (FGA) Nedílnou součástí bezpečnostních mechanismů je i možnost auditu operací prováděných jednotlivými uživateli. Základní auditovací mechanismy většinou vytvářejí velký objem záznamů nepřehledné, těžce zpracovatelné proto Oracle vyvinul FGA. FGA umožňuje detailně určit, jakých dat se má operace týkat, specifikací sloupce tabulky a podmínky. Pouze pokud se v rámci uživatelem prováděné operace začne pracovat se záznamem splňujícím podmínku a je vrácena informace z definovaného sloupce, je tato operace zapsána do auditovacího logu. Při takové události je možné spustit i uloženou proceduru, která zajistí patřičnou reakci například zašle SMS správci databáze. 2.8 Mechanismus Oracle Internet Directory (OID) Standardní správa uživatelů vyžaduje aktualizace uživatelů v mnoha systémech při odchodech či nástupech zaměstnanců do zaměstnání a změnách funkcí zaměstnanců. Častým jevem je neaktuálnost uživatelských účtů a nezrušení jejich účtů v systémech. Řešením je centrální správa uživatelů na jednom místě, ze kterého si jednotlivé aplikace přebírají data pomocí standardu LDAP. V prostředí Oracle funkci tohoto centrálního prvku plní OID. Centrální správu uživatelů v OID lze samozřejmě využít i pro správu databázových uživatelů a rolí. Tato funkcionalita je označena jako Enterprise User Security. Databáze může přebírat nejen seznam uživatelů, ale může z OID získat i seznam rolí přiřazených uživatelům. 3. Správa uživatelů V mnoha společnostech se stále setkáváme se správou uživatelů individuálně v jednotlivých aplikacích. Tento tradiční přístup však kromě vysokých nároků na správu, kdy je nezbytné udržovat uživatelské účty a role v několika systémech, hrozí neaktuálností, nekonzistencí, pomalými reakcemi na změny pracovního zařazení a potřeb zaměstnanců, přístupová oprávnění jsou špatně kontrolovatelná a hlavně hrozí ponechání přístupu neoprávněným osobám. Současným trendem je proto centrální evidence uživatelů ideálně všech informačních systémů společnosti na jediném místě, například formou LDAP služeb. Takové řešení je snáze spravovatelné, přehlednější, jednoduše zařaditelné do procesu přijímání a propouštění pracovníků, což přináší i rychlejší reakce na požadované změny. IDAS2/2 Zabezpečení a ochrana dat 10

Pojmy k zapamatování Příkazy a funkce: CREATE ROLE GRANT, REVOKE, CREATE/ALTER/DROP E/ALTER/DROP USER, Problém: zabezpečení, práva, role, přidělování a odejímání oprávnění, využití pohledů pro zabezpečení, správa uživatelů, bezpečnostní mechanismy Oracle databáze Shrnutí V této lekci jste se seznámili se zabezpečením a ochranou dat v databázích. Bezpečnost dat v SQL databázích je založena na právech, objektových a systémových oprávněních. Pro dosažení zabezpečení je možno využít projekce a restrikce dat zajišťované pohledy. Pro přidělování práv slouží příkaz GRANT. Příkaz REVOKE slouží pro odebírání dříve přidělených práv. Při přidělování práv je vhodné se řídit principem minimálních nutných objektových i systémových práv, která uživatel potřebuje pro svoji práci. Správu uživatelů ve společnosti je vhodné realizovat centrálně. Otázky na procvičení 1. K čemu slouží příkazy GRANT a REVOKE? 2. Která práva se pojí s databázovým objektem tabulka? 3. Vyjmenujte příklady systémových práv? 4. K čemu slouží role? 5. K čemu slouží klíčové slovo PUBLIC? Odkazy a další studijní prameny http://www.oracle.com/technetwork/database/enterpriseedition/documentation (dokumentace k databázové platformě Oracle) http://www.penguin.cz/noviny/?id=chip/index (seriál Databáze standardu SQL z časopisu CHIP) http://www.techonthenet.com/oracle/grant_revoke.php (Oracle/PLSQL: Grant/Revoke příkazy) IDAS2/2 Zabezpečení a ochrana dat 11

Odkazy a další studijní prameny GROFF, J.R., WEINBERG, P.N. SQL - kompletní průvodce.. Praha: Computer Press, 2005. ISBN 80-251-0369-2. LACKO, L. Oracle Správa, programování a použití databázového systému. Praha: Computer Press, 2007. ISBN 978-80-251-1490-2. STEPHENS, K.R., PLEW, R.R. Naučte se SQL za 21 dní. Praha: Computer Press, 2004. ISBN 80-7226-870-8. IDAS2/2 Zabezpečení a ochrana dat 12

3. blok Transakce Studijní cíl Tento blok je věnován základům řízení transakcí, které jsou nezbytné pro zachování konzistentního stavu databáze při aktualizacích dat v tabulkách. Doba nutná k nastudování 2-3 hodiny Průvodce studiem Při studiu tohoto bloku se předpokládá, že čtenář je obeznámen s DML příkazy (SELECT, INSERT, UPDATE, DELETE) jazyka SQL. 1. Zpracování transakcí Pro pochopení pojmu transakce se vysloveně nabízí příklad z bankovního světa, tedy finanční transakce. Představte si, že chcete převést částku na půlroční pobyt na vysokoškolských kolejích na účet správy kolejí. Podáte příkaz k úhradě z vašeho účtu a předpokládáte, že částka bude následující pracovní den po jejím stržení z vašeho účtu připsána na účet příjemce. Nejprve je tedy částka odepsána z účtu plátce a následně připsána na účet příjemce. Co se ale stane v případech, kdy: příjemce svůj účet zrušil, omylem jste uvedli neexistující číslo účtu, na účtu plátce není dostatek finančních prostředků, na účtu plátce je exekuce. V takovém případě se buď částka vůbec neodepíše, nebo se částka odepíše z účtu plátce, ale není možné ji připsat na účet příjemce. Obdobná situace nastane, když při převodu dojde k selhání techniky. Je tedy nezbytné takovou transakci stornovat a připsat odepsanou částku zpět na účet plátce. Transakce tedy buď proběhne jako celek (v našem příkladu se peníze pomocí několika elementárních operací převedou z účtu plátce na účet příjemce) nebo se jako celek odvolá. V systémech řízení báze dat transakce představují skupinu operací, které je nezbytné úspěšně provést jako celek ve správném logickém pořadí jednotlivých elementárních operací nebo neprovést vůbec. V případě neprovedení musí výsledný IDAS2/3 Transakce 1

stav databáze odpovídat stavu před provedením první operace zařazené do transakce. Hovoříme zde o tom, že výchozí a závěrečných stav databáze před a po provedení či odvolání transakce jsou konzistentními stavy. Celý princip transakce je důležitý pro programy, které aktualizují databázi, neboť zajišťuje integritu dat. Databáze je odpovědná za dodržování principu vše nebo nic i v případě, kdy dojde k technickému selhání systému, například hardwarové poruše či výpadku napájení. Při zotavení z tohoto selhání systému jsou nepotvrzené transakce považovány za nedokončené a provedené změny jsou odrolovány zpět. Příkladem z databázového prostředí může být například skupina DML operací, kdy se změny musí realizovat v několika tabulkách nebo pomocí posloupnosti několika elementárních operací. Bohužel se často zapomíná na to, že dle modelu ANSI/ISO i jedna operace INSERT, UPDATE či DELETE provedená uživatelem nebo programem automaticky zahájí transakci a transakci je nezbytné některým z dále uvedených způsobů ukončit. V různých databázových systémech se mohou drobně lišit způsoby pro řízení transakcí. Po zahájení transakce je jí přiřazen dostupný návratový tabulkový prostor (undo tablespace), kam se ukládají staré hodnoty dat, které byly SQL příkazem v rámci transakce změněny a které mohou být využity pro případný ROLLBACK transakce a pro operaci konzistentního čtení, která je popsána níže v tomto dokumentu. 2. Ukončení transakcí Transakce je ukončena buď: jejím potvrzením příkazem COMMIT, vrácením zpět/odvoláním transakce příkazem ROLLBACK, uživatel řádně ukončí spojení s databázovým serverem (transakce je potvrzena automaticky), spojení uživatele se serverem se ukončí abnormálně transakce se odroluje zpět automaticky, explicitní potvrzení transakce, zadáním příkazu DDL (CREATE, DROP, RENAME, ALTER), před provedením příkazu DDL se automaticky ukončí předchozí transakce, v samostatné transakci se pak provede příkaz DDL. IDAS2/3 Transakce 2

Stav databáze před transakcí SELECT SELECT SELECT SELECT transakce UPDATE INSERT Odrolování transakce UPDATE INSERT Odrolování transakce UPDATE Selhání HW Odrolování transakce UPDATE INSERT DELETE Chyba programu ROLLBACK COMMIT Stav databáze po transakci Obrázek 1: Princip transakce v SQL. Změny provedené příkazy obsaženými v transakci jsou viditelné pro ostatní uživatele a jiná spojení (sessions) uživatele provádějícího transakci až od okamžiku potvrzení transakce. Výsledky elementárních operací v rámci rozpracované transakce je možné zjistit pouze v session, v níž transakce probíhá. Ve všech ostatních session je tedy možné vidět konzistentní stavy související s potvrzenými transakcemi. 3. Základní vlastnosti transakcí - ACID Atomicity (Atomičnost) - Atomičnost transakce znamená, že buď je provedena celá transakce, nebo žádná z databázových operací, které ji tvoří. Consistency (Konzistence) - Konzistence transakce znamená, že izolovaná transakce zachovává konzistenci databáze. Isolation (Izolace) - Izolace transakce znamená, že i při souběžném běhu transakcí SŘBD zajistí, že pro každou dvojici souběžných transakcí T i a T j se T i jeví, že T j skončila dříve, než T i zahájila provádění nebo T j zahájila provádění až poté, co T i skončila. Durability (Trvalost) - Trvalost transakce znamená, že poté, co transakce úspěšně skončí, budou mít všechny změny v databázi, které transakce provedla, trvalý charakter a to i při výpadku systému. IDAS2/3 Transakce 3

4. Odrolování na úrovni příkazu Pokud během provádění SQL příkazu nastane nějaká chyba, všechny změny provedené příkazem jsou odrolovány zpět. Toto se nazývá Statement-Level Rollback (odrolování na úrovni příkazu). Není totiž možné připustit stav, kdy by příkaz ovlivnil jen ty řádky tabulky, než nastala chyba a poté by se jeho činnost přerušila. Takový stav by byl vysoce rizikový, neboť by nebyla zajištěna konzistence dat. Příklady takových chyb: Pokus o vložení řádku s duplicitní hodnotou primárního klíče, Narušení referenční integrity, Deadlock (pokus o současnou změnu shodných dat dvěma transakcemi). Syntaktická chyba při parsování neumožní spustit provádění příkazu, proto se nejedná o odrolování na úrovni příkazu. Chyba při provádění příkazu neovlivní změny provedené předchozími příkazy v rámci dané transakce. 5. Návratové body Návratové (někdy v literatuře nazývané jako úložné ) body umožňují označit další místa mezi jednotlivými elementárními SQL příkazy, které jsou součástí transakce. Představme si situaci, kdy v rámci jednotlivých příkazů pracujeme s velkým množstvím záznamů, jejichž zpracování trvá určitou dobu. Pokud v určitý okamžik dojde k potřebě odrolovat probíhající transakci, nemusíme provést odrolování transakce až na její počátek, ale jen k danému návratovému bodu. Veškeré změny provedené transakcí po návratovém bodu jsou tedy odrolovány, ale změny před návratovým bodem jsou ponechány a je tedy možno na tento rozpracovaný stav transakce navázat. Příkazy: SAVEPOINT <bod návratu> - slouží pro označení místa (například po provedení některých operací), kam bychom se v případě potřeby mohli navrátit, slouží pro rozdělení velké transakce na menší části ROLLBACK TO <bod návratu> odrolování transakce do bodu návratu IDAS2/3 Transakce 4

Příklad: SAVEPOINT plosne_zvyseni_mzdy; UPDATE pracovnici SET mzda=mzda*1.04; SAVEPOINT navyseni_manazeri; UPDATE pracovnici SET mzda=mzda+1000 WHERE pozice LIKE manažer ; ROLLBACK TO navyseni_manazeri; Po odrolování transakce k návratovému bodu: jsou vráceny pouze změny provedené SQL příkazy po nastavení návratového bodu, všechny návratové body nastavené po daném návratovém bodu jsou ztraceny, Oracle uvolní všechny uzamčené tabulky a řádky, které byly uzamčeny po nastavení návratového bodu (ty nastavené dříve zůstanou zachovány), Transakce zůstává aktivní a může dále pokračovat. 6. Konzistentní čtení Představme si situaci, kdy probíhá SELECT, jehož vyhodnocení trvá několik hodin (může jít například o měsíční uzávěrku) a mezitím někteří uživatelé provedou určité změny dat a tyto potvrdí příkazem COMMIT. To znamená, že tyto jimi provedené změny jsou přístupné a viditelné i dalším uživatelům. Do SQL dotazu, který byl zahájen před potvrzením změn provedených jinými uživateli, však tyto změny nebudou zahrnuty. Výsledek tedy bude takový, že: ve výsledku dříve spuštěného dotazu nebudou potvrzené změny během doby zpracování dotazu zahrnuty, ostatní uživatelé budou normálně pracovat s aktuální verzí dat (tedy po potvrzení změn). Obrázek ukazuje příklad pro čtení dat z tabulky. Příkaz SELECT je spuštěn v okamžiku SCN (System Change Number) = 10023. Pokud se při čtení narazí na bloky dat změněné po tomto čase (SCN je vyšší, neboť se s každou potvrzenou transakcí zvyšuje o 1), budou pro výsledek dotazu vstupní data rekonstruována s využitím informací uložených v návratovém tabulkovém prostoru. Tím je zajištěna konzistence vstupních dat pro zpracování dotazu a platnost výsledku. IDAS2/3 Transakce 5

Obrázek 2: Princip konzistentního čtení. Zdroj: neznámý. Oracle vždy zajišťuje konzistenci pro čtení na úrovni dotazu. Ani potvrzení jiné transakce příkazem COMMIT během zpracování dotazu neovlivní jeho výsledek vždy je důležitý stav při zahájení dotazu. Tato konzistence je zajištěna automaticky bez účasti uživatele. Vztahuje se i na vnořené dotazy. Toto ovšem také znamená, že daný dotaz nevidí změny vyvolané jím samotným, ale vždy pracuje s daty ve stavu při jeho spuštění! Poznámka: Problém by mohl nastat, pokud by příkaz SELECT spouštěl funkci, která by opět obsahovala jiný SELECT (ta by ovšem měla jiné SCN začátku) a uvažovala by již změněná data. 7. Nezapomínejte na potvrzování transakcí Doporučuje se, aby transakce obsahovala jen tolik operací, které nezbytně potřebuje. Pokud nedochází k potvrzování transakcí, výrazně se zpomaluje práce databázového serveru, neboť musí být do transakčního logu odkládáno spousta změn a tyto se mohou z transakčního žurnálu odstranit až po dokončení (potvrzení či odrolování) transakce. Také je dobré si uvědomit, že například pro smazání dat z databáze o velikosti 10 GB potřebujeme 3-4 GB pro uložení transakčního žurnálu. Databázový server se totiž musí pojistit pro případ, kdyby se něco nepovedlo. Paradoxně to může vést k hlášce IDAS2/3 Transakce 6

Data není možné vymazat, protože na disku není dostatek volného prostoru. Řešením by pak bylo odmazávání dat po menších blocích s průběžným potvrzováním příkazem COMMIT. Druhou variantou by mohlo být použití příkazu TRUNCATE. Zatímco DELETE vymaže řádky po jednom a do transakčního logu se zaznamená každé jednotlivé vymazání samostatně, TRUNCATE TABLE vymaže data dealokací (uvolněním) datových stránek použitých pro tabulku a do transakčního logu jsou zaznamenány jen tyto dealokace. Některé databáze podporují volbu AUTOCOMMIT. v příkazech: Tuto volbu lze používat SET AUTOCOMMIT ON; SET AUTOCOMMIT OFF; -- potvrzuje všechny příkazy jako transakce -- příkazy nejsou implicitně potvrzovány, nutno používat příkazy pro řízení transakcí 8. Transakce a víceuživatelské zpracování Pokud souběžně přistupuje do databáze více uživatelů, databáze musí zajistit, aby se akce uživatele nemíchaly s akcemi jiného uživatele. Ideálním případem by bylo, kdyby k ní měl každý uživatel exklusivní přístup bez starání se o akce jiných uživatelů. Odborně se tato problematika nazývá izolací uživatelů a model transakcí SQL definuje několik izolačních úrovní. Je nutné si uvědomit, že dochází k ovlivňování probíhajících transakcí potvrzenými změnami dokončených transakcí. Míra ovlivňování je dána izolační úrovní, v níž transakce pracuje. V některých případech může konflikt s jinou transakcí způsobit zrušení transakce, i když v ní nebyla chyba. Aplikační program musí být připraven tuto situaci obsloužit. V následujících odstavcích se podívejme na rizika při zpracování souběžných transakcí. Obecně mohou nastat tyto 4 problémy: problém ztracené aktualizace, problém nepotvrzených dat, problém neopakovatelného čtení, problém přízračných dat. 8.1. Problém ztracené aktualizace Dva uživatelé se v současně rozpracovaných transakcích pokouší aktualizovat stejný záznam (záznamy). Pokud již jedna transakce tato aktualizovaná data potvrdí (příkazem COMMIT), došlo by při potvrzení druhé transakce ke ztrátě dat aktualizovaných předchozí transakcí. IDAS2/3 Transakce 7

Pokud však aspoň jedna z těchto transakcí odrolovala změny příkazem ROLLBACK, k problému by nedošlo. Příklad: Na obrázku níže hrozí uváznutí. Obě transakce akce se snaží aktualizovat data dříve aktualizovaná jinou současně probíhající transakcí. Transakce 1 Transakce 2 UPDATE PRODUKTY SET NAZEV= V1234 WHERE ID=11; UPDATE PRODUKTY SET NAZEV= M17x WHERE ID=22; UPDATE PRODUKTY SET NAZEV= M17X Base WHERE ID=22; čas UPDATE PRODUKTY SET NAZEV= Vostro 1234 WHERE ID=11; CHYBA: ORA-00060: Deadlock detected while waiting for resource. Obrázek 3: Problém ztracené aktualizace. Zdroj: neznámý. Databáze automaticky detekuje uvíznutí (deadlocky) tak, že periodicky každých například 5 sekund kontroluje zámky, které jsou v držení více transakcemi. Zjistí-li uvíznutí, řeší je tím, že odroluje zpět jednu z příkazů, který deadlock způsobil. Transakce dostává zprávu, že proběhl rollback na úrovni příkazu. Transakce se poté může odrolovat zpět explicitně nebo se pokusí odrolovaný příkaz znovu provést. 8.2. Problém nepotvrzených dat (Dirty read) Transakce může číst data, která byla zapsána jinou transakcí, ale ještě nedošlo k jejich potvrzení. V tabulce mohou být v aktuální chvíli jakákoliv data. Není tedy zaručena úplnost dat. V databázích Oracle je Dirty read nemožné. Příklad: Transakce 1 provede dvakrát stejný příkaz SELECT. Mezi těmito dvěma příkazy ale Transakce 2 změní řádek zobrazovaný Transakcí 1 bez potvrzení transakce. Transakce 1 při druhém SELECTu přečte nepotvrzená data a poté co bude Transakce 2 odrolována zpět, tak mohou být tato podruhé zobrazená data špatná. IDAS2/3 Transakce 8

čas Transakce 1 Transakce 2 SELECT * FROM PRODUKTY WHERE ID=123; UPDATE PRODUKTY SET NAZEV= Vostro1320 WHERE ID=123; SELECT * FROM PRODUKTY WHERE ID=123; čas ROLLBACK; Obrázek 4: Problém nepotvrzených dat. 8.3. Problém neopakovatelného atelného čtení (Nonrepeatable read / Fuzzy read) Transakce čte opakovaně stejné hodnoty, ale dostává různé výsledky. Ty jsou ovlivněny potvrzenými změnami v současně běžících jiných transakcích. Příklad: Transakce 1 se skládá ze dvou příkazů SELECT. V mezičase mezi dvěma příkazy Transakce 2 změní řádek a příkazem COMMIT se ukončí. Transakce 1 při obou vykonávaných příkazech čte potvrzená data, ale i přesto se tato data při běhu jedné transakce liší. Nezmění se počet řádků na výstupu, ale změní se jejich obsah. Nastalo tedy tzv. Nonrepeatable read neboli neopakovatelné čtení. Transakce 1 Transakce 2 SELECT * FROM PRODUKTY WHERE ID=123; UPDATE PRODUKTY SET NAZEV= Inspiron 15R WHERE ID=123; COMMIT; SELECT * FROM PRODUKTY WHERE ID=123; Obrázek 5: Problém neopakovatelného čtení. IDAS2/3 Transakce 9

čas 8.4. Problém přízračných dat (Phantom read) Když uživatel provede čtení v čase t 1 a v čase t 2 provede stejný příkaz, do databáze mohou být přidány v mezidobí další řádky jinou současně běžící potvrzenou transakcí a ty mohou ovlivnit výsledek. Od problému neopakovatelného čtení se problém přízračných dat liší v tom, že data, která uživatel právě čte, nejsou změněna, ale ve výsledku v čase t 2 je více dat. Příklad: Transakce 1 je opět složena příkazů SELECT. Současně s Transakcí 1 nyní Transakce 2 provede vložení řádku a následné potvrzení transakce. Oba dva příkazy SELECT v Transakci 1 budou vracet na výstupu potvrzená data, ale počet řádků se od sebe bude lišit. Objeví se tzv. zjevení přízračná data. Transakce 1 Transakce 2 SELECT * FROM PRODUKTY WHERE ID > 100; INSERT INTO PRODUKTY (ID, NAZEV) VALUES (131, XPS L702x ); COMMIT; SELECT * FROM PRODUKTY WHERE ID=123; Obrázek 6: Problém přízračných dat. 8.5. Izolační úrovně transakcí Standard SQL2 definuje příkaz SET TRANSACTION <izolační úroveň>, který slouží k nastavení izolačních úrovní transakcí. Čím vyšší izolační úroveň, tím vyšší jsou systémové požadavky na databázový server a tím více hrozí vzájemné blokování transakcí. Následující tabulka popisuje, které problémy se mohou vyskytnout v jednotlivých izolačních úrovních. IDAS2/3 Transakce 10

Izolační úroveň READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE Ztracená aktualizace NE NE NE NE Nepotvrzená data Neopakovatelné čtení Přízračná data ANO ANO ANO NE ANO ANO NE NE ANO NE NE NE Tabulka 1 - Izolační úrovně transakcí. Pojmy k zapamatování Příkazy a funkce: COMMIT, ROLLBACK, SET SAVEPOINT, ROLLBACK TO SAVEPOINT Problém: transakce, ACID, explicitní a implicitní potvrzení transakce, explicitní a implicitní odrolování transakce, problém ztracené aktualizace, problém nepotvrzených dat, problém nekonzistentních dat, problém přízračných dat Shrnutí V této lekci jste se seznámili s řízením transakcí jako se základním principem pro zajištění konzistence dat. Transakce jsou logickou jednotkou práce v databázi, která se skládá z několika elementárních operací příkazů SQL. Příkaz COMMIT potvrzuje provedenou transakci a činí změny v databázi trvalými. Příkaz ROLLBACK odroluje změny doposud provedené transakcí do výchozího stavu před započetím transakce. V případě selhání systému v databázi zůstanou po zotavení pouze změny, které byly v čase selhání potvrzeny. Transakce umožňují souběžný přístup více uživatelů či aplikací k databázi. Je však nutné si uvědomit, že i tak dochází k ovlivňování transakcí potvrzenými změnami souběžně probíhajících transakcí. V některých případech může konflikt s jinou transakcí způsobit zrušení transakce, i když v ní nebyla chyba. IDAS2/3 Transakce 11

Otázky na procvičení 1. K čemu slouží příkazy COMMIT a ROLLBACK? 2. Co se stane s rozpracovanou transakcí při ukončení spojení s databázovým serverem? 3. Jaké riziko představuje práce bez používání příkazů pro řízení transakcí? 4. Popište problémy, jak se mohou ovlivňovat transakce při souběžné práci více uživatelů? 5. Co je to deadlock a kdy k němu může dojít? Odkazy a další studijní prameny http://www.root.cz/clanky/transakce-a-izolace-transakci-v-databazich/ (Transakce a izolace transakcí v databázích) http://www.oracle.com/technetwork/database/enterpriseedition/documentation (dokumentace k databázové platformě Oracle) http://www.penguin.cz/noviny/?id=chip/index (seriál Databáze standardu SQL z časopisu CHIP) Odkazy a další studijní prameny GROFF, J.R., WEINBERG, P.N. SQL - kompletní průvodce.. Praha: Computer Press, 2005. ISBN 80-251-0369-2. STEPHENS, K.R., PLEW, R.R. Naučte se SQL za 21 dní. Praha: Computer Press, 2004. ISBN 80-7226-870-8. LACKO, L. Oracle Správa, programování a použití databázového systému. Praha: Computer Press, 2007. ISBN 978-80-251-1490-2. IDAS2/3 Transakce 12

4. lekce Přístup k databázi z vyššího programovacího jazyka Studijní cíl Tento blok popisuje základní principy přístupu k databázi z vyššího programovacího jazyka. Doba nutná k nastudování 2-3 hodiny Průvodce studiem Při studiu tohoto bloku se předpokládá, že čtenář je obeznámen se základy SQL a běžnými pojmy z oblasti výpočetní techniky a její historie. 1. Úvod K přístupu k databázi je možné využít níže popsaná rozhraní. Výběr závisí na potřebách konkrétní aplikace - požadavcích na výkon, použité technologii, databázové platformě, dostupnosti ovladačů i konkrétní implementaci. Na nejnižší úrovni lze pro komunikaci se systémem pro řízení báze dat (SŘBD) používat jeho nativní rozhraní. Je specifické pro každou databázovou platformu a připojuje se v podobě dynamických knihoven. Využívá se výjimečně v nízkoúrovňových systémech extrémně náročných na rychlost. 2. Rozhraní pro přístup k databázi Efektivnější je využití některého níže popsaného databázového rozhraní.. Ta lze v základu rozdělit do dvou linií: a) obecné b) nativní (přímé) Obecná rozhraní jsou nezávislá na použité databázové platformě. Poskytují omezenou množinu služeb. Umožňují relativně jednoduchou změnu databázové platformy i současné využití více typů SŘBD v rámci jedné aplikace. Příkladem mohou být ODBC (JDBC) ovladače. Jiří Lebduška, IDAS2/4 Přístup k databázi z vyššího programovacího jazyka 1

Přímá rozhraní jsou závislá na konkrétní databázové platformě (někdy i verzi) a mnohdy také klientské straně (vývojovém nástroji). Výhodou je možnost využití všech dostupných funkcí databázového stroje a jeho výkonu. Příkladem může být OCI (Oracle Call Interface) ovladač. 2.1 ODBC (Open Database Connectivity) Představuje aplikační rozhraní pro přístup k datům v relační databázi nezávisle na databázové platformě (Oracle, Microsoft SQL Server, Microsoft Access, DB2, Sybase, MySQL, PostgreSQL atd.) i operačním systému (Windows, Linux). 2.2 ODBC Driver Manager (Object Linking and Embedding Databases) Správce ovladačů (ODBC DM) tvoří mezivrstvu mezi aplikací a ODBC ovladačem. Zajišťuje načítání potřebných knihoven ODBC ovladače. Umožňuje současnou inicializaci více ovladačů a tedy i jejich přepínání v rámci jedné aplikace. Je tedy možné přistupovat současně k více zdrojům dat. 2.3 OCI (Oracle Call Interface) Rozhraní OCI určené pro platformu Oracle nabízí širokou paletu funkcí pro komunikaci s databázovým serverem a zároveň poskytuje vyšší výkon, než např. ODBC rozhraní. Rozhraní OCI obsahuje (kromě základních funkcí pro práci s db) podporu pro volání PL/SQL, transakce, načítání a ukládání objektu typu LOB/CLOB, funkce pro správu. 3. Připojení k databázi V následujících ukázkách kódu bude pro jednoduchost jako příklad použito jazyka PHP, nicméně volání db. v jiných jazycích (i použitá množina funkcí) je analogické. Pro práci s databází je nejprve nutné navázat spojení a provést autorizaci i autentizaci uživatele. 3.1 Prostřednictvím ODBC Pro vytvoření spojení se používá funkce odbc_connect.. Její deklarace vypadá následovně: $database_resource = odbc_connect($dsn, $user, $password); Parametry: $dsn adresa databázového zdroje, např. "localhost" Jiří Lebduška, IDAS2/4 Přístup k databázi z vyššího programovacího jazyka 2