AKTIVNÍ DATABÁZE Milan Plachý Dan Kobr 2010/2011.

Prezentace na téma: "AKTIVNÍ DATABÁZE Milan Plachý Dan Kobr 2010/2011."— Transkript prezentace:

1 AKTIVNÍ DATABÁZE Milan Plachý Dan Kobr 2010/2011

2 Obsah referátu  Úvod  Základní pojmy  Starburst  Oracle  DB2  Chimera  Taxonomie konceptů aktivních databází  Aplikace, příklady

3 Úvod Aktivní databáze  podporují použití aktivních pravidel Aktivní pravidla (triggery)  umožňují databázovému systému reagovat na různé události a změny  definují činnosti, které se mají provést v případě provedení konkrétní operace nad databází

4 Přínos aktivních pravidel  velmi silný nástroj k zajištění kontroly a integrity dat  standardní databáze mohou ke kontrole využít pouze integritních omezení  usnadňují práci s databází

5 Problémy spojené s triggery  standardizace – sémantika triggeru záleží na konkrétní implementaci - kdy přesně je trigger spuštěn - jak proběhne a co jej může přerušit - jakým způsobem (zda vůbec) je ošetřeno zacyklení vzájemně se volajících triggerů  těžko odhadnutelný výsledek operací ve složitých databázových systémech

6 Aktivní databáze  Těsné svázání databázového systému a pravidel, kterými se databáze řídí automaticky  Paradigma: Událost-Podmínka-Akce (Event- Condition-Action)

7 Taxonomie – základní pojmy event (událost) - jakákoli změna stavu databáze - vyhledávání záznamu v databázi - pravidelně se opakující události - definovány externí aplikací

8 Taxonomie – základní pojmy condition (podmínka) - vrací logickou hodnotu True / False - databázový predikát - databázový dotaz – ohodnocen True, pokud je výsledek neprázdný

9 Taxonomie – základní pojmy action (akce) - libovolná manipulace s daty v databázi - může aktivovat procedury definované externí aplikací - může obsahovat transakční příkazy (ROLLBACK) - může aktivovat / deaktivovat aktivní pravidla

10 Active rule engine (jádro aktivních pravidel)  Nastavení pravidel, pořadí akcí a transakcí, kontrola změn databáze dle nastavených pravidel  Zaručení reagujícího chování databáze  Možnost nahrazení části sémantiky databáze aktivními pravidly  Nová dimenze závislostí - knowledge independence  Aplikace není nijak vázána s těmito pravidly a ani je nemusí/nesmí znát  Nastavení pouze jednou, poté pouze úpravy -> ušetření práce aplikace resp. uživatele  společné pro všechny aplikace a uživatele

11 Jak chápat aktivní databázi  Aktivní databáze je klasický databázový systém obsahující navíc množinu pravidel, podle kterých se databáze chová  Jednoduchým příkladem (bez ohledu na databázový systém) může být například databáze firmy, která si vede historii o změnách v databázi. V případě, že jeden ze zaměstnanců přidá do tabulky s výrobky novou položku, databáze automaticky zanese tuto informaci do tabulky s historií a přidá například údaje o zaměstnanci  Výhodou pravidel je především jejich nezávislost na konkrétní aplikaci a zjednodušení práce aplikace

12  Syntaxe se mění v závislosti na databázovém systému, závisí na orientaci databáze (relační, objektově orientovaná)  Budeme se zajímat o systémy Starbust, Chimera - objektově orientované Oracle, DB2 - relační  V relačních databázích - trigger - někdy používáno jako synonymum k active rule engine resp. jeho příkladem Syntaxe a sémantika aktivní databáze

13 Triggery  Snaha standardizovat od 80-tých let, nepovedlo se je zařadit do standardu SQL-92 kvůli nedostatkům standardizačního dokumentu  Snaha výrobců vytvořit aplikace co nejblíže připravovanému standardu  Problémy, které jsou dány tedy řeší výrobci různě (Oracle podle SQL3)  1990 - 1995 dominuje standardizaci SQL3 1996 podává DB2 žádost o úpravu SQL3 standardu a navrhuje přesné sémantické řešení triggerů s ohledem na kontrolu integrity

