🗄️ Transazioni nei Database

Dispensa completa per la classe 5° Informatica - Le proprietà ACID spiegate in modo chiaro e completo

📚 Informatica - Classe 5° ⏱️ Tempo di lettura: 45 minuti 📊 Livello: Intermedio

📌 1. Cos'è una Transazione?

🎯 Obiettivi di Apprendimento

  • Comprendere il concetto di transazione come unità logica di lavoro
  • Identificare scenari reali che richiedono transazioni
  • Capire perché le operazioni multiple devono essere raggruppate
🎯 Definizione

Una transazione è un insieme di operazioni che devono essere eseguite in blocco come fosse un'unica operazione (si parla di unità logica di lavoro).

🏦 L'esempio classico: il Bonifico Bancario

Immagina di dover trasferire 100€ dal conto di Alice al conto di Bob:

Tabella CONTI (prima)
IDNomeSaldo
1Alice1000€
2Bob500€
Tabella CONTI (dopo)
IDNomeSaldo
1Alice900€
2Bob600€

Per fare questo bonifico, servono DUE operazioni:

-- OPERAZIONE 1: Togli 100€ da Alice
UPDATE Conti SET saldo = saldo - 100 WHERE id = 1;

-- OPERAZIONE 2: Aggiungi 100€ a Bob
UPDATE Conti SET saldo = saldo + 100 WHERE id = 2;

⚠️ Il Problema

Cosa succede se il sistema si blocca dopo l'operazione 1 ma prima dell'operazione 2?

  • Alice ha perso 100€ ❌
  • Bob NON ha ricevuto nulla ❌
  • 100€ sono "spariti" nel nulla! 💸

La Soluzione: Usare una Transazione

BEGIN TRANSACTION;  -- Inizio transazione

UPDATE Conti SET saldo = saldo - 100 WHERE id = 1;
UPDATE Conti SET saldo = saldo + 100 WHERE id = 2;

COMMIT;  -- Conferma tutto (se OK)
-- oppure ROLLBACK; per annullare tutto (se errore)

Con la transazione: se qualcosa va storto, il database annulla automaticamente TUTTO e torna allo stato precedente!

📋 Spiegazione Dettagliata di transazione eseguita con successo con Esempio Bancario

Consideriamo un sistema bancario in cui due utenti, Anna e Bruno, possiedono rispettivamente due conti: Conto A (di Anna) e Conto B (di Bruno). Anna desidera trasferire 100€ dal suo conto al conto di Bruno.

Tabella CONTI - Stato Iniziale
ID ContoIntestatarioSaldo
AAnna200€
BBruno50€

🔄 Operazioni della Transazione di Bonifico

1. Verifica del saldo del Conto A: controllo che Anna abbia almeno 100€
2. Prelievo: sottraggo 100€ dal Conto A (saldo aggiornato a 100€)
3. Deposito: aggiungo 100€ sul Conto B (saldo aggiornato a 150€)
4. Registrazione nel log: tutte le operazioni vengono tracciate per garantire tracciabilità
5. Conferma (COMMIT): le modifiche diventano permanenti

✍️ Quiz di Verifica

1. Perché un bonifico bancario richiede una transazione?
A) Perché è un'operazione singola sul database
B) Perché coinvolge più operazioni che devono essere eseguite tutte insieme
C) Perché i database non supportano operazioni singole
D) Perché è più veloce eseguire più operazioni in transazione
2. Cosa succede se il sistema va in crash durante una transazione (con atomicità)?
A) Le modifiche parziali rimangono salvate
B) Tutte le modifiche vengono annullate automaticamente
C) Il database si corrompe
D) Solo l'ultima operazione viene eseguita

📝 Riepilogo della Sezione

  • Una transazione raggruppa più operazioni in un'unità logica
  • Le transazioni garantiscono che le operazioni correlate siano eseguite insieme
  • Senza transazioni, i crash di sistema possono causare perdita di dati

