Basi di dati attive

1. Basi di dati attive

2. Sommario • Preliminari • Approcci architetturali • Linguaggi per la specifica di regole • Eventi • Condizioni • Azioni • Ulteriori caratteristiche • Modello di esecuzione • Esecuzione delle regole • Soluzione dei conflitti • Modalità di accoppiamento • Terminazione

3. Sommario • Regole attive in Starbust • Regole attive in SQL-99 • Regole attive in Oracle

4. Preliminari: DBMS passivi Vs attivi • I DBMS tradizionali sono passivi: eseguono delle operazioni solo su richiesta • Spesso si ha la necessità di avere capacità reattive: il DBMS reagisce autonomamente ad alcuni eventi ed esegue determinate operazioni • In questo ultimo caso parleremo di DBMS attivi (ADBMS), per cui è possibile definire regole attive o trigger

5. Preliminari: applicazioni dei ADBMS • Esempi di applicazioni in cui i DBMS attivi sono utili: • controllo dei processi • gestione automatizzata del lavoro di ufficio • sistemi di controllo in ambito medico

6. Magazzino Prodotto Quantità DBMS x 5 Quantità di prodotto disponibile? Vendita di 2 item del prodotto x Preliminari: esempio • Esempio: gestione automatizzata di un magazzino in cui se la quantità di un prodotto scende sotto 4 devo ordinare 100 item di tale prodotto • DBMS tradizionale: 3 Ordine di 100 item di prodotto x 3 2 1

7. Preliminari: esempio (cont.) • DBMS attivo: • Regola attiva A: se la quantità diventa <=4 allora ordina 100 item Magazzino Prodotto Quantità ADBS x 5 Ordine di 100 item di prodotto x 3 Regola attiva A Vendita di 2 item del prodotto x

8. Preliminari • Questo è un esempio di uso delle regole attive per monitoraggio • Altri esempi: • vincoli di integrità • alerting • auditing • sicurezza • statistiche • viste

9. controllo Applicazioni (modifiche) Polling periodico DBMS passivo risposta Approcci architetturali DBMS passivi: approccio 1 Problema: determinare la frequenza ottima di polling

10. DBMS passivo Applicazioni estese con codice per il monitoraggio di situazioni Approcci architetturali DBMS passivi: approccio 2 Problema: • Compromette la modularità e la riusabilità del codice • quando cambia la condizione monitorata, cambia l’applicazione • La logica è esterna alla base di dati

11. Specifica delle situazioni da monitorare Interrogazioni e modifiche (re) azioni DBMS attivo Eventi esterni Approcci architetturali DBMS attivi

12. Approcci architetturali • DBMS attivi: • supportano il monitoraggio di situazioni • integrazione omogenea con le altre componenti del DBMS • semantica ben definita • efficienza

13. Linguaggi per la specifica di regole • una base di dati attiva è una base di dati nella quale alcune operazioni sono automaticamente eseguite quando si verifica una determinata situazione • la situazione può corrispondere al fatto che: • si verifichino eventi specifici, • siano riscontrati particolari condizioni o particolari stati o transizioni di stato • una regola attiva (trigger) è un costrutto sintattico per definire la reazione del sistema

14. Il paradigma ECA • Il paradigma più noto per la definizione dei trigger è quello Evento-Condizione-Azione (ECA) • Evento: • se si verifica provoca l’attivazione del trigger • Condizione: • se è soddisfatta, l’azione del trigger è eseguita • Azione: • sequenza di operazioni che può anche modificare la base di dati, viene eseguita solo se la condizione è vera

15. Il paradigma ECA • La forma più comune di trigger è quindi: ON evento IF condizione THEN azione • se si verifica l’evento, la condizione è valutata • se la condizione è soddisfatta l’azione viene eseguita • Le regole attive hanno origine dalle regole dell’ Intelligenza Artificiale • Tali regole normalmente non hanno eventi, sono della forma (CA): IF condizione THEN azione

