Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

AKTIVNÍ DATABÁZE Ladislav Novák Dotazovací jazyky I - NDBI001.

Podobné prezentace


Prezentace na téma: "AKTIVNÍ DATABÁZE Ladislav Novák Dotazovací jazyky I - NDBI001."— Transkript prezentace:

1 AKTIVNÍ DATABÁZE Ladislav Novák Dotazovací jazyky I - NDBI001

2 OBSAH 1.Úvod 2.Syntaxe a sémantika vybraných DB 3.Taxonomie 4.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 SYNTAXE A SÉMANTIKA VYBRANÝCH DB Starburst, Oracle, DB2

7 Vybrané DB 1.Starburst 2.Oracle 3.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 ON WHEN [ IF ] THEN [ PRECEDES ] [ FOLLOWS ] = INSERTED | DELETED | UPDATED [( )]

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 – ALTER RULESET [ ADDRULES ] [ DELRULES ] – DROP RULESET manipulace s pravidly – DEACTIVATE RULE ON – ACTIVATE RULE ON – DROP RULE ON

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 – PROCESS RULESET 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 {BEFORE | AFTER} ON [[ REFERENCING ] FOR EACH ROW [ WHEN ( ) ]] = INSERT | DELETE | UPDATE [OF ] = OLD AS | NEW AS

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 - těsně před provedením události – AFTER - 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 [ BEFORE | AFTER ] [OF ] ON [ REFERENCING ] [FOR EACH ROW | FOR EACH STATEMENT] WHEN

27 DB2 - detaily Reference - rozdílné pro příkazové a řádkové triggery = [OLD AS ] [ NEW AS ] [ OLD_TABLE AS ] [ NEW_TABLE AS ] 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 ( 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) WHENIFTHEN Typicky primitiva pro změnu DB stavu Některé systémy mohou monitorovat časově orientované události (každý pátek, 5 hod, …) Databázový predikát Dotaz – je interpretován jako TRUE, pokud vrací nějakou n-tici, jinak FALSE Manipaluce s daty Může obsahovat transakční příkazy (ROLLBACK) 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 VYUŽITÍ AKTIVNÍ DB Příklady napsány ve STARBURST

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

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

40 Správa integrity [INTEGRITY MANAGEMENT] Statické vs. dynamické 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í 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. Integritní omezení jsou zadávána pomocí predikátů – integritní pravidla (integrity rules) Specifikují podmínky, které musí být splněny nad DB

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

42 Správa integrity [GENEROVÁNÍ PRAVIDEL II] Pohled na pravidla: a.Rušící (abort) Pokud je porušení omezení detekováno => dojde k zrušení příkazu (rollback) b.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] IDoddelenijmenoprijmenimzda 1ODD07KarelChytrý ODD07PetrVokroutil ODD13IvanaKamtokoukáš IDcislo_oddelenijmeno_odd 1ODD01IT 2ODD07Obchodní 3ODD13Vedení Tabulka: zamestnanciTabulka: 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í: 1.Na tabulce zamestnanci: a.Přidání zaměstnance b.Převelení zaměstnance na jiné oddělení 2.Na tabulce oddeleni: a.Zrušení oddělení b.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 WHEN INSERTED, UPDATED (oddeleni) IF EXISTS ( SELECT * FROM zamestnanci WHERE NOT EXISTS ( SELECT * FROM oddeleni WHERE cislo_oddeleni = oddeleni ) )THEN ROLLBACK

46 Správa integrity [PŘÍKLAD – ABORT RULE II] CREATE RULE zamOdd2 ON oddeleni WHEN DELETED, UPDATED (cislo_oddeleni) IF EXISTS ( SELECT * FROM zamestnanci WHERE NOT EXISTS ( SELECT * FROM oddeleni WHERE cislo_oddeleni = oddeleni ) )THEN ROLLBACK

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 WHEN INSERTED IF EXISTS ( SELECT * FROM INSERTED WHERE NOT EXISTS ( SELECT * FROM oddeleni WHERE cislo_oddeleni = oddeleni ) )THEN UPDATE 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 WHEN UPDATED(cislo_oddeleni) IF EXISTS ( SELECT * FROM NEW-UPDATED WHERE NOT EXISTS ( SELECT * FROM oddeleni WHERE cislo_oddeleni = oddeleni ) )THEN UPDATE 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 WHEN DELETED IF EXISTS ( SELECT * FROM zamestnanci WHERE EXISTS ( SELECT * FROM DELETED WHERE WHERE cislo_oddeleni=oddeleni ) )THEN DELETE FROM zamestnanci WHERE EXISTS ( SELECT * FROM DELETED WHERE oddeleni=cislo_oddeleni )

51 Správa integrity [PŘÍKLAD - REPAIR RULE IV] CREATE RULE zamOdd4 ON oddeleni WHEN UPDATE(id) IF EXISTS ( SELECT * FROM zamestnanci WHERE EXISTS ( SELECT * FROM OLD-UPDATED WHERE WHERE cislo_oddeleni=oddeleni ) )THEN DELETE FROM zamestnanci WHERE EXISTS ( SELECT * FROM OLD-UPDATED WHERE oddeleni=cislo_oddeleni )

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

53 Taxonomie INTERNÍ Správa integrity SPRÁVA ODVOZENÝCH DAT Replikace EXTERNÍ Business rules – Alerts upozornění na změnu obsahu pouze informativní zpráva bez změny obsahu

