1 / 74

Aktivní databáze

Aktivní databáze. Milan Plachý Dan Kobr 2010/2011. Obsah referátu. Úvod Základní pojmy Starburst Oracle DB2 Chimera Taxonomie konceptů aktivních databází Aplikace, příklady. Úvod. Aktivní databáze podporují použití aktivních pravidel Aktivní pravidla (triggery)

taini
Download Presentation

Aktivní databáze

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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í - knowledgeindependence • 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 a sémantika aktivní databáze • 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

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

  17. Syntaxe vytvoření pravidlave Starbust - příklad CREATERULE kontrola_platu ON Zamestnanci WHENINSERTED, DELETED, UPDATED(Plat) IF (SELECTAVG (Plat) FROM Zamestnanci)> 20000 THENUPDATE 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í n1 a její úprava na n2 se chová jako vložení n2

  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 • DEACTIVATERULE <jméno_pravidla> ON <tabulka> • ACTIVATERULE <jméno_pravidla> ON <tabulka> • DROPRULE <jméno_pravidla> ON <tabulka> • Pravidla mohou být organizována ve větších množinách tzv. RULESET • CREATERULESET <jméno_množiny> • ALTERRULESET <jméno_množiny> • [ADDRULES <jména pravidel>] • [DELRULES <jména pravidel>] • DROPRULESET <jméno množiny>

  23. Další příkazy pro práci s pravidly • Možnost manuálního zpracování pravidel (jak množiny, jak jediného pravidla) • PROCESSRULES|PROCESSRULESET <jméno_množiny> |PROCESSRULE <jméno_pravidla>

  24. Příklad provádění pravidel • Nyní předpokládejme databázi s pouze jedním pravidlem a to kontrolou platu zaměstnanců • CREATERULE kontrola_platu • ON Zamestnanci • WHENINSERTED, DELETED, UPDATED(Plat) • IF (SELECTAVG (Plat) FROM Zamestnanci)> 10000 • THENUPDATE Zamestnanci • SET Plat = 0.9 * Plat • Dále tabulku s platy zaměstnanců Zamestananci v následujícím stavu

  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

  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 <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 ROWurč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ň CREATETRIGGER <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ů>]

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

  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é

More Related