Ladislav Novák Dotazovací jazyky I - NDBI001

Prezentace na téma: "Ladislav Novák Dotazovací jazyky I - NDBI001"— Transkript prezentace:

1 Ladislav Novák Dotazovací jazyky I - NDBI001
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 Aktivní pravidlo = trigger
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 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)
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)
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 AFTER 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 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 Příklady napsány ve STARBURST
Využití aktivní DB

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

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

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é 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á 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.

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 ID oddeleni jmeno prijmeni mzda 1 ODD07 Karel Chytrý 21 000 2 Petr Vokroutil 71 000 3 ODD13 Ivana Kamtokoukáš 18 000 ID cislo_oddeleni jmeno_odd 1 ODD01 IT 2 ODD07 Obchodní 3 ODD13 Vedení 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 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 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 SELECT * FROM OLD-UPDATED WHERE oddeleni=cislo_oddeleni

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

53 Taxonomie INTERNÍ EXTERNÍ Správa integrity SPRÁVA ODVOZENÝCH DAT
Replikace 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: Odvozená data jsou virtuálně podporována Jejich obsah je spočítán na žádost, kdykoli aplikace vyžádá pohled 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: Vložení zaměstnance oddělení Smazání 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Í EXTERNÍ Správa integrity SPRÁVA ODVOZENÝCH DAT
Replikace Business rules Alerts upozornění na změnu obsahu pouze informativní zpráva bez změny obsahu

62 Taxonomie INTERNÍ EXTERNÍ Správa integrity Správa odvozených dat
REPLIKACE 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: 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 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Í EXTERNÍ Správa integrity Správa odvozených dat
REPLIKACE 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