2001/02 Lezione N. 17 Progetto di banche dati

2001/02
Lezione N. 17
Progetto di banche dati
Generalità. Il progetto di una banca dati consiste nella scelta dei dati e della loro organizzazione. Il progetto di un
database è un’operazione complessa che deve essere eseguita con rigore per portare a risultati soddisfacenti.
Esistono diverse metodologie di progetto, la cui scelta dipende anche dal tipo di database che si vuol realizzare. In
questa lezione illustreremo una tecnica di normalizzazione delle relazioni che è particolarmente adatta al progetto
di database relazionali. Si noti che il progetto di un database è un’attività informatica che non richiede
programmazione.
Classificazione dei dati e definizione dei campi. Il progetto comincia individuando tutti gli elementi (dati, o
attributi) che compongono le informazioni che il database dovrà gestire. Tali elementi saranno associati ai campi
del database, caratterizzati da un nome (unico) e da un tipo di dati. L’assegnazione dei nomi e dei tipi ai campi del
database è la prima fase del progetto.
Es: supponiamo di voler costruire un database per la gestione degli ordini di un’azienda. Supponiamo che i dati
che rappresentano un ordine siano: il codice, la città e la nazione del fornitore, il codice del prodotto, la quantità di
prodotto. Per ogni dato creiamo un campo caratterizzato da nome e tipo: FID (intero di 3 cifre), FC (stringa di 10
caratteri), FN (stringa di 10 caratteri), PID (intero di tre cifre), Q (intero di 2 cifre).
Rappresentazione delle relazioni. Il progetto della struttura del database consiste nell’individuare (e
rappresentare in forma tabellare) le relazioni che intercorrono tra i campi. Indichiamo con una freccia (AÆB) la
relazione funzionale tra il campo A e il campo B di uno stesso record. In un database relazionale, ogni tabella
rappresenta una o più relazioni tra i suoi campi (o colonne). In particolare, esiste una relazione tra l’insieme dei
campi che compongono una chiave della tabella e i restanti campi della tabella stessa. Infatti, per la proprietà di
unicità di cui la chiave gode per definizione, il valore dei campi che compongono la chiave individua univocamente
un record, e quindi determina univocamente il contenuto dei restanti campi.
Il progetto della struttura del database è complesso poiché non c’è un solo modo di rappresentare in forma
tabellare le relazioni tra i dati, e dalla rappresentazione dipende l’efficienza del database. I database la cui struttura
rispetta alcuni requisiti ben definiti (che vedremo in seguito) sono detti in forma normale. E’ buona norma
progettare database in forma normale. Questo può essere fatto applicando i procedimenti di normalizzazione
descritti nel seguito a partire da un progetto di primo tentativo che generalmente non è in forma normale.
Prima forma normale. Un database è in prima forma normale (1NF) quando le tabelle che lo compongono hanno
record tutti della stessa lunghezza e i campi omonimi occupano la stessa posizione (colonna). Se una tabella non è
in prima forma normale, la gestione dei dati in essa contenuti diventa laboriosa (ricerca solo sequenziale) e può
causare spreco di memoria e poca flessibilità.
Prima normalizzazione. Per costruire un database in prima forma normale è sufficiente costruire un’unica tabella
le cui colonne sono tutti i campi del database (presi una sola volta).
Es: Tabella1(FID,FC,FN,PID,Q).
Seconda forma normale. Una tabella è in seconda forma normale (2NF) quando non esistono dipendenze
funzionali tra un sottoinsieme dei campi che compongono una chiave e un sottoinsieme dei restanti campi. La
dipendenza da una chiave è detta dipendenza piena, quella da un sottoinsieme dei campi chiave è detta
dipendenza non piena.
Es: I campi {FID,PID} sono una chiave per la tabella dell’esempio precedente, quindi sussiste la relazione
{FID,PID}Æ{FC,FN,Q}. Tuttavia sussiste anche la dipendenza non piena {FID}Æ{FC,FN}. Pertanto, la tabella 1 non
è in seconda forma normale (pur essendo in prima forma normale).
Seconda normalizzazione. Il procedimento di seconda normalizzazione consiste nello spezzare la tabella
originale in due nuove tabelle: la prima esprime la dipendenza non piena, la seconda esprime la dipendenza
(piena) dei restanti campi dalla chiave originale.
Es: Tabella1(FID,FC,FN) rappresenta la relazione {FID}Æ{FC,FN}, Tabella2(FID,PID,Q) rappresenta la relazione
{FID,PID}Æ{Q}. Si noti che la relazione {FID}Æ{FC,FN} è diventata una dipendenza piena per la nuova tabella. Le
due tabelle che compongono il database sono entrambe in seconda forma normale, quindi lo è il database stesso.
Terza forma normale. Una tabella è in terza forma normale (3NF) se è in seconda forma normale e non esistono
dipendenze tra i suoi campi non chiave. Dati due campi non chiave A e B, una dipendenza AÆB creerebbe una
dipendenza transitiva di B dalla chiave K: KÆAÆB.
Es: La Tabella1 dell’esempio precedente ha una dipendenza transitiva FIDÆFCÆFN, pertanto non è in terza
forma normale.
Terza normalizzazione. Il procedimento di terza normalizzazione consiste nel dividere la tabella originale in due
nuove tabelle: la prima esprime la dipendenza tra i campi non chiave della tabella originale, la seconda esprime la
dipendenza dalla chiave originale ma non contiene più i campi dipendenti transitivamente.
Es: Tabella2(FC,FN) esprime la relazione {FC}Æ{FN}, Tabella3(FID,FC) esprime la relazione {FID}Æ{FC}.
Ridondanza. Le forme normali 2FN e 3FN servono ad eliminare ridondanza, ovvero duplicazione di dati. Si pensi
ad esempio alla tabella (FID,FC,FN,PIN,Q). In ogni record che rappresenta un ordine fatto allo stesso fornitore
(FID) va ripetuto l’indirizzo del fornitore (FC,FN). Questo è inefficiente in termini di occupazione di memoria, ma
soprattutto può creare inconsistenze e perdita di informazioni. Infatti, se cambia l’indirizzo del fornitore occorre
modificarlo in tutti i record a lui riferiti. Inoltre, se si cancellano tutti i record relativi agli ordini fatti ad un certo
fornitore, si perdono anche le informazioni sull’indirizzo del fornitore.
Ref: Boni Cap. 7.430-438