🧪 2. Le Proprietà ACID

🎯 Obiettivi di Apprendimento

  • Comprendere cosa significa l'acronimo ACID
  • Identificare le quattro proprietà fondamentali delle transazioni
  • Riconoscere l'importanza di ogni proprietà per l'integrità dei dati

Per garantire che le transazioni funzionino correttamente, i database relazionali rispettano 4 proprietà fondamentali, ricordate con l'acronimo ACID:

ACID Transazioni Affidabili A Atomicity Tutto o Niente C Consistency Vincoli Rispettati I Isolation Nessuna Interferenza D Durability Modifiche Permanenti
A

Atomicità

Tutto o niente

C

Consistenza

Vincoli sempre rispettati

I

Isolamento

Transazioni indipendenti

D

Durabilità

Dati salvati per sempre

Clicca su ogni lettera per vedere esempi dettagliati di cosa succede quando NON sono garantite!

📝 Riepilogo della Sezione

  • Atomicità: le operazioni sono indivisibili
  • Consistenza: il database rispetta sempre i vincoli
  • Isolamento: le transazioni non interferiscono tra loro
  • Durabilità: le modifiche confermate sono permanenti

⚛️ 3. Atomicità (Atomicity)

🎯 Obiettivi di Apprendimento

  • Comprendere il principio "tutto o niente" delle transazioni
  • Simulare scenari con e senza atomicità
  • Identificare le conseguenze della mancanza di atomicità

📖 Definizione

Atomicità significa che una transazione è INDIVISIBILE, o vengono eseguite tutte le operazioni con successo, oppure – in caso di errore – nessuna di esse avrà mai effetto sul database..

Regola: Il sistema può trovarsi solo in due stati:✅ Commit: Tutte le modifiche vengono salvate. ❌ Rollback: Nessuna modifica viene salvata (si torna allo stato iniziale)..

🎬 Simulazione: Bonifico CON e SENZA Atomicità

🔬 Prova tu stesso!

Clicca sui pulsanti per vedere cosa succede durante un bonifico di 100€ da Alice a Bob quando il sistema va in crash:

Clicca un pulsante per vedere la simulazione...

✅ Scenario 1: Transazione fallita con proprietà di Atomicità

Scenario: CON atomicità – Server crash durante operazione
BEGIN TRANSACTION
Sottrai 200€ da Mario → Saldo: 800€ ✓
💥 SERVER CRASH / Errore di rete PRIMA del COMMIT!
Luca NON riceve i 200€ ✗
Al riavvio della rete: ROLLBACK automatico → tutte le modifiche temporanee vengono scartate e i conti tornano allo stato che avevano prima della transazione
Risultato: Mario ha ancora 1000€, Luca ha 500€. Nessun dato è stato perso o corrotto! L'atomicità ha salvato la situazione. 👍

❌ Scenario 2: Transazione Fallita senza proprietà Atomicità

Supponiamo che durante la transazione si verifichi un errore dopo il prelievo ma prima del deposito (es. problema di connessione, errore hardware o crash di sistema):

Scenario: SENZA atomicità – Server crash durante operazione
Sottrai 200€ da Mario → Saldo: 800€ ✓
💥 SERVER CRASH / Errore di rete
Luca NON riceve i 200€ ✗
DISASTRO: Mario ha perso 200€ che sono spariti nel nulla! Luca non li ha ricevuti. I soldi sono letteralmente scomparsi dal sistema! 😱
Senza atomicità, il database non può "annullare" le modifiche temporanee apportate prima del crash e dopo il crash quelle modifiche diventano effettive e permanente → perdita di dati e inconsistenza.
💡 Perché l'Atomicità è fondamentale?
Senza atomicità, i dati diventano inconsistenti e inaffidabili. Immagina una banca dove i soldi possono sparire o apparire dal nulla!

