13-Le Basi di Dati

{gspeech style=2}

In generale, con il termine base di dati o database si intende un insieme di file, memorizzati sii disco, contenenti dati collegati tra loro. Ognuno di questi file deve essere pensato come parte integrante dell’insieme, perché tutte le informazioni memorizzate nel database concorrono a costituire, dal punto di vista logico, un’unica raccolta di dati. Per esempio, potrebbe costituire un database l’insieme delle informazioni riguardanti gli studenti di una scuola. Vi si potrebbero registrare i dati anagrafici, la classe frequentata, i voti, le pagelle, le assenze: tutti questi dati verrebbero distribuiti su file diversi, secondo precise regole di progettazione, ma sempre in modo da formare un unico insieme, che sarebbe appunto il database “studenti”. Questo database potrebbe a sua volta essere ampliato in un altro contenente informazioni, oltre che sugli studenti, anche su docenti, non docenti ecc. Si verrebbe a costituire, in questo modo, la base informativa dell’intera scuola.

IL DBMS
Per operare correttamente su una base di dati, cioè per inserire, aggiornare, elaborare le informazioni in essa contenute, occorre utilizzare un sistema per la gestione di basi di dati, detto anche DBMS (Data Base Management System). Spesso si fa molta confusione tra i due concetti e vale la pena di sottolineare, invece, il loro preciso significato. Un database è una collezione di dati, mentre un sistema di gestione è un insieme di programmi che opera su di essa.
Si può usare lo stesso sistema di gestione per operare su basi di dati diverse. Per esempio, possiamo creare un database allo scopo di gestire la nostra biblioteca e uno per lo nostra contabilità: nel primo dobbiamo registrare i dati relativi ai libri che possediamo e nel secondo quelli relativi alle spese, al conto corrente, allo stipendio ecc.: per entrambi, potremmo usare, per esempio, Access. L’affermazione, piuttosto frequente, “io uso il database”, non ha quindi molto senso, perché tende a confondere in uno solo due oggetti diversi. Si usa un sistema di gestione per “amministrare” i propri dati, che sono stati organizzati in uno o più database. Capita anche che vengano usati indifferentemente le espressioni “banca dati” e “base di dati” . In realtà, non si tratta proprio della stessa cosa, perché per banca dati si intende generalmente un insieme di informazioni messe a disposizione di un grande pubblico di utenti. Tali informazioni possono essere collocate in un database.

Caratteristiche per una buona base di dati
Le caratteristiche che deve avere una buona base di dati sono molteplici e tutte particolarmente importanti quando la base di dati deve gestire un numero molto elevato di informazioni, e questo accade nella maggior parte dei casi.

ESEMPIO
L’amministrazione di un condominio.
Consideriamo le informazioni relative all’amministrazione di un condominio. Tra i dati da registrare, ci saranno, sicuramente, i dati anagrafici dei condomini, le informazioni sugli appartamenti che possiedono, sulle rate che devono versare e sui pagamenti che via via effettuano. Non sarebbe corretto utilizzare un solo file per contenere queste informazioni. Supponiamo, infatti, di dover elencare i campi di un record che contenga tutte quelle che si riferiscono a un particolare condomino: cominciamo con il codice (che viene assegnato ad ogni persona appartenente al condominio), il nome, il cognome, l’indirizzo, il codice fiscale, la data di nascita, la professione. A questo punto, sarebbe necessario un campo per individuare l’appartamento che il condomino possiede (Io si potrebbe identificare con un numero progressivo) e le relative caratteristiche (superficie, numero vani, millesimi, numero civico, piano). Se, però, ne possiede due, queste informazioni devono essere raddoppiate; triplicate se ne possiede tre. In sostanza, quanti campi occorre riservare per memorizzare i dati di tutti gli appartamenti relativi a quel condominio? Ci si trova ancora peggio quando si esaminano i campi necessari per la memorizzazione dei pagamenti effettuati. Ci vuole un campo per la data e uno per l’importo del primo pagamento: Io stesso per il secondo e poi per il terzo ecc. Non si sa, però, quanti campi si dovrebbero prevedere, perché l’elenco dei pagamenti si allunga indefinitamente.
Lo stesso discorso vale per le rate da pagare. In pratica, conviene memorizzare in altri file tutte le informazioni che si ripetono. Del resto, la pretesa di raccogliere tutti i dati nello stesso file costituisce proprio un errore concettuale, perché nasce dalla confusione tra più “oggetti” della realtà esaminata: i condomini, gli appartamenti, le rate e i pagamenti. È chiaro che sono tutti collegati tra loro, ma questo non vuol dire che debbano essere memorizzati nello stesso file.
Conviene, invece, progettare quattro file distinti: uno per i dati anagrafici dei condomini, uno per
gli appartamenti, uno per i pagamenti, uno per le rate. Come si vede dalle figure, il collegamento tra un condomino e tutti gli “oggetti” di sua competenza (appartamenti, rate ecc.) è realizzato semplicemente per mezzo del codice del condomino stesso. Al codice dello stesso condomino possono far riferiremo più appartamenti, più rate e più pagamenti.

