ACC: Informazioni di base sulla normalizzazione dei database

Traduzione articoli Traduzione articoli
Identificativo articolo: 100139 - Visualizza i prodotti a cui si riferisce l?articolo.
Questo articolo Ŕ stato precedentemente pubblicato con il codice di riferimento I100139
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

Utenti inesperti: Ŕ richiesta la conoscenza dell'interfaccia utente dei computer a utente singolo.

In questo articolo sono riportate informazioni di base sulla terminologia correlata alla normalizzazione dei database. Queste informazioni possono rivelarsi utili per la definizione della struttura di un database relazionale.

NOTA: Ŕ inoltre disponibile una WebCast in cui sono illustrati i principi della normalizzazione dei database. Per visualizzare questa WebCast, visitare il seguente sito Web di Microsoft:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1 (informazioni in lingua inglese)
NOTA: per visualizzare queste informazioni per Microsoft Access 2000, vedere il seguente articolo della Knowledge Base (informazioni in lingua inglese):
209534ACCESS 2000: Concetti di base sulla normalizzazione dei database

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 queste tabelle sulla base di regole progettate in modo da proteggere i dati e rendere il database pi¨ flessibile tramite l'eliminazione di due fattori, ovvero la ridondanza e la dipendenza incoerente.

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 associato a tale 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 "forma normale". Se si osserva la prima regola, il database sarÓ nella "prima forma normale". Se si osservano le prime tre regole, il database sarÓ 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 garantisce 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.

NOTA: nelle descrizioni che seguono sono inclusi degli esempi.

Prima forma normale

  • Eliminare i gruppi ripetitivi in singole tabelle.
  • Creare una tabella diversa per ciascun set 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 forma normale

  • Creare tabelle diverse per set di valori validi per pi¨ record.
  • Correlare queste tabelle a una chiave esterna.
I record devono dipendere solo sulla 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 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˛ 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 i mailing di gruppo Ŕ 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 a quella Candidati utilizzando una chiave basata sul codice universitÓ.

ECCEZIONE: l'adozione della terza forma 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. In teoria, la normalizzazione rappresenta un metodo valido, tuttavia un numero elevato di tabelle di dimensioni ridotte pu˛ influire negativamente sulle prestazioni oppure superare i limiti relativi al numero di file aperti e alla memoria.

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

Sono inoltre disponibili una quarta forma normale, denominata Boyce Codd Normal Form (BCNF) e una quinta forma, 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Ó.
               **********************************
                 Esempi di tabelle normalizzate
               **********************************

 Esempi di normalizzazione:

 Tabella non normalizzata:

    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
 
  1. Prima forma normale: GRUPPI NON RIPETITIVI

    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. ╚ anche possibile esaminare questo problema da un altro punto di vista. Nel caso di una relazione uno a molti non inserire la parte uno e la parte molti nella stessa tabella. Creare invece un'altra tabella utilizzando la prima forma normale ed eliminando il gruppo ripetitivo (Class#), come illustrato di seguito:
           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
     
  2. Seconda forma normale: ELIMINARE I 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:   Student#    Advisor   Adv-Room
                    ------------------------------
                    1022        Jones       412
                    4123        Smith       216
    
        Registration:   Student#    Class#
                        ------------------
                        1022        101-07
                        1022        143-01
                        1022        159-02
                        4123        201-01
                        4123        211-02
                        4123        214-01
     
  3. Terza forma normale: ELIMINARE I DATI NON DIPENDENTI DALLA 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:   Student#    Advisor
                    -------------------
                    1022        Jones
                    4123        Smith
    
        Faculty:    Name    Room    Dept
                    --------------------
                    Jones   412     42
                    Smith   216     42
     

Riferimenti

Per ulteriori informazioni sulla definizione di un database, fare clic sul numero dell'articolo della Knowledge Base riportato di seguito (informazioni in lingua inglese):
234208ACCESS 2000: Documento "Understanding Relational Database Design" disponibile per il download dall'Area download Microsoft
"FoxPro 2 A Developer's Guide", Hamilton M. Ahlo Jr. e al., pagine 220-225, M & T Books, 1991

"Using Access for Windows", Roger Jennings, pagine 799-800, Que Corporation, 1993

ProprietÓ

Identificativo articolo: 100139 - Ultima modifica: mercoledý 11 febbraio 2004 - Revisione: 1.1
Le informazioni in questo articolo si applicano a:
  • Microsoft Access versioni 1.0, 1.1, 2.0, 7.0, 97
Chiavi:á
kbusage tblothr KB100139
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.
Dichiarazione di non responsabilitÓ per articoli della Microsoft Knowledge Base su prodotti non pi¨ supportati
Questo articolo Ŕ stato scritto sui prodotti per cui Microsoft non offre pi¨ supporto. L?articolo, quindi, viene offerto ?cosý come Ŕ? e non verrÓ pi¨ aggiornato.

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