DetailPage-MSS-KB

Microsoft Knowledge Base

Identificativo articolo: 209534 - Ultima modifica: lunedì 8 agosto 2005 - Revisione: 2.2

Questo articolo è stato precedentemente pubblicato con il codice di riferimento I209534
Utenti inesperti: è richiesta la conoscenza dell'interfaccia utente dei computer a utente singolo.

Per la versione di questo articolo relativa a Microsoft Access 97, vedere 100139  (http://support.microsoft.com/kb/100139/ ) .
Per la versione di questo articolo relativa a Microsoft Access 2002, vedere 283878  (http://support.microsoft.com/kb/283878/ ) .

In questa pagina

Sommario

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):
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1 (http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fservicedesks%2fwebcasts%2fwc060600%2fwc060600.asp%3ffr%3d1)
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:
100139  (http://support.microsoft.com/kb/100139/ ) ACC: Informazioni 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 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#AdvisorAdv-RoomClass1Class2Class3
    1022Jones412101-07143-01159-02
    4123Smith216201-01211-02214-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#AdvisorAdv-RoomClass#
    1022Jones412101-07
    1022Jones412143-01
    1022Jones412159-02
    4123Smith216201-01
    4123Smith216211-02
    4123Smith216214-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#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 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
    1022Jones
    4123Smith

    Faculty

    Riduci questa tabellaEspandi questa tabella
    NameRoomDept
    Jones41242
    Smith21642

Riferimenti

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.

Le informazioni in questo articolo si applicano a
  • Microsoft Access 2000 Standard Edition
Chiavi: 
kbdatabase kbdesign kbinfo kbusage KB209534
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.
Condividi
Altre opzioni per il supporto
Forum del supporto di Microsoft Community
Contattaci direttamente
Ricerca di un partner certificato Microsoft
Microsoft Store