16. Linguaggi per la specifica di regole • Perché è vantaggioso avere l’evento? • La condizione è costosa (in termini di efficienza) da valutare, mentre rilevare l’accadere di un evento è molto meno complesso • Questo problema è ancora più sentito in ambito basi di dati in cui ho grosse moli di dati • Inoltre, posso specificare azioni diverse per eventi diversi e stessa condizione

17. Che cos’è un evento? “Un evento è qualcosa che accade, o si verifica, che è di interesse e che può essere mappato in un istante di tempo” • Modifica dei dati: inserimento, cancellazione, modifica • Accesso ai dati: interrogazione su una tabella • Operazione del DBMS: login di un utente, gestione di transazioni e/o autorizzazioni • Eventi temporali: ogni giorno alle 12 • Eventi definiti da applicazioni: data troppo grande

18. Eventi • Possibilità di definire regole che possono essere attivate before o after un evento • Possibilità di combinare gli eventi (eventi compositi): • operatori logici: and, or, ecc. • sequenza: considero un trigger se due o più eventi accadono in un certo ordine • composizione temporale: considero un trigger quando l’evento E2 avviene 5 sec. dopo l’evento E1

19. Che cos’è una condizione? “Una condizioneè un ulteriore controllo che viene eseguito quando la regola è considerata e prima che l’azione sia eseguita” • Predicati: clausola WHERE di SQL, è vantaggioso avere predicati semplici perché sono più efficienti da valutare • Interrogazioni: condizione vera se e solo se l’interrogazione restituisce l’insieme vuoto • Procedure applicative: chiamata ad una procedura

20. Condizioni: osservazioni • la condizione può far riferimento a stati passati o a variabili di sistema • passaggio di parametri tra condizione e azione (non sempre possibile) • se la condizione non c’è si assume vera

21. Che cos’è una azione? “Un’azione è una sequenza di operazioni che viene eseguita quando la regola è considerata e la sua condizione è vera” • Modifica dei dati: inserimento, cancellazione, modifica • Accesso ai dati: interrogazione su una tabella • Altri comandi: definizione di dati, controllo delle transazioni (commit, rollback), garantire e revocare privilegi • Procedure applicative: chiamata ad una procedura

22. Ulteriori caratteristiche • Comandi per le regole: permettono la creazione, la modifica e la cancellazione di una regola, oppure la sua abilitazione o disabilitazione • Priorità per le regole: spesso devo scegliere quale regola attivare fra un insieme di regole • priorità relative (fra coppie di regole); più flessibili • priorità assolute (priorità numerica); aggiornamento con l’evolversi dell’insieme di regole

23. Modello di esecuzione • Attività fondamentali in un ADBMS: • rilevare gli eventi e attivare le regole corrispondenti • processo reattivo: selezionare ed eseguire le regole Possono essere eseguite concorrentemente Possibile modello: attività 1 While true do seleziona eventi attiva le regole appropriate endWhile

24. Modello di esecuzione selezione valutazione attività 2 While ci sono regole da considerare Do (1) trova una regola R da considerare (2) valuta la condizione di R (3) If la condizione di R è vera Then esegui l’azione di R endIf endWhile esecuzione • scelta non deterministica fra le regole a priorità più alta (le altre • regole rimangono attivate) • la regola viene eliminata dall’insieme di regole da considerare • verifica condizione ed esecuzione sequenziale delle operazioni • nell’azione

25. Passi del processo di esecuzione L’evento viene individuato dal DBMS Source signaling Individuazione del corpo della regola e relativa istanziazione Verifica evento triggering Determinaz. ordine di esecuz. delle regole (soluzione conflitti) Attivita’ 1 Triggered scheduling Regole attivate Valutazione della condizione valutazione Valutaz. regole esecuzione signaling Attivita’ 2 Esecuz. regole

26. Modello di esecuzione • Granularità del processo reattivo: frequenza di attivazione del processo • Gerarchia di granularità comuni: • sempre, non appena un evento si verifica • dopo un comando di manipolazione dei dati completo (es. dopo un comando SQL) • ai confini (start o commit) di una transazione (insieme di comandi) • Momenti di attivazione specificati dall’applicazione

