16.10.2012 Vítězslav Čížek, Roman Kučera.  Advanced Database Systems by Zaniolo, Ceri, Faloutsos, Snodgrass, Subrahmanian and Zicari Morgan Kaufmann,

Prezentace na téma: "16.10.2012 Vítězslav Čížek, Roman Kučera.  Advanced Database Systems by Zaniolo, Ceri, Faloutsos, Snodgrass, Subrahmanian and Zicari Morgan Kaufmann,"— Transkript prezentace:

1 16.10.2012 Vítězslav Čížek, Roman Kučera

2  Advanced Database Systems by Zaniolo, Ceri, Faloutsos, Snodgrass, Subrahmanian and Zicari Morgan Kaufmann, 1997

3  Co jsou aktivní databáze?  Syntax a sémantika  Příklady použití  Shrnutí

4  Aktivní databáze monitoruje schéma a operace které ho mění  Automaticky provádí akce při splnění nějakých podmínek  Aktivně spolupracuje s aplikacemi ◦ aplikace nepřímo spustí nějaké pravidlo  Architektura řízená událostmi

5  Přesouvá úkoly z aplikace přímo na databázi  Vyjmutí znalosti z aplikací a převedení na pravidla db  Znalosti zakódovány ve schématu  Aplikace nemusí vědět o dalším zpracování  Sdílená všemi aplikacemi protože je přímo v db  Při změně stačí upravit schéma db místo modifikace všech aplikací

6  kontrola vstupních dat (constraints)  upozorňování na situace (alerts)  správa odvozených dat  správa zdrojů (resource management)  Správa znalostí (knowledge management)  autorizace

7  interní ◦ Kontrola integrity ◦ Správa odvozených dat ◦ Správa replikací  Rozšířené ◦ Workflow management ◦ Správa verzí ◦ Sledování a zaznamenávání událostí  business rules

8  Co jsou aktivní databáze?  Syntax a sémantika  Příklady použití  Shrnutí

9  Lehký úvod do vlastností aktivních databází  4 konkrétní implementace ◦ Výzkumné prototypy Starburst a Chimera ◦ Prakticky využívané Oracle a DB2  Shrnutí společných vlastností a rozdílů

10  Aktivní pravidlo = trigger, tedy aktivní databáze je taková, která podporuje triggery  Ve standardu SQL jsou triggery až od SQL:1999, zatímco popisované implementace vznikaly již od začátku 90. let ◦ Z toho plynou různé odchylky  Základem aktivních databází je princip Událost-Podmínka-Akce (Event-Condition- Action, či jen ECA)

11  Událost v aktivní databázi znamená změnu stavu databáze  Typickým příkladem jsou události INSERT, UPDATE, nebo DELETE, které nastávají při provedení stejnojmenného SQL příkazu. ◦ Některé systémy mohou mít i další události, spouštěné zvenčí další aplikací, nebo vázané na určitý čas. Tyto typy událostí nebudeme v prezentaci uvažovat.

12  Podmínka je databázový predikát, nebo dotaz.  Výsledkem podmínky je vždy pravdivostní hodnota, pokud je podmínkou databázový dotaz, pak prázdná odpověď znamená hodnotu FALSE, neprázdná TRUE.  Pokud je podmínka splněna, dojde k vyhodnocení akce, jinak se neděje nic.

13  Akcí může být libovolná manipulace s daty, ať už těmi, které způsobily událost vedoucí k této akci, nebo s úplně jinými.  Akce může obsahovat komplexní sadu dotazů včetně transakčních příkazů jako například ROLLBACK.

14  Starburst je prototyp rozšiřitelné relační databáze vyvíjený v IBM Almaden Research Center v letech 1984-1992.  Aktivní pravidla jsou jedním z rozšíření tohoto databázového systému.

15 CREATE RULE ON WHEN [ IF ] THEN [ PRECEDES ] [ FOLLOWS ] ::= INSERTED | DELETED | UPDATED [ ( ) ]

16  Pravidla jsou vyhodnocována až po potvrzení transakce (COMMIT WORK), nebo po explicitním vyžádání (PROCESS RULES). ◦ Tzv. odložené (deffered) zpracování.  Každé pravidlo je buď aktivováno (triggered), pokud nastala jeho událost, nebo nikoliv. ◦ Nikdy není pravidlo aktivované vícekrát najednou. ◦ Pro určení, zda událost nastala, se bere končený výsledek transakce. Pokud byl proveden na stejném řádku UPDATE i DELETE, počítá se pouze jako smazání.

