Descrizione dei principi relativi alla normalizzazione dei database

Traduzione articoli Traduzione articoli
Identificativo articolo: 283878 - Visualizza i prodotti a cui si riferisce l?articolo.
Questo articolo Ŕ stato precedentemente pubblicato con il codice di riferimento I283878
Utenti inesperti: Ŕ richiesta la conoscenza dell'interfaccia utente dei computer a utente singolo.

Per la versione di questo articolo relativa a Microsoft Access 2000, vedere 209534.
Per la versione di questo articolo relativa a Microsoft Access 95 o Microsoft Access 97, vedere 100139.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

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.

NOTA: Ŕ inoltre disponibile una presentazione tecnica online (WebCast) in cui sono illustrati i principi della normalizzazione dei database. Per visualizzare questa presentazione tecnica online, visitare il seguente sito Web Microsoft (informazioni in lingua inglese):
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1

Informazioni

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 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, ciascuna delle quali viene definita "forma normale". Se si osserva la prima regola, il database viene considerato nella "prima forma normale". Se si osservano le prime tre regole, il database viene considerato nella "terza forma normale". Sebbene siano possibili altri livelli di normalizzazione, la terza forma normale Ŕ considerata il livello massimo necessario per la maggior parte delle applicazioni.

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

Nelle descrizioni che seguono sono inclusi alcuni esempi.

Prima forma 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, Ŕ possibile creare un record di inventario contenente 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 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 forma 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 forma 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˛ essere applicabile a pi¨ record della tabella, provare a 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 di 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 forma 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. Nella 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 forme di normalizzazione

Sono inoltre disponibili una quarta forma normale, denominata Boyce Codd Normal Form (BCNF), e una quinta forma anche se vengono raramente prese in considerazione nella progettazione pratica. Il mancato utilizzo di queste regole pu˛ non consentire una perfetta progettazione 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 Students fittizia.
  1. Tabella non normalizzata:

    Riduci questa tabellaEspandi questa tabella
    Student#AdvisorAdv-RoomClass1Class2Class3
    1022Jones412101-07143-01159-02
    4123Smith216201-01211-02214-01
  2. Prima forma 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.

    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, ma creare un'altra tabella utilizzando la prima forma normale ed eliminando il gruppo ripetuto (Class#), come illustrato di seguito:

    Riduci questa tabellaEspandi questa tabella
    Student#AdvisorAdv-RoomClass#
    1022Jones412101-07
    1022Jones412143-01
    1022Jones412159-02
    4123Smith216201-01
    4123Smith216211-02
    4123Smith216214-01
  3. Seconda forma 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 forma normale.

    Le due tabelle che seguono illustrano la seconda forma normale:

    Students:

    Riduci questa tabellaEspandi questa tabella
    Student#AdvisorAdv-Room
    1022Jones412
    4123Smith216


    Registration:

    Riduci questa tabellaEspandi questa tabella
    Student#Class#
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Terza forma normale: eliminazione di dati non dipendenti da chiave

    Nell'ultimo esempio, Adv-Room (il numero dell'ufficio 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
    1022Jones
    4123Smith


    Faculty:

    Riduci questa tabellaEspandi questa tabella
    NameRoomDept
    Jones41242
    Smith21642

ProprietÓ

Identificativo articolo: 283878 - Ultima modifica: martedý 16 luglio 2013 - Revisione: 6.4
Le informazioni in questo articolo si applicano a:
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Chiavi:á
kbinfo kbdesign kbdatabase kbhowto KB283878
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com