Descrizione dei principi relativi alla normalizzazione dei database

In questo articolo viene spiegata la terminologia relativa alla normalizzazione dei database per gli utenti inesperti. La conoscenza di questa terminologia può rivelarsi utile nel discutere la struttura di un database relazionale.

Descrizione di normalizzazione

La normalizzazione è il processo di organizzazione dei dati in un database. Tale processo comprende la creazione di tabelle e la definizione di relazioni tra di esse sulla base di regole progettate in modo da proteggere i dati e rendere il database più flessibile mediante 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 ovunque seguendo le stesse modalità. Ad esempio, è più agevole implementare la modifica relativa all'indirizzo di un cliente se i dati relativi sono memorizzati 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 le informazioni relative allo stipendio del dipendente che si occupa di quel cliente. Le informazioni sullo stipendio sono correlate al dipendente, ovvero sono dipendenti da quest'ultimo, pertanto devono essere spostate nella tabella Dipendenti. Le dipendenze incoerenti possono rendere difficile l'accesso ai dati, in quanto il percorso per la ricerca dei dati può risultare mancante o danneggiato.

Per la normalizzazione dei database è necessario seguire alcune regole, Ogni regola è chiamata "forma normale". Se viene osservata la prima regola, il database è considerato in "prima forma normale". Se vengono rispettate le prime tre regole, il database è considerato in "terza forma normale". Sebbene siano possibili altri livelli di normalizzazione, la terza forma normale è considerata il livello più alto 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 ripetuti in singole tabelle.
  • Creare una tabella separata per ciascun insieme di dati correlati.
  • Identificare ciascun insieme di dati correlati associandovi una chiave primaria.

Non utilizzare campi multipli in una singola tabella per memorizzare dati simili. Ad esempio, per controllare una voce di inventario proveniente da due possibili origini, un record di inventario può contenere campi per il 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 e non permette di inserire agevolmente un numero dinamico di fornitori. È invece opportuno inserire tutte le informazioni sui fornitori in un'altra tabella denominata Fornitori e quindi collegare l'inventario ai fornitori tramite una chiave basata sul numero di voce oppure i fornitori all'inventario tramite una chiave basata sul codice fornitore.

Seconda maschera normale

  • Creare tabelle separate 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). Si consideri, ad esempio, l'indirizzo di un cliente in un sistema contabile. 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 voce separata in ciascuna tabella, è preferibile memorizzarlo in un'unica tabella, ovvero nella tabella Clienti oppure in una tabella Indirizzi separata.

Terza maschera normale

  • Eliminare i campi che non dipendono dalla chiave.

I valori di un record non compresi nella chiave del record stesso non appartengono alla tabella. In generale, ogni volta che il contenuto di un gruppo di campi può essere applicabile a più record della tabella, vlautare la possibilità di inserire tali campi in una tabella separata.

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

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

Può risultare più appropriato applicare la terza forma 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

La quarta maschera normale, chiamata anche Boyce Codd Normal Form (BCNF) e la quinta maschera normale esistono, ma vengono raramente prese in considerazione nella progettazione pratica. Il mancato rispetto di queste regole può portare a una progettazione non perfetta del database, ma non dovrebbe influire sulla funzionalità.

Normalizzazione di una tabella di esempio

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

  1. Tabella non normalizzata:

    Student# Advisor Adv-Room Class1 Class2 Class3
    1022 Jones 412 101-07 143-01 159-02
    4123 Smith 216 101-07 143-01 179-04
  2. Prima maschera normale: nessun gruppo ripetuto

    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.

    I fogli di calcolo utilizzano spesso la terza dimensione, ma nel caso delle tabelle non è opportuno. Un'altra prospettiva da cui osservare questo problema è l'utilizzo di una relazione uno-a-molti, senza inserire la parte uno e la parte molti nella stessa tabella. Occorre invece creare un'altra tabella in prima forma normale eliminando il gruppo di ripetizione (Class##), come illustrato in seguito:

    Student# Advisor Adv-Room Class#
    1022 Jones 412 101-07
    1022 Jones 412 143-01
    1022 Jones 412 159-02
    4123 Smith 216 101-07
    4123 Smith 216 143-01
    4123 Smith 216 179-04
  3. Seconda maschera normale: eliminare i dati ridondanti

    Considerare i valori multipli Class# per ogni valore Student# nella tabella precedente. Class# non dipende funzionalmente da Student# (chiave primaria), quindi questa relazione non è in seconda forma normale.

    Le tabelle che seguono illustrano la seconda maschera normale:

    Students:

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

    Registration:

    Student# Class#
    1022 101-07
    1022 143-01
    1022 159-02
    4123 101-07
    4123 143-01
    4123 179-04
  4. Terza maschera normale: eliminare i dati non dipendenti dalla chiave

    Nell'ultimo esempio, Adv-Room (il numero dell'ufficio del tutor) è funzionalmente dipendente dall'attributo Advisor. Per risolvere il problema è possibile spostare tale attributo dalla tabella Students alla tabella Faculty, come illustrato di seguito:

    Students:

    Student# Advisor
    1022 Jones
    4123 Smith

    Faculty:

    Nome Room Rep.
    Jones 412 42
    Smith 216 42