1

Le Basi di Dati Attive

Angelo Chianese, Vincenzo Moscato, Antonio Picariello, Lucio Sansone Basi di dati per la gestione dell'informazione 2/edMcGraw-HillCapitolo 8, paragrafo 8.2

Manuale PostgreSQL 36.1: Overview of Trigger Behavior

Appunti dalle lezioni

Sistemi informativi e basi di dati

Il modello relazionale

SQL come DDL

SQL come DML

SQL come DCL

La Progettazione Concettuale

Strumenti CASE

Utilizzo di un DBMS Reale

Programmazione

Forme normali

Transazioni e tecnologie di supporto

Basi di dati direzionali

Basi di dati distribuite

La Progettazione Logica

La Progettazione Fisica

2

SQL in Linguaggi di programmazione

� L’uso diretto dell’ interprete SQL ètipicamente riservato a pochi utenti esperti.

� L’utente generico accede alla base di dati attraverso applicazioni scritte usando linguaggi tradizionali di alto livello o speciali.

� I linguaggi tradizionali sono di tipo procedurale mentre SQL è un linguaggio dichiarativo.

� Le istruzioni SQL sono allora incapsulate nel linguaggio e passate all’ interprete tramite opportune chiamate.

SQL

Uso diretto

In linguaggi“classici”

Call LevelInterface

ODBC

JDBC

Stored Procedures TriggersLinguaggiad hoc

3

Stored procedures

Triggers

� I triggers sono delle stored procedures che scattano in relazione ad eventi.

� Definiti a livello di standard da SQL-3, ma presenti nei sistemi (con sintassi e caratteristiche diverse) già dalla fine degli anni Ottanta.

� Attraverso i triggers realizziamo le Basi di Date attive

� Evento Condizione Azione (E-C-A)

4

Il Paradigma E-C-A

� Evento� Una richiesta di modifica dello stato della base di

dati: INSERT, DELETE, UPDATE

� Quando avviene l’evento, il trigger viene attivato

� Condizione� Un predicato che identifica le situazioni in cui è

necessaria l’applicazione del trigger

� Quando si valuta la condizione il trigger viene considerato

� Azione� Un generico comando di modifica o una stored

procedure

� Il trigger viene eseguito

Dal punto di vista sintattico …

� I Triggers:

� Sono definiti con istruzioni DDL (create trigger)

� basati sul paradigma ECA:

� 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 detta target e risponde ad eventi relativi a tale tabella

� I valori di tale tabella vengono “congelati” prima e dopo l’ evento in due strutture dette di transizione.

5

Modo e Granularità� Modo di esecuzione

� After: il trigger è considerato ed eseguito dopo l’applicazione sulla base dati dell’azione che lo ha attivato

� Before: il trigger è considerato ed eseguito prima della applicazione alla base dati dell’azione che lo ha attivato

� Instead: il trigger è considerato al posto dell’azione che lo ha attivato

� Granularità� di tupla (row - level):

� attivazione per ogni tupla della tabella target coinvolta nell'operazione

� di operazione (statement - level): � una sola attivazione per ogni istruzione SQL, con riferimento a

tutte le ennuple della tabella target coinvolte (“set-oriented”)

Trigger: esempio

� Warehouse(Part,QtyAvbl,QtyLimit,QtyReord)

� PendigOrders(Part,Qty,Date)

6

Trigger: esempio

create trigger Reorder

after update of QtyAvbl on WAREHOUSE

for each row

when (new.QtyAvbl < new.QtyLimit)

declare X number;

begin

select count(*) into X

from PENDINGORDERS

where Part = new.Part;

if X = 0 then

insert into PENDINGORDERS

values(new.Part,new.QtyReord,sysdate)

end if;

end;

Trigger: esempio

� Viene eseguita T1:� update WAREHOUSE

set QtyAvbl = QtyAvbl – 70where Part = 1

� La esecuzione di T1 causa un’esecuzione del trigger “Reorder”� porta nella tabella PENDINGORDERS la tupla

(1,100,<oggi>);

7

Trigger: esempio� Viene eseguita T2:

� update WAREHOUSEset QtyAvbl = QtyAvbl – 60where Part <= 3

� La successiva esecuzione di T2 causa l’esecuzione del trigger “Reorder” per tre volte con soddisfacimento della condizione di scatto per le parti 1 e 3.

� L’azione relativa alla parte 1 non ha effetto select count(*) into X from PENDINGORDERSwhere Part = new.Part;

valuta X=1 � poiché è già presente la parte considerata;