27. Esecuzione delle regole • Due modalità: • orientata all’istanza (instance oriented): la regola attivata è eseguita (azione) per ogni elemento della base di dati che attiva la regola e soddisfa la condizione • orientata all’insieme (set oriented): la regola è eseguita una volta per l’insieme di tali elementi • dipende dalla granularità del processo reattivo es. Granularità “sempre”  orientata all’istanza • possono esserci differenze nel risultato

28. Esecuzione delle regole • Esempio: relazione Impiegati • regola R: • azione = sostituire il valore dell’attributo Stipendio delle tuple inserite con il valore medio + 5 di Stipendio calcolato su tutte le tuple della relazione Impiegati • esecuzione orientata all’insieme: tutti gli impiegati appena inseriti avranno lo stesso valore per l’attributo Stipendio • esecuzione orientata all’istanza: gli impiegati appena inseriti avranno valori di Stipendio diversi

29. Soluzione dei conflitti • Il passo (1) del processo reattivo considera una sola regola • In realtà, più regole possono essere attivate nello stesso momento: • l’evento attiva più regole • la granularità del processo reattivo è grossolana • molti eventi si verificano prima che la regola venga attivata • regole attivate e non selezionate al passo (1) del processo reattivo sono ancora attivate • E’ necessario scegliere una regola fra le regole attivate

30. Soluzione dei conflitti • Come scegliere una regola fra un insieme di regole attivate? • arbitrariamente • priorità • assoluta • relativa • proprietà statistiche (e.g., momento della creazione) • proprietà dinamiche (e.g., regola attivata più di recente) • alternativa: valutare più regole concorrentemente

31. Modalità di accoppiamento (coupling modes) • Regole che stabiliscono le relazioni esistenti tra la transazione che genera l’evento e il processamento delle regole • Specificate per regolare relazione tra: • evento e condizione • condizione e azione

32. Modalità di accoppiamento • Possibili modalità di accoppiamento sono: • Immediata: immediatamente nella stessa transazione • Differita: al momento del commit della transazione corrente • Separata: in una nuova transazione • differita: • utile per vincoli di integrita’ • durante l’esecuzione, una transazione potrebbe violare un vincolo ma prima del commit potrebbe ripristinare uno stato consistente

33. Modalità di accoppiamento modalità EC (modalità CA immediata)

34. Il problema della terminazione • Il processo reattivo potrebbe non terminare • Soluzioni possibili: • lasciare al progettista il compito di progettare le regole di modo che la non terminazione non si verifichi • fissare un limite superiore che stabilisce un numero massimo di regole che possono essere attivate • restrizioni sintattiche sulle regole per garantire la terminazione: • le regole non si possono attivare a vicenda • le regole si possono attivare a vicenda ma non formano cicli • le regole possono formare cicli ma si garantisce che la condizione di qualche regola, prima o poi, diventa falsa

35. Tabelle di transizione • Sono relazioni che permettono di riferire l’insieme di tuple che sono state effettivamente • inserite • cancellate • modificate • Nel caso di “tuple modificate” le tabelle sono due: una contiene i valori prima della modifica, mentre l’altra contiene i valori successivi alla modifica • Possono essere usate nella valutazione della condizione e/o della azione di una regola • Migliorano l’efficienza, limitando la valutazione della condizione della regola alla tabella di transizione

36. Le regole attive in Starbust

37. Starbust • Progetto di ricerca sviluppato all’IBM • Starbust: DBMS relazionale estensibile al quale è stata aggiunta una componente attiva • Ha influenzato molto lo standard SQL:1999 • Completa integrazione della componente reattiva del sistema con il linguaggio di interrogazione e le transazioni

38. Starbust • Regola in Starbust: CREATE RULE Nome ON Relazione WHEN Eventi [IF Condizione] THEN Lista Azioni [PRECEDES Lista Regole] [FOLLOWS Lista Regole] • Nota: più di un evento può attivare una regola