17  Dokud existují aktivovaná pravidla ◦ Vyber aktivované pravidlo s nejvyšší prioritou a označ ho za neaktivované.  Definiční jazyk umožňuje definovat částečné uspořádání, systém ho ovšem doplní na úplné uspořádání podle času vzniku pravidla. ◦ Vyhodnoť jeho podmínku. ◦ Pokud je podmínka splněna, spusť akci tohoto pravidla.  Akce může aktivovat další pravidla, včetně toho právě prováděného.

18  V podmínce i akci je možné využívat pomocné přechodové tabulky INSERTED, DELETED, OLD-UPDATED a NEW-UPDATED obsahující patřičné řádky ovlivněné událostí, která pravidlo aktivovala.

19 DEACTIVATE RULE ON ; ACTIVATE RULE ON ; DROP RULE ON ; CREATE RULESET ; ALTER RULESET [ ADDRULES ] [ DELRULES ]; DROP RULESET ; PROCESS RULESET ; PROCESS RULE ;

20  Pokud je průměrný plat zaměstnanců větší než 50000, sníží se plat všech zaměstnanců o 10%. CREATE RULE KontrolaPlatu ON Zamestnanci WHEN INSERTED, DELETED, UPDATED (Plat) IF (SELECT AVG(Plat) FROM Zamestnanci) > 50000 THEN UPDATE Zamestnanci SET Plat =.9*Plat

21  Implementace během začátku 90. let podle předběžného dokumentu pro SQL3 (1999) standard.  Pravidla jsou spouštěna okamžitě.  Akce může spouštět PL/SQL kód, s výjimkou DDL a transakčních příkazů.  Události na úrovni řádku či celého příkazu.  Rozlišuje pravidla vyhodnocovaná před událostí a po události.

22 CREATE TRIGGER { BEFORE | AFTER } ON [ [ REFERENCING ] FOR EACH ROW [ WHEN ( ) ] ] ::= INSERT | DELETE | UPDATE [ OF ] ::= OLD AS | NEW AS

23 1. Spuštění příkazových pravidel před událostí (= statement-level before-trigger) 2. Pro každý ovlivněný řádek v cílové tabulce a)Spuštění řádkových pravidel před událostí. b)Provedení události, včetně kontroly referenční integrity apod. c)Spuštění řádkových pravidel po události. 3. Dokončení události, kontroly které nejsou prováděny na úrovni řádku, ale dotazu. 4. Spuštění příkazových pravidel po události.

24  Každá změna v akci pravidla může způsobit spuštění dalšího pravidla. ◦ Toto další pravidlo se provádí okamžitě, jako volání vnořené funkce. ◦ Maximální hloubka vnoření je 32, pak se vyhodí výjimka, aby se zabránilo nekonečnému volání.  Původní příkaz, který vyvolal spuštění prvního pravidla, je v tomto případě odrolován a není proveden.

25  Pro ty co mají zkušenost s MySQL, ale nikoliv s Oraclem, takto se v syntaxi Oracle píše klíčové slovo AUTOINCREMENT: CREATE SEQUENCE seq_tabulka_id INCREMENT BY 1START WITH 1 NOMAXVALUE MINVALUE 0; CREATE TRIGGER tr_tabulka_id BEFORE INSERT ON tabulka FOR EACH ROW begin SELECT seq_tabulka_id.nextval INTO :new.id FROM dual; end;

26  Implementace aktivních pravidel v roce 1996 v IBM Almaden Research Center.  Snaha o precizní a jednoznačnou sémantiku, s využitím zkušeností ze systému Starburst.  Na základě této implementace navržena a schválena úprava standardu SQL3, tedy výsledný standard z roku 1999 je blíže implementaci v DB2 než té od Oracle.  Pravidlo je vždy navázáno jen na jednu událost.

27 CREATE TRIGGER { BEFORE | AFTER } ON [ REFERENCING ] FOR EACH { ROW | STATEMENT } WHEN ( ) ::= INSERT | DELETE | UPDATE [ OF ] ::= { OLD | NEW | OLD_TABLE | NEW_TABLE } AS