� L’azione relativa alla parte 2 non ha effetto� L’azione relativa alla parte 3 porta nella tabella

PENDINGORDERS la nuova tupla (3,120,<oggi>)

Sintassi SQL:2003 dei trigger

� Lo standard propone una sintassi simile a quella offerta da IBM DB2; ogni trigger è caratterizzato da:� Nome del trigger

� nome della tabella che viene monitorata

� modo di esecuzione (BEFORE o AFTER)

� l’evento monitorato (INSERT, DELETE o UPDATE)

� granularità (statement-level o row-level)

� nomi e alias per “transition tables” e “transition rows”

� eventuale condizione

� l’azione

� il timestamp di creazione

8

Sintassi SQL:2003 dei trigger

� create trigger NomeTrigger{before | after}{ insert | delete | update [of Colonne] } on Tabella[referencing

{[old table [as] AliasTabellaOld] [new table [as] AliasTabellaNew] } |{[old [row] [as] NomeTuplaOld][new [row] [as] NomeTuplaNew] }]

[for each { row | statement }][when Condizione]ComandiSQL

Esecuzione: conflitti tra trigger

� Se vi sono più trigger associati allo stesso evento, SQL:2003 prescrive questa politica di gestione:

� Vengono eseguiti i trigger BEFORE statement-level

� Vengono eseguiti i trigger BEFORE row-level

� Si applica la modifica e si verificano i vincoli di integrità definiti sulla base di dati

� Vengono eseguiti i trigger AFTER row-level

� Vengono eseguiti i trigger AFTER statement-level

� Se vi sono più trigger della stessa categoria:

� l’ordine di esecuzione viene scelto dal sistema in un modo che dipende dall’implementazione.

9

Impiego dei trigger

� Per la descrizione di regole esterne (o regole aziendali)

� Esprimono conoscenza di tipo applicativo

� Per la descrizione di regole interne alla base di dati

� Trigger generati dal sistema e non visibili all’utente (gestione della integritàreferenziale).

Integrità referenziale: esempio

� Si consideri il seguente schema di base dati:IMPIEGATI (Matricola, Nome, Salario, Dipartimento) DIPARTIMENTI(Numero, Direttore)

� CREATE TRIGGER ControllaDipImpiegatoBEFORE INSERT ON IMPIEGATI FOR EACH ROW WHEN ( not exists select * from DIPARTIMENTI

where Numero = NEW.Dipartimento)BEGIN raise_application_error(-20000, ‘Dipartimento non valido‘); END;

10

Vincoli Integrità

� CREATE TRIGGER ControllaModificaDipartimentoAFTER UPDATE OF Numero ON DIPARTIMENTIFOR EACH ROWWHEN (exists select * from IMPIEGATI

where Dipartimento = OLD.Numero)BEGINupdate IMPIEGATI set Diaprtimento = NEW.Numerowhere Dipartimento = OLD.Numero;END;

Vicoli di Integrità

� CREATE TRIGGER ControllaCancDipartimento AFTER DELETE ON DIPARTIMENTIFOR EACH ROWWHEN (exists select * from IMPIEGATI

where Dipartimento = OLD.Numero)BEGINUPDATE IMPIEGATISET Dipartimento=NULLWHERE Dipartimento = OLD.Numero;END;

11

Triggers in PostgreSQL 9.0

� On tables � triggers can be defined to execute either

before or after any INSERT, UPDATE, or DELETE operation, either once per modified row, or once per SQL statement.

� UPDATE triggers can moreover be set to fire only if certain columns are mentioned in the SET clause of the UPDATE statement.

Esempio 1: Creare il DB

12

Esempio 1: Creare il Trigger

Esempio 1: Effetto

13

Esempio 2: Creare il DB

Esempio 2: Creare i Trigger

14

Esempio 2: Creare i Trigger

Esempio 2: Creare i Trigger

15

Esempio 2: Effetto

Triggers in PostgreSQL 9.1

� On views� triggers can be defined to execute

� instead of INSERT, UPDATE, or DELETE operations.

� It is the responsibility of the trigger's function to perform the necessary modifications to the underlying base tables and, where appropriate, return the modified row as it will appear in the view.

� INSTEAD OF triggers are fired once for each row that needs to be modified in the view.

� Triggers on views can also be defined to execute once per SQL statement, before or after INSERT, UPDATE, or DELETE operations.

16

Esempio 3: Creare il DB

Esempio 3:

� Sulla vista ovviamente ….

17

Esempio 3: Col Trigger nella 9.0

Esempio 3: RULE nella 9.0