14 Starburst  Projekt IBM vývojové centrum Almaden  Aktivní rozšíření -> Starbust active rule system  Populární - jednoduchá syntaxe a sémantika - množinově orientovaná syntax - sémantika relačních databází  Umožňuje vytvářet a mazat pravidla podle paradigmatu Událost-Podmínka-Akce  Události - INSERT, DELETE, UPDATE  Podmínka - Predikát stavu databáze vyjádřen v SQL  Akce - zahrnují klasické SQL příkazy (SELECT, INSERT, DELETE, UPDATE), dále pak příkazy pro manipulaci s pravidly a instrukce transakcí (ROLLBACK WORK)  Paradigma má intuitivní a jednoduchou sémantiku:  Nastane-li událost a je splněna podmínka, poté se provede akce (U většiny databází)

15 Starburst - pravidla  Pravidlo je  spuštěné (trigerred) - nastane-li událost, která ho definuje  zvážené (considered) - po kontrole podmínky  vykonané (executed) - po provedení akce  Různé systémy se na tyto položky dívají různě  Každá aplikace může dynamicky pracovat s pravidly vypínání/zapínání pravidel

16 Syntaxe vytvoření pravidla ve Starbust CREATE RULE ON WHEN [IF ] THEN [PRECEDES ] [FOLLOWS ] = INSERTED | UPDATED | DELETED [( )]

17 Syntaxe vytvoření pravidla ve Starbust - příklad CREATE RULE kontrola_platu ON Zamestnanci WHEN INSERTED, DELETED, UPDATED(Plat) IF (SELECT AVG (Plat) FROM Zamestnanci)> 20000 THEN UPDATE Zamestnanci SET Plat = 0.9 * Plat Co pravidlo dělá??

18 Vlastnosti pravidel  V případě přidání, odebrání nebo upravení platu některého ze zaměstnanců se automaticky spustí toto pravidlo. To nejprve zprůměruje platy všech zaměstnanců a v případě, že průměr jejich platů přesáhne limitní hranici, všechny platy sníží o 10%  Každé pravidlo musí mít unikátní jméno a je jednoznačně přiřazeno nějaké tabulce (cíl pravidla)  Jak je vidět z příkladu, každé pravidlo může monitorovat více událostí  Podobně jedna událost může být monitorována více pravidly  Pořadí vykonávání pravidel je dáno posledními dvěma částmi formule  Je nutné zajistit acykličnost

19 Sémantika aktivního pravidla v systému Starburst  V případě transakcí se implicitně pravidla spouští ve chvíli, kdy transakce zavolá COMMIT WORK, dále se spuštění pravidel dá zavolat explicitně: PROCESS RULES příkazem  Pravidlo  na začátku vykonání transakce nespuštěné  spuštěné v případě, že během transakce proběhne jeho spouštěcí událost  Ve chvíli spuštění triggerů - konfliktní množina  množina se postupně zmenšuje následovným algoritmem  1) Vyber z množiny pravidlo P s nejvyšší prioritou, nastav ho na nespuštěné  2) Vyhodnoť podmínku pravidla P  3) Pokud je podmínka pravdivá, vykonej akci popsanou v pravidle P  Určení priority v bodě 1) je podle počtu předchůdců všech pravidel, pravidla se stejnou prioritou jsou řazena podle data vytvoření

20 Cyklické spouštění pravidel  Může se stát, aby se dvě (a více) pravidla zacyklila??  Ano, v tomto případě říkáme, že je databáze je v nehybném stavu, resp. že pravidla jsou neukončitelná  Náhled ze strany stavů databáze - posun ze stavu S1 do S2 množinami zasažených příkazy transakce insert, delete, update  Je možné extrahovat pouze konkrétní množiny atributů: updated(Plat)  Pravidla jsou spuštěna pouze tehdy když n-tice, kterou ovlivňují je neprázdná  Pravidla umožňují takzvaný efekt sítě:  Spojení pravidel ovlivňujících stejnou n-tici dohromady  Každá n-tice změněna pouze jednou  Příklad:  insert + delete = null  vložení n 1 a její úprava na n 2 se chová jako vložení n 2

