di Piero Giuseppe Goletto
Le basi di dati ci tolgono il problema di gestire in ciascuna applicazione gli stessi dati, cioè di dover mantenere aggiornate copie multiple dei dati.
Se questo venisse dovremmo creare “allineamenti” continui tra le singole applicazioni, cioè non potersene servire per molto tempo durante la giornata e occupandosi più di controllare che le informazioni siano coerenti. “Coerente” vuol dire che gli stessi dati presenti nelle varie applicazioni coincidono. E se invece disponessimo di un “qualcosa” che ci garantisce, automaticamente, questa coerenza?
Ecco i sistemi di gestione di basi di dati. Questi sistemi dedicati alla gestione dati centralizzano il loro aggiornamento e lo rendono indipendente dalle applicazioni.
I dati diventano così un patrimonio perché le basi dati garantiscono l’affidabilità degli stessi e una gestione astratta: ho bisogno di un elenco cronologico? Seleziono i dati che mi servono e li ordino per data; come la data sia memorizzata non è per me un vincolo.
Tutto ciò implica l’uso di un modello “Entità – Relazioni” che fa emergere “cosa c’è dentro alla mia base dati”, come ciascun elemento si collega con gli altri, a quali regole di coerenza mi devo attenere e, in ultimo, quali regole di trasformazione vanno applicate.
In questo modello, ogni “entità” verrà costruita come tabella composta di righe e colonne.
Il modello esplicita quindi:
• la descrizione di un concetto rilevante per l' applicazione ovvero la definizione precisa di un'entità,
di un attributo o di un’associazione del modello E-R;
• un vincolo di integrità cioè una regola di controllo di coerenza;
• una derivazione ovvero le regole con cui si ottengono nuovi dati da dati esistenti.
Nel prossimo articolo vedremo un esempio pratico. La manipolazione di questi dati viene effettuata con tre azioni: inserimento, aggiornamento e cancellazione.
Queste azioni sono legate al concetto di transazione. Una transazione è un blocco di istruzioni che sono correlate in modo logico tra loro. E’ cioè un insieme di istruzioni che “fanno qualcosa” e che se non si concludono in modo corretto vanno necessariamente annullate. Una transazione cioè o viene eseguita tutta o non viene eseguita affatto. Fino a quando una transazione non ha esito positivo, le modifiche che apporta sono visibili solo per la sessione che ha avviato la transazione. Succede allora questo: prima di avviare una transazione il sistema effettua una fotografia dei dati, registra le modifiche ed effettua i vari passi intermedi. Se uno di questi passaggi dovesse fallire, in virtù della fotografia fatta prima di avviare le modifiche il sistema è in grado di tornare indietro a prima dell’aggiornamento. Se, come succede nella quasi totalità dei casi, l’aggiornamento ha successo, il sistema effettuerà una nuova fotografia e renderà disponibili i dati aggiornati.
E’ per questo motivo che i sistemi di gestione basi di dati hanno architetture molto complesse:
la figura 2
(fonte: documentazione tecnica Oracle) mostra un esempio di questa struttura.
Va però detto che se una base dati viene utilizzata solamente per interrogazione e per ricavarneaggregazioni non sono strettamente necessari tutti i controlli di congruenza prima citati; se si verificano errori è sufficiente far ripartire la procedura di calcolo, perché i dati originari vengono solo letti e mai modificati.
Questa considerazione ha portato alla creazione di sistemi che abbandonano il concetto di tabella peradottare altri metodi. Sono sistemi importanti perché consentono, ad esempio, la gestione di documenti. Un caso tipico viene dal mondo web dove si parla di CMS (sistemi di gestione dei contenuti).