Esempi reali:
  • Bonifico bancario: i soldi devono uscire E entrare contemporaneamente
  • Acquisto online: pagamento E prelievo dal magazzino devono avvenire insieme
  • Registrazione account: creazione profilo E invio email di conferma

✍️ Quiz: Atomicità

3. Cosa significa che una transazione è "atomica"?
A) La transazione riguarda i dati atomici (non scomponibili)
B) La transazione viene eseguita completamente o non viene eseguita affatto
C) La transazione è molto piccola e veloce
D) La transazione coinvolge solo un singolo dato

📏 4. Consistenza (Consistency)

🎯 Obiettivi di Apprendimento

  • Comprendere che la consistenza riguarda i vincoli del database
  • Identificare i tipi comuni di vincoli (chiave primaria, CHECK, NOT NULL)
  • Capire come la consistenza lavora con l'atomicità

📖 Definizione

Consistenza significa che una transazione deve portare il database da uno stato VALIDO a un altro stato VALIDO.

Regola: Tutti i vincoli del database devono essere rispettati prima E dopo la transazione.

📋 Esempi di Vincoli che Devono Essere Rispettati

  • Chiave primaria: non ci possono essere due righe con lo stesso ID
  • Chiave esterna: un ordine deve riferirsi a un cliente esistente
  • CHECK: il saldo non può essere negativo
  • NOT NULL: alcuni campi non possono essere vuoti
  • UNIQUE: certi valori devono essere univoci (email, codice fiscale)

📚 Esempio Pratico: Database di una Libreria

Consideriamo un database per la gestione di una libreria con libri e autori. Supponiamo che ci sia un vincolo di integrità referenziale che richiede che ogni libro sia associato ad almeno un autore presente nella tabella autori.

Tabella LIBRI
IDTitoloAutore_ID
1Libro A1
2Libro B2
Tabella AUTORI
IDNome
1Autore X
2Autore Y

❌ Scenario 1 senza CONSISTENZA: Tentativo di Inserimento con Vincolo Violato senza consistenza

Un utente tenta di inserire un nuovo libro nel database, ma fornisce un ID autore non valido o inesistente:

Operazione:
INSERT INTO libri (titolo, autore_id) 
VALUES ('Il grande romanzo', '12345');

Risultato:

  • L'ID autore "12345" non corrisponde a nessun autore nel database ma senza consistenza l'autore viene inserito lo stesso
  • Violazione del vincolo di integrità referenziale!
Dopo il tentativo (modifica che viola il vincolo di integrità referenziale)
IDTitoloAutore_ID
1Libro A1
2Libro B2
3Il grande romanzo12345

nuovo libro inserito - database non consistente (con vincolo di integrità violato)

✅ Scenario 2 con CONSISTENZA: Tentativo di Inserimento con Vincolo Violato con consistenza

Un utente desidera aggiungere un nuovo libro nel database, ma fornisce un ID autore non valido o inesistente:

Operazione:
INSERT INTO libri (titolo, autore_id) 
VALUES ('Il grande romanzo', '12345');

Risultato:

  • L'ID autore "12345" non corrisponde a nessun autore e quindi non è presente nella tabella referenziata ✓
  • Vincolo di integrità violato
  • Grazie ala consistenza il nuovo libro con autore non identificabile non viene aggiunto ed il database rimane in uno stato valido
Dopo la transazione
IDTitoloAutore_ID
1Libro A1
2Libro B2

Libro che viola il vincolo di integrità referenziale non inserito- database consistente

🔬 Simulazione: Prelievo con Vincolo di Saldo

🔬 Prova tu stesso!

Carlo ha 50€ sul conto. Vincolo: il saldo non può essere negativo. Cosa succede se prova a prelevare 80€?

Clicca un pulsante per vedere la simulazione...

💥 Cosa succede SENZA Consistenza

  • Saldi che diventano negativi (impossibile nella realtà)
  • Ordini che puntano a clienti inesistenti
  • Prodotti venduti più volte della disponibilità
  • Dati che violano le regole di business
  • Due utenti con lo stesso ID univoco
  • Giacenze magazzino negative (vendi più di quanto hai!)