21 Odkazování se na upravovaná data  Vytvoření dočasných tabulek s měněnými daty charakterizujícími změny stavu  tabulky INSERTED, DELETED, OLD-UPDATED, NEW-UPDATED  INSERTED - vkládaná/vkládané n-tice  DELETED - tabulka se smazanou n-ticí  OLD-UPDATED - tabulka s původními hodnotami n-tice  NEW-UPDATED - tabulka s novými hodnotami n-tice po UPDATu  Proč referovat na nové hodnoty??  Přístup do temporálních tabulek je z důvodu jejich malé velikosti rychlý a s novými daty se bude pravděpodobně opět pracovat

22 Další příkazy pro práci s pravidly  Rozšíření starburstu obsahuje pčíkazy pro změnu, smazání, aktivování a deaktivování pravidla  DEACTIVATE RULE ON  ACTIVATE RULE ON  DROP RULE ON  Pravidla mohou být organizována ve větších množinách tzv. RULESET  CREATE RULESET  ALTER RULESET  [ADDRULES ]  [DELRULES ]  DROP RULESET

23 Další příkazy pro práci s pravidly  Možnost manuálního zpracování pravidel (jak množiny, jak jediného pravidla)  PROCESS RULES | PROCESS RULESET | PROCESS RULE

24 Příklad provádění pravidel  Nyní předpokládejme databázi s pouze jedním pravidlem a to kontrolou platu zaměstnanců  CREATE RULE kontrola_platu  ON Zamestnanci  WHEN INSERTED, DELETED, UPDATED(Plat)  IF (SELECT AVG (Plat) FROM Zamestnanci)> 10000  THEN UPDATE Zamestnanci  SET Plat = 0.9 * Plat  Dále tabulku s platy zaměstnanců Zamestananci v následujícím stavu ZamestnanecPlat Pepa10000 Karel9000 Honza10000

25 Příklad provádění pravidel  Přidejme nyní do tabulky dvojici Jaromír 12000, po přidání, se spustí pravidlo kontrola_platu, průměr je nyní vyšší než 10000, proto bude kontrolní podmínka vyhodnocena jako true a každému zaměstnanci se plat sníží o 10%.  Nyní je průměrný plat nižší než 10000, nicméně pravislo je spuštěno znovu, protože proběhl UPDATE předchozím pravidlem, nicméně podmínka bude vyhodnocena jako false z důvodu nízkého platu zaměstnanců  V případě, že by ale byla hodnota průměrného platu stále moc vysoká, spouštělo by se toto pravidlo neustále dokola a mohlo by dojít (špatným nastavením pravidla) k zacyklení, zkuste vymyslet jak  Správné nastavení pravidel je pouze v rukou vývojáře a je nutné je dobře specifikovat

26 Příklad provádění pravidel ZamestnanecPlat Pepa9000 Karel8100 Honza9000 Jaromír10800

27 Oracle  Oracle podporuje triggery obecného účelu podle předběžného dokumentu popisující triggery - SQL3  Velmi silné, je povoleno v triggeru libovolný PL/SQL kód  Reagují na INSERT, DELETE, UPDATE na dané tabulce  2 různé úrovně granuality triggerů  řádková úroveň (row-level)  výrazová úroveň (statement-level)  Statement level - podobné jako starburst, množinově orientovaná sémantika  row-level - sémantika orientovaná na konkrétní instance - každý řádek, který byl ovlivněn

28 Oracle  Možnost spustit trigger před nebo po provedení příkazu -> těsné svázání s konkrétním příkazem  2 typy x 2 možnosti spuštění = 4 možnosti  řádkové trigery před příkazem (row-level before-triggers)  výrazové triggery před příkazem (statement-level before-triggers)  řádkové triggery po příkazu (row-level after-triggers)  výrazové triggery po příkazu (statement-level after-triggers)

29 Syntaxe Oracle triggeru CREATE TRIGGER BEFORE | AFTER} ON [[REFERENCING ] FOR EACH ROW [WHEN ( )]] = INSERT | DELETE | UPDATE [OF ] = OLD AS NEW AS FOR EACH ROW určuje úroveň (vynechání = statement level)

30 Syntaxe Oracle triggeru  podmínka je podporována pouze v případě řádkové úrovně (řádkový predikát), v případě úrovně výrazu je možné použít příkaz WHERE, což ale umožňuje možnost nekonečného cyklu  odkazy na předchozí stavy databáze jsou možné pouze v řádkové úrovni pomocí nastavení REFERENCING nebo zabudovaných proměnných OLD a NEW

