Questo articolo, il primo di una serie di due, vuole essere un'introduzione teorica all'argomento. Per un uso vero e proprio, si rimanda alla seconda parte.

Un pericolo: la scrittura

I database sono utilizzati per conservare le informazioni, questo indipendentemente dal tipo di database che si sta utilizzando.

Che sia un super-sofisticato server con gigabyte di spazio di tabelle, o un volgare file .DBF, lo scopo ultimo è quello di memorizzare dati in un modo che consenta un facile accesso e reperimento degli stessi.

La lettura dei dati stessi non è poi un problema, raramente si incontrano degli errori o si creano guai leggendo semplicemente i dati da un database.

Supponiamo che nel bel mezzo di una lettura il computer si blocchi, il peggio che può capitare è che il nostro programma non si accorga di aver letto metà di quello che gli serve e ci proponga delle informazioni errate ritenendole giuste, ma avviene di rado perché (di solito) il programmatore prevede la possibilità che il database si blocchi o risponda in modo anomalo.

Le informazioni sono comunque presenti nel nostro database, ed in un modo o nell'altro riusciremo a metterci sopra le mani.

Il momento più critico per qualunque sistema di memorizzazione è la scrittura, cioè quando le informazioni vengono effettivamente immesse nel sisetma.

Se il sistema si blocca per qualunque motivo nel mezzo dell'operazione di scrittura, non vi è nessuna certezza su cosa è stato scritto e dove. Un confronto tra lo stato del database prima e dopo ci potrà dire solo che il database è stato cambiato (per forza), ma difficilmente ci potrà essere d'aiuto.

Questo è ancora più importante quando le operazioni di scrittura devono essere correlate, cioè è necessario aggiornare più di una tabella in modo coerente.

Faccio il classico esempio: il programma di contabilità che deve aggiornare le tabelle delle Entrate ed Uscite in risposta all'inserimento di un qualunque movimento contabile.

Se il sistema dovesse bloccarsi a metà della scrittura cosa occorre fare? E' stata scritta l'entrata? E l'uscita? Se non si ha la sicurezza di quali informazioni sono state scritte e dove, la situazione richiede l'intervento di un tecnico che vada a rimettere a posto le cose a mano. Immaginiamo di avere un sistema che aggiorna una dozzina (o più) di tabelle ad ogni operazione, si capisce bene che l'intero sistema è fortemente a rischio.

Le scritture atomiche

Una prima soluzione al problema è quello di utilizzare operazioni di scrittura 'atomiche', cioè minime, che vanno a modificare una singola informazione e nient'altro.

A questo punto è possibile seguire l'operazione di scrittura suddividendola in 'passi', ad ogni passo un solo punto può essere causa di errore.

Si ottiene quindi una struttura del tipo:

Inizio operazioni

 Aggiorna tabella1
 Errore?
  Recupera tabella1
 Aggiorna tabella2
Errore?
  Recupera tabella2
#9;Recupera tabella1

Aggiorna tabella3

Errore?
  Recupera tabella3
 Recupera tabella2
  Recupera tabella1
Fine operazioni

In questo modo è possibile aggiornare i dati in modo da 'recuperare' eventuali errori. Ma solo fino ad un certo punto, perché se la funzione di 'recupero' dovesse andare in errore, saremmo al punto di partenza, salvo il fatto che il tecnico saprebbe in quali tabelle occorre andare a mettere le mani.

Insomma la strada è quella giusta ma ancora non ci siamo.

Scrittura su temporaneo

Supponiamo però di unire al meccanismo precedente una scrittura su di una tabella temporanea, in questo modo gli aggiornamenti non sono fatti sulla tabella vera, ma su una copia della stessa che esiste in via temporanea.

A questo punto avremmo:

Inizio operazioni

 Aggiorna tabella1

 Aggiorna tabella2

 ...

 Errore (in qualsiasi punto) ?

  Butta via tutto

 Tutto Ok?

  Riporta in definitivo

Fine operazioni

In questo modo tutte le operazioni vengono 'simulate' in modo completo, il sistema richiede tutti i blocchi, la congruenza dei dati e quant'altro è necessario per fare l'aggiornamento senza farlo, poi, se tutto è andato bene, tutte le operazioni vengono concluse in un solo colpo.

Questo significa che:

• tutte le tabelle sono state aggiornate come dovuto
• nessuna tabella è stata modificata

L'intero processo a questo punto prende il nome di transazione, in sostanza il concetto della transazione è quello di riunire in un unico blocco più operazioni di cambiamento (qualunque cambiamento, sia esso aggiunta, modifica o cancellazione), in modo da eseguirle tutte in un colpo solo.

Ovviamente non tutto è così pulito. In particolare potrebbe verificarsi un problema nel preciso istante in cui il computer inizia il processo di scrittura.

In effetti non esiste un sistema certo al 100% ed assolutamente esente di difetti, diciamo solo che un meccanismo come questo riduce la possibilità di errori ai soli errori hardware (se il computer prende fuoco niente vi può evitare i guai).