ESEMPIO
Le visite mediche.
Supponiamo di voler registrare alcune informazioni relative alle visite effettuate da un medico. Si potrebbe progettare un file come quello presentato in figura. Poiché, però, accade che lo stesso paziente si presenti più volte per una visita, in questo modo si avrebbe l’inconveniente di dover registrare i suoi dati personali tutte le volte. Anche questo inconveniente, del resto, nasce da un errore concettuale, perché è stata operata una forzatura riunendo due distinti gruppi di informazioni.
I dati anagrafici del paziente, infatti, sono informazioni generali che lo riguardano: la diagnosi e la cura prescritta sono, invece, informazioni relative a un preciso evento: la visita effettuata su un particolare paziente in un giorno ben preciso.
In pratica, il codice del paziente è sufficiente per risalire ai suoi dati, ma non per risalire al risultato di una visita: per questo occorre conoscere, infatti, anche la data. Conviene, allora, progettare due file distinti: uno per i pazienti e uno per le visite.

ESEMPIO
La catalogazione di progetti.
Consideriamo, infine, un ufficio nel quale vengano sviluppati diversi progetti e supponiamo che ogni dipendente sia assegnato a un solo progetto. I dati che si dovrebbero registrare sono i seguenti: codice del dipendente, nome e cognome, data di nascita, indirizzo, telefono, data di assunzione, qualifica, codice fiscale, codice del progetto, descrizione del progetto, durala prevista del progetto, nome del dipendente a capo del progetto. Se fossero tutti riuniti in un solo record, le informazioni relative al progetto al quale il dipendente è assegnato verrebbero ripetute, sempre uguali, sui record di tutti i dipendenti assegnati allo stesso progetto. Anche questo inconveniente dipende da un errore di interpretazione della realtà, perché il codice del progetto è strettamente legalo al codice del dipendente, che gli è assegnato, mentre i dati relativi al progetto non riguardano in realtà il dipendente, ma il progetto stesso. Questa sistemazione dei dati, tra l’altro, comporta parecchi problemi: quando nasce un nuovo progetto, non si possono registrare i dati a esso relativi finché non gli viene assegnato qualche dipendente: se si deve apportare una modifica (per esempio, alla durata prevista), lo si deve fare su tutti i record dei dipendenti che gli sono assegnati. Conviene, allora, distinguere due “oggetti”: dipendente (con i relativi dati personali) e progetto (con codice, descrizione, durata e nome del dipendente a capo del progetto).

PROCESSO DI NORMALIZZAZIONE
I tre esempi precedenti presentano tre situazioni non corrette e indicano in che modo effettuare gli aggiustamenti necessari. Si è tentato, così, di dare un’idea del cosiddetto processo di normalizzazione mettendo in evidenza gli errori di progettazione che devono assolutamente essere evitati in modo da non incorrere in quegli inconvenienti che abbiamo potuto riscontrare via via.

LE INDICIZZAZIONI
Un sistema per la gestione di basi di dati ottiene senz’altro Io scopo di alleggerire il compito del programmatore, ma è il caso di sottolineare che non si può lavorare bene con un database in cui la progettazione dei dati è stata fatta male. Nascono inevitabilmente problemi nella scrittura dei programmi e certe elaborazioni possono addirittura risultare impossibili. Si può dire, in questo senso, che proprio l’uso dei database ha fatto compiere molto cammino nella direzione di una “buona” progettazione. Certe regole, però, dovrebbero essere applicale sempre, anche per la progettazione di file tradizionali, prescindendo dalla successiva realizzazione di un database. Esse vengono utilizzate, infatti, in una delle prime fasi dell’analisi di un problema e costituiscono una guida molto valida per interpretare correttamente le informazioni che caratterizzano la realtà che si deve gestire. La realizzazione vera e propria del database avviene in una fase successiva. D’altra parte, è vero che i dati si devono poter interrogare ed elaborare in modo efficiente e quindi occorre prendere delle decisioni sul modo di organizzarli.

LA CHIAVE PRIMARIA
II primo problema che si presenta nella gestione di un database è quello di riuscire a ricercare le informazioni memorizzate in un tempo soddisfacente. A questo proposito occorre dare alcune definizioni.
In un record, si dice chiave primaria un campo (o un insieme di campi) sufficiente a individuare univocamente un record all’interno del file. Spesso, per distinguere l’uno dall’altro i record di un file, si utilizza un codice (come si è già visto, del resto, in altri esempi). Consideriamo, per fissare le idee, il file che contiene i dati anagrafici dei dipendenti di un’azienda. Il nome e il cognome non bastano a individuarne univocamente uno (potrebbero esserci degli omonimi). Si dovrebbe, allora, unire al nome e al cognome la data di nascita, sperando che i tre campi insieme bastino per una identificazione sicura (ma non è detto). Oppure si potrebbe assumere come chiave il codice fiscale. In ogni caso, campi chiave così complessi non sono tanto comodi da usare e quindi conviene attribuire a ogni dipendente un codice, per esempio formato da cinque o sei caratteri. Si tratta, evidentemente, di un dato fittizio, cioè di un dato che non fa parte, per sua natura, di quelli che caratterizzano un dipendente, come il suo indirizzo o il suo stato civile, ma è un’informazione di comodo, progettata allo scopo di identificare correttamente i dati dei dipendenti all’interno del file.