31 Sémantika triggeru v Oraclu  Každá operace může být na každé úrovni monitorována nejvýše jedním triggerem -> max 4 triggery  pořadí vykonávání triggerů není možné explicitně ovlivnit  Postup při vyhodnocování výrazu  1. Vykoná se výrazový trigger před příkazem  2. Pro každý řádek cílové tabulky a. řádkový trigger před výrazem b. modifikace řádku a kontrola řádkové integrity c. řádkový trigger po výrazu  3. Kontrola integrity na úrovni výrazu  4. výrazový trigger po příkazu  během všech akcí je možné zavolat nový trigger - možné kaskádové šíření - max 32 aktivovaných triggerů, potom vyhození výjimky, ROLLBACK (podpora částečných nejen transakčních rollbacků)

32 DB2  Triggery podobně jako Oracle  Definováno ve výzkumném středisku IBM  Snaha definovat přesnou sémantiku triggerů vzhledem k integritě

33 DB2 - syntaxe  Každý trigger monitoruje pouze jednu událost  Jako v Oraclu existují AFTER a BEFORE triggery, řádková/výrazová úroveň CREATE TRIGGER {BEFORE | AFTER} ON [REFERENCING ] FOR EACH {ROW|STATEMENT} WHEN ( )  = INSERT | DELETE | UPDATE [OF ]

34 DB2 - syntaxe  OLD a NEW označují n-tice jako v Oraclu  OLD_TABLE a NEW_TABLE popisují n-tice před a po množinově orientovaném dotazu  INSERT definován pouze proměnnou NEW_TABLE, DELETE naopak pouze OLD_TABLE  Obsah tabulek je podobný jako u Starburstových INSERTED, DELETED, OLD_UPDATED, NEW_UPDATED s rozdílem, že ve Starburst může všechny události monitorovat pouze jeden trigger  Možnost vyhození chyb -> Výrazový ROLLBACK

35 DB2 – sémantika triggerů  Before triggery slouží pro kontrolu vkládaných dat  Nemohou obsahovat výrazy INSERT, UPDATE, DELETE – nedojde ke kaskádovému šíření  AFTER triggery se vykonají po akci  Jednu událost může monitorovat více triggerů, provádějí se v pořadí podle času definování  Postup při zpracování procedury v DB2:  Akce A vyvolá událost E poté probíhá následující procedura  1. Pozastaví se a do zásobníku uloží pracovní prostor pro A  2. Spočtou se hodnoty OLD a NEW vůči E  3. Vykonání všechny before-triggery vůči E, možné změnit NEW  4. Aplikování přechodu pomocí NEW  5. Vykonání všech after-triggerů případně rekurzivní volání dalších  6. Vhodí ze zásobníku pracovní místo pro A a pokračuje

36 DB2 – sémantika triggerů  Kroky nejsou nutné v případě uživatelem definované transakce  V případě, že v bodě 4 jsou porušena integritní omezení (s check constrains) jsou volány kompenzační akce dokud se nedosáhne opravené pozice  V tomto případě nastávají následné akce  4. Aplikování přechodu pomocí NEW, pro každé integritní omezení IC bereme akci Aj, která znovu zaručí integritu a. Spočtou se hodnoty NEW a OLD vůči Aj b. Vykonají se before-triggery vzhledem k Aj, možnost změny hodnoty NEW c. Aplikování změn v NEW, čímž A nabyde efektivity d. Dá všechny triggery vztahující se k Aj do fronty pro další vykonání  Fronta může narůst kvůli velkému množství kompenzačních akcí

37 Chimera  Čistě objektově orientovaný databázový systém, spojuje objektově orientovaný datový model, deklarativní jazyk a jazyk aktivní databáze  Aktivní pravidlo - trigger - množinově orientované  Několik novinek oproti předchozím  Využívá identifikátorů objektů pro popis objektů, které jsou akcí ovlivněny. Identifikátory poskytují spojovací mechanismus událost-podmínka, podmínka- akce  Poskytují různé módy pro zpracování událostí - event consumption modes  Podpora jak okamžitého tak odloženého spuštění triggeru  Mechanismy pro přístup do okamžitých stavů databáze  Možnost podpory efektu sítě (speciální predikát)

