Descrizione dei principi della normalizzazione dei database in Access 2000

In questo articolo viene spiegata la terminologia relativa alla normalizzazione dei database per gli utenti inesperti. Queste informazioni possono rivelarsi utili per la definizione della struttura di un database relazionale.

NOTA: è inoltre disponibile una presentazione tecnica online (WebCast) in cui sono illustrati i principi della normalizzazione dei database. Per visualizzare questa presentazione tecnica online (WebCast), visitare il seguente sito Web di Microsoft (informazioni in lingua inglese): Per ulteriori informazioni su questo argomento in una versione precedente di Access, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:

Definizione di normalizzazione

Il termine normalizzazione indica il processo di organizzazione dei dati in un database. Tale processo comprende la creazione di tabelle e la definizione di relazioni tra queste sulla base di regole progettate in modo da proteggere i dati e rendere il database più flessibile tramite l'eliminazione della ridondanza e delle dipendenze incoerenti.

La presenza di dati ridondanti comporta uno spreco di spazio su disco nonché problemi di manutenzione. Se è necessario modificare dati presenti in più posizioni, la modifica deve essere effettuata secondo le stesse modalità in tutte le posizioni. È ad esempio più agevole implementare una modifica relativa all'indirizzo di un cliente se tale dato è memorizzato solo nella tabella Clienti.

Che cos'è una "dipendenza incoerente"? Mentre è intuitivo per un utente cercare nella tabella Clienti l'indirizzo di un cliente specifico, può non avere senso cercare in tale tabella informazioni sullo stipendio del dipendente che segue quel cliente. Le informazioni sullo stipendio sono correlate al dipendente o dipendono da questo, pertanto devono essere spostate nella tabella Dipendenti. Le dipendenze incoerenti possono rendere difficoltoso l'accesso ai dati, in quanto il percorso per la ricerca dei dati può risultare mancante o danneggiato.

Per la normalizzazione dei database sono disponibili alcune regole, ciascuna delle quali viene definita "maschera normale". Se si osserva la prima regola, il database sarà nella "prima maschera normale". Se si osservano le prime tre regole, il database sarà nella "terza maschera normale". Sebbene siano possibili altri livelli di normalizzazione, la terza maschera normale è considerata il livello massimo necessario per la maggior parte delle applicazioni.

Come per molte regole e specifiche formali, gli scenari reali non garantiscono sempre la conformità totale. In generale, poiché richiede l'uso di tabelle aggiuntive, la normalizzazione viene considerata troppo onerosa per alcuni clienti. Se si decide di violare una delle prime tre regole di normalizzazione, assicurarsi che l'applicazione sia in grado di prevenire i possibili problemi derivanti, quali la ridondanza dei dati e le dipendenze incoerenti.

Nelle descrizioni che seguono sono inclusi alcuni esempi.

Prima maschera normale

• Eliminare i gruppi ripetitivi in singole tabelle.
• Creare una tabella diversa per ciascun insieme di dati correlati.
• Associare una chiave primaria a ciascun set di dati correlati.

Non utilizzare campi multipli in una singola tabella per memorizzare dati simili. Ad esempio, per controllare una voce di inventario proveniente da due possibili fornitori, è possibile creare un record di inventario che contiene i campi per Codice fornitore 1 e Codice fornitore 2.

Che cosa succede quando si aggiunge un terzo fornitore? La soluzione non consiste nell'aggiungere un campo. Sono infatti necessarie modifiche al programma e alla tabella che tuttavia non permettono di inserire agevolmente un numero variabile di fornitori. È invece opportuno inserire tutte le informazioni sui fornitori in un'altra tabella denominata Fornitori e collegare l'inventario ai fornitori tramite una chiave basata sul numero di voce o i fornitori all'inventario tramite una chiave basata sul codice fornitore.

Seconda maschera normale

• Creare tabelle diverse per insiemi di valori validi per più record.
• Correlare queste tabelle a una chiave esterna.

I record devono dipendere solo dalla chiave primaria di una tabella, se necessario una chiave composta. Se si considera, ad esempio, l'indirizzo di un cliente in un sistema di contabilità, si noterà che l'indirizzo è richiesto non solo dalla tabella Clienti, ma anche dalle tabelle Ordini, Spedizioni, Fatture, Contabilità fornitori e Raccolte. Invece di memorizzare l'indirizzo del cliente come singola voce in ciascuna tabella, memorizzarlo in un'unica tabella, ovvero nella tabella Clienti oppure in una tabella Indirizzi diversa.

Terza maschera normale

• Eliminare i campi che non dipendono dalla chiave.

I valori di un record non compresi nella relativa chiave non appartengono alla tabella. In generale, ogni volta che il contenuto di un gruppo di campi può risultare valido per più record della tabella, provare a inserire tali campi in un'altra tabella.