In sintesi: Il database contiene dati "impossibili" o "sbagliati"!

✍️ Quiz: Consistenza

3. In un ordine e-commerce, quale vincolo viene violato se crei un ordine per un cliente che non esiste?
A) Vincolo CHECK
B) Vincolo di Chiave Esterna (FK)
C) Vincolo UNIQUE
D) Vincolo NOT NULL
4. Un prodotto ha 5 unità in magazzino. Due clienti ordinano contemporaneamente 5 unità ciascuno. Senza controllo di consistenza, cosa potrebbe succedere?
A) Il sistema impedisce automaticamente il secondo ordine
B) Entrambi gli ordini vengono rifiutati
C) La giacenza potrebbe diventare -5 (vendi più di quanto hai!)
D) Il database segnala automaticamente l'errore

📝 Riepilogo della Sezione

  • La consistenza garantisce il rispetto di tutti i vincoli del database
  • I vincoli comuni includono: PRIMARY KEY, FOREIGN KEY, CHECK, NOT NULL, UNIQUE
  • In un e-commerce, senza consistenza si possono creare ordini per clienti inesistenti(violazione vincolo di integrità referenziale) o vendere più prodotti di quanto disponibile (violazione vincolo quantità>=0)
  • L'atomicità e la consistenza lavorano insieme per proteggere i dati

🔒 5. Isolamento (Isolation)

🎯 Obiettivi di Apprendimento

  • Comprendere perché le transazioni concorrenti possono interferire
  • Identificare le quattro anomalie di concorrenza (Dirty Read, Lost Update, ecc.)
  • Conoscere i livelli di isolamento e quando usarli

📖 Definizione

Isolamento significa che le transazioni eseguite contemporaneamente non devono interferire tra loro.

Regola: Ogni transazione deve "vedere" il database come se fosse l'unica in esecuzione.

🎯 Perché l'Isolamento è fondamentale?

Immagina un supermercato con un solo prodotto rimasto sullo scaffale. Due clienti lo vedono contemporaneamente e vanno alla cassa convinti di averlo acquistato. Senza isolamento, il database potrebbe "vendere" lo stesso prodotto a entrambi!

L'isolamento garantisce che le operazioni concorrenti vengano gestite in modo ordinato e sicuro, come se avvenissero una dopo l'altra.

🚨 Problemi che si verificano SENZA Isolamento

Quando più transazioni accedono agli stessi dati contemporaneamente, possono verificarsi quattro tipi di anomalie:

1️⃣ Dirty Read (Lettura Sporca)

Cos'è: Una transazione legge dati modificati da un'altra transazione che non ha ancora fatto COMMIT.

Esempio: T1 modifica il saldo da 1000€ a 800€ ma non conferma. T2 legge 800€. T1 fa ROLLBACK. T2 ha letto un valore che non è mai esistito!

Gravità: 🔴 Alta - Si lavora su dati "fantasma"

2️⃣ Non-Repeatable Read (Lettura Non Ripetibile)

Cos'è: Una transazione legge lo stesso dato due volte e ottiene valori diversi.

Esempio: T1 legge il saldo: 1000€. T2 modifica e fa COMMIT: 800€. T1 rilegge: 800€. Il valore è cambiato durante la stessa transazione!

Gravità: 🟠 Media - Inconsistenza nelle letture ripetute

3️⃣ Phantom Read (Lettura Fantasma)

Cos'è: Una transazione esegue la stessa query due volte e ottiene un numero diverso di righe.

Esempio: T1 conta i clienti di Roma: 50. T2 inserisce un nuovo cliente a Roma e fa COMMIT. T1 riconta: 51. Sono apparsi "fantasmi"!

Gravità: 🟡 Media - Inconsistenza nei risultati di query

