1 / 68

AKTIVNÍ DATABÁZE

AKTIVNÍ DATABÁZE. Ladislav Novák Dotazovací jazyky I - NDBI001. OBSAH. Úvod Syntaxe a sémantika vybraných DB Taxonomie Použití. Úvod, historie, aktivní pravidla. AKTIVNÍ DB A PRAVIDLA. Aktivní databáze Rozšíření DB systému o aktivní pravidla Aktivní pravidlo = trigger

tana-rutledge
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 Ladislav Novák Dotazovací jazyky I - NDBI001

  2. OBSAH • Úvod • Syntaxe a sémantika vybraných DB • Taxonomie • Použití

  3. Úvod, historie,aktivní pravidla

  4. AKTIVNÍ DB A PRAVIDLA • Aktivní databáze • Rozšíření DB systému o aktivní pravidla • Aktivní pravidlo = trigger • Událost – podmínka – akce • Reakce na změnu dat v DB – vyhodnocení podmínky – příslušná akce • Na DB úrovni • Na jednom místě • Usnadnění práce programátora • Pravidla implementována přímo v DB – společná pro všechny aplikace, které ji využívají

  5. HISTORIE • První pokusy koncem 80. let • Nestihlo se do SQL-92 • Vývojáři přináší vlastní implementace, co možná nejblíže rozpracovanému návrhu standardu • 1. polovina 90. let – Oracle • 1996 – DB2 od IBM

  6. Starburst, Oracle, DB2 Syntaxe a sémantika vybraných db

  7. Vybrané DB • Starburst • Oracle • DB2

  8. STARBUST

  9. Starbust • vyvíjeno IBM Almaden Research Center • postaveno na SQL • aktivní pravidla v rozšíření SARS (Starburst Active Rules • System) • jednoduchá syntaxe i sémantika • rozšíření jazyka umožňuje vytváření a mazání aktivních • pravidel

  10. Starburst - UPA • Událost-Podmínka-Akce (ECA, Event-Condition-Action) • Událost • INSERT, DELETE, UPDATE • Podmínka • boolovský predikát, vyjádřený v SQL • Akce • Libovolné SQL příkazy • SELECT, INSERT, DELETE, UPDATE... • Příkazy pro řízení transakcí (ROLLBACK WORK)

  11. Starburst - syntaxe CREATE RULE <název_pravidla> ON <název_tabulky> WHEN <události> [ IF <podmínka> ] THEN <SQL-akce> [ PRECEDES <seznam_názvů_pravidel> ] [ FOLLOWS <seznam_názvů_pravidel> ] <události> = INSERTED | DELETED | UPDATED [(<názvy_sloupců>)]

  12. Starburst - příklad CREATE RULE vysoke_platy ON zamestnanci WHEN INSERTED, DELETED, UPDATED IF (SELECT avg(plat) FROM zamestnanci) > 100 THEN UPDATE zamestnanci SET plat = 0.9 * plat

  13. Starburst - Čistý efekt • pomocné tabulky • INSERTED - co bylo přidáno • DELETED - co bylo smazáno • OLD-UPDATED - co se změnilo (předchozí stav) • NEW-UPDATED - co se změnilo (nový stav) • Čistý efekt (Net effect) • V tabulkách jsou jen čisté výsledky: • Příklady: • několik UPDATE stejného řádku má ve výsledku efekt jako samotný poslední z nich. • INSERT a DELETE - efekt jako DELETE

  14. Starburst - Další syntaxe • Sdružování pravidel do sad • CREATE RULESET <nazev_sady> • ALTER RULESET <nazev_sady> [ ADDRULES <pravidlo> ] [ DELRULES <pravidlo> ] • DROP RULESET <nazev_sady> • manipulace s pravidly • DEACTIVATE RULE <pravidlo> ON <tabulka> • ACTIVATE RULE <pravidlo> ON <tabulka> • DROP RULE <pravidlo> ON <tabulka>

  15. Starburst - chování triggerů • odložené spuštění - pravidla se kontrolují po COMMITu celé transakce • možnost spuštění ručně • ruční spouštění pravidel • PROCESS RULES • PROCESS RULE <pravidlo> • PROCESS RULESET <sada_pravidel> • jedno pravidlo může sledovat více událostí • více pravidel může sledovat jednu událost • pořadí pravidel je určeno pomocí FOLLOWS a PRECEDES • musí být acyklické • zajištění, aby se triggery nezacyklily, je pouze na programátorovi

  16. Starburst - sémantika • Pravidlo je: • Spuštěné (triggered) • nastala událost, ke které se váže • Bráno v úvahu (considered) • je vyhodnocena a splněna podmínka • Provedeno (executed) • je vykonána akce pravidla

  17. OracLE

  18. Oracle • triggery vyvíjeny podle připravované specifikace SQL • Dva typy aktivních pravidel: • řádkové triggery (row-level) • monitorují události na jednotlivých řádcích, při změně více řádků se spouští na každém zvlášť • příkazové triggery (statement-level) • monitorují celé příkazy, které mohou měnit více řádků najednou

  19. Oracle - syntaxe CREATE TRIGGER <název_triggeru> {BEFORE | AFTER} <události> ON <název_tabulky> [[ REFERENCING <reference> ] FOR EACH ROW [ WHEN (<podmínka>) ]] <PL/SQL_kód> <události> = INSERT | DELETE | UPDATE [OF <seznam_sloupců>] <reference> = OLD AS <stará_hodnota> | NEW AS <nová_hodnota>

  20. Oracle - UPA • Událost-Podmínka-Akce (ECA, Event-Condition-Action) • Událost • INSERT, DELETE, UPDATE • Podmínka • řádkový predikát, vyjádřený v SQL • pouze pro řádkové triggery! • Akce • Libovolný PL/SQL kód • SELECT, INSERT, DELETE, UPDATE... • bez DDL příkazů a transakčních příkazů

  21. Oracle - další syntaxe • predikáty INSERTING, DELETING, UPDATING • pro určení konkrétní události, která pravidlo spustila • reference OLD, NEW • staré a nové hodnoty změněného sloupce • pouze u řádkových triggerů • granularita • FOR EACH ROW = řádkový trigger, jinak příkazový

  22. Oracle - spouštění triggerů • není zpožděné, nastává okamžitě s událostí • dvě možnosti spuštění akce • BEFORE <událost> - těsně před provedením události • AFTER <událost> - ihned po provedení události • nelze spustit ručně (příkazem jako u Starburstu) • trigger může spustit jiný trigger • maximální hloubka zanoření 32, pak výjimka • při výjimce nebo chybě jsou vráceny všechny změny původní operace i všech triggerů

  23. Oracle - pořadí spouštění • příkazové "before" triggery • Pro každý řádek v tabulce • řádkové "before" triggery • změna řádku a kontrola jeho integrity • řádkové "after" triggery • kontrola integrity na úrovni příkazu • příkazové "after" triggery • Pořadí v rámci jednotlivých úrovní • Podle pořadí vytvoření • Nově (verze 11.1) klauzule FOLLOWS jako u Starburstu

  24. DB2

  25. DB2 - triggery • vytvořeno IBM Almaden Research Center • snaha o jednoznačnou sémantiku • podle zkušeností se systémem Starburst • každý trigger monitoruje jedinou událost • UPDATE, DELETE nebo INSERT • spouštění stejné jako u Oracle • BEFORE nebo AFTER • řádkové a příkazové triggery • více triggerů pro jednu událost • uspořádání podle času vytvoření • řádkové i příkazové triggery jsou promíchány

  26. DB2 - syntaxe CREATE TRIGGER <název_triggeru> [ BEFORE | AFTER ] <událost> [OF <sloupce>] ON <název_tabulky> [ REFERENCING <reference> ] [FOR EACH ROW | FOR EACH STATEMENT] WHEN <podmínka> <SQL_kód>

  27. DB2 - detaily • Reference - rozdílné pro příkazové a řádkové triggery <reference> = [OLD AS <původní_hodnoty> ] [ NEW AS <nové_hodnoty> ] [ OLD_TABLE AS <původní_tabulka> ] [ NEW_TABLE AS <nová_tabulka> ] • kód akce nesmí obsahovat • DDL příkazy (měnit schéma DB) • transakční příkazy • kód akce smí obsahovat volání chyb (=> rollback příkazu)

  28. DB2 - sémantika • BEFORE triggery • vhodné ke kontrole dat, před vložením do DB • nesmí měnit obsah DB (=> nespouští další triggery) • mohou upravovat měněná data vkládáním do proměnných NEW • mohou vyvolávat chyby • AFTER triggery • zastupují aplikační logiku • spuštěny po změně dat • stav před událostí musí být odvozen z přechodových tabulek (<tabulka> MINUS NEW_TABLE) UNION OLD_TABLE

  29. DB2 – příklady CREATE TRIGGER ZadanyVek BEFORE UPDATE OF Vek ON Uzivatele REFERENCING NEW AS UpravenyUzivatel FOR EACH ROW WHEN (UpravenyUzivatel.Vek IS NULL) SIGNAL SQLSTATE '70005' ('Vek musi byt uveden') CREATE TRIGGER SledovaniPoctuUzivatelu AFTER UPDATE ON Uzivatele REFERENCING OLD_TABLE AS Tab FOR EACH STATEMENT INSERT INTO PoctyUzivatelu VALUES ( CURRENT_DATE,(SELECT COUNT(*) FROM Tab) )

  30. Taxonomie aktivních db

  31. Taxonomie aktivních DB[ZÁKLADNÍ RYSY] • Pravidlo: UDÁLOST PODMÍNA AKCE (event) (condition) (action) WHEN IF THEN • Manipaluce s daty • Může obsahovat transakční příkazy (ROLLBACK) • Databázový predikát • Dotaz – je interpretován jako TRUE, pokud vrací nějakou n-tici, jinak FALSE • Typicky primitiva pro změnu DB stavu • Některé systémy mohou monitorovat časově orientované události (každý pátek, 5 hod, …) • Pravidlo vs. událost = 1:1 či 1:N (disjunktivní) • Event language – disjunkce, konjunkce, negace, precedence

  32. Taxonomie aktivních DB[BRÁNÍ V ÚVAHU] • Okamžité (immediate) • před (BEFORE), po (AFTER), namísto (INSTEAD OF) monitorované události • Odložené (deferred) • Na konci transakce (odstartované příkazem COMMIT WORK) • Po uživatelském příkazu • Následkem uživatelskéoh příkazu (např. PROCESS RULES příkaz) • Oddělené (detached) • V samostatné transakci vypuštěné počáteční transakci poté, co nastala událost, která ji vyvolala • Závislost mezi oběma transakcemi (rollback)

  33. Taxonomie aktivních DB[VYKONÁNÍ AKCE] • Okamžité (immediate) • následuje ihned po vyhodnocení podmínky (nejčastěji používané) • Odložené (deferred) • akce je odsunuta na konec transakce • akce je vyvolána uživatelským příkazem • Oddělené (detached) • stejné jako v předchozím

  34. Taxonomie aktivních DB[ÚROVEŇ SLEDOVÁNÍ ZMĚN] • Úroveň instancí (instance level) • Změny ovlivňující jednotlivé řádky tabulky (nebo individuální objekty uvnitř trídy) • Data popisující změnu jsou uloženy v NEW a OLD proměnných • Úroveň příkazů (statement level) • Událost je příkaz manipulující s daty • Data popisující změnu jsou uloženy v INSERTED nebo DELETED (OLD-UPDATED, NEW-UPDATED)

  35. Taxonomie aktivních DB[VÍCE PRAVIDEL VE STEJNOU DOBU] • Konfliktní množina (conflict set) • Aktivní pravidla, která jsou aktivována ve stejnou dobu • Je nutné mít politiku, která určí pořadí vykonávání konfliktních pravidel • Výběr je ovlivněn prioritou: • Úplné uspořádání – svázáno s číselnou prioritou • Částečné uspořádání – číselnou či relativní prioritou • Soulad mezi systémovým uspořádáním nebo nedeterministickým výběrem • Bez explicitně vyjádřené priority • Systém drží úplné uspořádání nebo nedeterministickým výběrem

  36. Taxonomie aktivních DB[PRÁCE S PRAVIDLY] • Aktivace a deaktivace pravidel • Deaktivace nebezpečná (funkce udržování integrity DB) • Součást autorizačních mechanismů • Práva pro vytvoření, změnu, mazání aktivních pravidel • Tyto akce může provádět pouze administrátor či uživatel s explicitně přidělenými právy (GRANT PRIVILEGE příkaz) • Možnost sdružovat pravidla do skupin

  37. Příklady napsány ve STARBURST Využití aktivní DB

  38. Taxonomie INTERNÍ EXTERNÍ Business rules Alerts upozornění na změnu obsahu pouze informativní zpráva bez změny obsahu • Správa integrity • Správa odvozených dat • Replikace

  39. Taxonomie INTERNÍ EXTERNÍ Business rules Alerts upozornění na změnu obsahu pouze informativní zpráva bez změny obsahu • SPRÁVA INTEGRITY • Správa odvozených dat • Replikace

  40. Správa integrity[INTEGRITY MANAGEMENT] • Integritní omezení jsou zadávána pomocí predikátů – integritní pravidla (integrity rules) • Specifikují podmínky, které musí být splněny nad DB Statické vs. dynamické Vestavěné vs. obecné Vestavěná omezení jsou fixní. Jsou to speciální konstrukce jazyka. V relačních db to jsou: klíče, unikátní atributy, NOTNULL atributy a referenční integrita. Obecná omezení jsou definovány obecným predikátem či dotazem. Například omezující podmínka na sloupec. • Statická omezení jsou predikáty vyhodnoceny nad stavem DB • Dynamická omezení jsou predikáty nad přechodem porovnávající dva stavy DB způsobené transakcí

  41. Správa integrity[GENEROVÁNÍ PRAVIDEL I] • Pravidlo: UDÁLOST PODMÍNA AKCE (event) (condition) (action) WHEN IF THEN

  42. Správa integrity[GENEROVÁNÍ PRAVIDEL II] • Pohled na pravidla: • Rušící (abort) • Pokud je porušení omezení detekováno => dojde k zrušení příkazu (rollback) • Opravná (repair) • Mohou mít stejné podmínky jako rušící pravidla • Obsahují opravnou akci, která opraví omezující podmínku • Příklad z SQL-92 je referenční integrita, která je specifikována s opravnou akcí – CASCADE, RESTRICT, SET NULL, SET DEFAULT.

  43. Správa integrity[PŘÍKLAD I] Tabulka: zamestnanci Tabulka: oddeleni • Integritní omezení je na tabulce zamestnanci: • každý zaměstnanec musí náležet jednomu oddělení, tzn. udržet podmínku: • EXISTS (SELECT* FROM oddeleni WHERE cislo_oddeleni = zamestnaci.oddeleni) • Nás však zajímají jen ti zaměstnanci, kteří poruší tuto podmínku – tzn.: zaměstnanci, které dostaneme znegováním předchozího predikátu

  44. Správa integrity[PŘÍKLAD II] • Operace, které poruší integritní omezení: • Na tabulce zamestnanci: • Přidání zaměstnance • Převelení zaměstnance na jiné oddělení • Na tabulce oddeleni: • Zrušení oddělení • Přejmenování oddělení • Následující příklad ukazuje rušící (abortivní) pravidlo

  45. Správa integrity[PŘÍKLAD – ABORT RULE I] CREATE RULE zamOdd1 ON zamestnanci WHENINSERTED, UPDATED (oddeleni) IFEXISTS ( SELECT * FROM zamestnanci WHERENOT EXISTS ( SELECT* FROM oddeleni WHERE cislo_oddeleni = oddeleni ) )THENROLLBACK

  46. Správa integrity[PŘÍKLAD – ABORT RULE II] CREATE RULE zamOdd2 ONoddeleni WHENDELETED, UPDATED (cislo_oddeleni) IFEXISTS ( SELECT * FROM zamestnanci WHERENOT EXISTS ( SELECT* FROM oddeleni WHERE cislo_oddeleni = oddeleni ) )THENROLLBACK

  47. Správa integrity[PŘÍKLAD – ABORT RULE III] • Vidí někdo nevýhodu? • Efektivita… • Kdykoli nastane daná událost, spočítá se podmínka, která bere v potaz velkou část databáze bez ohledu na transakční data (vkládaná, upravovaná) • Následující příklad ukazuje opravné (repair) pravidlo: • První nastaví do císlo_oddelení NULL pro nově vložené zaměstnance • Druhé pro změněné zaměstnance vloží do cislo_oddeleni 99 jako defaultní hodnotu oddělení

  48. Správa integrity[PŘÍKLAD - REPAIR RULE I] CREATE RULE zamOdd1 ON zamestnanci WHENINSERTED IFEXISTS ( SELECT * FROM INSERTED WHERENOT EXISTS ( SELECT* FROM oddeleni WHERE cislo_oddeleni = oddeleni ) )THENUPDATE zamestnanci SET cislo_oddeleni = NULL WHERE id IN(SELECT id FROM INSERTED) AND NOT EXISTS (SELECT* FROM oddeleni WHERE cislo_oddeleni = oddeleni)

  49. Správa integrity[PŘÍKLAD - REPAIR RULE II] CREATE RULE zamOdd2 ON zamestnanci WHENUPDATED(cislo_oddeleni) IFEXISTS ( SELECT * FROM NEW-UPDATED WHERENOT EXISTS ( SELECT* FROM oddeleni WHERE cislo_oddeleni = oddeleni ) )THENUPDATE zamestnanci SET cislo_oddeleni =99 WHERE id IN(SELECT id FROM NEW-UPDATED) AND NOT EXISTS (SELECT* FROM oddeleni WHERE cislo_oddeleni = oddeleni)

  50. Správa integrity[PŘÍKLAD - REPAIR RULE III] CREATE RULE zamOdd3 ON oddeleni WHENDELETED IFEXISTS ( SELECT * FROM zamestnanci WHERE EXISTS ( SELECT * FROM DELETED WHEREWHERE cislo_oddeleni=oddeleni ) )THENDELETE FROM zamestnanci WHERE EXISTS ( SELECT* FROM DELETEDWHERE oddeleni=cislo_oddeleni )

More Related