Ad esempio, in una tabella Colloqui di assunzione è possibile includere il nome e l'indirizzo dell'università dei candidati. Per le liste di distribuzione è tuttavia necessario disporre di un elenco completo di università. Se le informazioni sull'università sono memorizzate nella tabella Candidati, non è possibile ottenere l'elenco delle università non associate ai candidati correnti. Creare una tabella Università e collegarla alla tabella Candidati utilizzando una chiave basata sul codice università.

ECCEZIONE: l'adozione della terza maschera normale non è sempre pratica anche se auspicabile. Se si dispone di una tabella Clienti e si desidera eliminare tutte le possibili dipendenze tra campi, è necessario creare tabelle diverse per città, CAP, rappresentanti, classi di clienti e gli eventuali altri fattori che possono essere duplicati in più record. Nella teoria la normalizzazione è sempre auspicabile, ma nella pratica l'utilizzo di un numero elevato di tabelle di dimensioni contenute può determinare un degrado delle prestazioni oppure richiedere capacità di memoria di apertura dei file superiori a quelle disponibili.

Può risultare più appropriato applicare la terza maschera normale solo ai dati soggetti a frequenti modifiche. Se sussistono dei campi dipendenti, progettare l'applicazione in modo da richiedere la verifica di tutti i campi correlati in caso di modifica di un campo.

Altre maschere di normalizzazione

Sono inoltre disponibili una quarta maschera normale, denominata Boyce Codd Normal Form (BCNF) e una quinta maschera, anche se raramente prese in considerazione. Il mancato utilizzo di queste regole può non consentire una perfetta definizione del database, senza tuttavia influire negativamente sulla funzionalità.

Normalizzazione di una tabella di esempio

La procedura descritta di seguito illustra il processo di normalizzazione di una tabella degli studenti fittizia.

1. Tabella non normalizzata:
   Riduci questa tabellaEspandi questa tabella

   Student#	Advisor	Adv-Room	Class1	Class2	Class3
   1022	Jones	412	101-07	143-01	159-02
   4123	Smith	216	201-01	211-02	214-01

2. Prima maschera normale: Nessun gruppo ripetitivo
   
   Le tabelle dovrebbero presentare solo due dimensioni. Poiché a un singolo studente sono associate più classi, è necessario elencare tali classi in una tabella diversa. I campi Class1, Class2 e Class3 nel record sopra riportato sono dunque indice di problemi di progettazione.
   
   Nei fogli di calcolo viene spesso utilizzata la terza dimensione, ma non nelle tabelle. Un'altra prospettiva da cui osservare questo problema è l'utilizzo di una relazione uno-a-molti. In questo caso non inserire entrambi i lati della relazione nella stessa tabella, bensì creare un'altra tabella utilizzando la prima maschera normale ed eliminando il gruppo ripetitivo (Class#), come illustrato di seguito:
   Riduci questa tabellaEspandi questa tabella

   Student#	Advisor	Adv-Room	Class#
   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Smith	216	201-01
   4123	Smith	216	211-02
   4123	Smith	216	214-01

3. Seconda maschera normale: Eliminazione di dati ridondanti
   
   Considerare i valori multipli di Class# per ciascun valore Student# nella tabella sopra riportata. Class# non è funzionalmente dipendente da Student# (chiave primaria), pertanto questa relazione non è compresa nella seconda maschera normale.
   
   Le due tabelle che seguono illustrano la seconda maschera normale:

   Students

   Riduci questa tabellaEspandi questa tabella

   Student#	Advisor	Adv-Room
   1022	Jones	412
   4123	Smith	216

   Registration

   Riduci questa tabellaEspandi questa tabella

   Student#	Class#
   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-01

4. Terza maschera normale: Eliminazione di dati non dipendenti da chiave
   
   Nell'ultimo esempio, Adv-Room (il numero della stanza del tutor) non è funzionalmente dipendente dall'attributo Advisor. Per risolvere il problema è possibile spostare tale attributo dalla tabella Students alla tabella Faculty, come illustrato di seguito:

   Students

   Riduci questa tabellaEspandi questa tabella

   Student#	Advisor
   1022	Jones
   4123	Smith

   Faculty

   Riduci questa tabellaEspandi questa tabella

   Name	Room	Dept
   Jones	412	42
   Smith	216	42

Ahlo, Hamilton M., Randy Brown e Peter Colclough. FoxPro 2: A Developer's Guide: Expert Guidance for Industrial-Strength Programming. John Wiley & Sons, ottobre 1991. Pagine 220-225.

Jennings, Roger. Using Access 1.1 for Windows. Que Corporation, luglio 1993. Pagine 799-800.