38 Shrnutí jazyku Chimery  Schémata se skládají z tříd objektů, každá třída má svůj stav sestávající se z atributů  Jazyk je klasický objektově orientovaný define object class Zamestnanec attributes Jmeno: string, Plat: integer end; define object class Oddeleni attributes Jmeno: string, Zamestnanci: set-of(Zamestnanec) end;  třídy jsou uspořádané v hierarchiích a v jejich deklaraci je možné zadefinovat integritní omezení, operací a přidělených triggerů

39 Chimera - deklarativní výrazy  Term  atom (konstanty, proměnné)  složený - funkcionální termy vytvořené deklarací (množina, list, záznam)  Formule  atomické formule se skládají z predikátu a seznamu parametrů formule typu - popis datového typu proměnné - integer(X) formule třídy - popis třídy objektu - Zamestnanec(X) formule srovnání - mezi dvěmi skalárními termy, funguje jako klasické porovnání - X.Jmeno = 'Karel'‚ formule náležení - mezi skalárem a množinou - Y in X.Oddeleni

40 Chimera - deklarativní výrazy  Formule  Složené formule se vytváří z jednoduchých jejich spojením a negací (negace pouze pro atomické) - Zamestnanec(X), Oddeleni(Y), Y.Jmeno = 'Marketing', not(X in Y.Zamestnanci)  Formule vyhodnocovány oproti databázi v nějakém stavu - matchování parametrů  Nezáleží na pořadí vyhodnocování výrazů, výsledek je vždy stejný

41 Primitivní výrazy (výrazová primitiva)  Procedurální výrazy jsou složeny z takzvaných primitivních výrazů  Primitivum select - select(X where Zamestnanec(X), X.Jmeno = 'Karel')  Primitivum create - create(Zamestnanec,['Josef',45000],X) X... výstupní proměnná vázaná k identifikátoru nově vytvořeného objektu  Primitivum delete - delete(Zamestnanec,X)  Primitivum modify (úprava) - modify(Zamestnanec.Plat,X,X.Plat*10)  Procedurální výrazy organizovány v transakčních řadách = řady primitivních výrazů oddělených čárkami  Transakční řada je nejmenší jednotka, která může být monitorována triggerem

42 Chimera - syntaxe definování triggeru define trigger [for ] events condition actions [{before|after} ] end = create | delete | modify [( )] = [ ][ ] = deferred | immediate = event-consuming | event-preserving

43 Chimera - sémantika triggerů  Zpracování triggerů je dáno vůči konkrétní transakci  immediate triggery se vykonávají po skončení transakční řady  deferred triggery se vykonají při zavolání commit nebo savepoint příkazu  immediate triggery zavolané akcí jiného triggeru se provádějí spolu s deferred  Na rozdíl od Starburstu jsou aktivní triggery vždy vykonány, nefunguje efekt sítě

44 Chimera - sémantika triggerů  Postup při zpracovávání triggerů  Dokud není prázdná množina aktivovaných triggerů opakuj Vyber z množiny trigger T s nejvyšší prioritou a nastav jeho příznak na neaktivovaný Zkontroluj podmínku triggeru T Pokud byla podmínka vyhodnocena kladně, vykonej akci v T  Výběr pořadí se řídí pouze podle after a before, novlivnitelný  Predikáty holds a occurred  slouží pro kontrolu akcí provedených triggerem  holds - kontrola výsledku síťového efektu

45 Chimera - sémantika triggerů  Módy zachování (consumption modes)  Consumed (zpracována) – každá instance události je zvažována pouze jednou a pak není relevantí  Preserved (zachována) – všechny instance události od začátku transakce jsou posuzovány neustále  Odkazy na předchozí stavy databáze jsou podporovány speciální funkcí old  Při prvním zvažování triggeru je old nastavena na začátek transakce

46 Sledování změn databáze - může probíhat na různých úrovních: - na úrovni instancí – např. změna objektu v rámci třídy nebo změna řádku tabulky - na úrovni příkazů – celý příkaz manipulující s daty je chápán jako událost

47 Sledování změn databáze - je nutné po určitou dobu uchovat staré i nové záznamy: - na úrovni instancí – používají se proměnné OLD a NEW pro řádek či objekt - na úrovni příkazů – proměnné DELETED a INSERTED representují celé tabulky

