Progetto di database: normalizzazione delle tabelle in 3NF

Progetto di database

La normalizzazione delle tabelle

SOTOO DLOI 01110100101 00 201010 010 TTOLIOLIO 0110110110101010100110110101010 T 1010101001018 1011101010101001010 01019 010Normalizzazioni

Una volta definito lo schema della base di dati, è utile effettuare una verifica del risultato della progettazione: se infatti lo schema della base di dati (cioè lo schema relazionale) non è costruito correttamente, possono verificarsi anomalie nell'utilizzo della base di dati stessa.Normalizzazioni

Consideriamo ad esempio la seguente tabella relativa agli ordini effettuati dai clienti (la chiave primaria è composta dagli attributi CodCliente, CodArticolo):

Anomalie nelle tabelle

Si possono notare le seguenti anomalie:

• Anomalia in inserimento: non è possibile inserire un nuovo cliente se non contestualmente ad un articolo ordinato; la chiave primaria della tabella è infatti CodCliente, CodArticolo, che non può mai essere nulla. Analogamente, non è possibile inserire un nuovo articolo senza specificare un cliente.
• Anomalia in cancellazione: nel cancellare una riga (ad esempio (Neri, Art5)) si possono cancellare i dati di un Cliente. Analoghe considerazioni valgono anche per un articolo.
• Anomalia in aggiornamento: la variazione dell'indirizzo di un cliente comporta di dover aggiornare tutte le righe e dove compare quel cliente.

Processo di normalizzazione

Per eliminare queste anomalie si ricorre ad un processo di normalizzazione, che è un processo graduale attraverso il quale si verifica se lo schema della base di dati risponda a "canoni standard" di correttezza, e, applicando un insieme di regole, si portano le tabelle in quelle che sono definite "forme normali". È importante rimarcare che la normalizzazione non è una metodologia di progettazione, ma di verifica dei risultati della progettazione stessa. L'obiettivo è quello di scomporre le tabelle in tabelle più piccole senza anomalie, in modo da avere tabelle più strutturate e ridurre al minimo la ridondanza dei dati (dati ripetuti inutilmente).

Forma normale

È una proprietà di uno schema relazionale che ne garantisce la "qualità", cioè l'assenza di determinati difetti. Esistono diverse forme normali: 1NF, 2NF, 3NF, BCNF (Boyce-Codd Normal Form), 4NF, 5NF. Noi analizzeremo le regole delle prime tre forme normali.

Prima forma normale

Una tabella si dice in prima forma normale (1NF) se:

• Esiste una chiave primaria
• Ogni attributo è definito su un dominio di valori atomici (è cioè un campo semplice, non composto e non multiplo)

La 1NF è di norma soddisfatta applicando le regole viste nella progettazione logica del modello relazionale. Quindi una tabella relazionale, per definizione, è nella prima forma normale.

Note sulla prima forma normale

Un campo "data" potrebbe essere considerato un campo composto, ma di solito si tralascia questa scomposizione, considerando una data come un campo semplice. Nel valutare la scomposizione di un "indirizzo" si deve considerare dove e come l'indirizzo verrà usato:

• Se serve solo per registrare un recapito per usarlo successivamente solo in lettura, potrà essere sufficiente inserirlo in un unico campo "stringa";
• Se si volessero effettuare ricerche particolari, ad esempio in base alla via, è opportuno scomporre l'attributo in più attributi.

Nel caso di attributi multipli è necessario creare una nuova tabella, applicando la stessa regola vista nella ristrutturazione del Modello ER:

(0:N) Persona NumeriDiTelefono Nome Cognome CodPersona CodPersona Cognome Nome NumeriDiTelefono

(0:N) (1:1) Persona possiede NumeroDiTelefono O Nome Cognome NumeroDiTelefono CodPersona CodPersona Cognome Nome CodPersona (fk) NumeroDiTelefono

Dipendenza funzionale

Prima di definire la 2NF dobbiamo introdurre in concetto di Dipendenza Funzionale: Se X e Y sono due attributi di una tabella R, diciamo che Y ha una dipendenza funzionale da X ( o Y è funzionalmente dipendente da X ), e si indica con: X -> Y, se ogni valore di X in R viene associato con un solo valore di Y. Lo stesso vale se, invece di singoli attributi, si considerano insiemi di attributi. Si dice che X determina Y, o anche che X è un determinante di Y.

Dipendenza funzionale: identificazione dei valori

Dire che la colonna Y è funzionalmente dipendente da X è come dire che i valori della colonna X identificano i valori della colonna Y. Se la colonna X è una chiave primaria, allora tutte le colonne nella tabella R devono essere funzionalmente dipendenti da X. Se, ad esempio, X è la chiave primaria, costituita da più attributi, e Y varia al variare di qualsiasi parte della chiave primaria, possiamo dire che Y dipende dall'intera chiave; viceversa, se Y varia al variare di una sola parte della chiave, Y non dipende funzionalmente dalla chiave, ma solo da una parte di essa.

Seconda forma normale (2NF)

