Come abbiamo visto nell’articolo SQL: creazione di un database, la creazione di un database richiede sia una modellazione concettuale del contesto sia la definizione di scripts SQL per la definizione delle strutture delle tabelle. Una volta che il nostro database è stato creato è necessario popolarlo con i dati a nostra disposizione e/o con le informazioni derivanti dalle interazioni degli utenti delle nostre applicazioni. Per far ciò bisogna utilizzare i comandi che ricadono nella categoria Data Manipulation Language o più semplicemente DML.
In particolare, alcune istruzioni DML modificano lo stato della base dati, ossia alterano il suo contenuto. I comandi che analizzeremo in questo articolo sono:
- INSERT
- DELETE
- UPDATE
Quando queste istruzioni vengono eseguite, il DataBase Management System (DBMS) deve verificare che tutti i vincoli definiti sui singoli campi e i vincoli di integrità referenziale tra le tabelle siano rispettati. Diversamente la modifica dei dati non deve essere eseguita e la base dati deve essere riportata allo stato precedente l’esecuzione dell’istruzione incriminata. Questa è la proprietà della “Consistenza”, una delle proprietà ACID delle transazioni, che si applica anche alle singole istruzioni.
Prima di procedere con l’analisi della sintassi delle istruzioni di modifica di una base dati, introduciamo il concetto di transazione e le sue proprietà affinché il contesto in cui operiamo sia più chiaro.
Transazioni
Le transazioni sono un concetto fondamentale nei database. Introdotte fin dai primi sviluppi dei database relazionali, esse hanno giocato un ruolo fondamentale nel successo dei database relazionali sul mercato. Ancora oggi sono uno dei motivi principali che rende i database relazionali più utilizzati in molti contesti. Infatti, molti database NoSQL non offrivano questa funzionalità fino a qualche anno fa. Ad esempio, MongoDB ha introdotto le transazioni solo dalla versione 3 e con alcune limitazioni. Altri database NoSQL tuttora non implementano questa funzionalità a causa della complessa gestione delle transazioni in un ambiente distribuito.
Ma cosa sono le transazioni? Per comprendere al meglio il loro meccanismo facciamo prima un esempio (anche abbastanza classico!).
Supponiamo che un cliente di una banca voglia trasferire del denaro dal suo conto corrente a quello di un altro cliente della stessa banca. Notate bene che abbiamo semplificato il contesto per fare in modo che le operazioni di scrittura siano all’interno dello stesso database e comprendere al meglio il concetto di transazione. In questo esempio l’applicazione dovrà compiere almeno due operazioni di scrittura sul database: una sottrazione della somma indicata dall’utente dal saldo del suo conto e un accredito della stessa somma sul conto corrente del destinatario. Entrambe queste operazioni di scrittura devono essere eseguite senza problemi. Diversamente potete immaginare che qualcuno perderà del denaro!
I problemi che possono generare un’interruzione di una delle operazioni sono molteplici. Potrebbe succedere che il cliente che dispone il trasferimento di denaro non abbia abbastanza fondi sul suo conto, oppure che l’IBAN del conto del destinatario non esista. Possono insorgere anche problemi tecnici come un’interruzione del servizio mentre si effettua l’operazione.
Il DBMS deve quindi fornire un meccanismo robusto affinché annulli tutte le operazioni eseguite se succede qualcosa di anomalo durante l’esecuzione della procedura. Questo meccanismo viene chiamato transazione. Le transazioni offrono non solo il meccanismo per ripristinare i dati del database a seguito di un malfunzionamento, ma anche la gestione dell’accesso concorrente ai dati.
Vediamo ora le proprietà delle transazioni per capirle al meglio.
Proprietà delle transazioni
Le transazioni sono definite come un’unità logica di lavoro, non ulteriormente scomponibile composta da istruzioni SQL di lettura e modifica dei dati che porta la base di dati da uno stato consistente a un altro stato consistente. I dati modificati dalla transazione saranno visibili e disponibili alle altre transazioni e utenti solo quando la transazione terminerà con successo. Il comando che indica la terminazione con successo è il COMMIT. Diversamente quando succede un errore il comando che viene eseguito è il ROLLBACK.
Le proprietà principali delle transazioni, riassunte dall’acronimo (inglese) ACID sono:
- Atomicity
- Consistency
- Isolation
- Durability
Atomicità
Una transazione è definita come un’unità indivisibile (atomo) di lavoro, ossia tutte le operazioni contenute nella transazione devono essere eseguite senza errori. Se un errore o un malfunzionamento avviene durante l’esecuzione delle operazioni contenute all’interno della transazione, tutto ciò che è stato eseguito fino a quel momento deve essere annullato. La base di dati non può rimanere in uno stato intermedio assunto durante l’esecuzione di una transazione.
Consistenza
L’esecuzione di una transazione deve portare la base di dati da uno stato iniziale consistente (corretto) a uno stato finale consistente. La correttezza è verificata dai vincoli di integrità definiti sulla base di dati. Quando si verifica la violazione di un vincolo di integrità il DBMS interviene per annullare la transazione oppure, per modificare lo stato della base di dati eliminando la violazione del vincolo.
Isolamento
L’esecuzione di una transazione è indipendente dalla contemporanea esecuzione di altre transazioni. Le modifiche sui dati effettuate da una transazione non sono visibili dalle altre transazioni finché la transazione non è terminata con successo. Per questo motivo il DBMS non salva gli stati intermedi della transazione in quanto non sono stabili per essere condivisi con le altre transazioni. Infatti, uno stato intermedio potrebbe essere annullato da un rollback successivo, cosa che comporterebbe un effetto domino su tutte le transazioni che hanno letto lo stato intermedio.
Persistenza
Le modifiche eseguite all’interno di una transazione terminata con successo (è stato eseguito il COMMIT) sono memorizzate in modo permanente. Ciò significa che, anche se i dati non sono stati ancora salvati su disco, il DBMS offre dei meccanismi di ripristino dello stato corretto della base di dati dopo che si è verificato un guasto.
Operazioni di manipolazione dati
Adesso che abbiamo visto le proprietà delle transazioni che si applicano anche alle singole operazioni qualora non siano inserite in una transazione, analizziamo le istruzioni di manipolazione dei dati. Ogni istruzione che vedremo può aggiornare il contenuto di una sola tabella alla volta.
INSERT
Questo comando viene utilizzato per inserire una o più righe di dati in un database. Prima di inserire i dati bisogna assicurarsi che la tabella sia già stata creata. La sintassi della query INSERT è la seguente:
INSERT INTO TableName [(ColumnsList)]
VALUES (ValueList);
È possibile anche inserire più tuple che vengono restituite dall’esecuzione di una query. La sintassi in questo caso è la seguente:
INSERT INTO TableName [(ColumnsList)]
Query;
Quando viene eseguita una INSERT, il DBMS controlla che la tipologia di dato fornita per ciascun campo sia corretta, che i vincoli di dominio, di tupla e di integrità referenziali (qualora siano definiti) siano soddisfatti.
UPDATE
Questo comando viene utilizzato per aggiornare i dati esistenti in una o più righe o colonne utilizzando le clausole UPDATE e WHERE. La sintassi della query UPDATE è la seguente:
UPDATE TableName
SET column = expression
{, column = expression }
[ WHERE predicate];
Qualora l’UPDATE modifichi i campi su cui è definito un vincolo di integrità referenziale, il DBMS deve verificare che i dati rimangano consistenti. Per far ciò si base sulle definizioni della tabella. Potrebbe, quindi, annullare l’operazione o propagare in cascata la modifica sulle tabelle referenzianti.
DELETE
Questo comando è usato per rimuovere uno o più record esistenti dalle tabelle del database. La sintassi della query DELETE è la seguente:
DELETE FROM TableName
[ WHERE predicate];
Come per l’UPDATE, il DBMS deve verificare il rispetto dei vincoli di integrità referenziale. In base alla definizione nella CREATE TABLE può annullare l’operazione oppure propagare la cancellazione sulle tabelle referenzianti.