Supponiamo, ora, di mantenere informazioni sugli stipendi che i dipendenti percepiscono ogni mese. Non sarebbe corretto aggiungerle a quelle contenute nei record di figura, perché si tratta di dati che si ripetono (ogni dipendente riceve uno stipendio per ogni mese della sua permanenza in azienda). Conviene, allora, progettare un nuovo file, in cui un record contenga il codice del dipendente, il mese e l’anno ai quali Io stipendio si riferisce e poi tutti i dati che compaiono sul cedolino. Come chiave primaria, ora, non è più sufficiente il codice del dipendente: infatti, dato. per esempio, il codice F9A32, vi sono molti record nel file che lo contengono (uno per ogni stipendio percepito dal relativo dipendente). D’altra parte, non bastano neppure mese e anno: infatti, considerato, per esempio, il mese di febbraio 1990, esso compare in tanti record del file (uno per ogni dipendente che ha percepito uno stipendio in quel mese). Dunque, la chiave primaria, in questo caso, è formata da codice, mese e anno insieme.

In generale, una chiave primaria viene utilizzata per ricercare un particolare record all’interno del file Per esempio, può capitare di cercare quello relativo al dipendente Paolo Bianchi (individuato dalla chiave B8G31) perché si deve aggiornare il suo indirizzo oppure la sua qualifica. Il metodo più semplice per effettuare la ricerca è leggere tutti i record finché non si trova quello che contiene il codice cercato. È chiaro, però, che un procedimento del genere è inaccettabile quando si lavora in un file molto grande e si ha, invece, necessità di operare velocemente. Al file, allora, ne viene associato un altro, detto indice, che si può pensare come una tabella formata da due colonne: nella prima compaiono i valori di tutte le chiavi; nella seconda, accanto a ogni chiave, compare la posizione che occupa nel file il record individuato da quella chiave. La figura, per esempio, mostra un indice associato al file dei dipendenti: nella colonna di sinistra, appaiono, ordinati, i valori della chiave primaria (i codici): in quella di destra, le posizioni dei corrispondenti record nel file.

LA CHIAVE SECONDARIA
Una ricerca, però, si può effettuare anche in base al valore di un campo che non è stato scelto come chiave primaria. Per esempio, si potrebbero cercare tutti i dipendenti con una certa qualifica (cioè, si potrebbero ricercare tutti i record in cui il campo qualifica contiene “impiegato” oppure “operaio” ecc.). Evidentemente, in questi casi, il risultato della ricerca non è necessariamente univoco. Un campo (che non sia chiave primaria) usato per effettuare una ricerca prende il nome di chiave secondaria. Anche per le ricerche con una chiave secondaria si può associare al file un indice, detto appunto indice secondario. La figura mostra un indice secondario, associato al file impiegati: nella colonna di sinistra, appaiono, ordinali, i valori della chiave secondaria (le qualifiche); in quella di destra, le posizioni dei corrispondenti record nel file. Si noti che, a una qualifica, può corrispondere più di un record.

Supponiamo, ora, che al file dipendenti venne aggiunto un record riferito a Franco Biagi, operaio, identificato dal codice H7E75. Supponiamo anche che vada a occupare il posto numero quattro nel fila. L’aggiornamento effettuato si deve riflettere anche sull’indice primario e su quello secondario. In particolare, nell’indice primario deve apparire la nuova chiave H7E75 e da questa si deve risalire al posto in cui si trova il corrispondente record.
Nell’indice secondario, invece, deve risultare un record in più relativo alla qualifica di “operaio”.
Ora, invece, consideriamo il caso che si voglia cancellare il record relativo al dipendente Aldo Rossi, identificato dal codice S3R46. Nell’indice primario, deve essere cancellala la riga in cui compare il codice S3R46 e, nell’indice secondario, la qualifica di “impiegato” non deve più rimandare al record di posto 1.

GLI INDICI
Gli indici sono uno strumento molto utile per rendere più veloci le operazioni di ricerca. Se, per esempio, si vuole ricercare nel file dipendenti, il dipendente identificato dal codice F9A32, dalla consultazione dell’indice primario si ricava subito che il record contenente i suoi dati si trova nella posizione 2. Se, invece, si vogliono individuare i dipendenti con la qualifica di “operaio “dalla consultazione dell’indice secondario si risale ai record che occupano le posizioni 3 e 4. In generale, in un sistema per la gestione di basi di dati, si hanno a disposizione istruzioni molto semplici per creare un indice primario o secondario.
Dal momento della creazione, il sistema si fa poi carico di tute le operazioni di aggiornamento che si rendono necessarie. Per esempio, quando nel file dipendenti viene aggiunto il record identificalo dalla chiaveH7E75, il passaggio dall’indice primario all’indice secondario vengono realizzati automaticamente dal sistema e sono del tutto trasparenti per il programmatore. Analogamente, quando si compie un’operazione di ricerca, si deve solo indicare il valore di chiave da cercare: è il sistema che consulta l’indice relativo e poi si posiziona di conseguenza. Al programmatore, allora, resta il compito di condurre l’analisi in modo accurato e di individuare, tra le altre cose, la chiave primaria e le chiavi secondarie: al sistema, invece, vengono demandati tutti gli aspetti tecnici della gestione degli indici.

