Normalizzazione di un database

Ci si serve di una base dati (o database) per memorizzare un certo gruppo di informazioni di interesse in maniera ordinata ed efficiente. Una delle funzionalità tipiche offerte da un database consente di estrarre dalla base dati tutti e soltanto i dati che corrispondano ad un certo criterio, specificato dall’utente.

Ad esempio, immaginiamo di memorizzare in un database i dati anagrafici relativi ai frequentatori di una certa palestra. Supponiamo poi di essere interessati a conoscere nomi e cognomi di tutti gli iscritti che non abbiano ancora compiuto trenta anni.

E’ possibile ottenere tale informazione tramite una semplice interrogazione del database, chiamata più comunemente anche query, che consente per l’appunto l’identificazione e la visualizzazione dei dati desiderati.

Un database dunque è uno strumento per il raggruppamento e la gestione di informazioni di varia natura tramite l’uso di tabelle, in cui i dati vengono messi in relazione tra loro. Ma in che modo le informazioni vengono raggruppate? Secondo quale criterio vengono costruite le tabelle?

La soluzione più immediata può essere l’inserimento di tutti i dati di interesse in un’unica tabella. Tale operazione però contribuisce a costruire una tabella con un numero di righe (record) e di colonne (campi) molto alto in rapporto alla mole di dati trattata.

Il problema generato dall’utilizzo di un’unica tabella, inoltre, è anche di tipo concettuale. L’utilizzo di una singola tabella non consente di evidenziare in modo puntuale e chiarificatore quali siano le specifiche relazioni che in genere coinvolgono anche uno o più sottogruppi del gruppo di dati presi in esame.

Immaginando invece che le informazioni siano contenute in più tabelle, diventa necessario e non semplice garantire che non vi siano informazioni duplicate, con conseguente spreco di memoria e necessità di più operazioni di aggiornamento.

Proprio per fornire linee guida per queste scelte, garantendo efficienza e completezza nella strutturazione dei dati, vengono definite le cosiddette forme normali di un database.

Un database strutturato in forma normale, infatti, facilita e rende più rapide le operazioni sui dati riducendo il rischio di ridondanza ed incoerenza dei dati.

Vediamo quindi di capire cosa s’intende per forme normali e normalizzazione dei database.

La prima forma normale (1NF)

La prima forma normale definita per un database esprime un concetto semplice ma fondamentale: ogni riga di ciascuna tabella deve poter essere identificata in modo univoco tramite un gruppo di dati in essa contenuti. In altre parole, in una tabella del tipo:

Alberto30Impiegato

non è possibile distinguere il dato inserito nella prima riga da quello inserito nella terza: le due righe sono infatti identiche. L’Alberto della prima riga, di 30 anni impiegato, non è infatti distiunguibile dall’Alberto, 30 anni, impiegato, della terza riga.

Il problema potrebbe essere risolto inserendo un altro campo nella tabella, con valore diverso per ogni riga, ad esempio il codice fiscale. A questo punto il database sarebbe in prima forma normale.

Il campo o l’insieme di campi diversi per ciascuna riga e sufficienti ad identificarla sono detti chiave primaria della tabella (in questo caso il codice fiscale).

LBRMNN79E64A112AAlberto30Impiegato

Il miglioramento delle prestazioni in questo caso è piuttosto evidente: la presenza di righe uguali all’interno di una tabella è infatti un evidente sintomo di inefficienza, che viene così eliminato.

Proprio per questo tutti i principali software di gestione database (come ad esempio SQL Server e Oracle) richiedono all’utente di definire una chiave primaria per ogni tabella creata.

Si noti che la presenza di una chiave primaria è requisito indispensabile ma non sufficiente affinchè una base dati sia in prima forma normale; infatti è altresì necessario che non vi siano gruppi di attributi che si ripetono (ossia ciascun attributo deve essere definito su un dominio con valori atomici).

La tabella vista poco sopra è in 1NF; per chiarezza facciamo un esempio di una tabella che, seppur munita di una chiave primaria, non può essere considerata in forma normale:

La tabella qui sopra NON è in 1NF in quanto, pur avendo una chiave primaria, presenta un campo (dettagli) che non contiene dati in forma atomica.

La seconda forma normale (2NF)

Un ulteriore miglioramento è possibile passando alla seconda forma normale. Perchè una base dati possa essere in 2NF è necessario che:

• si trovi già in 1NF;
• tutti i campi non chiave dipendano dall’intera chiave primaria (e non solo da una parte di essa).

Per fare un esempio si supponga di avere a che fare con il database di una scuola con una chiave primaria composta dai campi "Codice Matricola" e "Codice Esame":

Il database qui sopra si trova in 1NF ma non in 2NF in quanto il campo "Nome Matricola" non dipende dall’intera chiave ma solo da una parte di essa ("Codice Matricola").

Per rendere il nostro database 2NF dovremo scomporlo in due tabelle:

e

Nella prima tabella il campo "Voto" dipende correttamente dalla chiave primaria composta da "Codice Matricola" e "Codice Esame", nella seconda tabella il campo "Nome Matricola" dipende correttamente dalla sola chiave primaria presente ("Codice Matricola").

Ora il nostro database è normalizzato in seconda forma normale.

La terza forma normale

Anche la terza forma normale, che definisce in modo ancora più puntuale ed efficiente la struttura delle tabelle di un database, si basa sul concetto di dipendenza funzionale già esposto.

Un database è in 3NF se:

• è già in 2NF (e quindi, necessariamente, anche 1NF);
• tutti gli attributi non chiave dipendono direttamente dalla chiave (quindi non ci sono attributi "non chiave" che dipendono da altri attributi "non chiave").

Per fare un esempio torniamo all’ipotetico database della palestra; supponiamo di avere una base dati che associ il codice fiscale dell’iscritto al corso frequentato ed all’insegnante di riferimento. Si supponga che il nostro DB abbia un’unica chiave primaria ("Codice Fiscale") e sia così strutturato:

LBRMNN79E64A112ABB01Marco

Il nostro database non è certamente 3NF in quanto il campo "insegnante" non dipende dalla chiave primaria ma dal campo "Codice Corso" (che non è chiave). Per normalizzare il nostro DB in 3NF dovremo scomporlo in due tabelle:

LBRMNN79E64A112ABB01

e

Il nostro database è ora in terza forma normale.