AKTIVNÍ DATABÁZE

Ladislav NovákDotazovací jazyky I - NDBI001

OBSAH

1. Úvod2. Syntaxe a sémantika vybraných DB3. Taxonomie4. Použití

ÚVOD, HISTORIE,AKTIVNÍ PRAVIDLA

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

SYNTAXE A SÉMANTIKA VYBRANÝCH DB

Starburst, Oracle, DB2

Vybrané DB

1. Starburst2. Oracle3. DB2

STARBUST

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

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

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

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

VYUŽITÍ AKTIVNÍ DBPříklady napsány ve STARBURST

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

Otázky?

Děkuji za pozornost…

Použitá literatura