39. Starbust - eventi e condizioni • Possibili eventi: • inserted • deleted • updated • updated(a1,…,an) • Condizione: condizione SQL • Nota: non c’è passaggio di parametri

40. Starbust - azioni • Possibili azioni: • Comandi di manipolazione INSERT, DELETE, UPDATE, SELECT • Comandi di definizione CREATE/DROP TABLE, CREATE/DROP VIEW, DROP RULE • Comando transazionale di ROLLBACK • Clausole PRECEDES/FOLLOWS vengono utilizzate per definire delle priorità relative fra le regole

41. Starbust - esempio • Si considerino le due tabelle Impiegati(Imp#,Stipendio,Dip#) Dipartimenti(Dip#,Dirigente) • Si vuole imporre il seguente vincolo: lo stipendio di un impiegato non può essere maggiore dello stipendio del direttore del dipartimento in cui lavora

42. Starbust - esempio (cont.) • Per garantire il precedente vincolo si può definire la seguente regola attiva: CREATE RULE stipendio_troppo_alto ON Impiegati WHEN inserted, updated(Stipendio), updated(Dip#) IF SELECT * FROM Impiegati E, Impiegati M, Dipartimenti D WHERE E.Stipendio>M.Stipendio AND E.Dip#=D.Dip# AND D.Dirigente = M.Imp# THEN ROLLBACK; • Nota: dovrei definire una regola simile su Dipartimenti

43. Starbust - transition table • insieme di tuple che sono state effettivamente inserite, cancellate, modificate • dette anche delta table • migliorano l’efficienza e il potere espressivo

44. Starbust - transition table • Starbust ammette le seguenti transition table: • inserted • deleted • new-updated, old-updated • Le transition table sono usate nella valutazione della condizione e nell’azione

45. Starbust - esempio • Si considerino le due tabelle Impiegati(Imp#,Stipendio,Dip#) Dipartimenti(Dip#,Dirigente) • Si vuole imporre il seguente vincolo: lo stipendio di un impiegato non può essere aumentato più di 100

46. Starbust - es. (cont.) • Per garantire il precedente vincolo si può definire la seguente regola attiva: CREATE RULE aumento_troppo_alto ON Impiegati WHEN updated(Stipendio) IF EXISTS (SELECT * FROM old-updated ou, new-updated nu WHERE nu.Stipendio-ou.Stipendio>100) THEN ROLLBACK;

47. Starbust - es. (cont.) • Si supponga adesso di voler inserire nella relazione Ben_Pagato gli impiegati che guadagnano più di 3000 CREATE RULE ins_in_bp ON Impiegati WHEN inserted THEN INSERT INTO Ben_Pagato SELECT * FROM inserted WHERE Stipendio > 3000 FOLLOWS aumento_troppo_alto ;

48. Starbust - es. (cont.) • Se lo stipendio medio degli impiegati inseriti eccede la media dello stipendio di tutti gli impiegati di almeno 1000, assegnare a tutti gli impiegati inseriti uno stipendio pari a 5000 CREATE RULE avg_ins ON Impiegati WHEN inserted IF (SELECT avg(Stipendio) FROM inserted) - (SELECT avg(Stipendio) FROM Impiegati) > 1000 THEN UPDATE Impiegati SET Stipendio = 5000 WHERE Imp# IN (SELECT Imp# FROM inserted);

49. Starbust- altri comandi • CREATE • DROP • ALTER • DEACTIVATE • la regola non puo’ piu’ essere attivata • ACTIVATE

50. Starbust - esecuzione regole • Granularita’ transazionale di default • possibilità di richiedere esplicitamente l’attivazione del processo reattivo (processing point) con il comando PROCESS RULES • esecuzione set-oriented • le regole sono eseguite alla fine delle transazioni • EC deferred • CA immediate • la semantica si basa sulla nozione di transizione di stato e di effetto netto