Descrizione dei principi della normalizzazione dei database in Access 2000

Traduzione articoli Traduzione articoli
Identificativo articolo: 209534 - Visualizza i prodotti a cui si riferisce l?articolo.
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.
Per la versione di questo articolo relativa a Microsoft Access 2002, vedere 283878.
Espandi tutto | Chiudi tutto

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
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 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.

ProprietÓ

Identificativo articolo: 209534 - Ultima modifica: lunedý 8 agosto 2005 - Revisione: 2.2
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.

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