28  Pravidlo před událostí může změnit hodnoty před jejich vložením/aktualizací, ale nemůže žádným jiným způsobem modifikovat databázi.  Může existovat více pravidel pro stejnou událost. Jejich vyhodnocování se provádí v takovém pořadí, v jakém byly vytvořeny.

29 1. ( Pozastav spouštění pravidla A a ulož jeho pracovní stav na zásobník. ) 2. Spočítej přechodové tabulky (OLD a NEW) vzhledem k aktivované události E. 3. Vyhodnoť všechna relevantní pravidla před událostí E, s možností změny tabulky NEW. 4. Aplikuj změny z přechodové tabulky NEW do databáze. 5. Vyhodnoť všechna relevantní pravidla po události E. Pokud jejich akce způsobí událost, která může spustit další pravidla, aplikuj rekurzivně celý proces. 6. ( Vyber ze zásobníku pracovní stav pro A a pokračuj v jeho vyhodnocování. )

30  Pokud je v bodu 4 (aplikace změn) porušeno integritní omezení s definovanou kompenzací (například kaskádové mazání), nastává i zde rekurzivní zpracování pravidel a vyhodnocování těchto kompenzačních akcí.

31  Při každé aktualizaci tabulky dodavatelů zaznamenáme do auditní tabulky uživatele, datum a kolik záznamů aktualizoval. CREATE TRIGGER AuditDodavatele AFTER UPDATE ON Dodavatele REFERENCING OLD_TABLE AS ot FOR EACH STATEMENT INSERT INTO Audit VALUES (USER, CURRENT_DATE, (SELECT COUNT(*) FROM ot))

32  Objektově orientovaný dotazovací jazyk  Výzkumný prototyp  Podporuje okamžité i odložené zpracování.  Podporuje různé módy zpracování.  … celkově podporuje spoustu různých možností a kombinací které vás mohou napadnout …

33 define object class Employee attributes Name: string, Salary: integer end; define object class Department attributes Name: string, Empoyees: set-of(Employee) end;

34 define [ { event-consuming | event-preserving } ] [ { deferred | immediate } ] trigger [ for ] events condition action [ { before | after } ] end ::= create | delete | modify [ ( )]

35  Vyhodnocení pravidel může být okamžité, odložené, či dokonce odpojené v samostatné transakci. ◦ Vyhodnocení akce pravidla může být vůči vyhodnocení podmínky opět v těchto variantách  Vyhodnocování může mít různé úrovně granularity.  Změna způsobující událost bývá uložená v pomocné tabulce.  Systémy mají různá pravidla pro pořadí vyhodnocování pravidel a pro vyhodnocení rekurzivních událostí.

36  Co jsou aktivní databáze?  Syntax a sémantika  Příklady použití  Shrnutí

37  Popsána pomocí predikátů – integritní pravidla  Constraints - Statická omezení ◦ Ke každému zaměstnanci musí být oddělení ◦ Predikáty vyhodnocovány nad stavy databáze  Rules - Dynamická omezení ◦ Vynucují constraints při změně stavů ◦ Predikáty vyhodnocovány nad přechody stavů ◦ porovnávají stavy produkované transakcí

38  Implicitní ◦ specifikovány jazykem, popisem dat ◦ v SQL: NOT NULL, UNIQUE, atd  Obecné ◦ specifikovány obecnými predikáty nebo dotazy ◦ př. check clause a assertion v SQL 92 standardu

39  Pohledy (VIEW)  Odvozené atributy  Virtuální pohledy ◦ počítány na vyžádání ◦ Implementovány pomocí změny dotazu ◦ Illustra  Materializované pohledy ◦ trvale uloženo v databázi ◦ nutnost přepočítat při změně zdrojových dat

40  Refresh ◦ Celé znovu přegenerovat ◦ Jednoduchá pravidla  Inkrementální údržba ◦ Složitější - specificky generované pro strukturu odvozujících pravidel ◦ Počítá rozdíly (delty) které budou přidány nebo odebrány z pohledu ◦ Problémy s rekurzí, duplikáty, vícenásobným odvozováním