4️⃣ Lost Update (Aggiornamento Perso)

Cos'è: Due transazioni leggono lo stesso valore, lo modificano entrambe, e una sovrascrive l'altra.

Esempio: Saldo = 500€. T1 legge 500€, aggiunge 100€. T2 legge 500€, toglie 200€. T1 scrive 600€. T2 scrive 300€. L'operazione +100€ è PERSA!

Gravità: 🔴 Alta - Perdita di dati senza alcun errore visibile

🏨 Esempio Pratico: Prenotazione Camera d'Albergo

Consideriamo una pagina web che gestisce le prenotazioni di camere di un albergo. Due clienti, Marco e Laura, tentano di prenotare la stessa camera (Camera 101) quasi contemporaneamente alle 10:00:00.

📊 Scenario Iniziale
  • Camera 101: disponibile
  • Marco e Laura tentano di prenotare la stessa camera allo stesso istante (10:00:00)
  • Il DBMS deve gestire le due transazioni in modo da garantire che solo una abbia successo

✅ Scenario CON Isolamento (Transazioni Serializzabili)

Transazione di Marco (T1) - Inizio: 10:00:00.000
10:00:00.000 - Fase 1: Marco avvia la prenotazione della Camera 101
10:00:00.050 - Fase 2: T1 legge lo stato della Camera 101 → Risultato: 'disponibile'
10:00:00.100 - Fase 3: Il DBMS applica un blocco in scrittura sulla Camera 101 per T1
10:00:00.150 - Fase 4: T1 modifica lo stato da "disponibile" a "prenotata"
10:00:00.200 - Fase 5: T1 conferma la transazione (COMMIT) → il blocco viene rilasciato
Transazione di Laura (T2) - Inizio: 10:00:00.100
10:00:00.100 - Fase 1: Laura avvia la prenotazione (solo 100ms dopo Marco)
10:00:00.150 - Fase 2: T2 tenta di leggere lo stato della Camera 101
10:00:00.150 - Fase 3: T2 deve attendere perché T1 ha già acquisito un blocco in scrittura
10:00:00.250 - Fase 4: Dopo 50ms di attesa, T2 legge lo stato → 'prenotata'
10:00:00.300 - Fase 5: Il DBMS rileva che la camera è già prenotata e blocca l'operazione
10:00:00.350 - Fase 6: T2 annulla la transazione (ROLLBACK)

📋 Tabella Riassuntiva delle Operazioni (CON Isolamento)

Tempo Transazione di Marco (T1) Transazione di Laura (T2)
10:00:00.000 BEGIN TRANSACTION; -
10:00:00.100 - BEGIN TRANSACTION;
10:00:00.050 / 10:00:00.150 SELECT stato FROM camere WHERE id = 101;
→ 'disponibile'
SELECT stato FROM camere WHERE id = 101;
→ in attesa (lock) per 50ms
10:00:00.100 Blocco in scrittura su Camera 101 -
10:00:00.150 / 10:00:00.250 UPDATE camere SET stato = 'prenotata' WHERE id = 101; In attesa del rilascio del blocco (50ms)
10:00:00.200 / 10:00:00.350 COMMIT; (prenotazione confermata) ROLLBACK; (prenotazione annullata)
Risultato Finale (CON Isolamento):
  • 10:00:00.200: Marco ha prenotato con successo la Camera 101 ✓
  • 10:00:00.350: Laura non è riuscita a prenotare e ha ricevuto una notifica
  • Tempo totale: 350ms per risolvere entrambe le transazioni
  • Il database è rimasto in uno stato consistente
  • Nessuna doppia prenotazione o conflitto

❌ Scenario SENZA Isolamento (Problemi di Concorrenza)

In questo scenario, il DBMS non applica blocchi o meccanismi di controllo della concorrenza:

