AKTIVNÍ DATABÁZEMilan PlachýDan Kobr2010/2011

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

ÚvodAktivní 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í

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í

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

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)

Taxonomie – základní pojmyevent (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í

Taxonomie – základní pojmycondition (podmínka)- vrací logickou hodnotu True / False- databázový predikát- databázový dotaz – ohodnocen True,

pokud je výsledek neprázdný

Taxonomie – základní pojmyaction (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

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

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

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

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

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í)

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

Syntaxe vytvoření pravidlave Starbust CREATE RULE <jméno_pravidla> ON <jméno_tabulky>WHEN <spouštěcí_operace>[IF <SQL_predikát>]THEN <SQL_výraz>[PRECEDES <jméno_pravidla>][FOLLOWS <jméno_pravidla>]  <spouštěcí_pravidlo> = INSERTED | UPDATED | DELETED [(<jména_ sloupců>)]

Syntaxe vytvoření pravidlave Starbust - příkladCREATE RULE kontrola_platu ON ZamestnanciWHEN INSERTED, DELETED, UPDATED(Plat)IF (SELECT AVG (Plat) FROM Zamestnanci)> 20000THEN UPDATE ZamestnanciSET Plat = 0.9 * Plat

Co pravidlo dělá??

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

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í

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í n1 a její úprava na n2 se chová jako vložení n2

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

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 <jméno_pravidla> ON <tabulka> ACTIVATE RULE <jméno_pravidla> ON <tabulka> DROP RULE <jméno_pravidla> ON <tabulka>

Pravidla mohou být organizována ve větších množinách tzv. RULESET

CREATE RULESET <jméno_množiny> ALTER RULESET <jméno_množiny> [ADDRULES <jména pravidel>] [DELRULES <jména pravidel>] DROP RULESET <jméno množiny>

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 <jméno_množiny> | PROCESS RULE <jméno_pravidla>

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

Zamestnanec PlatPepa 10000Karel 9000Honza 10000

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

Příklad provádění pravidel

Zamestnanec PlatPepa 9000Karel 8100Honza 9000Jaromír 10800

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

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)

Syntaxe Oracle triggeruCREATE TRIGGER <jméno_triggeru> BEFORE | AFTER} <událost_triggeru>ON <tabulka>[[REFERENCING <odkazy> ]FOR EACH ROW[WHEN (<podmínka>)]] <PL/SQL blok>  <událost_triggeru> = INSERT | DELETE | UPDATE [OF

<jména_sloupců>]<odkazy> = OLD AS <pojmenování_předchozí_n_tice>

NEW AS <pojmenování_nové_n_tice>FOR EACH ROW určuje úroveň (vynechání = statement level)

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

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ů)

DB2

Triggery podobně jako Oracle

Definováno ve výzkumném středisku IBM  Snaha definovat přesnou sémantiku triggerů

vzhledem k integritě

DB2 - syntaxe Každý trigger monitoruje pouze jednu událost Jako v Oraclu existují AFTER a BEFORE triggery,

řádková/výrazová úroveňCREATE TRIGGER <jméno_triggeru>{BEFORE | AFTER} <spouštěcí_událost>ON <tabulka>[REFERENCING <odkazy>]FOR EACH {ROW|STATEMENT}WHEN (<SQL_podmínka>)<SQL_procedura>

<spouštěcí událost> = INSERT | DELETE | UPDATE [OF <jména_sloupců>]

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

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

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í

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)

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 Zamestnanecattributes Jmeno: string,

Plat: integerend; define object class Oddeleniattributes 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ů

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

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ý

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

Chimera - syntaxe definování triggerudefine <nastavení> trigger <jméno_triggeru>[for <jméno_třídy>]events <spouštěcí_události>condition <formule>actions <procedurální_výraz>[{before|after} <jména_triggerů>]end <spouštěcí_událost> = create | delete | modify

[(<jméno_atributu>)] <nastavení> = [<nastavení_vykonávání>][<nastavení_zachování>]<nastavení_vykonávání> = deferred | immediate<nastavení_zachování> = event-consuming | event-preserving

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ě

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

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

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

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

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

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

Opakovatelnost

- jsou dány dvě stejné transakce, databázea množina triggerů

- vykonání transakce je opakovatelné, pokud jsou výsledky provedených transakcí stejné

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

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ěnExterní využití, business rules- mohla by být součástí externích aplikací- alerters – poskytování informace,

varování, nemění obsah databáze

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

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

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ů

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

PříkladTabulky

Zaměstnanec(Zam, Odd)Oddělení(Odd)

OmezeníKaždý zaměstnanec musí patřit do nějakého oddělení

PříkladAkce, 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

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

PříkladPřerušovací pravidlo pro tabulku Zaměstnanci

CREATE RULE OddZam1 ON ZaměstnanciWHEN INSERTED, UPDATED (Odd)IF EXISTS (

SELECT * FROM ZaměstnanciWHERE NOT EXISTS ( SELECT * FROM Oddělení WHERE Odd = Zaměstnanci.Odd ) )

THEN ROLLBACK

PříkladPřerušovací pravidlo pro tabulku Oddělení:

CREATE RULE OddZam2 ON OdděleníWHEN DELETED, UPDATED (Odd)IF EXISTS (

SELECT * FROM ZaměstnanciWHERE NOT EXISTS( SELECT * FROM Oddělení WHERE Odd = Zaměstnanci.Odd ) )

THEN ROLLBACK

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

PříkladOpravné pravidlo pro tabulku Zaměstnanci:

CREATE RULE OddZam1 ON ZaměstnanciWHEN 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)

PříkladOpravné pravidlo 2 pro tabulku Zaměstnanci:CREATE RULE OddZam2 ON ZaměstnanciWHEN 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)

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

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

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, ZamestnanciWHERE Oddeleni.Odd = Zamestnanci.OddAND Zamestnanci.Plat > 50000 )

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í

Příklad – obnova celého pohledu

CREATE RULE pravidlo1 ON ZamestnanciWHEN 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 )

Příklad – inkrementální obnova

CREATE RULE pravidlo2 ON OddeleniWHEN INSERTED

THEN INSERT INTO StedraOddeleni: ( SELECT DISTINCT Oddeleni.Jmeno FROM INSERTED, Zamestnanci WHERE INSERTED.Odd = Zamestanci.Odd

AND Zamestnanci.Plat > 50000 )

Replikace- distribuované systémy – více kopií jedné

informace je uloženo na různých databázových serverech

schémata replikace:- asymetrická- asymetrická

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

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í

Zdroje

C. Zaniolo, S. Ceri, C. Faloutsos, R. Snodgrass, V. Subrahmanian, R. Zicari:

Active Database Systems- část první: Aktivní databáze