Basi di Dati attive

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive2 Definizione Una base di dati si dice attiva quando dispone di un sottosistema integrato per definire e gestire regole di produzione (regole attive) che seguono il paradigma E (evento) – C (condizione) – A (azione) Allo stato attuale molte basi di dati relazionali sia di tipo commerciale (Oracle, MS SQL server) che open source (PostgreSQL, MySQL) possono essere considerate basi di dati attive poiché mettono a disposizione semplici regole chiamate trigger

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive3 Proprietà Comportamento reattivo – mediante l’attivazione di regole attive la base di dati è in grado di “reagire” agli eventi, in generale alle modifiche delle istanze del DB. Processore delle regole – cattura gli eventi ed esegue le regole attive determinando un alternarsi tra l’esecuzione delle transazioni, lanciate dagli utenti, e quella delle regole, lanciate dal sistema. Indipendenza della conoscenza – “azioni” sottratte ai programmi applicativi vengono codificate in regole attive, che tramite il DDL fanno parte dello schema e possono, quindi, essere condivise da tutte le applicazioni che utilizzano la base di dati attiva senza dover essere replicate negli applicativi stessi.

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive4 Il paradigma ECA Evento – è una primitiva per la manipolazione dei dati in SQL (DML): insert, update o delete Condizione – è un predicato booleano espresso in SQL (stessi operatori utilizzati per definire una condizione semplice o complessa della clausola WHERE di una selectSQL ) Azione – è in generale una sequenza di statement SQL (select, insert, update e delete) arricchita dai costrutti forniti da linguaggi di programmazione proprietari (PL/sql in Oracle, PL/pgsql in PostgreSQL) Una regola attiva è definita su una sola tabella chiamata target. La regola è attivata a seguito di un evento su tale tabella, se la condizione è verificata allora viene eseguita l’azione.

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive5 Utilità delle regole attive gestione interna (DBMS) – le regole attive possono gestire vincoli di integrità predefiniti (per es. una politica di reazione di tipo cascade per una foreign key può essere implementata con una regola attiva), calcolare attributi derivati, gestire dati duplicati e le eccezioni (per es. sollevate dalla violazione dei vincoli di integrità) gestione esterna – le regole attive permettono di codificare complesse regole aziendali (business rules) non rappresentabili in altro modo nello schema (per es. mediante check o assertion). In questo caso non esistono schemi fissi per la codifica delle regole e ciascun problema applicativo va affrontato singolarmente.

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive6 Trigger – La sintassi Problema – I trigger non sono stati definiti in SQL-92, la sintassi ed la gestione variano a seconda dello specifico DBMS utilizzato Sintassi generale per la creazione di un trigger CREATE TRIGGER NomeTrigger modalità evento {, evento} on TabellaTarget [referencing referenza] [granularità] [when (condizione)] StatementSQL

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive7 Trigger – In sintesi Attivazione Granularità Valutazione Esecuzione Un trigger in quanto regola attiva è caratterizzato dalle seguenti fasi: Attivazione, Valutazione ed Esecuzione e per ciascuna fase è possibile specificare proprietà diverse Modalità immediata (AFTER/BEFORE) Modalità differita Comporta l’esecuzione dello statementSQL che può contenere la modifica delle tuple di una tabella su cui è definito un secondo trigger che a seguito della modifica viene attivato. In altri termini, l’azione di un trigger può anche essere l’evento di un altro trigger (trigger in cascata)

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive8 Modalità: AFTER o BEFORE?? Modalità after: la valutazione avviene immediatamente dopo l’evento (caso più frequente) Modalità before: la valutazione del trigger precede logicamente l’evento a cui si riferisce Modalità differita: la valutazione avviene alla fine della transazione, a seguito del commit-work I trigger AFTER evento vengono utilizzati: 1.in applicazioni di audit, ossia nel caso in cui si devono aggiornare le tuple di una tabella B a seguito di una modifica nella tabella target A e, se esiste una clausola WHEN, solo se i nuovi dati verificano la condizione. La modalità after è necessaria poiché la modifica riuscita di una riga implica il superamento dei vincoli di integrità referenziale definiti per la tabella target e solo in questo caso il trigger viene attivato; 2.nel calcolo dei dati derivati e nella gestione delle politiche di reazione dei vincoli di integrità referenziale. I trigger BEFORE evento vengono utilizzati: 1.se si deve impostare il valore di una colonna in una riga inserita mediante un trigger, ossia se è necessario accedere ai valori “nuovi” e “vecchi” per poterli prima verificare. L’uso di un trigger AFTER INSERT non consentirebbe di impostare il valore inserito, in quanto la riga sarebbe già stata inserita nella tabella; 2.nella verifica di dati e chiavi duplicati e nella gestione delle eccezioni impedendo, in caso di errore, l’esecuzione dell’evento che ha attivato il BEFORE trigger.

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive9 Granularità & Referenza I trigger hanno due livelli di granularità: di riga (row-level): Per creare un trigger a livello di riga occorre utilizzare la clausola for each row nel comando create trigger. In questo caso il trigger viene attivato, verificato ed eseguito per ogni tupla della tabella target coinvolta dall’evento (comportamento orientato alle singole stanze). di primitiva (statement-level-è il livello di default): Per creare un trigger a livello di primitiva occorre utilizzare la clausola for each statement nel comando create trigger. In questo caso il trigger viene attivato, verificato ed eseguito una sola volta per tutte le tuple della tabella target (comportamento orientato agli insiemi). Per la definizione di un trigger è possibile fare riferimento ai “valori vecchi e nuovi” utilizzando due variabili predefinite: NEW – rappresenta la nuova tupla (esiste quando l’evento è insert oppure update) OLD – rappresenta la vecchia tupla (esiste quando l’evento è delete oppure update) Per accedere ad un campo specifico di una tupla si usa la dot notation La clausola referencing permette di rinominare tali variabili ad esempio è possibile scrivere: referencing NEW AS nuoviDati

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive10 Granularità: ROW o STATEMENT?? Le variabili NEW ed OLD sono implicitamente disponibili, per indicare la tupla nello stato precedente e successivo all’evento, solo a livello di riga. Inoltre poiché la condizione del WHEN è valutata generalmente sui valori assunti dalle tuple della tabella target se non è possibile utilizzare le variabili new ed old non è possibile esprimere neanche la condizione e pertanto viene attualmente implementata solo a livello di riga. Segue che le clausole referencing e when, rimangono sempre opzionali, ma possono essere utilizzate solo per trigger con granularità a livello di riga. I trigger FOR EACH STATEMENT vengono utilizzati: se l’azione del trigger deve essere sempre eseguita al verificarsi dell’evento su un’intera tabella. I trigger FOR EACH ROW vengono utilizzati: se l’attivazione, la valutazione o l’esecuzione di un trigger richiedono la conoscenza dello stato precedente e/o successivo all’evento.

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive11 StatementSQL Generalmente lo statementSQL si compone di due parti: una parte dichiarativa ed una esecutiva. La sintassi varia a seconda del linguaggio procedurale utilizzato. DECLARE parte dichiarativa (opzionale) BEGIN parte esecutiva END; dichiarazione di variabili con i tipi definiti da SQL-92 sequenza di istruzioni SQL (select, insert, update, delete) arricchite con strutture tipiche di ogni linguaggio procedurale quali IF [..] ELSE [..], cicli FOR e WHILE

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive12 Esempio 1: Regola aziendale TRACCIA: Creare una regola che riduca del 10% lo stipendio di tutti gli impiegati quando la media dei salari supera i 100 milioni. ANALISI: 1.L’aumento della media può avvenire a causa di un inserimento o un aggiornamento nella tabella Impiegato segue che gli eventi sono insert e update e la tabella target è Impiegato. 2.La regola va attivata subito dopo che è avvenuto l’evento che può aver aumentato la media segue che l’attivazione è immediata. 3.L’aggiornamento dello stipendio va fatto su tutte le tuple ed è attivato sulla base di una condizione (la media dei salari) che coinvolge tutte le tuple della tabella target (comportamento orientato agli insiemi) segue che la granularità è a livello di primitiva. 4.Con una granularità a livello di primitiva la clausola when non esiste quindi il valore della media va calcolato nello statementSQL come condizione della clausola where.

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive13 Esempio 1: Regola aziendale SOLUZIONE: CREATE TRIGGER ControlloStipendio after insert, update on Impiegato Begin Update Impiegato set stipendio=0,9 * stipendio where 100 < ( Select avg(stipendio) from Impiegato) end;

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive14 Esempio 2: Integrità referenziale DIPARTIMENTO(NomeDip, sede, num_dip, tel) IMPIEGATO(Codice, nome, cognome, dipart) TRACCIA: Creare una regola che reagisca alla cancellazione di un dipartimento ponendo a null il valore del campo dipart nella tabella Impiegato. SOLUZIONE: CREATE TRIGGER CancellaDipart after delete on Dipartimento for each row when (exists (Select * from Impiegato where dipart=OLD.NomeDip)) Begin Update Impiegato set dipart=null where dipart=OLD.NomeDip end;

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive15 Esempio 3: Dati derivati ORDINE(Prod, Forn, Data, qta) TOTALE(Prod, Forn, qtaTot) TRACCIA: Creare una regola che ad ogni nuovo ordine aggiorni la quantità totale ordinata. SOLUZIONE: CREATE TRIGGER AggiornaTot after insert on Ordine for each row Begin Update Totale set qtaTot=qtaTot + NEW.qta where Prod=NEW.Prod AND Forn=NEW.Forn end;

Sistemi Informativi DEE - Politecnico di Bari E. TinelliBasi di dati attive16 Esempio 4: Regola aziendale BIBLIOTECA(ISBN, titolo, editore, categoria, valutazione) AUDIT_BIBLIOTECA (ISBN, timestamp_audit, titolo, editore, categoria, nuova_valutazione, vecchia_valutazione) TRACCIA: Creare una regola che memorizzi necessariamente tutte le modifiche della valutazione di un libro nella tabella di audit ma solo nel caso si verifichi una riduzione del valore della valutazione. SOLUZIONE: CREATE TRIGGER AggiornaValutazione before update on Biblioteca for each row when (NEW.valutazione<OLD.valutazione) Begin Insert into Audit_Biblioteca(ISBN, timestamp_audit, titolo, editore, categoria, nuova_valutazione, vecchia_valutazione) values(:OLD.ISBN, current_date, :OLD.titolo, :OLD.editore, :OLD.categoria, :NEW.nuova_valutazione, :OLD.vecchia_valutazione) end; La transazione eseguita sulla tabella BIBLIOTECA dipende dal successo dell’esecuzione del trigger.