54 Správa odvozených dat [DERIVED DATA MAINTENANCE] Pohled (odvozená data): Je to dotaz nad databází Dotaz vrací tabulku (nebo objektově orientovaný model) Obsah tabulky je odvozen z obsahu databáze Pohledy mohou být použity aplikacemi (stejně jako jiné tabulky) Pro podporu pohledů databáze poskytuje dvě strategie: 1.Odvozená data jsou virtuálně podporována Jejich obsah je spočítán na žádost, kdykoli aplikace vyžádá pohled 2.Odvozená data jsou materializována Jejich obsah je uložen do databáze – přístup je stejný jako k jiným datům. Obsah musí být přepočítán kdykoli se zdrojová data změní.

55 Správa odvozených dat [MATERIALIZATION] Materializace odvozených dat přes: – Úplná obnova Data se po každé změně zdrojových dat přepočítají Snadná automatická údržba pravidel – Inkrementální obnova Ze změny zdrojových dat se odvodí změna odvozených dat Na úrovni n-tic, které mají být přidány/smazány Komplikovaná pravidla

56 Správa odvozených dat [PŘÍKLAD I] Pohled, který vybere taková oddělení, která mají alespoň jedoho „bohatého“ zaměstnance (vydělává více než 50,000) DEFINE VIEW bohataOddeleni AS ( SELECT DISTINCT jmeno_odd FROM oddeleni, zamestnanci WHERE cislo_oddeleni = oddeleni AND plat > 50K )

57 Správa odvozených dat [PŘÍKLAD II] Události, které mohou způsobit přepočítání pohledu: 1.Vložení zaměstnance oddělení 2.Smazání zaměstnance oddělení 3.Aktualizace číslo oddělení umístění zaměstnance mzdy

58 Správa odvozených dat [PŘÍKLAD III - REFRESH RULES] CREATE RULE obnovBohataOdd2 ON zamestnanci WHEN INSERTED, DELETED, UPDATED(oddeleni), UPDATED(mzda) THEN DELETE * FROM bohataOddeleni; INSERT INTO bohataOddeleni: (SELECT DISTINCT jmeno_odd FROM oddeleni, zamestnanci WHERE cislo_oddeleni = oddeleni AND mzda > 50K)

59 Správa odvozených dat [PŘÍKLAD IV - REFRESH RULES] CREATE RULE obnovBohataOdd1 ON oddeleni WHEN INSERTED, DELETED, UPDATED(cislo_oddeleni) THEN DELETE * FROM bohataOddeleni; INSERT INTO bohataOddeleni: (SELECT DISTINCT jmeno_odd FROM oddeleni, zamestnanci WHERE cislo_oddeleni = oddeleni AND mzda > 50K)

60 Správa odvozených dat [PŘÍKLAD V – INCREMENTAL RULES] Inkrementální pravidlo je jednoduché pro INSERT na odděleních, ale pro ostatní je komplikované CREATE RULE incBohataOddeleni ON oddeleni WHEN INSERTED THEN INSERT INTO bohataOddeleni: (SELECT DISTINCT jmeno_odd FROM INSERTED, zamestnanci WHERE cislo_oddeleni = oddeleni AND mzda > 50K)

61 Taxonomie INTERNÍ Správa integrity SPRÁVA ODVOZENÝCH DAT Replikace EXTERNÍ Business rules – Alerts upozornění na změnu obsahu pouze informativní zpráva bez změny obsahu

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

63 Replikace [REPLICATION] Je to zvláštní forma odvozování dat mezi několika kopiemi stejných informací Používá se v distribuovaných systémech – několik kopií stejných informací jsou udržovány na jiných databázových serverech Dvě replikační schémata: 1.Zachytávací modul (capture / apply module) Rozlišuje mezi primární a sekundárními kopiemi Všchny změny prováděny na primární kopii Sekundární kopie jsou asynchroně aktulizovány Sekundární kopie jsou jen pro čtení Změny na primární kopii zaznamenány (capture) a dále propagovány (apply) na sekundárních kopiích 2.Symetrická replikace Střídavě primární a sekundární role (všechny kopie obsahují capture a apply modul)

64 Replikace [PŘÍKLAD I – CAPTURE MODULE] Aktivní pravidla poskytují mechanismum pro implementaci zachytávacího modulu Změny udržovány ve změnových tabulkách CREATE RULE zachyceni1 ON primarniKopie WHEN INSERTED THEN INSERT INTO pozitivniZmena (SELECT * FROM INSERTED) CREATE RULE zachyceni2 ON primarniKopie WHEN DELETED THEN INSERT INTO negativniZmena (SELECT * FROM DELETED)

65 Replikace [PŘÍKLAD II – CAPTURE MODULE] CREATE RULE zachyceni3 ON primarniKopie WHEN UPDATED THEN INSERT INTO pozitivniZmena (SELECT * FROM NEW-UPDATED) INSERT INTO negativniZmena (SELECT * FROM OLD-UPDATED) Změny uložené v tabulkách pozitivniZmena a negativniZmena jsou později aplikované na sekundární kopiie

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

67 Otázky? Děkuji za pozornost…

68 Použitá literatura


Stáhnout ppt "AKTIVNÍ DATABÁZE Ladislav Novák Dotazovací jazyky I - NDBI001."

Podobné prezentace


Reklamy Google