Transazione di Marco (T1) - Inizio: 10:00:00.000
10:00:00.000 - Fase 1: Marco avvia la prenotazione della Camera 101
10:00:00.050 - Fase 2: T1 legge lo stato → 'disponibile'
10:00:00.100 - Fase 3: T1 modifica lo stato da "disponibile" a "prenotata"
10:00:00.200 - Fase 4: T1 conferma la transazione (COMMIT)
Transazione di Laura (T2) - Inizio: 10:00:00.100
10:00:00.100 - Fase 1: Laura avvia la prenotazione (solo 100ms dopo Marco)
10:00:00.150 - Fase 2: T2 legge lo stato della Camera 101
T1 senza ISOLAMENTO non ha attivato un blocco, quindi T2 può accedere immediatamente
La camera risulta "disponibile" (la modifica di T1 non è ancora visibile a T2)
10:00:00.200 - Fase 3: T2 modifica lo stato da "disponibile" a "prenotata"
10:00:00.250 - Fase 4: T2 conferma la transazione (COMMIT)

📋 Tabella Riassuntiva delle Operazioni (SENZA Isolamento)

Tempo Transazione di Marco (T1) Transazione di Laura (T2)
10:00:00.000 BEGIN TRANSACTION; -
10:00:00.100 - BEGIN TRANSACTION;
10:00:00.050 / 10:00:00.150 SELECT stato FROM camere WHERE id = 101;
→ 'disponibile'
SELECT stato FROM camere WHERE id = 101;
→ 'disponibile' (ancora!)
10:00:00.100 / 10:00:00.200 UPDATE camere SET stato = 'prenotata' WHERE id = 101; UPDATE camere SET stato = 'prenotata' WHERE id = 101;
10:00:00.200 / 10:00:00.250 COMMIT; COMMIT; (sovrascrive T1!)
Risultato Finale (SENZA Isolamento):
  • 10:00:00.200: Marco crede di aver prenotato la Camera 101, ma...
  • 10:00:00.250: La sua modifica è stata sovrascritta da Laura
  • 10:00:00.250: Laura ha ottenuto la prenotazione
  • 10:00:00.250: Stato finale nel database: Camera 101 prenotata da Laura
  • Marco non è a conoscenza del problema (potrebbe presentarsi in hotel senza camera!)

🎬 Simulazioni Interattive

🔬 Simulazione 1: Dirty Read (Lettura Sporca)

Scenario: Due transazioni contemporanee
T1: Modifica il saldo di Alice da 1000€ a 0€
T2: Legge il saldo di Alice per un report

Clicca un pulsante per vedere la simulazione...

🔬 Simulazione 2: Lost Update (Aggiornamento Perso)

Scenario: Due prelievi contemporanei
Saldo iniziale di Emma: 100€
Sportello A: Preleva 80€ | Sportello B: Preleva 80€

Clicca un pulsante per vedere la simulazione...

📊 Livelli di Isolamento

I DBMS offrono 4 livelli di isolamento che controllano quali anomalie sono permesse:

Livello Dirty Read Non-Repeatable Phantom Read Prestazioni
READ UNCOMMITTED Possibile Possibile Possibile 🚀 Massima
READ COMMITTED ❌ Impossibile Possibile Possibile ⬆️ Alta
REPEATABLE READ ❌ Impossibile ❌ Impossibile Possibile* ⬇️ Media
SERIALIZABLE ❌ Impossibile ❌ Impossibile ❌ Impossibile 🐢 Bassa

✍️ Quiz: Isolamento e Concorrenza

5. Cos'è un "Dirty Read"?
A) Leggere dati modificati da una transazione che non ha ancora fatto COMMIT
B) Leggere dati da una tabella sporca o corrotta
C) Leggere dati che sono stati eliminati dal database
D) Leggere dati in modo incompleto o parziale
6. Due transazioni leggono lo stesso valore (100€), poi la prima aggiunge 50€ e la seconda toglie 30€. Qual è il risultato finale SENZA isolamento?
A) 120€ (100 + 50 - 30)
B) 70€ (la seconda sovrascrive la prima)
C) 150€ (100 + 50)
D) 80€ (100 - 30 + 50, ma in ordine diverso)

