📑 Indice della Dispensa
- 1. Cos'è una Transazione?
- 2. Le Proprietà ACID - Panoramica
- 3. Atomicità (A) - Tutto o Niente
- 4. Consistenza (C) - Vincoli rispettati
- 5. Isolamento (I) - Nessuna Interferenza
- 6. Durabilità (D) - Dati al Sicuro
- 7. Comandi SQL per le Transazioni
- 8. Scenario Completo: E-Commerce
- 9. Riepilogo e Punti Chiave
📌 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
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:
| ID | Nome | Saldo |
|---|---|---|
| 1 | Alice | 1000€ |
| 2 | Bob | 500€ |
| ID | Nome | Saldo |
|---|---|---|
| 1 | Alice | 900€ |
| 2 | Bob | 600€ |
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.
| ID Conto | Intestatario | Saldo |
|---|---|---|
| A | Anna | 200€ |
| B | Bruno | 50€ |
🔄 Operazioni della Transazione di Bonifico
✍️ Quiz di Verifica
1. Perché un bonifico bancario richiede una transazione?
2. Cosa succede se il sistema va in crash durante una transazione (con atomicità)?
📝 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:
Atomicità
Tutto o niente
Consistenza
Vincoli sempre rispettati
Isolamento
Transazioni indipendenti
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:
✅ Scenario 1: Transazione fallita con proprietà di Atomicità
❌ 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):
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.
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"?
📏 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.
| ID | Titolo | Autore_ID |
|---|---|---|
| 1 | Libro A | 1 |
| 2 | Libro B | 2 |
| ID | Nome |
|---|---|
| 1 | Autore X |
| 2 | Autore 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:
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!
| ID | Titolo | Autore_ID |
|---|---|---|
| 1 | Libro A | 1 |
| 2 | Libro B | 2 |
| 3 | Il grande romanzo | 12345 |
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:
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
| ID | Titolo | Autore_ID |
|---|---|---|
| 1 | Libro A | 1 |
| 2 | Libro B | 2 |
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€?
💥 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?
4. Un prodotto ha 5 unità in magazzino. Due clienti ordinano contemporaneamente 5 unità ciascuno. Senza controllo di consistenza, cosa potrebbe succedere?
📝 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.
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.
- 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
Transazione di Laura (T2) - Inizio: 10:00:00.100
📋 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) |
- 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
Transazione di Laura (T2) - Inizio: 10:00:00.100
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)
📋 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!) |
- 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
🔬 Simulazione 2: Lost Update (Aggiornamento Perso)
Scenario: Due prelievi contemporanei
Saldo iniziale di Emma: 100€
Sportello A: Preleva 80€ | Sportello B: Preleva 80€
📊 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"?
6. Due transazioni leggono lo stesso valore (100€), poi la prima aggiunge 50€ e la seconda toglie 30€. Qual è il risultato finale SENZA isolamento?
📝 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.
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à?
| 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?
✍️ Quiz: Durabilità
7. Cosa garantisce la proprietà di Durabilità?
📝 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:
BEGIN TRANSACTION;
FASE 2: Verifica disponibilità (CONSISTENZA)
COMMIT; -- Tutto salvato su disco!
FASE 6: Anche se il server crasha...
📋 9. Riepilogo e Punti Chiave
📊 Tabella Riassuntiva ACID
| Proprietà | Significato | Se NON garantita... | Esempio problema |
|---|---|---|---|
| Atomicità | Tutto o niente | Operazioni eseguite "a metà" | 100€ spariscono durante un bonifico |
| Consistenza | Regole rispettate | Dati invalidi nel database | Saldo diventa -50€ |
| Isolamento | Transazioni indipendenti | Interferenze tra operazioni | Due prelievi da 80€ su saldo di 100€ |
| Durabilità | Modifiche permanenti | Dati persi dopo crash | Ordine confermato ma sparito |
⚖️ Confronto: Con ACID vs Senza ACID
✓ CON Transazioni ACID
- ✅ Dati sempre consistenti
- ✅ Nessuna perdita di informazioni
- ✅ Operazioni atomiche
- ✅ Resistente ai crash
- ✅ Transazioni indipendenti
- ✅ Database affidabile al 100%
💳 Usato da: Banche, E-commerce, Sistemi critici
✗ SENZA Transazioni ACID
- ❌ Dati inconsistenti
- ❌ Soldi che spariscono
- ❌ Operazioni parziali
- ❌ Crash = perdita dati
- ❌ Conflitti tra operazioni
- ❌ Database inaffidabile
💥 Risultato: CAOS TOTALE!
✍️ Quiz Finale di Autovalutazione
8. Quale delle seguenti NON è una proprietà ACID?
9. In un trasferimento di 100€, se il sistema crasha DOPO aver tolto i soldi al mittente ma PRIMA di darli al destinatario, quale proprietà ACID entra in gioco per risolvere il problema?
🎓 Punti Chiave da Ricordare
- Una transazione raggruppa più operazioni in un'unità logica
- ACID sono le 4 proprietà che garantiscono l'affidabilità delle transazioni
- BEGIN/COMMIT/ROLLBACK sono i comandi TQL fondamentali per gestire le transazioni
- Senza ACID, i database sarebbero inaffidabili per applicazioni serie (banche, e-commerce, sanità...)
- I DBMS moderni (MySQL, PostgreSQL, Oracle, SQL Server) garantiscono tutte le proprietà ACID
📖 Glossario dei Termini Chiave
❓ Domande Frequenti
COMMIT = "Conferma tutto, salva definitivamente"ROLLBACK = "Annulla tutto, torna allo stato precedente"
Complimenti! Hai completato la dispensa completa sulle Transazioni e ACID!
Ora comprendi come i database garantiscono l'affidabilità dei tuoi dati!