Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo illustra la terminologia della normalizzazione del database per principianti. Una conoscenza di base di questa terminologia è utile quando si discute della progettazione di un database relazionale.
Descrizione della normalizzazione
La normalizzazione è il processo di organizzazione dei dati in un database. Include la creazione di tabelle e la definizione di relazioni tra tali tabelle in base alle regole progettate sia per proteggere i dati che per rendere il database più flessibile eliminando la ridondanza e la dipendenza incoerente.
I dati ridondanti sprecano spazio su disco e creano problemi di manutenzione. Se i dati presenti in più posizioni devono essere modificati, i dati devono essere modificati esattamente nello stesso modo in tutte le posizioni. Una modifica dell'indirizzo del cliente è più semplice da implementare se tali dati vengono archiviati solo nella tabella Customers e in nessun altro punto del database.
Che cos'è una "dipendenza incoerente"? Anche se è intuitivo che un utente guardi nella tabella Clienti per l'indirizzo di un determinato cliente, potrebbe non avere senso cercare lo stipendio del dipendente che chiama il cliente. Lo stipendio del dipendente è correlato o dipendente dal dipendente e deve quindi essere spostato nella tabella Dipendenti. Le dipendenze incoerenti possono rendere difficile l'accesso ai dati perché il percorso per trovare i dati potrebbe essere mancante o interrotto.
Esistono alcune regole per la normalizzazione del database. Ogni regola è denominata "forma normale". Se viene osservata la prima regola, si dice che il database sia in "primo formato normale". Se vengono osservate le prime tre regole, il database viene considerato in "terza forma normale". Anche se sono possibili altri livelli di normalizzazione, la terza forma normale è considerata il livello più elevato necessario per la maggior parte delle applicazioni.
Come per molte regole e specifiche formali, gli scenari reali non sempre consentono una conformità perfetta. In generale, la normalizzazione richiede tabelle aggiuntive e alcuni clienti trovano questo complesso. Se si decide di violare una delle prime tre regole di normalizzazione, assicurarsi che l'applicazione prevedi eventuali problemi che potrebbero verificarsi, ad esempio dati ridondanti e dipendenze incoerenti.
Le descrizioni seguenti includono esempi.
Prima forma normale
- Eliminare i gruppi ripetuti in singole tabelle.
- Creare una tabella separata per ogni set di dati correlati.
- Identificare ogni set di dati correlati con una chiave primaria.
Non usare più campi in una singola tabella per archiviare dati simili. Ad esempio, per tenere traccia di un articolo di inventario che può provenire da due possibili origini, un record di inventario può contenere campi per codice fornitore 1 e codice fornitore 2.
Cosa accade quando si aggiunge un terzo fornitore? L'aggiunta di un campo non è la risposta; richiede modifiche di programma e tabella e non supporta senza problemi un numero dinamico di fornitori. Inserire invece tutte le informazioni del fornitore in una tabella separata denominata Fornitori, quindi collegare l'inventario ai fornitori con una chiave numerica dell'articolo o i fornitori all'inventario con una chiave di codice fornitore.
Seconda forma normale
- Creare tabelle separate per set di valori applicabili a più record.
- Correla queste tabelle con una chiave esterna.
I record non dovrebbero dipendere da nient'altro oltre alla chiave primaria di una tabella (una chiave composta, se necessario). Si consideri, ad esempio, l'indirizzo di un cliente in un sistema di contabilità. L'indirizzo è necessario per la tabella Customers, ma anche per le tabelle Orders, Shipping, Invoices, Accounts Receivable e Collections. Anziché archiviare l'indirizzo del cliente come voce separata in ognuna di queste tabelle, archiviarlo in un'unica posizione, nella tabella Customers o in una tabella Addresses separata.
Terza forma normale
- Eliminare i campi che non dipendono dalla chiave.
I valori di un record che non fanno parte della chiave del record non appartengono alla tabella. In generale, ogni volta che il contenuto di un gruppo di campi può essere applicato a più di un singolo record nella tabella, è consigliabile inserire tali campi in una tabella separata.
Ad esempio, in una tabella Employee Recruiting è possibile includere il nome e l'indirizzo dell'università di un candidato. Ma hai bisogno di un elenco completo di università per le mailing di gruppo. Se le informazioni sull'università vengono archiviate nella tabella Candidati, non c'è modo di elencare le università senza candidati attuali. Creare una tabella Università separata e collegarla alla tabella Candidati con una chiave del codice universitario.
ECCEZIONE: l'adesione alla terza forma normale, mentre teoricamente auspicabile, non è sempre pratica. Se si dispone di una tabella Customers e si desidera eliminare tutte le possibili dipendenze tra campi, è necessario creare tabelle separate per città, codici POSTALI, rappresentanti di vendita, classi di clienti e qualsiasi altro fattore che può essere duplicato in più record. In teoria, la normalizzazione vale la pena perseguire. Tuttavia, molte tabelle di piccole dimensioni possono ridurre le prestazioni o superare le capacità di memoria e file aperti.
Potrebbe essere più fattibile applicare la terza forma normale solo ai dati che cambiano frequentemente. Se alcuni campi dipendenti rimangono, progettare l'applicazione per richiedere all'utente di verificare tutti i campi correlati quando ne viene modificata una.
Altre forme di normalizzazione
La quarta forma normale, chiamata anche Boyce-Codd Forma normale (NORMALEF) e la quinta forma normale esistono, ma sono raramente considerate in progettazione pratica. L'ignorare queste regole può comportare una progettazione di database inferiore a quella perfetta, ma non dovrebbe influire sulle funzionalità.
Normalizzazione di una tabella di esempio
Questi passaggi illustrano il processo di normalizzazione di una tabella degli studenti fittizi.
Tabella nonmalizzata:
Studente# Consulente Adv-Room Classe1 Classe2 Classe3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04 Prima forma normale: nessun gruppo ripetuto
Le tabelle devono avere solo due dimensioni. Poiché uno studente ha diverse classi, queste classi devono essere elencate in una tabella separata. I campi Class1, Class2 e Class3 nei record precedenti indicano problemi di progettazione.
I fogli di calcolo usano spesso la terza dimensione, ma le tabelle non dovrebbero. Un altro modo per esaminare questo problema è con una relazione uno-a-molti, evitando di mettere il lato singolo e i lati multipli nella stessa tabella. Creare invece un'altra tabella nella prima forma normale eliminando il gruppo ripetuto (Class#), come illustrato nell'esempio seguente:
Studente# Consulente Adv-Room Classe# 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 Seconda forma normale: Eliminare i dati ridondanti
Si notino i valori Class# multipli per ogni valore Student# nella tabella precedente. Class# non dipende dal punto di vista funzionale da Student# (chiave primaria), quindi questa relazione non è in seconda forma normale.
Le tabelle seguenti illustrano la seconda forma normale:
Studenti:
Studente# Consulente Adv-Room 1022 Jones 412 4123 Smith 216 Registrazione:
Studente# Classe# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Terza forma normale: Eliminare i dati non dipendenti dalla chiave
Nell'ultimo esempio, Adv-Room (numero di ufficio del consulente) è funzionalmente dipendente dall'attributo Advisor. La soluzione consiste nello spostare l'attributo dalla tabella Students alla tabella Faculty, come illustrato di seguito:
Studenti:
Studente# Consulente 1022 Jones 4123 Smith Facoltà:
Nome Stanza Dipartimento Jones 412 42 Smith 216 42