48 Konfliktní množina triggerů - množina pravidel, která mají být vykonána ve stejnou dobu - je nutné vybrat následující pravidlo - typicky se tak děje po vyhodnocení každé podmínky pravidla nebo po vykonání triggeru - je také možné vytvořit seznam triggerů a ty vykonávat jeden po druhém

49 Konfliktní množina triggerů - priority - úplné uspořádání – pravidla jsou ohodnocena prioritami a pořadí vykonání je jednoznačné - částečné uspořádání – ohodnocení pravidel je nejednoznačné (vyhodnotí systém nebo uživatel), výběr může být nedeterministický - bez priorit – vyhodnotí systém či uživatel

50 Opakovatelnost - jsou dány dvě stejné transakce, databáze a množina triggerů - vykonání transakce je opakovatelné, pokud jsou výsledky provedených transakcí stejné

51 Aktivace / deaktivace pravidel - některé systémy umožňují triggery dynamicky aktivovat a deaktivovat - deaktivace může způsobit porušení referenční integrity - tato oprávnění jsou předmětem bezpečnostních mechanismů databáze - slučováním triggerů do skupin se zjednodušuje přidělování oprávnění k aktivaci / deaktivaci

52 Aplikace aktivních databází Interní využití - údržba databáze (zajištění integrity, replikace) - automaticky generovaná pravidla - správa verzí, logování změn Externí využití, business rules - mohla by být součástí externích aplikací - alerters – poskytování informace, varování, nemění obsah databáze

53 Zajištění integrity databáze - nejvýznamnější interní aplikace aktivní databáze - integritní pravidla – odpovídající pravidla - statická – vyhodnocují stavy databáze - dynamická – porovnávají stav databáze před a po provedení transakce - vestavěná – zabudovaná konstrukce dotazovacího jazyka (např. NOT NULL) - obecná – specifikována generickým predikátem nebo dotazem

54 Generování triggerů 1. deklarace omezení odpovídá podmínce pravidla 2. akce porušující omezení odpovídají události pravidla – lze získat analýzou podmínky pravidla 3. akce zajišťující opětovné dodržení omezení odpovídají akci triggeru

55 Klasifikace generovaných triggerů Přerušovací pravidla (Abort rules) - aktivovány událostí, která způsobuje porušení podmínky - porušení způsobí rollback (zrušení transakce se všemi důsledky) - nevýhoda – časté rušení transakcí a příkazů

56 Klasifikace generovaných triggerů Opravná pravidla (repair rules) - detekují porušení podmínky - obsahují sadu pravidel aplikovaných při porušení podmínky, aby byla zachována referenční integrita databáze - SQL-92: CASCADE, RESTRICT, SET NULL, SET DEFAULT

57 Příklad Tabulky Zaměstnanec(Zam, Odd) Oddělení(Odd) Omezení Každý zaměstnanec musí patřit do nějakého oddělení

58 Příklad Akce, které mohou omezení porušit - vložení nového zaměstnance - smazání oddělení - změna hodnoty Zaměstnanci.Odd - změna hodnoty Oddělení.Odd

59 Příklad Vyjádření podmínky EXISTS ( SELECT * FROM Oddělení WHERE Odd = Zam.Odd ) - musí být pravdivá pro všechny zaměstnance

60 Příklad Přerušovací pravidlo pro tabulku Zaměstnanci CREATE RULE OddZam1 ON Zaměstnanci WHEN INSERTED, UPDATED (Odd) IF EXISTS ( SELECT * FROM Zaměstnanci WHERE NOT EXISTS ( SELECT * FROM Oddělení WHERE Odd = Zaměstnanci.Odd ) ) THEN ROLLBACK

61 Příklad Přerušovací pravidlo pro tabulku Oddělení: CREATE RULE OddZam2 ON Oddělení WHEN DELETED, UPDATED (Odd) IF EXISTS ( SELECT * FROM Zaměstnanci WHERE NOT EXISTS( SELECT * FROM Oddělení WHERE Odd = Zaměstnanci.Odd ) ) THEN ROLLBACK