📝 Riepilogo della Sezione

  • L'isolamento previene le interferenze tra transazioni concorrenti
  • Le quattro anomalie sono: Dirty Read, Non-Repeatable Read, Phantom Read, Lost Update
  • I livelli di isolamento offrono un compromesso tra sicurezza e prestazioni

💾 6. Durabilità (Durability)

🎯 Obiettivi di Apprendimento

  • Comprendere cosa significa "permanenza" dei dati
  • Conoscere i meccanismi tecnici (WAL, checkpoint, recovery)
  • Capire cosa succede in caso di crash dopo un COMMIT

📖 Definizione

Durabilità significa che una volta che una transazione ha fatto COMMIT, le modifiche sono PERMANENTI.

Regola: Anche se il sistema va in crash subito dopo il COMMIT, i dati NON devono essere persi.

🎯 Perché la Durabilità è fondamentale?

Immagina di completare un bonifico online. La banca ti conferma: "Operazione completata con successo!"

Un secondo dopo, un blackout colpisce i server della banca. Cosa succede ai tuoi soldi?

Con la durabilità: Il trasferimento è al sicuro, già salvato su disco.
Senza durabilità: I tuoi soldi potrebbero scomparire nel nulla! 😱

🛡️ Come si garantisce la Durabilità?

🔧 Meccanismi Tecnici del DBMS
Meccanismo Come funziona Quando agisce
Write-Ahead Logging (WAL) Prima di modificare i dati, scrive cosa sta per fare in un file di LOG Prima di ogni modifica
Checkpoint Salva periodicamente lo stato completo del database su disco Ogni N minuti o transazioni
Recovery Al riavvio, rilegge il LOG e ripristina le transazioni confermate Dopo un crash
Backup Copie di sicurezza complete su supporti esterni Periodicamente

🎬 Simulazione Interattiva

🔬 Scenario: Ordine online con crash del server

Situazione: Un cliente completa un ordine e riceve la conferma.
Evento: Subito dopo, il server va in crash a causa di un blackout.
Domanda: L'ordine è stato salvato?

Clicca un pulsante per vedere la simulazione...

✍️ Quiz: Durabilità

7. Cosa garantisce la proprietà di Durabilità?
A) Che le transazioni siano eseguite velocemente
B) Che i dati non possano essere modificati da altri utenti
C) Che le modifiche confermate sopravvivano a crash di sistema
D) Che il database rispetti tutti i vincoli definiti

📝 Riepilogo della Sezione

  • La durabilità garantisce che i dati confermati siano permanenti
  • Il Write-Ahead Logging è fondamentale per la recovery
  • Anche un blackout immediato dopo il COMMIT non può perdere i dati

💻 7. Comandi SQL per le Transazioni

🎯 Obiettivi di Apprendimento

  • Conoscere i comandi SQL fondamentali per le transazioni
  • Saper scrivere transazioni complete con gestione degli errori
  • Comprendere l'uso dei SAVEPOINT per rollback parziali
Comando Descrizione Quando usarlo
BEGIN TRANSACTION Inizia una nuova transazione All'inizio di un gruppo di operazioni correlate
COMMIT Conferma tutte le modifiche Quando tutte le operazioni sono andate a buon fine
ROLLBACK Annulla tutte le modifiche Quando si verifica un errore o si vuole annullare
SAVEPOINT nome Crea un punto di salvataggio intermedio Per poter fare rollback parziale

📝 Esempio Completo: Trasferimento Bancario Sicuro

-- Tabella di partenza
-- conti: id | intestatario | saldo
--         1  | Mario        | 1000
--         2  | Luca         | 500