Un database viene generalmente definito come un insieme di file che contengono dati collegati tra loro. Ora, per mezzo di alcuni esempi, esamineremo in che modo le informazioni contenute in un file possano essere logicamente collegate a quelle di un altro.
L’UFFICIO PERSONALE
Consideriamo l’insieme di tutti i dati gestiti dall’ufficio personale di un’azienda. Tra quelli che si riferiscono a uno stesso dipendente, identificato per mezzo di un codice, conviene distinguere le informazioni di tipo anagrafico (come l’indirizzo, lo stato civile, la data di nascita ecc.) da quelli riguardanti gli stipendi che via via percepisce, i progetti ai quali partecipa, i corsi di aggiornamento che frequenta ecc. Sarà opportuno, allora, progettare un file per ogni “oggetto” della realtà esaminata. Supponiamo, in particolare, che i dipendenti possano richiedere un prestito all’azienda. Non è detto che tutti lo facciano, ma, quando qualcuno si avvale di questa possibilità, occorre registrare alcuni dati relativi all’operazione, come il valore della somma richiesta, il tasso d’interesse, la durata, l’importo della rata, il numero totale di rate. Occorre anche mantenere aggiornalo il numero di rate pagate. Può succedere che, una volta estinto un debito, il dipendente ne contragga un altro, ma non è possibile sovrapporre due operazioni e quindi ognuno risulta collegato, al più, a una sola. Ovviamente. ogni prestito si riferisce a uno e un solo dipendente. Si può affermare che il prestito è uno degli “oggetti” che caratterizzano la realtà studiata e quindi si può progettare un file “prestiti”. in cui ogni record contiene almeno i seguenti campi: debito iniziale, numero totale rate, data inizio del prestito,. data fine, tasso, importo di una rata, numero di rate pagate. Per individuare in modo univoco ogni operazione di prestito, si può decidere di utilizzare, come chiave primaria, un codice, per esempio un numero progressivo. Resta, però, da realizzare il collegamento tra il dipendente e l’eventuale prestito da lui richiesto. Si tratta di un legame, o corrispondenza, di tipo “uno a uno” o, come spesso si scrive, 1-1, perché a un dipendente non corrisponde più di un prestito e un prestito si riferisce a un solo dipendente. Per legare i due “oggetti” si aggiunge ai dati di ognuno di essi la chiave primaria dell’altro.
Nella figura, per esempio, si può vedere che il dipendente Mario Rossi (identificato dal codice D456) ha richiesto il prestito individuato dal numero 64. Viceversa, il prestito numero 64 fa riferimento al dipendente D456. Se un dipendente (come accade per Carlo Bianchi) non sta estinguendo alcun debito, il campo corrispondente al numero del prestito contiene il valore zero, cioè non rimanda a nessuna operazione effettiva. Spesso, quando si ha a che fare con una corrispondenza di tipo 1-1, si tende a riunire in uno solo i due record collegati. Se, però, conte in questo caso, si utilizzano due record distinti, il loro legame viene mantenuto facendo sì che ognuno dei due si riferisca all’altro per mezzo della chiave primaria. che lo identifica.

IL CONTO CORRENTE
Consideriamo l’insieme dei dati relativi ai conti correnti gestiti da una banca. Possiamo individuare tre oggetti distinti: il cliente, il conto corrente e il movimento. Per ogni cliente, identificato per mezzo di un codice (sua chiave primaria), vengono memorizzati dati di tipo anagrafico: per ogni conto corrente, individuato da un numero (sua chiave primaria). si registrano informazioni come la data di apertura, il tipo di conto, il saldo ecc.; per i movimenti, numerati progressivamente nell’ambito dello stesso conto, bisogna memorizzare l’importo, la data, la causale, ecc. In questa situazione, non ci sono corrispondenze di tipo 1-1, perché a ogni cliente può corrispondere più di un conto corrente e a ogni conto corrente più di un movimento (facciamo l’ipotesi che ogni conto corrente faccia riferimento a una sola posizione anagrafica). Si tratta, allora, di corrispondenze del tipo “uno a molti” o 1-M, dove, con il termine “molti” non si intende “in grande quantità”, ma, semplicemente, “uno o più di uno”. Un record relativo a un conto corrente contiene, come legante con il cliente al quale è intestato, il codice del cliente stesso. Non è possibile il viceversa, perché non si sa quanti conti correnti può aprire un cliente e quindi non si sa quanti campi prevedere per memorizzare, tra i suoi dati, anche tutti i numeri di conto. Analogamente, tra i dati del conto corrente non ci saranno i numeri dei relativi movimenti, mentre un movimento farà riferimento al conto corrente. In questo modo, tra l’altro, si può scegliere, come chiave primaria per il movimento, la coppia di campi costituita dal codice del conto corrente e dal numero progressivo di movimento nell’ambito del conio. Non occorre inserire anche il codice del cliente tra i dati contenuti nel record relativo a un movimento: dal movimento si risale al conto e dal conto al cliente, secondo uno schema come quello di figura.
In conclusione, nel caso delle corrispondenze di tipo 1-M, solo uno dei due “oggetti” interessati fa riferimento all’altro: ognuno di quelli che costituiscono i molti si riferisce all’unico oggetto al quale è collegato per mezzo della chiave primaria di quest’ultimo.