41  Pohled který vybírá oddělení, kde alespoň jeden zaměstnanec bere více než 100K DEFINE VIEW HodnePlacenaOddeleni AS (SELECT DISTINCT Odd.Jmeno FROM Odd, Zam WHERE Odd.CisloOdd = Zam.CisloOdd AND Zam.Plat > 100K)  Kritické události: ◦ INSERT do Zam, Odd ◦ DELETE ze Zam, Odd ◦ UPDATE na Zam.CisloOdd, Zam.Plat, Odd.CisloOdd

42 CREATE RULE ObnovHodnePlacenaOddeleni1 ON Zam WHEN INSERTED, DELETED, UPDATED(CisloOdd), UPDATED(Plat) THEN DELETE * FROM HodnePlacenaOddeleni; INSERT INTO HodnePlacenaOddeleni: (SELECT DISTINCT Odd.Jmeno FROM Odd, Zam WHERE Odd.CisloOdd = Zam.CisloOdd AND Zam.Plat > 100K ) CREATE RULE ObnovHodnePlacenaOddeleni2 ON Odd WHEN INSERTED, DELETED, UPDATED(CisloOdd) THEN DELETE * FROM HodnePlacenaOddeleni; INSERT INTO HodnePlacenaOddeleni: (SELECT DISTINCT Odd.Jmeno FROM Odd, Zam WHERE Odd.CisloOdd = Zam.CisloOdd AND Zam.Plat > 100K)

43  Inkrementální pravidlo obnovy pro INSERT do Odd: CREATE RULE InkremObnovHodnePlacenaOddeleni ON Odd WHEN INSERTED THEN INSERT INTO HodnePlacenaOddeleni: (SELECT DISTINCT Odd.Jmeno FROM INSERTED, Zam WHERE INSERTED.CisloOdd = Zam.CisloOdd AND Zam.Plat > 100K)  Pravidlo není nutné, pokud existuje FOREIGN KEY constraint ze Zam do Odd  Pravidla pro jiné události než INSERT jsou složitější

44  Udržování několika kopií stejných informací ◦ v podstatě podmnožina odvozování dat  Distribuované databázové servery  Asynchronní propagování změn mezi kopiemi  Většinou není nutné mít kopie sesynchronizovány  Delty aplikovány na sekundární kopie

45  Jedna primární a více sekundárních kopií ◦ sekundární kopie asynchronně aktualizovány ◦ sekundární jsou pro aplikace jen pro čtení  Symetrické replikace ◦ dvě kopie mohou asynchronně přijímat změny ◦ fungují jako primární i sekundární zároveň ◦ paralelní aktualizace bez synchronizac  => možnost ztráty konzistence

46 CREATE RULE Pridano ON Primarni WHEN INSERTED THEN INSERT INTO PridanoDelta (SELECT * FROM INSERTED)  Obdobná pravidla pro DELETE a UPDATE

47 = „Workflow management“  Popis procesu v systému  Monitorování přidělených úkolů a pomoc s rozdělováním  Reaktivní proces  Monitoruje události v systému a spouští podle toho aktivity

48 define trigger PostupPriNehode for Nehoda events create (Nehoda) condition Nehoda(N) occured(create, N) Rezervace(R) R.Auto = N.PoskozeneAuto Actions create(Varovani, [R.Cislo, R.Agent], X) end

49  Vnější události které souvisejí s obsahem databáze  Nemohou být deklarativně popsána  Sledování určitých cílů ◦ Maximalizace zisku ◦ Optimální logistika

50  Řízení provozu  Inventární systémy  Logistika a plánování  Pravidla pro obchod s akciemi

51  Pro složité systémy se ale aktivní pravidla ukazují jako nepraktická  XCON ◦ 10000 pravidel neúnosné na údržbu ◦ S přidáváním nových pravidel je stále těžší určit pořadí v jakém se mají procházet ◦ Přidání nových pravidel může způsobit nečekané efekty  Pokusy o zlepšení situace nepřinesli dostatečná zlepšení ◦ Chimera

52  Co jsou aktivní databáze?  Syntax a sémantika  Příklady použití  Shrnutí

53  Aktivní pravidla jsou mocný nástroj, který výrazně rozšiřuje možnosti databázového systému.  Všechny moderní SQL databáze jsou aktivní, tj. podporují aktivní pravidla. ◦ Jednotlivé implementace se drobně liší v syntaxi i sémantice, ale základ je podobný  V praxi se používají spíše jednodušší aktivní pravidla, komplexní sada pravidel může být velmi nepřehledná a matoucí.