62 Příklad - neefektivní – kdykoli může být podmínka porušena, ověřuje se její platnost pro celou databázi - jinak – použitím opravovacího pravidla

63 Příklad Opravné pravidlo pro tabulku Zaměstnanci: CREATE RULE OddZam1 ON Zaměstnanci WHEN INSERTED IF EXISTS (SELECT * FROM INSERTED WHERE NOT EXISTS ( SELECT * FROM Oddělení WHERE Odd = Zaměstnanci.Odd ) ) THEN UPDATE Zaměstnanci SET Odd = NULL WHERE Zam IN ( SELECT Zam FROM INSERTED ) AND NOT EXISTS ( SELECT * FROM Oddělení WHERE Odd = Zaměstnanci.Odd)

64 Příklad Opravné pravidlo 2 pro tabulku Zaměstnanci: CREATE RULE OddZam2 ON Zaměstnanci WHEN UPDATED (Odd) IF EXISTS ( SELECT * FROM NEW-UPDATED WHERE NOT EXISTS ( SELECT * FROM Oddělení WHERE Odd = Zaměstnanci.Odd ) ) THEN UPDATE Zaměstnanci SET Odd = 99 WHERE Zam IN ( SELECT Zam FROM NEW-UPDATED ) AND NOT EXISTS ( SELECT * FROM Oddělení WHERE Odd = Zaměstnanci.Odd)

65 Data získaná z databáze - pohled – výsledek databázového dotazu (tabulka, třída) přístupy k implementaci - virtuální – obsah spočítán při požadavku - materializovaný – data permanentně uložena v databázi, kdykoli při změně nutné aktualizovat

66 Materializace odvozených dat pomocí aktivních pravidel: - obnovováním – odvozená data se přepočítají vždy při změně původních dat – jednoduchá implementace - přírůstky – je spočítána a aktualizována pouze změněná část materializovaných dat

67 Materializace odvozených dat Příklad - původní tabulky Zaměstnanci a Oddělení - definujme pohled „Oddělení, která mají alespoň jednoho zaměstnance s platem nad 50.000,-“ DEFINE VIEW StedraOddeleni AS (SELECT DISTINCT Oddeleni.Jmeno FROM Oddeleni, Zamestnanci WHERE Oddeleni.Odd = Zamestnanci.Odd AND Zamestnanci.Plat > 50000 )

68 Materializace odvozených dat Co může způsobit změnu dat pohledu - vložení nového zaměstnance - vložení nového oddělení - odstranění zaměstnance - odstranění oddělení - změna oddělení u zaměstnance - změna platu zaměstnance - změna čísla oddělení

69 Příklad – obnova celého pohledu CREATE RULE pravidlo1 ON Zamestnanci WHEN INSERTED, DELETED, UPDATED(oddeleni), UPDATED(plat) THEN DELETE * FROM StedraOddeleni; INSERT INTO StedraOddeleni: ( SELECT DISTINCT Oddeleni.Jmeno FROM Oddeleni, Zamestnanci WHERE Oddeleni.Odd = Zamestanci.Odd AND Zamestnanci.Plat > 50000 )

70 Příklad – inkrementální obnova CREATE RULE pravidlo2 ON Oddeleni WHEN INSERTED THEN INSERT INTO StedraOddeleni: ( SELECT DISTINCT Oddeleni.Jmeno FROM INSERTED, Zamestnanci WHERE INSERTED.Odd = Zamestanci.Odd AND Zamestnanci.Plat > 50000 )

71 Replikace - distribuované systémy – více kopií jedné informace je uloženo na různých databázových serverech schémata replikace: - asymetrická

72 Asymetrická replikace - jedna primární kopie, více sekundárních kopií záznamu (jen pro čtení) - změny prováděny na primární kopii, následně jsou aktualizovány sekundární kopie - zachytávací modul – monitoruje změny prováděné na primárním záznamu – přirozené a efektivní použití aktivních pravidel - přijímací modul – aplikuje změny na sekundární záznam

73 Symetrická replikace - dvě kopie stejného záznamu mohou asynchronně přijímat změny - každá kopie je střídavě primární a sekundární

74 Zdroje C. Zaniolo, S. Ceri, C. Faloutsos, R. Snodgrass, V. Subrahmanian, R. Zicari: Active Database Systems - část první: Aktivní databáze