I CLIENTI E GLI ORDINI
Consideriamo l’insieme dei dati relativi ai clienti di un’azienda e agli ordini che questi effettuano (ipotizziamo che un ordine faccia sempre riferimento a un solo cliente). Si deve prevedere, ovviamente, un file contenente tutte le informazioni anagrafiche sulla clientela (per ogni cliente: codice, nome, cognome, indirizzo ecc.). Tra i dati di un ordine, si può ipotizzare un numero progressivo, che lo identifica, una data relativa al ricevimento dell’ordine stesso e una di consegna.
È facile, inoltre, riconoscere una corrispondenza di tipo 1-M tra il cliente e gli ordini da lui effettuali. Di conseguenza, per realizzare questo legame, occorre che, tra i dati di un ordine, appaia anche il codice del relativo cliente. Per esempio, nella figura, l’ordine numero 2 si riferisce al cliente B35 (Carlo Bianchi): al cliente A12 (Maria Verdi), corrispondono due ordini: il numero 1 e il numero 3. Occorre, d’altra parte, registrare anche gli articoli che sono stati ordinati. II numero di articoli ai quali un ordine fa riferimento può variare da uno in su.

Conviene, allora, pensare le singole righe dell’ordine come “oggetti” a parte. Ogni riga deve contenere il codice del prodotto ordinato e la quantità richiesta. Poiché a un ordine possono corrispondere più righe, nasce una seconda corrispondenza 1-M e, per realizzare anche questo legame, si inserisce tra i dati della riga il numero progressivo dell’ordine al quale essa appartiene. Nella figura, per esempio, le prime due righe dell’ultima tabella appartengono all’ordine numero 1. Per quanto riguarda il prodotto ordinato, è sufficiente che una riga faccia riferimento al suo codice, perché descrizione, prezzo, aliquota IVA, ecc. sono reperibili nel file contenente i dati relativi ai prodotti. Nella figura, si può osservare che a un ordine possono far riferimento più righe e lo stesso può accadere per un prodotto. Per esempio, all’ordine numero 1 corrispondono due righe e al prodotto 6X ne corrispondono tre. Questo succede perché gli ordini e i prodotti sono collegati da un tipo di corrispondenza che viene chiamata “molti a molti” o anche N-M. Nel caso in esame, ciò significa che un ordine può far riferimento a più prodotti e un prodotto, da parte sua, può essere referenziato in più ordini. In una situazione di questo tipo, il legame tra i due “oggetti” si esprime introducendo un terzo “oggetto”. Nel nostro esempio, infatti, ordine e prodotto sono stati collegati proprio grazie all’introduzione della tabella che riporta tutte le righe di dellaglio degli ordini. Tra l’altro, in questo modo, la relazione N-M è stata “scomposta” in due relazioni 1-M: quella tra prodotti e righe d’ordine e quella tra ordini e righe d’ordine. Dalla figura si può vedere che la seconda riga dell’ultima tabella collega il prodotto identificato dal codice 2H all’ordine individuato dal numero progressivo 1, indicando una richiesta pari a otto pezzi: la quinta riga della stessa tabella collega il prodotto identificato dal codice 6X all’ordine numero 3, indicando una quantità pari a venti pezzi. Scegliendo, in quest’ultima tabella, tutte le righe che riportano lo stesso numero d’ordine, si ricostruisce l’ordine per intero.

I SISTEMI DI GESTIONE
Quando, nel corso dell’analisi di un problema, si affronta la progettazione dei dati, si costruisce uno schema, nel quale trovano posto tutti gli “oggetti” della situazione esaminata e tutte le informazioni che li caratterizzano. Negli esempi che sono stati presi in considerazione finora, si è sempre supposto che a ogni “oggetto” (cliente o dipendente o altro) corrispondesse effettivamente un file. Inoltre, per collegare logicamente un record ad un altro è stato sempre utilizzato il sistema di inserire tra i dati del primo la chiave primaria del secondo. Ora, però, vale la pena di sottolineare che uno scherma di questo tipo rappresenta sopratutto un modello, costruito dall’analista, adatto a rappresentare tutti i dati che occorre gestire. Se poi si passa alla realizzazione di un database, il modo in cui vengono fisicamente registrati i dati e i loro collegamenti dipende dal sistema per la gestione di basi di dati che si sceglie di utilizzare.

IL SISTEMA DI TIPO RELAZIONALE
Finora, è stato fatto implicitamente riferimento a un gestore di tipo relazionale, nel quale i dati appaiono organizzati in tabelle, che possono essere collegate tra loro per mezzo del contenuto di certi campi. Esistono anche sistemi di tipo gerarchico e di tipo reticolare, che risultano, però, di più difficile apprendimento. In generale, Io scopo di un gestore di database è mettere a disposizione dell’utente dei comandi per operare sui dati a livello logico, senza curarsi di tutti i problemi derivanti dalla gestione di una memoria periferica. I comandi vengono automaticamente “tradotti” nelle istruzioni necessarie per operare sulla realtà fisica dei dati. Da questa punto di vista, un sistema di ulto relazionale offre maggiori facilitazioni a chi lo usa, perché organizza i dati in modo molto aderente al modello che viene costruito in fase di analisi.

