La ragione principale per cui le aziende decidono di non adottare il DevOps per il database è di preservare la sicurezza del database stesso. Eppure, si tratta di una concezione errata: applicando il DevSecOps al DB, infatti, è possibile creare in ambienti strutturati le condizioni per un rilascio sicuro degli script del database, gestendo al meglio potenziali rischi di sicurezza. Segui il webinar per apprendere come includere il DB all’interno della tua strategia DevSecOps.
La ragione principale per cui le aziende decidono di non adottare il DevOps per il database è di preservare la sicurezza del database stesso. Eppure, si tratta di una concezione errata: applicando il DevSecOps al DB, infatti, è possibile creare in ambienti strutturati le condizioni per un rilascio sicuro degli script del database, gestendo al meglio potenziali rischi di sicurezza. Segui il webinar per apprendere come includere il DB all’interno della tua strategia DevSecOps.
This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)
DotNetCampus - Continuous Integration con Sql ServerAlessandro Alpi
Continuous Integration con SQL Server. Come automatizzare i processi di build e di test su database SQL Server. Come includere SQL Server nei processi di Application Lifecycle Management (Database Lifecycle Management).
La continuous integration, ovvero un insieme di pratiche di sviluppo atte a rilasciare frequentemente le modifiche al nostro codice, può essere applicata anche a SQL Server. In questa sessione andremo a descrivere come mettere sotto controllo del codice sorgente i nostri database in un'ottica di teamwork e, successivamente, a capire come automatizzare il processo di test unitario al fine di prevenire regressioni e correggere quanto prima bug.
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQLPar-Tec S.p.A.
In occasione del MySQL Day 2017 di Milano il TechAdvisor Michelangelo Uberti ha fornito una panoramica delle soluzioni native di alta disponibilità di MySQL.
I punti trattati durante la presentazione sono:
- Presentazione dell’offerta Par-Tec dedicata a MySQL Enterprise
- High Availability: cause, esigenze, aspettative
- Funzionamento, benefici e limiti dei principali approcci:
- Replica tradizionale
- MySQL Cluster
- MySQL Group Replication
- La novità: MySQL InnoDB Cluster
Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su https://www.par-tec.it/dalla-replica-a-innodb-cluster-l-ha-secondo-mysql-milano
Descrizione delle opportunità e criticità in fase di informatizzazione di un magazzino esistente. Articolo di Giuseppe Daloiso, Operations Manager Gruppo DI LILLO
La presentazione della tesi magistrale in Ingegneria Informatica presso l'Università di Bologna, sviluppata durante uno stage in IBM e intitolata "ANALISI E SVILUPPO DI STRUMENTI
PERFORMANCE-AWARE PER LA
MIGRAZIONE CLOUD ENTERPRISE"
MLS - Un software per la gestione del LEAN ManufacturingAngeloScordo
Un modo migliore di gestire la produzione e di controllare il magazzino. Una soluzione snella sia come requisiti hardware, sia come struttura software. Utilizza i concetti LEAN per ridurre o eliminare i magazzini di processo e per sostituire i metodi Pull al tradizionale Push. Può sostituire vantaggiosamente i tradizionali sistemi MRP II. Colla sua facilità di gestione prende per mano il personale di produzione ed elimina la carta dall'officina.
This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)
DotNetCampus - Continuous Integration con Sql ServerAlessandro Alpi
Continuous Integration con SQL Server. Come automatizzare i processi di build e di test su database SQL Server. Come includere SQL Server nei processi di Application Lifecycle Management (Database Lifecycle Management).
La continuous integration, ovvero un insieme di pratiche di sviluppo atte a rilasciare frequentemente le modifiche al nostro codice, può essere applicata anche a SQL Server. In questa sessione andremo a descrivere come mettere sotto controllo del codice sorgente i nostri database in un'ottica di teamwork e, successivamente, a capire come automatizzare il processo di test unitario al fine di prevenire regressioni e correggere quanto prima bug.
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQLPar-Tec S.p.A.
In occasione del MySQL Day 2017 di Milano il TechAdvisor Michelangelo Uberti ha fornito una panoramica delle soluzioni native di alta disponibilità di MySQL.
I punti trattati durante la presentazione sono:
- Presentazione dell’offerta Par-Tec dedicata a MySQL Enterprise
- High Availability: cause, esigenze, aspettative
- Funzionamento, benefici e limiti dei principali approcci:
- Replica tradizionale
- MySQL Cluster
- MySQL Group Replication
- La novità: MySQL InnoDB Cluster
Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su https://www.par-tec.it/dalla-replica-a-innodb-cluster-l-ha-secondo-mysql-milano
Descrizione delle opportunità e criticità in fase di informatizzazione di un magazzino esistente. Articolo di Giuseppe Daloiso, Operations Manager Gruppo DI LILLO
La presentazione della tesi magistrale in Ingegneria Informatica presso l'Università di Bologna, sviluppata durante uno stage in IBM e intitolata "ANALISI E SVILUPPO DI STRUMENTI
PERFORMANCE-AWARE PER LA
MIGRAZIONE CLOUD ENTERPRISE"
MLS - Un software per la gestione del LEAN ManufacturingAngeloScordo
Un modo migliore di gestire la produzione e di controllare il magazzino. Una soluzione snella sia come requisiti hardware, sia come struttura software. Utilizza i concetti LEAN per ridurre o eliminare i magazzini di processo e per sostituire i metodi Pull al tradizionale Push. Può sostituire vantaggiosamente i tradizionali sistemi MRP II. Colla sua facilità di gestione prende per mano il personale di produzione ed elimina la carta dall'officina.
1. Basi di dati attive
Sommario
Approcci architetturali
Linguaggi per la specifica di trigger:
Eventi
Condizioni
Azioni
Ulteriori caratteristiche
Modello di esecuzione:
Esecuzione delle regole
Soluzione dei conflitti
Terminazione
1
2. Sommario
Trigger in SQL:
Sintassi
Modello di esecuzione
Applicazione dei trigger:
Vincoli d’integrità
Calcolo di dati derivati
Regole operative
2
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
DBMS con queste funzionalità sono conosciuti come
DBMS attivi (ADBMS), tramite cui è possibile
definire regole attive o trigger
3
3. DBMS attivi: applicazioni
Esempi di applicazioni dei DBMS attivi:
Controllo di processi
Gestione automatizzata del lavoro di ufficio
Sistemi di controllo in ambito medico
Reti di sensori
4
DBMS attivi
La conoscenza di tipo reattivo viene sottratta
ai programmi applicativi e codificata (tramite
comandi del DDL) in regole attive
Questo consente di definire il comportamento
reattivo una sola volta e di farlo condividere
da più applicazioni
Benefici in termini di efficienza e costi di
manutenzione
5
4. DBMS attivi
Iniziano ad affermarsi a partire dagli anni 90
I maggiori DBMS commerciali (Oracle, IBM
DB2, Microsoft SQL Server) sono stati estesi
con la possibilità di specificare trigger
A partire da SQL:1999 anche lo standard
recepisce tali estensioni
Attualmente i DBMS non sono
completamente allineati a SQL:2003
6
Esempio
Gestione automatizzata di un magazzino in
cui se la quantità di un prodotto scende sotto
le 4 unità devo ordinare 100 item di tale
prodotto
DBMS tradizionale: Magazzino
Prodotto Quantità
<= 3
x 5
Ordine di 100 item
DBMS
di prodotto x
3
2
1
Quantità di Vendita di 2 item
prodotto disponibile? del prodotto x 7
5. Esempio
DBMS attivo:
Trigger T: se la quantità diventa <4 allora ordina
100 item
Magazzino
Prodotto Quantità
x 5
ADBMS
Ordine di 100 item
3
di prodotto x
Trigger T
Vendita di 2 item
del prodotto x
8
DBMS attivi
Il lucido precedente mostra un esempio di
uso dei trigger per il monitoraggio
Altri esempi:
Vincoli di integrità
Alerting
Auditing
Sicurezza
Statistiche
Eccezioni
9
6. Approcci architetturali
DBMS passivi: approccio 1
controllo
Applicazioni Polling
DBMS passivo
(modifiche) periodico
risposta
Problema: determinare la frequenza ottima di polling
10
Approcci architetturali
DBMS passivi: approccio 2
Applicazioni estese
DBMS passivo con codice per il
monitoraggio di
situazioni
Problema:
• Compromette la modularità e la riusabilità del codice
• quando cambia la condizione monitorata, cambia l’applicazione
• La correttezza del comportamento del sistema dipende dalla 11
corretta implementazione dei programmi applicativi
7. Approcci architetturali
DBMS attivi
Specifica delle situazioni
da monitorare
Interrogazioni
(re-) azioni e modifiche
DBMS attivo
Eventi esterni
12
DBMS attivi
DBMS attivi:
Supportano il monitoraggio di situazioni
Integrazione della componente reattiva con le
altre componenti del DBMS
Semantica ben definita
Efficienza
Condivisione
13
8. Specifica di trigger
Una base di dati attiva è una base di dati nella quale
alcune operazioni sono automaticamente eseguite
quando si verifica una determinata situazione
interna o esterna alla base di dati
La situazione può corrispondere al fatto che:
Si verifichino eventi specifici (insert, update, ecc.)
Siano state riscontrate particolari condizioni o particolari
stati o transizioni di stato
Un trigger (o regola attiva) è il costrutto sintattico per
definire la reazione del sistema
I trigger sono specificati nel DDL del DBMS
14
Paradigma ECA
Il paradigma più noto per la definizione dei
trigger è quello Evento-Condizione-Azione
(ECA)
La forma più comune di trigger è quindi:
ON evento IF condizione THEN azione
1. Se si verifica l’evento, la condizione è
valutata
2. Se la condizione è soddisfatta l’azione
viene eseguita
15
9. Eventi
“Un evento è qualcosa che accade, che è di
interesse (per la definizione delle regole) e che
può essere mappato, dal punto di vista del
sistena, in un istante di tempo”
Aggiornamento dati: inserimento, cancellazione,
modifica
Accesso ai dati: interrogazione su una tabella
Operazioni di sistema: login utenti, operazioni
connesse alla gestione di transazioni e/o delle
autorizzazioni
Eventi temporali: ogni giorno alle 12
Eventi esterni: ad esempio, definiti da una 16
applicazione
Eventi
Possibilità di definire trigger che possono
essere attivati before o after un evento
Possibilità di combinare gli eventi (eventi
composti) tramite:
Operatori logici: and, or, ecc.
Sequenza: seleziono un trigger se due o più
eventi accadono in un certo ordine
Composizione temporale: seleziono un trigger
quando l’evento E2 avviene 5 sec. dopo l’evento
E1
17
10. Eventi
Tutti i i DBMS commerciali che forniscono i
trigger permettono di specificare come eventi
operazioni di aggiornamento dati
Alcuni (es. Oracle) ammettono come eventi
anche determinate operazioni di sistema e/o
supportano eventi composti (es. PostgreSQL)
18
Condizioni
“Una condizione è un ulteriore controllo che viene
eseguito quando il trigger è considerato e prima che
l’azione sia eseguita”
Predicati: clausola WHERE di SQL
Interrogazioni: condizione vera se e solo se
l’interrogazione non restituisce l’insieme vuoto
In entrambi i casi precedenti, per ragioni di
efficienza, è di solito possibile utilizzare solo un
sottoinsieme di quanto offerto da SQL
Funzioni applicative: chiamata ad una funzione
19
11. Condizioni
La condizione può far riferimento a stati
passati o a variabili di sistema (es. id utente)
Se la condizione non c’è si assume vera
Non tutti i DBMS commerciali permettono la
definizione della condizione (vedi SQL Server
e PostgreSQL)
20
Condizioni vs. eventi
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 per
basi di dati di grosse dimensioni
Inoltre, posso specificare azioni diverse
per eventi diversi e stessa condizione
21
12. Azioni
“Un’azione è una sequenza di operazioni che viene
eseguita quando il trigger è considerato e la sua
condizione è vera”
Aggiornamento dati: inserimento, cancellazione,
modifica
Accesso ai dati: interrogazione su una tabella
Altri comandi: definizione dati, controllo delle
transazioni (commit, rollback), specifica/revoca
autorizzazioni
Procedure applicative: chiamata ad una procedura
22
Tabelle di transizione
L’insieme delle tuple inserite, cancellate o
modificate da un evento viene chiamato
tabella di transizione
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 dell’azione di un trigger
23
13. Comandi per la gestione di
trigger
I DBMS che forniscono funzionalità attive
prevedono comandi per la:
Creazione/cancellazione e modifica di trigger
Temporanea abilitazione/disabilitazione di trigger
24
Esempio
Relazione Film
Trigger T: assegna un valore di default all’attributo
valutaz, se questo non è specificato al momento
dell’inserimento della tupla
Il valore di valutaz è posto uguale alla media delle
valutazioni, calcolata su tutte le tuple presenti nella
relazione Film
Trigger T:
Evento: inserimento nella relazione Film
Condizione: valutaz IS NULL
Azione: calcolo del valor medio di valutaz ed
assegnazione di tale valore all’attributo valutaz delle tuple
inserite
25
14. Modello di esecuzione
Attività fondamentali in un ADBMS:
1. Rilevare gli eventi ed attivare i trigger corrispondenti
2. Processo reattivo: selezionare ed eseguire i trigger
Possono essere eseguite concorrentemente
Possibile modello:
attività 1:
While true do
seleziona eventi
attiva i trigger appropriati
endWhile
26
Modello di esecuzione selezione
valutazione
attività 2:
While ci sono trigger da considerare Do
(1) seleziona un trigger T
(2) valuta la condizione di T
(3) If la condizione di T è vera Then
esegui l’azione di T endIf
endWhile esecuzione
Scelta di uno dei trigger attivati dall’evento
1)
Valutazione della condizione del trigger selezionato, il trigger
2)
viene eliminato dall’insieme dei trigger da considerate
Verifica condizione ed esecuzione sequenziale delle operazioni
3)
27
nell’azione
15. Processo reattivo
L’esecuzione di un trigger può provocare
nuovi eventi che possono a loro volta attivare
altri trigger
Tali trigger possono:
Essere aggiunti all’insieme di trigger da
considerare (modalità iterativa)
Possono dar origine ad una nuova esecuzione
dell’algoritmo durante l’esecuzione dell’azione del
trigger correntemente attivato (modalità ricorsiva)
28
Processo reattivo
Il processo reattivo è influenzato da molti fattori:
Granularità di attivazione
Modalità di esecuzione dei trigger
Coupling mode
Conflitti
Terminazione
29
16. Granularità del processo reattivo
Frequenza di attivazione del processo reattivo
Granularità comuni:
Sempre, non appena un evento si verifica
Dopo l’esecuzione di un comando SQL
Al termine di ogni transazione
Maggiore è la granularità, maggiore sarà il numero
di trigger da considerare durante il processo reattivo
La selezione del trigger avviene mediante una
priorità
30
Priorità
Priorità:
Assoluta
Relativa
Assegnate dall’utente
Determinate implicitamente dal sistema
Calcolate in base a:
Proprietà statiche (es. momento della creazione)
Proprietà dinamiche (es. trigger attivato più/meno di
recente)
Per ragioni di efficienza, spesso i DBMS commerciali
utilizzano priorità assolute basate su proprietà statiche
31
17. Esempio
Transazione:
Inserisce un insieme di film nella relazione Film
1.
mediante un singolo comando INSERT
Inserisce un insieme di video nella relazione
2.
Video per i film inseriti al punto (1), mediante un
singolo comando INSERT, ma solo se la
valutazione dei film contenuti è > 2, altrimenti i
video non vengono inseriti in quanto si assume
che il film non riscuoterà successo
32
Esempio
Granularità “sempre”:
Eventi: esecuzione comandi SQL:
Processo reattivo: dopo l’esecuzione di (1) e dopo
l’esecuzione di (2)
Eventi: operazioni che coinvolgono singole tuple:
Processo reattivo: una volta per ogni film e video inserito
Granularità “comando SQL”
Processo reattivo: dopo l’esecuzione di (1) e dopo
l’esecuzione di (2)
Granularità “transazione”:
Processo reattivo: al commit della transazione
33
18. Esecuzione dei trigger
Due modalità:
Orientata all’istanza (instance oriented): il
trigger selezionato è eseguito una volta per
ogni tupla coinvolta nell’evento che attiva il
trigger e soddisfa la condizione
Orientata all’insieme (set oriented): il trigger è
eseguito una sola volta per tutte le tuple
coinvolte nell’evento
Possono esserci differenze nel risultato
34
Esecuzione dei trigger
Trigger T visto in precedenza:
Azione: assegnare un valore di default
all’attributo valutaz se questo non è specificato al
momento dell’inserimento della tupla
Il valore dell’attributo valutaz è posto uguale alla
media delle valutazioni calcolata su tutte le tuple
presenti nella relazione Film
Comando SQL che inserisce 5 tuple in Film
35
19. Esecuzione dei trigger
Esecuzione orientata all’insieme: tutti i 5
film inseriti avranno lo stesso valore per
l’attributo valutaz
Esecuzione orientata all’istanza: i 5 film
inseriti avranno valori dell’attributo valutaz
potenzialmente diversi perché la media è
calcolata su insiemi differenti di valori
36
Riprendiamo il processo
reattivo
While ci sono trigger da considerare Do
(1) seleziona un trigger T
(2) valuta la condizione di T
(3) If la condizione di T è vera Then
esegui l’azione di T endIf
endWhile
37
20. Processo reattivo
Esecuzione orientata all’insieme: i passi (2) e (3)
vengono eseguiti una sola volta, per l’insieme di
tuple coinvolte nell’evento che ha attivato il trigger
selezionato al passo (1). L’insieme delle tuple
aggiornate dall’evento viene chiamato tabella di
transizione
Esecuzione orientata all’istanza: i passi (2) e (3)
vengono eseguiti una volta, per ogni tupla coinvolta
nell’evento che ha attivato il trigger selezionato al
passo (1). La tupla coinvolta nell’evento viene
chiamata variabile o tupla di transizione
38
Coupling mode
Specificato per regolare la relazione tra:
Evento e condizione: quando devo testare la
condizione rispetto all’accadere dell’evento?
Subito, alla fine della transazione che genera
l’evento…
Condizione ed azione: quando devo eseguire
l’azione rispetto alla valutazione della
condizione? Appena la condizione è verificata,
alla fine della transazione corrente, …
39
21. Coupling mode
Possibilità:
Immediato: immediatamente nella stessa transazione
Differito: al momento del commit della transazione
corrente
Separato: in una nuova transazione
Modalità differita:
Utile per trigger che modellano vincoli di integrità
Durante l’esecuzione, una transazione potrebbe violare un
vincolo ma prima del commit potrebbe ripristinare uno
stato consistente
Modalità separata:
Utile in presenza di molti trigger da attivare
40
Coupling mode
Tra evento e condizione (modalità CA immediata)
41
22. Esempio
Consideriamo il trigger relativo all’attributo valutaz
visto in precedenza e la transazione T1 che:
Inserisce un insieme di film mediante un unico comando
1.
INSERT
Inserisce con un unico comando di INSERT un insieme di
2.
video relativi ai film inseriti al punto (1), ma solo se la
valutazione dei film in essi contenuti è maggiore di 2
Granularità processo reattivo: singolo comando, coupling
mode CA immediato
42
Esempio
T1 inserisce il film Kill Bill I di Quentin
Tarantino per cui non è specificata la
valutazione
Coupling mode EC:
Immediato:
Il trigger viene eseguito prima del passo (2) della
transazione, viene assegnato all’attributo valutaz il
valor medio delle valutazioni dei film presenti nella
base di dati, supponiamo pari a 2.5
Viene eseguito il passo (2) ed eventuali video relativi
al film Kill Bill I vengono inseriti nella tabella Video
43
23. Esempio
Coupling mode EC:
Differito:
Il passo (2) della transazione viene eseguito prima
dell’esecuzione del trigger
Essendo il valore dell’attributo valutaz della tupla inserita
uguale a NULL, eventuali video relativi a Kill Bill I non
vengono inseriti
La valutazione del film Kill Bill I viene modificata dal trigger
al termine della transazione
In caso di errore durante l’esecuzione dell’azione del
trigger, i film ed i video inseriti dalla transazione verranno
rimossi in seguito al rollback della transazione
44
Esempio
Coupling mode EC:
Separato:
Comportamento analogo al caso precedente
L’unica differenza è che in caso di errore durante
l’esecuzione dell’azione del trigger, i film ed i video
inseriti dalla transazione non vengono rimossi, in
quanto inseriti da una transazione separata. Non sarà
però aggiornato il valore dell’attributo valutaz
45
24. Terminazione
Il processo reattivo potrebbe non terminare
Soluzioni possibili:
Lasciare al progettista il compito di progettare i
trigger in modo che sia assicurata la terminazione
Fissare un limite superiore al numero massimo di
trigger che possono essere attivati
Restrizioni sintattiche sui trigger per garantire la
terminazione:
I trigger non possono attivarsi a vicenda
I trigger possono attivarsi a vicenda ma non formando cicli
I trigger possono formare cicli ma si garantisce che la
condizione di qualche trigger, prima o poi, diventi falsa
46
Trigger in SQL
25. Creazione trigger
CREATE TRIGGER <nome trigger>
{BEFORE | AFTER} <evento> ON <tabella soggetto>
[REFERENCING { OLD [ROW] AS <variabile> |
NEW [ROW] AS <variabile> |
OLD TABLE AS <variabile> |
NEW TABLE AS <variabile> }]
[FOR EACH {ROW | STATEMENT}]
[WHEN <condizione>]
{<comando SQL> |
BEGIN ATOMIC <sequenza di comandi SQL> END} ;
48
Evento
Possibili eventi: INSERT, DELETE, UPDATE,
UPDATE [OF <lista attributi>] per la tabella soggetto
Se si specifica UPDATE OF a1,…,an, il trigger viene
attivato solo da un evento che modifica tutti e soli gli
attributi a1,…,an
Un solo evento può attivare un trigger, quindi non
sono possibili eventi composti
E’ possibile specificare che il trigger sia attivato
prima (before) o dopo (after) l’esecuzione
dell’operazione associata all’evento
49
26. Clausola REFERENCING
La clausola REFERENCING permette di
specificare alias a livello di tabella o tupla di
transizione
La parola chiave OLD permette di specificare
alias per la tabella/tupla di transizione
esistente prima dell’esecuzione dell’evento,
NEW per quella esistente dopo l’esecuzione
dell’evento
50
Condizione ed azione
Condizione:
Espressione booleana SQL arbitraria
Azione:
Un singolo comando SQL
Una sequenza di comandi SQL
Non possono contenere parametri di connessione
Condizione e azione possono essere eseguite:
FOR EACH ROW
FOR EACH STATEMENT (default)
51
27. Clausola REFERENCING
Quali tuple sono visibili durante la valutazione
della condizione e l’esecuzione dell’azione?
Dipende:
Dall’evento che ha attivato il trigger
Dal tipo di trigger (before/after)
Dal tipo di esecuzione (row/statement)
52
Clausola REFERENCING
Le tuple di transizione sono visibili solo per
esecuzioni orientate alle istanze
Per trigger di tipo BEFORE, la tabella di
transizione non è mai visibile (ma in caso di
esecuzione orientata all’istanza è visibile la
tupla di transizione)
53
28. Clausola REFERENCING
Se l’evento è INSERT:
Non si possono specificare clausole
REFERENCING OLD in quanto le tuple inserite
dall’evento non esistevano prima dell’evento
stesso
Se il trigger è di tipo BEFORE, le tuple inserite
non sono visibili nella tabella soggetto ma
possono essere accedute usando la clausola
REFERENCING NEW (a livello di tupla o tabella)
Se il trigger è di tipo AFTER, le tuple inserite sono
anche visibili nella tabella soggetto
54
Clausola REFERENCING
Se l’evento è DELETE:
Non si possono specificare clausole
REFERENCING NEW in quanto le tuple
cancellate dall’evento non esistono più dopo
l’esecuzione dell’evento
Se il trigger è di tipo BEFORE, le tuple cancellate
sono visibili nella tabella soggetto è possono
essere accedute anche usando la clausola
REFERENCING OLD (a livello di tupla o tabella)
Se il trigger è di tipo AFTER le tuple cancellate
non sono visibili nella tabella soggetto
55
29. Clausola REFERENCING
Se l’evento è UPDATE:
I valori precedenti e correnti delle tuple possono
essere acceduti usando le clausole
REFERENCING OLD e NEW (a livello di tupla o
tabella)
Se il trigger è di tipo AFTER, l’effetto della
modifica è visibile anche nella tabella soggetto
56
Azione
Nel caso di trigger di tipo BEFORE, SQL
sconsiglia l’esecuzione di comandi di
aggiornamento dei dati nel contesto
dell’azione, ma non lo vieta
Un trigger di tipo BEFORE potrebbe
aggiornare alcuni dati prima dell’esecuzione
dell’evento che ha attivato il trigger,
generando comportamenti anomali
57
30. Esempio
CREATE TRIGGER ModificaValNull
AFTER INSERT ON Film
REFERENCING NEW TABLE AS NT
FOR EACH STATEMENT
WHEN EXISTS(SELECT *
FROM NT
WHERE valutaz IS NULL)
UPDATE Film
SET valutaz = (SELECT AVG(valutaz) FROM Film)
WHERE (titolo,regista) IN (SELECT titolo,regista FROM NT);
58
Esempio
CREATE TRIGGER ModificaValNull
AFTER INSERT ON Film
REFERENCING NEW ROW AS NR
FOR EACH ROW
WHEN (NR.valutaz IS NULL)
UPDATE Film
SET valutaz = (SELECT AVG(valutaz) FROM Film)
WHERE titolo = NR.titolo AND regista = NR.regista;
Il risultato dei due trigger può essere diverso
59
31. Cancellazione trigger
DROP TRIGGER <nome trigger>;
60
Modello di esecuzione
Granularità: comando SQL
Due modalità di esecuzione:
FOR EACH ROW
FOR EACH STATEMENT (default)
Scelta trigger, dipende:
Dal tipo di trigger (before/after)
Dalla modalità di esecuzione (row/statement)
Dalla priorità. Si associano priorità assolute in base al
tempo di creazione: un trigger “vecchio” è eseguito
prima di un trigger “giovane”
61
32. Modello di esecuzione
Possono esistere vincoli specificati per la
tabella soggetto
L’esecuzione degli eventi può violare i vincoli,
questo implica che nel determinare l’ordine di
esecuzione è necessario considerare anche il
controllo dei vincoli
62
Modalità di esecuzione
La valutazione avviene secondo il seguente ordine:
Trigger BEFORE, FOR EACH STATEMENT
Per ogni tupla oggetto del comando che rappresenta
l’evento:
Trigger BEFORE, FOR EACH ROW:
Esecuzione evento per la singola tupla
Verifica dei vincoli di integrità sulla tupla, con valutazione
immediata
Trigger AFTER, FOR EACH ROW
Verifica dei vincoli con valutazione immediata sulla tabella
Trigger AFTER, FOR EACH STATEMENT
63
33. Terminazione
Lo standard non fornisce indicazioni su
questo aspetto
Non vengono poste restrizioni sintattiche per
evitare la non terminazione
I DBMS commerciali di solito fissano un limite
superiore al numero di trigger attivabili
ricorsivamente
64
Trigger: esempi di
utilizzo
34. Trigger e vincoli
I trigger sono più flessibili dei vincoli di integrità,
infatti permettono di stabilire come reagire ad una
violazione di un vincolo
Tramite trigger è inoltre possibile specificare vincoli
di transizione
La flessibilità non sempre è un vantaggio
A volte definire dei vincoli è più vantaggioso:
Migliore ottimizzazione
Meno errori di programmazione
I vincoli sono parte dello standard da lungo tempo, i trigger
no
66
Vincoli di integrità
Ogni cliente non può noleggiare più di tre
video contemporaneamente:
CREATE ASSERTION VerificaNoleggi
CHECK (NOT EXISTS
(SELECT * FROM Noleggio
WHERE dataRest IS NULL
GROUP BY codCli
HAVING COUNT(*) > 3));
67
35. Vincoli di integrità
Ogni cliente non può noleggiare più di tre
video contemporaneamente:
CREATE TRIGGER VerificaNoleggi
AFTER INSERT ON Noleggio
REFERENCING NEW ROW AS NR
FOR EACH ROW
WHEN (SELECT COUNT(*)
FROM Noleggio
WHERE dataRest IS NULL AND
codCli = NR.codCli) > 3
ROLLBACK;
68
Vincoli di integrità
Ogni cliente non può noleggiare più di tre
video contemporaneamente:
CREATE TRIGGER VerificaNoleggi
AFTER INSERT ON Noleggio
REFERENCING NEW ROW AS NR
FOR EACH ROW
WHEN (SELECT COUNT(*)
FROM Noleggio
WHERE dataRest IS NULL AND
codCli = NR.codCli) > 3
ROLLBACK;
69
36. Vincoli di integrità
Vincolo precedente, invece di abortire la
transazione se il vincolo è violato si vuole
annullare l’inserimento:
CREATE TRIGGER VerificaNoleggi
AFTER INSERT ON Noleggio
REFERENCING NEW ROW AS NR
FOR EACH ROW
WHEN (SELECT COUNT(*)
FROM Noleggio
WHERE dataRest IS NULL AND codCli = NR.codCli) > 3
DELETE FROM Noleggio
WHERE colloc = NR.colloc AND dataNol = NR.dataNol;
70
Vincoli di integrità
CREATE TRIGGER VerificaNoleggi
AFTER INSERT ON Noleggio
REFERENCING NEW TABLE AS NT
FOR EACH STATEMENT
WHEN EXISTS
(SELECT *
FROM Noleggio
WHERE Noleggio.dataRest IS NULL AND
Noleggio.codCli IN (SELECT codCli FROM NT)
GROUP BY codCli
HAVING COUNT(*) > 3)
DELETE FROM Noleggio
WHERE (colloc,dataNol) IN (SELECT colloc, dataNol FROM NT)
AND codCli IN (SELECT codCli
FROM Noleggio
WHERE Noleggio.dataRest IS NULL AND
Noleggio.codCli IN (SELECT codCli FROM NT)
GROUP BY codCli 71
HAVING COUNT(*) > 3);
37. Calcolo di dati derivati
Aggiornamento automatico attributo
ptiMancanti nella tabella Standard
Noleggio VHS: 1 punto
Noleggio DVD: 2 punti
72
Calcolo di dati derivati
CREATE TRIGGER CalcolaPtiMancanti
AFTER INSERT ON Noleggio
REFERENCING NEW ROW AS NR
FOR EACH ROW
BEGIN ATOMIC
UPDATE Standard
SET ptiMancanti = ptiMancanti - 1
WHERE codCli = NR.codCLI AND
NR.colloc IN (SELECT colloc FROM Video
WHERE tipo = 'v');
UPDATE Standard
SET ptiMancanti = ptiMancanti - 2
WHERE codCli = NR.codCLI AND
NR.colloc IN (SELECT colloc FROM Video
WHERE tipo = 'd');
END; 73
38. Regole operative
Quando il valore dell’attributo ptiMancanti
per un cliente standard diventa 0, il cliente
è rimosso dalla tabella Standard ed inserito
nella tabella VIP con bonus pari a 5 euro:
CREATE PROCEDURE OrganizzaClienti()
BEGIN
INSERT INTO VIP
SELECT codCli, 5.00
FROM Standard
WHERE ptiMancanti <= 0;
DELETE FROM Standard
WHERE ptiMancanti <=0;
END; 74
Regole operative
CREATE TRIGGER OrganizzaClienti
AFTER UPDATE OF ptiMancanti ON Standard
REFERENCING NEW ROW AS NR
FOR EACH ROW
WHEN NR.ptiMancanti <= 0
BEGIN ATOMIC
INSERT INTO VIP
VALUES (NR.codCli,5.00);
DELETE FROM Standard
WHERE codCli = NR.codCli;
END;
75