Una tabella è in seconda forma normale (2NF) se è in prima forma normale e ogni attributo non chiave dipende funzionalmente e completamente (cioè non parzialmente) dalla chiave primaria. Nota: Dalla definizione di seconda forma normale ne consegue che in una tabella dove la chiave primaria è semplice (non composta), non ci sono problemi inerenti alla seconda forma normale.

Anomalie in 2NF: esempio

Vediamo quali sono le anomalie che possiamo incontrare se una tabella R non è in 2NF partendo da un esempio:

Anomalie riscontrabili nella tabella R (CodOrdine (pk), CodCliente, CodProdotto (pk), DataOrdine, Quantità, PrezzoUnitario, Descrizione):

• Anomalia in inserimento: non è possibile inserire un nuovo articolo sino a quando non viene ordinato; la chiave primaria della tabella è infatti CodOrdine, CodProdotto, che non può mai essere nulla.
• Anomalia in cancellazione: se si cancellano la 2ª, 3ª e 4ª riga si perdono le informazioni sugli articoli.
• Anomalia in aggiornamento: se varia il prezzo unitario di un articolo, occorre aggiornare tutte le ennuple dove compare.

Verifica delle dipendenze funzionali

Verifichiamo le dipendenze funzionali dalla chiave primaria, composta dagli attributi: CodOrdine e CodProdotto:

• CodOrdine-> CodCliente, DataOrdine
• CodOrdine, CodProdotto > Quantità
• CodProdotto PrezzoUnitario, Descrizione

Le dipendenze funzionali (DF) possono anche essere descritte mediante uno schema grafico come nella seguente figura:

CodOrdine CodCliente CodProdotto DataOrdine Quantità PrezzoUnitario Descrizione

Osservazione sulle dipendenze funzionali

Una Dipendenza Funzionale (DF) è una proprietà della semantica o del significato degli attributi, cioè:

• è una proprietà dello schema relazionale di R: non si può desumere dai dati contenuti in una particolare istanza di una tabella (cioè dai dati contenuti in una tabella reale);
• deve essere definita esplicitamente da qualcuno che conosce il significato degli attributi di R.

Scomposizione della tabella R in 2NF

Per portare la tabella R in 2NF e risolvere le anomalie di cui sopra, si scompone la tabella R in relazioni più semplici, dove ogni attributo non chiave dipenda funzionalmente e completamente dalla chiave primaria, seguendo i seguenti passi:

a) Costruiamo una prima tabella R1 considerando gli attributi nelle dipendenze funzionali che violano la 2NF: nel nostro caso partiamo da: CodOrdine CodCliente, DataOrdine. Il determinante della dipendenza funzionale, CodOrdine, diventa chiave primaria di una nuova tabella: R1 (CodOrdine (pk), CodCliente, DataOrdine)

b) Riprendiamo la tabella R togliendo gli attributi CodCliente, DataOrdine (parzialmente dipendenti dalla chiave) inseriti in R1 e mantenendo il determinante CodOrdine (come chiave esterna) : R2 (CodOrdine (fk), CodProdotto (pk), Quantità, PrezzoUnitario, Descrizione) e ripetiamo il procedimento di decomposizione da a) applicandolo a R2:

a') Verifichiamo le dipendenze funzionali dalla chiave primaria CodProdotto di R2: CodProdotto -> PrezzoUnitario, Descrizione Il determinante della dipendenza funzionale, CodProdotto, diventa chiave primaria di una nuova tabella: R3 (CodProdotto (pk), PrezzoUnitario, Descrizione)

b') Riprendiamo la tabella R2 togliendo gli attributi PrezzoUnitario, Descrizione (parzialmente dipendenti dalla chiave) inseriti in R3, lasciando il determinante CodProdotto (come chiave esterna) : R2 diventa: R4 (CodOrdine (fk), CodProdotto (fk), Quantità) e ripetiamo il procedimento di decomposizione da a) applicandolo a R4:

a") Verifichiamo le dipendenze funzionali in R4 dalla chiave primaria, composta dagli attributi: CodOrdine e CodProdotto: CodOrdine, CodProdotto -> Quantità Tutti gli attributi non chiave dipendono ora funzionalmente e completamente dalla chiave primaria.

Schema relazionale in 2NF

Riassumendo, la nostra tabella: R(CodOrdine (pk), CodCliente (pk), CodProdotto, DataOrdine, Quantità, PrezzoUnitario, Descrizione) è stata decomposta in un nuovo schema relazionale che soddisfa la 2NF:

• R1 (CodOrdine (pk), CodCliente, DataOrdine)
• R3 (CodProdotto (pk), PrezzoUnit, Descrizione)
• R4 (CodOrdine (fk), CodProdotto (fk), Quantità)

Se ora, a partire dallo schema logico così ottenuto nel processo di normalizzazione, costruiamo (con una operazione di reverse engineering) lo schema concettuale ER corrispondente, otteniamo il seguente:

Quantità (1:N) (0:N) Ordine contiene Prodotto DataOrdine PrezzoUnitario CodCliente Descrizione CodOrdne CodProdotto