Nel caso si operi in ambiente relazionale, prima (li procedere alla vera e propria fase di stesura dei programmi, occorre:

• analizzare il problema e individuare gli “oggetti” che lo caratterizzano (a ogni “oggetto” corrisponderà una tabella);
• per ogni tabella, stabilire esattamente quali sono i dati (campi) che compongono i suoi record;
• prevedere i campi necessari alla realizzazione dei legami tra i record di una tabella e quelli di un’altra.

Quando il problema da analizzare risulta molto complesso, è preferibile scomporlo in più parti e sviluppare analisi separate. Generalmente, però, i singoli sottoproblemi hanno in comune alcuni dati. Per esempio, in una banca, i programmi che gestiscono i conti correnti e quelli che gestiscono i depositi fanno riferimento alle stesse informazioni di tipo anagrafico relative ai clienti. In casi di questo genere, e corretto progettare programmi distinti, prevedendo, però, che utilizzino, quando occorra, gli stessi file. Questa metodologia di progettazione oggi sembra ovvia. soprattutto a chi si accosta solo adesso alla gestione dei dati attraverso il computer. Se, però, si ripercorre un poco la storia dell’elaborazione dei dati, ci si rende conto che le prime procedure informatiche erano organizzate secondo una logica del tutto diversa. All’interno della stessa azienda, i programmi per la gestione del magazzino e quelli per la fatturazione, per esempio, pur avendo in comune alcuni dati relativi ai prodotti, non condividevano alcun file.
Esisteva, quindi, un file “prodotti” utilizzato dai programmi del magazzino e un file “prodotti” utilizzato dalla fatturazione. I dati comuni venivano quindi registrati due volte, provocando, in tal modo, una serie di inconvenienti:

• inutile spreco di spazio su disco;
• possibilità di discordanze: poteva accadere facilmente, per esempio, che una variazione nell’indirizzo di un cliente fosse registrata in uno solo dei due file.

Oggi appare scontato che il file contenente i dati relativi ai prodotti sia comune ai programmi che gestiscono il magazzino e a quelli relativi alla fatturazione e che ognuna delle due applicazioni Io utilizzi secondo le proprie necessità.

L’INTEGRAZIONE DEI DATI
Così, pur mantenendo distinti i programmi, viene realizzata quella che si chiama integrazione dei dati; si dispone, cioè, di un unico patrimonio informativo che può essere utilizzato da diversi processi di elaborazione. I dati, organizzati in uno o più database e i programmi, che operano sui dati, costituiscono il sistema informatico dell’azienda. Seguendo la metodologia di progettazione che abbiamo descritto, si perviene, generalmente, a disegnare schemi di dati piuttosto complessi, perché in essi confluiscono informazioni che saranno poi elaborate da programmi differenti. È proprio la presenza di un sistema per la gestione di basi di dati che consente di tenere sono controllo database caratterizzati da molti file e da molti collegamenti. In particolare, un gestore di database risulta molto utile perché e in grado di mettere a disposizione dei singoli programmi la porzione di dati, proveniente da uno o più file, che essi devono elaborare.
Riprendiamo in esame, per fare un esempio, i dati relativi ai clienti di un’azienda e agli ordini da essi effettuati.
Le quattro tabelle della figura contengono i dati relativi ai clienti, agli ordini, ai prodotti e, infine, alle righe di dettaglio che appaiono negli ordini. Seguendo, correttamente, le regole per la progettazione dei dati, è stato ottenuto il risultato di “sparpagliare” su quattro file diversi i dati che devono comparire, tutti insieme, su un ordine. Questo fatto, a prima vista, appare piuttosto strano, perché verrebbe forse più naturale pensare all’ordine come a un unico gruppo di dati, registrati tutti insieme nello stesso record.

Ciò accade perché si fa un’enorme confusione tra il documento cartaceo, del tipo presentato in figura, e la struttura logica dei dati che devono comparire in esso. Un sistema di gestione di basi di dati è in grado di “vedere” insieme file diversi tra loro correlati. Di conseguenza, informazioni che, pur appartenendo a tabelle diverse, sono logicamente legate, possono essere agevolmente riunite.

Così, se si deve stampare un ordine, i dati necessari vengono prelevati contemporaneamente dalle quattro tabelle di figura. Per chiarire meglio la distinzione tra la struttura logica dei dati e il modo in cui gli stessi dati possono essere riuniti in una visione d’insieme, possiamo prendere in esame un’altra situazione.

Consideriamo i dati relativi ai dipendenti di un’azienda e supponiamo di voler realizzare, per ogni dipendente, una sorta di curriculum, memorizzando tutti i reparti nei quali ha lavorato. È facile rendersi conto che questa situazione è caratterizzata da tre “oggetti” distinti: il dipendente, il reparto, il periodo di servizio prestalo da un dipendente in un reparto. Si hanno quindi, i tre file presentati in figura.

Dalla figura si vede, per esempio, che il dipendente Carlo Bianchi è stato assunto il giorno 1/4/95, nel reparto vendite, ed è rimasto in quel reparto fino al 14/7/06; dal giorno successivo fino al 15/10/96 ha lavorato al personale. I dipendenti e i reparti sono identificati per mezzo di un codice, che ne costituisce la chiave primaria. La chiave della terza tabella, invece, è costituita da tre campi: il codice del reparto, il codice del dipendente, la data nella quale è iniziato il lavoro del dipendente nel reparto.
Quest’ultimo campo è necessario perché un dipendente potrebbe aver lavorato nello stesso reparto in due periodi diversi e, in questo caso, nella tabella esisterebbero due record contenenti Io stesso codice dipendente e lo stesso codice reparto. Di conseguenza, i due codici non sono sufficienti a identificare univocamente i record della terza tabella.

Tra i dipendenti e i reparti esiste una relazione molti a molti, perché un dipendente può, nel corso della sua vita aziendale, lavorare in più reparti e in un reparto lavorano o hanno lavorato diversi dipendenti. La terza tabella nasce proprio perché sia possibile registrare informazioni sul lavoro svolto dai dipendenti nei reparti. Supponiamo ora che si voglia consegnare a ogni dipendente un prospetto del tipo di quello presentalo in figura. Per ottenerlo, il gestore di database riunisce i dati dei dipendenti, quelli dei reparti e quelli relativi ai periodi di servizio prestato.

Un sistema per la gestione di basi di dati è responsabile della corretta manutenzione dei file e dei loro collegamenti nell’ambito dei database progettati dall’utente. Inoltre, è in grado di fornire, se occorre, finta visione d’insieme di tutte le informazioni che di volta in volta devono essere elaborate. Attraverso un gestore di database, si possono effettuare anche molti controlli sulla correttezza dei dati memorizzati. Supponiamo, per esempio, che facciano parte della stessa base di dati una tabella relativa ai clienti e una tabella contenente i dati dei pagamenti da essi effettuati.
Tra i due “oggetti” (cliente e pagamento) esiste una relazione 1-M, che può essere posta sono il controllo del sistema di gestione in modo che, ogni volta che viene registrato un nuovo pagamento, verifichi se si riferisce a un cliente effettivamente esistente nella relativa tabella e, in caso contrario, rifiuti di effettuate l’inserimento. Analogamente, deve essere negato il permesso di cancellare i dati di un cliente quando esistono ancora dei pagamenti che gli si riferiscono.

L’INTEGRITÀ DEI DATI
Attuando questi controlli, il sistema di gestione riesce a mantenere la coerenza tra informazioni contenute in file diversi e collegate tra loro; contribuisce, così, alla conservazione di quella che si chiama integrità dei dati. Si possono attivare anche controlli sul contenuto di alcuni campi; per esempio, si può imporre che un importo sia compreso entro certi valori. A questo punto, però, è necessario descrivere, almeno per sommi capi, come si utilizza un gestore di database. Vi sono sistemi per la gestione di basi di dati che sono linguaggi veri e propri (come il dBase III) e quindi permettono di scrivere tutti i programmi necessari alle elaborazioni che si vogliono effettuare. Utilizzando i comandi messi a disposizione dal linguaggio, si può, prima di tutto, comunicare al sistema il nome e la struttura delle tabelle che sono state progettate. Fatto questo, si scrivono i programmi per l’inserimento dei dati e la loro elaborazione. È, però, possibile operare su un database anche utilizzando linguaggi tradizionali, come il Cobol; in questo caso, si dovrà ricorrere a un uso “combinato” di istruzioni del linguaggio tradizionale e di istruzioni proprie di un sistema per la gestione di basi di dati (uno, ovviamente, che sia progettato in modo da poter essere utilizzato insieme al linguaggio tradizionale scelto). In questo caso, si scrive normalmente il programma nel linguaggio tradizionale, ma, quando occorre effettuare operazioni sul database, si utilizza un comando proprio del sistema “abbinato”. Vale la pena di sottolineare che, in ogni caso, un sistema per la gestione di basi di dati mette a disposizione dell’utente due gruppi di comandi:

• quelli che devono essere utilizzati per la definizione dei dati: in ambiente relazionale, servono a descrivere la struttura delle tabelle, i campi che le compongono, gli indici primari e secondari. i legami tra una tabella e un’altra;
• quelli che devono essere utilizzati per le operazioni sui dati.

OPERAZIONI SUI DATI
Quando si opera sui dati, uno dei problemi principali è costituito dal fatto che più utenti possono accedere contemporaneamente allo stesso database. Consideriamo, per esempio, il sistema informatico di una banca. Tutte le operazioni di sportello relative ai conti correnti, per lo meno all’interno della stessa filiale, operano su un unico database, contenente i dati anagrafici dei clienti, i dati relativi ai conti correnti (numero del conto, data di apertura, saldo, ecc.) e dati relativi ai movimenti (data, importo, causale, ecc.). Supponiamo, ora, che due impiegati si trovino, contemporaneamente, ad accreditare due somme sullo stesso conto corrente e che ognuno dei due possa, senza alcun controllo da parte del sistema, richiedere la visualizzazione, sul video del proprio computer, dei dati del conto. Questo significa che il sistema di gestione legge i dati relativi al conto e li rende disponibili. Quando un impiegato immette, attraverso il video, l’importo da accreditare, esso viene sommalo al valore del saldo che è stato letto.

Supponiamo, ora, che la sequenza delle operazioni sia:

1. il primo impiegato richiede la visualizzazione dei dati (il saldo risulta pari a lire 10.000.000);
2. il secondo impiegato richiede la visualizzazione dei dati (il saldo risulta ancora pari a lire 10.000.000);
3. il primo impiegato registra un versamento di lire 100.000; esse vengono sommate al saldo che è stato letto e quindi il valore del saldo viene modificato a lire 10.100.000;
4. il secondo impiegato effettua un versamento di lire 50.000; esse vengono sommate al saldo che è stato letto (ancora lire 10.000.000) e quindi ora il valore del saldo risulta lire 10.050.000.

Questo accade perché le operazioni si sono svolte secondo una sequenza che non dovrebbe assolutamente essere permessa, se si vogliono evitare conseguenze disastrose. Il sistema di gestione del database deve svolgere quindi anche questa funzione importantissima: impedire che, mentre un utente sta effettuando un aggiornamento su un particolare record, altri utenti richiedano di aggiornare lo stesso record. Nel nostre esempio, allora. le operazioni 1, 2, 3, 4 devono essere eseguite in un altro ordine (1, 3, 2, 4) perché il sistema impedisca la sovrapposizione di due aggiornamenti. In questo modo, la seconda lettura reperisce il valore già aggiornato del saldo (lire 10.100.000) e quindi il risultato finale del passo 4 è un nuovo saldo di lire 10.150.000, che è corretto. Il sistema di gestione, quindi, deve essere in grado di “mettere in fila” tutte le richieste di operare aggiornamenti sul medesimo record, mentre, ovviamente, può permettere di aggiornare contemporaneamente record diversi.

LA PROTEZIONE DEI DATI
Può darsi che, tra tutte le operazioni che si possono effettuare su un database, alcune siano di natura riservata e quindi non sia possibile permetterle indistintamente a tutti gli utenti del sistema. In casi del genere, si ha la possibilità di proteggere i dati per mezzo di password: in questo modo, se un utente tenta di compiere un’operazione riservata, il sistema glielo permette solo se ha fornito una password che Io autorizza a eseguirla. In mancanza della password corretta, l’operazione viene rifiutata. Il funzionamento è simile a quello dei prelievi da uno sportello automatico, in cui l’operazione non viene effettuata se chi la richiede non è in grado di fornire il numero di codice associato alla sua tessera. I dati contenuti in un database possono risultare danneggiati non sola a causa dell’esecuzione di operazioni non autorizzate, ma anche per errori involontari o malfunzionamenti imprevisti. Può accadere, per esempio, che venga eseguita, un’elaborazione che è stata progettata male, dal punto di vista logico e quindi aggiorna i dati in modo sbagliato. Oppure può succedere che si verifichi un errore fisico sul disco contenente i dati. In casi di questo tipo, nasce il problema di ripristinare una versione corretta della base di dati, senza però perdere gli ultimi aggiornamenti effettuati.

La copia di sicurezza
Supponiamo, per esempio, di aver eseguito una copia di sicurezza del database alla fine di una giornata di lavoro e di aver poi apportato diverse modifiche al contenuto dei suoi dati nel corso della giornata seguente. Se, a questo punto, si verifica un errore, logico o fisico, a causa del quale i dati risultano irrimediabilmente danneggiati, si può, certamente, ripristinare la copia del giorno prima, ma, così facendo, si perdono tutti gli aggiornamenti della giornata in corso. Per evitare problemi di questo genere, un sistema per la gestione di basi di dati tiene traccia di tutte le variazioni avvenute dal momento in cui è stata eseguita l’ultima copia in poi. Così, quando si verifica un guasto, si può ripristinare una versione corretta dei dati utilizzando l’ultima copia e poi rieseguire, una per una, tutte le operazioni di aggiornamento di cui il sistema ha temuto traccia.

{/gspeech} 

Esercizi

1. Cos’è una base di dati?

• Programmi per la lettura di informazioni su computer remoti.
• Sono archivi di dati, organizzati in maniera opportuna affinché sia possibile, tramite appositi software, effettuare su di essi una serie molto ampia di operazioni, quali ricerche, inserimenti, ecc.
• Soltanto finestre di Windows.
• Dispositivi di memorizzazione dei dati. 

2. A che cosa serve il modello Entità/Relazioni nel progetto di database?

• Permette di rappresentare tutti gli elementi che compongono una base di dati in maniera chiara e concisa.
• Rappresenta i dati che sono contenuti nella base di dati.
• Permette di rendere più veloce il database.
• Permette di rendere più compatto il database.

ESERCIZI

1. Che cos’è la chiave primaria di un’entità?

• L’attributo che contraddistingue un elemento appartenente a quell’entità da tutti gli altri elementi appartenenti alla stessa entità.
• Un attributo come gli altri.
• Un attributo che è più importante degli altri in quanto può esistere o no.
• Nessuna delle precedenti.

2. Che cosa si intende per attributi multivalore?

• Sono attributi che contengono o meglio possono contenere un diverso numero di valori.
• Sono attributi che si spezzano in diversi valori.
• Non esistono.
• Sono attributi che inglobano al loro interno la chiave primaria.

3. Le relazioni 1®1 indicano che:

• Ad un elemento della prima entità corrisponde sempre un elemento della seconda e viceversa.
• Ad un elemento della prima entità corrisponde al massimo un elemento della seconda e al minimo nessun elemento e viceversa.
• Ad un elemento della prima entità corrispondono sempre tanti elementi della seconda e viceversa.
• Nessuna delle precedenti.