BEGIN TRANSACTION;

    -- Operazione 1: Togli soldi da Mario
    UPDATE conti 
    SET saldo = saldo - 200 
    WHERE intestatario = 'Mario';
    
    -- Operazione 2: Aggiungi soldi a Luca
    UPDATE conti 
    SET saldo = saldo + 200 
    WHERE intestatario = 'Luca';
    
    -- Controllo: il saldo di Mario non deve essere negativo
    IF (SELECT saldo FROM conti WHERE intestatario = 'Mario') < 0
    BEGIN
        ROLLBACK;  -- ANNULLA tutto!
        PRINT 'Errore: saldo insufficiente!';
    END
    ELSE
    BEGIN
        COMMIT;    -- SALVA tutto!
        PRINT 'Trasferimento completato!';
    END

-- Risultato finale:
-- Mario: 800€, Luca: 700€

✍️ Esercizio Pratico: Transazione E-commerce

Situazione: Devi implementare un sistema di ordini per un e-commerce.

Requisiti:

  • Verificare che il cliente esista
  • Verificare che il prodotto sia disponibile
  • Creare l'ordine
  • Aggiornare la giacenza
  • Se qualcosa va storto, annullare tutto

Scrivi lo pseudocodice per la transazione:

-- INIZIO TRANSAZIONE
BEGIN TRANSACTION;

    -- Step 1: Verifica cliente esistente
    SELECT id FROM clienti WHERE id = 1;
    IF NOT FOUND
    BEGIN
        ROLLBACK;
        RETURN 'Errore: cliente non trovato';
    END

    -- Step 2: Verifica disponibilità prodotto
    SELECT giacenza FROM prodotti WHERE id = 101;
    IF giacenza < 2  -- quantità richiesta
    BEGIN
        ROLLBACK;
        RETURN 'Errore: prodotto non disponibile';
    END

    -- Step 3: Crea ordine
    INSERT INTO ordini (cliente_id, prodotto_id, quantità) 
    VALUES (1, 101, 2);

    -- Step 4: Aggiorna giacenza
    UPDATE prodotti SET giacenza = giacenza - 2 
    WHERE id = 101;

    -- Step 5: Conferma
    COMMIT;
    RETURN 'Ordine completato!';

📝 Riepilogo della Sezione

  • BEGIN, COMMIT e ROLLBACK sono i comandi base
  • SAVEPOINT permette rollback parziali
  • La gestione degli errori è fondamentale per transazioni sicure

🎬 8. Scenario Completo: Acquisto su E-Commerce

🎯 Obiettivi di Apprendimento

  • Comprendere come tutte le proprietà ACID lavorano insieme
  • Applicare i concetti teorici a un caso reale
  • Valutare l'importanza di ACID in sistemi critici

Vediamo come tutte e 4 le proprietà ACID lavorano insieme in un caso reale di acquisto online:

🛒 Acquisto di un prodotto da 50€
FASE 1: Inizio transazione
BEGIN TRANSACTION;
FASE 2: Verifica disponibilità (CONSISTENZA)
Controlla magazzino: 10 unità disponibili ✓
Controlla saldo cliente: 100€ ✓
FASE 3: Esegui operazioni (ATOMICITÀ + ISOLAMENTO)
Sottrai 1 unità dal magazzino: 10 → 9
Sottrai 50€ dal cliente: 100 → 50
Crea ordine nel sistema
Nessun'altra transazione può interferire (LOCK)
FASE 4: Verifica finale (CONSISTENZA)
Magazzino ≥ 0? ✓ (9 unità)
Saldo ≥ 0? ✓ (50€)
Ordine valido? ✓
FASE 5: Conferma (DURABILITÀ)
COMMIT;  -- Tutto salvato su disco!
FASE 6: Anche se il server crasha...
💥 Server va in crash
🔄 Server si riavvia
✓ Rilegge il log delle transazioni
✓ L'ordine è salvato!
✓ Il magazzino è aggiornato!
✓ Il saldo è corretto!