Basi di dati attive

Basi di dati con componente per la gestione di regole Evento-Condizione-Azione (regole di produzione). Hanno comportamento reattivo (in contrasto con passivo): eseguono non solo le transazioni utenti ma anche le regole. Le regole sono simili alle procedure, ma l’invocazione è automatica. Nell’ambito dei DBMS commerciali si parla di trigger (standardizzati in SQL-3)

Paradigma evento-condizione-azione (ECA)

• Intuitivamente:

– quando si verifica l’evento (attivazione)
– se la condizione è soddisfatta (considerazione)
– allora esegui l’azione (esecuzione)

• I trigger sono definiti con istruzioni DDL (create trigger)

– evento: modifica dei dati, specificata con insert, delete, update
– condizione (opzionale) predicato SQL
– azione: sequenza di istruzioni SQL (o estensioni, ad esempio PL/SQL in Oracle)

• Ogni trigger fa riferimento ad una tabella (target): risponde ad eventi relativi a tale tabella.

Granularità

• Granularità
– di tupla (row-level): attivazione per ogni tupla coinvolta nell’operazione.
– di operazione (statement-level): una sola attivazione per ogni istruzione SQL, con riferimento a tutte le tuple coinvolte (set-oriented)
Regola attiva

create trigger GestioneRiordino
after update of QtaDisp on Magazzino
when (new.QtaDisp < new.QtaRiord)
for each row
X exception
begin
if new.QtaDisp < 0 then raise(X);
insert into Riordino
values(new.CodProd,sysdate,new.QtaRiord)
end

Esempio: gestione automatica del riordino

1. . evento:
update(QtaDisp) in Magazzino
2. . condizione: la nuova quantità disponibile è inferiore alla (nuova) quantità di riordino:
new.QtaDisp < new.QtaRiord
3. . azione:
se la quantità disponibile è insufficiente: eccezione emissione di un ordine.

Esecuzione dell’applicazione

update Magazzino
set QtaDisp = QtaDisp – 150
where CodProd = 4

CodProd

QtaDisp

QtaRiord

Esecuzione del trigger

evento : update(QtaDisp) on Magazzino
condizione : VERA
azione : if new.QtaDisp < 0 then raise(X)
non scatta
insert into Riordino values
(new.CodProd,sysdate,new.QtaRiord)

CodProd

Data

Qta

10-10-97

Integrità referenziale

Supponiamo che la tabella magazzino abbia oltre alla voce QtaRiord e QtaDisp anche QtaMax
rappresenti la quantità massima di un articolo che può essere immagazzinato.
Si introducono due vincoli di integrità referenziale.
– La quantità di riordino non può MAI superare la quantità massima
– La quantità disponibile non può MAI superare la quantità massima
Politiche di reazione

• Diverse sono le politiche di reazione alla violazione di uno dei due vincoli.

– Abortire la transazione
– Modificare il contenuto della quantità eccedente in modo che il valore sia inferiore o uguale al valore massimo

• Attenzione agli effetti nascosti di operazioni automatiche.

Quantità disponibile

• Realizziamo la seguente politica per la gestione della quantità disponibile
• Si impedisce la transizione
• Per cui avremo

create trigger TroppoDisp
after update of QtaDisp on Magazzino
when (new.QtaDisp > new.QtaMax)
X exeception
Raise(x)

Politiche per la quantità di riordino

La politica di reazione
– ridurre del 33% la quantità disponibile fino a quando il valore non è inferiore alla quantità massima
create trigger TroppoRiod
after update of QtaRiod on Magazzino
when (new.QtaRiod > new.QtaMax)
Update Magazzino set
QtaRiod=new.QtaRiod*0.77
Where Magazzino.CodProd=new.CodProd
Esecuzione dell’applicazione

update Magazzino
set QtaRiord = 200
where CodProd = 4

CodProd

QtaDisp

QtaRiord

QtaMax

180

200

190

Descrizione

1. evento:

update(QtaRiod) in Magazzino

2. condizione: la nuova quantità di riordino è maggiore di quella massima prevista per quell’articolo
3. azione:
Si impone che la quantità di riordino sia diminuita del 33% rispetto a la valore precedente.

Esecuzione del trigger
evento : update(QtaRiord) on Magazzino
condizione : VERA
azione : Update Magazzino set

QtaRiod=new.QtaRiod*.77
Where Magazzino.CodProd=new.CodProd
• Notare che l’azione fa scatenare ancora un volta lo stesso trigger

CodProd

QtaDisp

QtaRiord

QtaMax

180

154

190

Esecuzione del trigger 2

evento : update(QtaRiord) on Magazzino
condizione : FALSA
azione : NON ESEGUITA

Conclusioni

• I trigger possono risultare utili in molti ambiti
• L’errata progettazione del trigger può portare a effetti indesiderati
• L’eccessiva proliferazione dei trigger rallenta il DBMS perché si devono controllare tutti i trigger che scattano sull’evento
• Limitazioni alla portabilità verso altri DBMS