In generale, con il termine base di dati o database si intende un insieme di file, memorizzati su 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 ed è utile sottolinearne il 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 la nostra contabilità: nel primo registreremo 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 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 usate 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, come accade nella maggior parte dei casi.
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 tutte queste informazioni.
Supponiamo di dover elencare i campi di un record che contenga i dati riferiti a un particolare condomino: cominciamo con il codice (assegnato a 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 (lo 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 condomino?
La situazione peggiora 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: lo 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.
Conviene quindi memorizzare in altri file tutte le informazioni che si ripetono. La pretesa di raccogliere tutti i dati nello stesso file costituisce 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.
Meglio 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 dallo schema, il collegamento tra un condomino e tutti gli “oggetti” di sua competenza (appartamenti, rate ecc.) è realizzato per mezzo del codice del condomino stesso. Al codice dello stesso condomino possono fare riferimento più appartamenti, più rate e più pagamenti.
Supponiamo di voler registrare alcune informazioni relative alle visite effettuate da un medico. Si potrebbe progettare un file come quello presentato in figura. Poiché 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 nasce da un errore concettuale: sono stati riuniti 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 anche la data. Conviene, allora, progettare due file distinti: uno per i pazienti e uno per le visite.
Consideriamo 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: codice del dipendente, nome e cognome, data di nascita, indirizzo, telefono, data di assunzione, qualifica, codice fiscale, codice del progetto, descrizione del progetto, durata 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 legato al codice del dipendente che vi è assegnato, mentre i dati relativi al progetto non riguardano il dipendente, ma il progetto stesso. Inoltre: quando nasce un nuovo progetto, non si possono registrare i dati ad esso relativi finché non gli viene assegnato qualche dipendente; se si deve modificare (es. la durata prevista), occorre intervenire su tutti i record dei dipendenti assegnati. Conviene, allora, distinguere due “oggetti”: dipendente e progetto.
Processo di normalizzazione
I tre esempi precedenti presentano situazioni non corrette e indicano gli aggiustamenti necessari. Si è data così un’idea del processo di normalizzazione, mettendo in evidenza gli errori di progettazione da evitare per non incorrere negli inconvenienti evidenziati.
Le indicizzazioni
La realizzazione vera e propria del database avviene in una fase successiva. È vero però che i dati si devono poter interrogare ed elaborare in modo efficiente e quindi occorre prendere decisioni sul modo di organizzarli.
La chiave primaria
Il primo problema nella gestione di un database è riuscire a ricercare le informazioni memorizzate in un tempo soddisfacente. In un record, si dice chiave primaria un campo (o un insieme di campi) sufficiente a individuare univocamente un record all’interno del file.
Consideriamo il file che contiene i dati anagrafici dei dipendenti di un’azienda. Il nome e il cognome non bastano (possono esistere omonimi). Si potrebbe unire al nome e al cognome la data di nascita, sperando che i tre campi insieme bastino per un’identificazione sicura (non garantito). Oppure si potrebbe usare il codice fiscale. In ogni caso, chiavi così complesse sono scomode; conviene attribuire a ogni dipendente un codice (per esempio di 5–6 caratteri): un dato “di comodo”, progettato allo scopo di identificare correttamente i record.
Supponiamo ora di mantenere informazioni sugli stipendi che i dipendenti percepiscono ogni mese. Non sarebbe corretto aggiungerle ai record anagrafici, perché si tratta di dati che si ripetono (uno stipendio per ogni mese). Conviene progettare un nuovo file, in cui un record contenga il codice del dipendente, il mese e l’anno ai quali lo stipendio si riferisce e poi tutti i dati del cedolino. La chiave primaria, in questo caso, è formata da codice + mese + anno.
In generale, una chiave primaria viene utilizzata per ricercare un particolare record. La ricerca sequenziale di tutti i record è inaccettabile su file grandi, quindi si associa al file un indice, tabella con (chiave → posizione del record nel file).
La chiave secondaria
Si può cercare anche in base a un campo non scelto come chiave primaria (es. “qualifica”). Il risultato non è univoco. Un campo così usato prende il nome di chiave secondaria. Anche per queste ricerche si può associare un indice secondario.
Se al file dipendenti viene aggiunto il record relativo a Franco Biagi (H7E75) in posizione 4, l’aggiornamento si deve riflettere nell’indice primario e nel secondario. Se si cancella il record di Aldo Rossi (S3R46), la riga corrispondente va rimossa nell’indice primario e l’indicazione nella voce “impiegato” dell’indice secondario va aggiornata.
Gli indici
Gli indici rendono più veloci le ricerche. Cercando il codice F9A32 nell’indice primario si ottiene subito la posizione del record (es. 2). Cercando la qualifica “operaio” nell’indice secondario si trovano le posizioni 3 e 4.
In un DBMS esistono comandi semplici per creare indici primari o secondari. Dal momento della creazione, il sistema si fa carico di tutti gli aggiornamenti necessari in modo trasparente.
Un database è un insieme di file con dati collegati tra loro. Vediamo, con alcuni esempi, come i dati di un file possano essere collegati logicamente a quelli di un altro.
Consideriamo l’insieme di tutti i dati gestiti dall’ufficio personale di un’azienda. Per un dipendente (identificato da un codice) distinguiamo le informazioni anagrafiche dagli stipendi, dai progetti a cui partecipa, dai corsi di aggiornamento, ecc.
Supponiamo che i dipendenti possano richiedere un prestito. Non tutti lo fanno; quando accade, occorre registrare importo, tasso, durata, importo della rata, numero totale di rate, numero di rate pagate. Non è possibile sovrapporre due prestiti contemporaneamente: ognuno è al più uno.
Il collegamento dipendente–prestito è di tipo 1–1: a un dipendente non corrisponde più di un prestito e ogni prestito si riferisce a un solo dipendente. Per legare i due oggetti si aggiunge ai dati di ciascuno la chiave primaria dell’altro.
Consideriamo i dati relativi ai conti correnti gestiti da una banca. Oggetti: cliente (chiave: codice), conto corrente (chiave: numero conto), movimento (numerato progressivamente nell’ambito del conto). Per i movimenti si memorizzano importo, data, causale.
Le corrispondenze sono 1–M: a ogni cliente possono corrispondere più conti; a ogni conto più movimenti. Un “conto” contiene il codice cliente; un “movimento” contiene il numero conto. La chiave del movimento può essere la coppia (numero conto, numero movimento).
Consideriamo i dati relativi ai clienti e agli ordini. C’è una relazione 1–M tra cliente e ordini (un ordine fa riferimento a un solo cliente). Tra i dati dell’ordine compare quindi il codice cliente.
Occorre poi registrare gli articoli ordinati. Il numero di articoli per ordine può variare: conviene modellare le righe d’ordine come oggetti autonomi, ognuna con codice prodotto e quantità, e con riferimento al numero dell’ordine a cui appartiene. Per il prodotto basta il codice (descrizione, prezzo, IVA, ecc. sono nel file “prodotti”).
Ordini e prodotti sono collegati da una relazione N–M: un ordine può contenere più prodotti e un prodotto comparire in più ordini. Il legame si esprime introducendo un terzo oggetto: le righe d’ordine, scomponendo la N–M in due relazioni 1–M.
I sistemi di gestione
In analisi si costruisce uno schema (modello) con tutti gli oggetti e le informazioni che li caratterizzano. Negli esempi si è supposto che a ogni oggetto corrisponda un file e che i collegamenti logici siano realizzati inserendo la chiave primaria dell’altro oggetto. Ricorda però che lo schema è soprattutto un modello logico; la realizzazione fisica dipende dal DBMS scelto.
Il sistema di tipo relazionale
Finora si è fatto riferimento a un gestore relazionale, in cui i dati sono organizzati in tabelle collegabili per mezzo di campi in comune. Esistono anche sistemi gerarchici e reticolari, ma in generale un DBMS relazionale aderisce meglio al modello logico e offre maggiori facilitazioni.
Prima della stesura dei programmi, in ambiente relazionale occorre:
- analizzare il problema e individuare gli “oggetti” (a ogni oggetto corrisponderà una tabella);
- per ogni tabella, stabilire i dati (campi) che compongono i record;
- prevedere i campi necessari ai legami tra record di tabelle diverse.
Quando il problema è complesso, conviene scomporlo in parti e sviluppare analisi separate. Spesso i sottoproblemi condividono dati (es. l’anagrafica clienti usata da conti e depositi). In questi casi è corretto progettare programmi distinti che utilizzino gli stessi file. Storicamente si duplicavano file (magazzino e fatturazione), con spreco di spazio e possibili discordanze; oggi si tende alla condivisione.
L’integrazione dei dati
Mantenendo distinti i programmi ma condividendo i dati si realizza l’integrazione dei dati: un unico patrimonio informativo utilizzabile da diversi processi. Dati (organizzati in uno o più database) e programmi costituiscono il sistema informatico dell’azienda. Un DBMS, soprattutto in schemi complessi, mette a disposizione dei programmi la porzione di dati (anche da più file) che essi devono elaborare.
Se si deve stampare un ordine, i dati necessari vengono prelevati contemporaneamente dalle quattro tabelle sopra. È importante distinguere la struttura logica dei dati dal modo in cui essi vengono riuniti in una “vista” per stampa o uso operativo.
Consideriamo ora i dati relativi ai dipendenti di un’azienda, volendo realizzare per ciascuno un “curriculum” con tutti i reparti nei quali ha lavorato. Gli oggetti sono tre: dipendente, reparto, periodo di servizio. Dipendenti e reparti sono identificati da un codice (chiavi primarie). La chiave della tabella “servizi” è composta da tre campi: codice reparto, codice dipendente, data di inizio servizio (necessaria perché lo stesso dipendente potrebbe lavorare nello stesso reparto in periodi diversi).
Tra dipendenti e reparti esiste una relazione N–M; la terza tabella consente di registrare i periodi di servizio. Per ottenere un prospetto come quello seguente, il DBMS riunisce i dati delle tre tabelle.
L’integrità dei dati
Un DBMS è responsabile della corretta manutenzione dei file e dei loro collegamenti, e può imporre controlli di coerenza. Per esempio, tra cliente e pagamento (relazione 1–M) il sistema può verificare, all’inserimento di un pagamento, l’esistenza del cliente e rifiutare l’inserimento in caso contrario; o negare la cancellazione di un cliente ancora referenziato da pagamenti. Attuando questi controlli, il DBMS mantiene la coerenza tra informazioni collegate e contribuisce all’integrità dei dati. Si possono attivare anche vincoli sul contenuto di alcuni campi (es. imporre che un importo sia compreso entro certi valori).
Alcuni DBMS sono veri e propri linguaggi (es. dBase III) e permettono di scrivere programmi di elaborazione. In alternativa si possono usare linguaggi tradizionali (es. Cobol) con comandi del DBMS abbinato. In ogni caso, un DBMS mette a disposizione due gruppi di comandi:
- definizione dei dati: struttura delle tabelle, campi, indici primari e secondari, legami tra tabelle;
- operazioni sui dati: inserimento, modifica, cancellazione, interrogazione.
Operazioni sui dati
Un problema centrale è l’accesso concorrente: più utenti possono operare sullo stesso database. Esempio in banca: due impiegati accreditano contemporaneamente somme sullo stesso conto e ciascuno legge lo stesso saldo iniziale (10.000.000). Il primo somma 100.000 (saldo → 10.100.000), il secondo, basandosi ancora su 10.000.000, somma 50.000 (saldo → 10.050.000): risultato errato.
Il DBMS deve impedire la sovrapposizione di due aggiornamenti sul medesimo record, “mettendo in fila” le operazioni. L’ordine corretto è: lettura 1 → aggiornamento 1 → lettura 2 → aggiornamento 2; così il secondo vede il saldo aggiornato (10.100.000) e il risultato finale diventa 10.150.000, che è corretto. Il DBMS può permettere in parallelo aggiornamenti su record diversi.
La protezione dei dati
Alcune operazioni possono essere riservate. Si usano password e controlli di autorizzazione: senza credenziali l’operazione viene rifiutata. I dati possono danneggiarsi anche per errori involontari o guasti fisici: occorre poter ripristinare una versione corretta senza perdere gli ultimi aggiornamenti.
La copia di sicurezza
Supponiamo di aver eseguito una copia di sicurezza alla fine di una giornata e di aver poi apportato modifiche nel corso della giornata successiva. Se si verifica un errore che danneggia i dati, si può ripristinare la copia del giorno prima, ma si perderebbero gli aggiornamenti correnti. Per evitare ciò, un DBMS tiene traccia di tutte le variazioni avvenute dall’ultima copia: quando si verifica un guasto, si ripristina l’ultima copia e poi si rieseguono, una per una, tutte le operazioni di aggiornamento di cui il sistema ha tenuto traccia.
Esercizi
- Programmi per la lettura di informazioni su computer remoti.
- Archivi di dati, organizzati in maniera opportuna affinché sia possibile, tramite appositi software, effettuare su di essi operazioni come ricerche, inserimenti, ecc.
- Soltanto finestre di Windows.
- Dispositivi di memorizzazione dei dati.
- 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.
- 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.
- Attributi che possono contenere un diverso numero di valori.
- Attributi che si spezzano in diversi valori.
- Non esistono.
- Attributi che inglobano al loro interno la chiave primaria.
- 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.