AKTIVNÍ DATABÁZE Ladislav Novák Dotazovací jazyky I - NDBI001
Jan 01, 2016
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í
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
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
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)
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ů>)]
Starburst - příklad
CREATE RULE vysoke_platyON zamestnanciWHEN INSERTED, DELETED, UPDATEDIF (SELECT avg(plat) FROMzamestnanci) > 100THEN UPDATE zamestnanci SETplat = 0.9 * plat
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
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>
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
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
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
Oracle - syntaxeCREATE 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>
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ů
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ý
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ů
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
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
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>
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)
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
DB2 – příkladyCREATE TRIGGER ZadanyVekBEFORE UPDATE OF Vek ON UzivateleREFERENCING NEW AS UpravenyUzivatelFOR EACH ROWWHEN (UpravenyUzivatel.Vek IS NULL)SIGNAL SQLSTATE '70005' ('Vek musi byt uveden')
CREATE TRIGGER SledovaniPoctuUzivateluAFTER UPDATE ON UzivateleREFERENCING OLD_TABLE AS TabFOR EACH STATEMENTINSERT INTO PoctyUzivatelu VALUES( CURRENT_DATE,(SELECT COUNT(*) FROM Tab) )
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
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)
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
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)
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
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
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
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
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
Správa integrity[GENEROVÁNÍ PRAVIDEL I]
• Pravidlo: UDÁLOST PODMÍNA AKCE (event) (condition)(action)WHEN IF THEN
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.
Správa integrity[PŘÍKLAD I]
ID oddeleni jmeno prijmeni mzda1 ODD07 Karel Chytrý 21 0002 ODD07 Petr Vokroutil 71 0003 ODD13 Ivana Kamtokoukáš 18 000
ID cislo_oddeleni jmeno_odd1 ODD01 IT2 ODD07 Obchodní3 ODD13 Vedení
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
Správa integrity[PŘÍKLAD II]
• Operace, které poruší integritní omezení:1. Na tabulce zamestnanci:
a. Přidání zaměstnanceb. 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
Správa integrity[PŘÍKLAD – ABORT RULE I]
CREATE RULE zamOdd1 ON zamestnanciWHEN INSERTED, UPDATED (oddeleni)IF EXISTS (
SELECT * FROM zamestnanciWHERE NOT EXISTS (
SELECT * FROM oddeleniWHERE cislo_oddeleni = oddeleni
))THEN ROLLBACK
Správa integrity[PŘÍKLAD – ABORT RULE II]
CREATE RULE zamOdd2 ON oddeleniWHEN DELETED, UPDATED (cislo_oddeleni)IF EXISTS (
SELECT * FROM zamestnanciWHERE NOT EXISTS (
SELECT * FROM oddeleniWHERE cislo_oddeleni = oddeleni
))THEN ROLLBACK
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í
Správa integrity[PŘÍKLAD - REPAIR RULE I]
CREATE RULE zamOdd1 ON zamestnanciWHEN INSERTEDIF EXISTS (
SELECT * FROM INSERTEDWHERE NOT EXISTS (
SELECT * FROM oddeleniWHERE 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)
Správa integrity[PŘÍKLAD - REPAIR RULE II]
CREATE RULE zamOdd2 ON zamestnanciWHEN UPDATED(cislo_oddeleni)IF EXISTS (
SELECT * FROM NEW-UPDATEDWHERE NOT EXISTS (
SELECT * FROM oddeleniWHERE 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)
Správa integrity[PŘÍKLAD - REPAIR RULE III]
CREATE RULE zamOdd3 ON oddeleniWHEN DELETEDIF EXISTS (
SELECT * FROM zamestnanciWHERE EXISTS (
SELECT * FROM DELETEDWHERE WHERE cislo_oddeleni=oddeleni
))THEN DELETE FROM zamestnanci
WHERE EXISTS (SELECT * FROM DELETED WHERE oddeleni=cislo_oddeleni
)
Správa integrity[PŘÍKLAD - REPAIR RULE IV]
CREATE RULE zamOdd4 ON oddeleniWHEN UPDATE(id)IF EXISTS (
SELECT * FROM zamestnanciWHERE EXISTS (
SELECT * FROM OLD-UPDATEDWHERE WHERE cislo_oddeleni=oddeleni
))THEN DELETE FROM zamestnanci
WHERE EXISTS (SELECT * FROM OLD-UPDATED WHERE oddeleni=cislo_oddeleni
)
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
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
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ánaJejich obsah je spočítán na žádost, kdykoli aplikace vyžádá pohled
2. Odvozená data jsou materializovánaJejich 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í.
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
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_oddFROM oddeleni, zamestnanciWHERE cislo_oddeleni = oddeleniAND plat > 50K
)
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
Správa odvozených dat[PŘÍKLAD III - REFRESH RULES]
CREATE RULE obnovBohataOdd2 ON zamestnanciWHEN INSERTED, DELETED,
UPDATED(oddeleni), UPDATED(mzda)THEN DELETE * FROM bohataOddeleni;
INSERT INTO bohataOddeleni:(SELECT DISTINCT jmeno_oddFROM oddeleni, zamestnanciWHERE cislo_oddeleni = oddeleniAND mzda > 50K)
Správa odvozených dat[PŘÍKLAD IV - REFRESH RULES]
CREATE RULE obnovBohataOdd1 ON oddeleniWHEN INSERTED, DELETED,
UPDATED(cislo_oddeleni)THEN DELETE * FROM bohataOddeleni;
INSERT INTO bohataOddeleni:(SELECT DISTINCT jmeno_oddFROM oddeleni, zamestnanciWHERE cislo_oddeleni = oddeleniAND mzda > 50K)
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 oddeleniWHEN INSERTEDTHEN INSERT INTO bohataOddeleni:
(SELECT DISTINCT jmeno_oddFROM INSERTED, zamestnanciWHERE cislo_oddeleni = oddeleniAND mzda > 50K)
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
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
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)
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 primarniKopieWHEN INSERTEDTHEN INSERT INTO pozitivniZmena
(SELECT * FROM INSERTED)
CREATE RULE zachyceni2 ON primarniKopieWHEN DELETEDTHEN INSERT INTO negativniZmena
(SELECT * FROM DELETED)
Replikace[PŘÍKLAD II – CAPTURE MODULE]
CREATE RULE zachyceni3 ON primarniKopieWHEN UPDATEDTHEN 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
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