La normalizzazione è una tecnica di progettazione di database, utilizzata per progettare una tabella di database relazionale fino a una forma normale superiore. Il processo è progressivo e non è possibile raggiungere un livello più alto di normalizzazione del database se i livelli precedenti non sono stati soddisfatti.
Ciò significa che, avendo i dati in forma non normalizzata (la meno normalizzata) e mirando a ottenere il massimo livello di normalizzazione, il primo passaggio sarebbe garantire la conformità alla prima forma normale, il secondo passaggio sarebbe garantire che la seconda forma normale sia soddisfatta, e così via nell’ordine sopra indicato, fino a quando i dati non sono conformi alla sesta forma normale. >
Tuttavia, vale la pena notare che le forme normali oltre 4NF sono principalmente di interesse accademico, poiché i problemi che esistono per risolvere appaiono raramente nella pratica.
Si noti che i dati nell’esempio seguente erano progettato intenzionalmente per contraddire la maggior parte delle forme normali. Nella vita reale, è del tutto possibile essere in grado di saltare alcuni passaggi di normalizzazione perché la tabella non contiene nulla che contraddica la forma normale data. Accade anche comunemente che la correzione di una violazione di una forma normale risolva anche una violazione di una forma normale superiore nel processo. Inoltre è stata scelta una tabella per la normalizzazione in ogni fase, il che significa che alla fine di questo processo di esempio, potrebbero esserci ancora alcune tabelle che non soddisfano la forma normale più alta.
Initial dataEdit
Consentire una tabella di database con la seguente struttura:
| Titolo | Autore | Nazionalità dell’autore | Formato | Prezzo | Oggetto | Pagine | Spessore | Editore | Paese editore | Tipo di pubblicazione | ID genere | Nome genere |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Inizio progettazione e ottimizzazione database MySQL | Chad Russell | Americano | Rilegato | 49,99 | MySQL,
Database, Design |
520 | Thick | Apress | USA | E-book | 1 | Tutorial |
In questo esempio assumiamo che ogni libro abbia un solo autore.
Soddisfare 1NFEdit
Per soddisfare 1NF, i valori in ciascuna colonna di una tabella devono essere atomici. Nella tabella iniziale, Oggetto contiene una serie di valori di soggetto, il che significa che non è conforme.
Un modo per ottenere 1NF sarebbe separare le doppiezze in più colonne utilizzando gruppi ripetuti Oggetto:
| Titolo | Formato | Autore | Nazionalità dell’autore | Prezzo | Soggetto 1 | Soggetto 2 | Soggetto 3 | Pagine | Thickness | Publisher | Paese editore | ID genere | Nome genere |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Inizio della progettazione e ottimizzazione del database MySQL | Rilegato | Chad Russell | Americano | 49,99 | MySQL | Database | Design | 520 | Thick | Apress | USA | 1 | Tutorial |
Sebbene ora la tabella sia formalmente conforme all’1NF (è atomica), il problema con questa soluzione è ovvio – se un libro ha più di tre soggetti, non può essere aggiunto al database senza alterarne la struttura.
Per risolvere il problema in modo più elegante, è necessario identificare le entità rappresentate nella tabella e separarle nelle rispettive tabelle. In questo caso, si otterrebbero tabelle Libro, Oggetto ed Editore:
| Titolo | Formato | Autore | Nazionalità dell’autore | Prezzo | Pagine | Thickness | Genre ID | Genre Name | ID editore |
|---|---|---|---|---|---|---|---|---|---|
| Inizio MySQL Progettazione e ottimizzazione del database | Rilegato | Chad Russell | Americano | 49.99 | 520 | Thick | 1 | Tutorial | 1 |
|
|
La semplice separazione dei dati iniziali in più tabelle interromperebbe la connessione tra i dati. Ciò significa che è necessario determinare le relazioni tra le tabelle di nuova introduzione. Tieni presente che la colonna ID editore nella tabella del libro è una chiave esterna che realizza una relazione molti a uno tra un libro e un editore.
Un libro può contenere molti argomenti, così come un soggetto può corrispondono a molti libri. Ciò significa che è necessario definire anche una relazione molti-a-molti, ottenuta creando una tabella dei collegamenti:
|
Invece di una tabella in forma non normalizzata, ora ci sono 4 tabelle conformi a 1NF.
Soddisfacente 2NFEdit
La tabella Book ha una chiave candidata (che è quindi la chiave primaria), la chiave composta {Title, Format}. Considera il seguente frammento di tabella:
| Titolo | Formato | Autore | Nazionalità dell’autore | Prezzo | Pagine | Spessore | ID genere | Nome genere | ID editore |
|---|---|---|---|---|---|---|---|---|---|
| Inizio progettazione e ottimizzazione del database MySQL | Rilegato | Chad Russell | Americano | 49,99 | 520 | Spesso | 1 | Tutorial | 1 |
| Inizio della progettazione e ottimizzazione del database MySQL | E-book | Chad Russell | Americano | 22.34 | 520 | Spesso | 1 | Tutorial | 1 |
| Il modello relazionale per la gestione dei database: versione 2 | E-book | EFCodd | Britannico | 13,88 | 538 | Spesso | 2 | Scienza popolare | 2 |
| Il modello relazionale per database Ma nagement: versione 2 | Paperback | EFCodd | britannico | 39,99 | 538 | Thick | 2 | Scienza popolare | 2 |
Tutti gli attributi che non fanno parte della chiave candidata dipendono dal titolo, ma solo il prezzo dipende anche dal formato. Per essere conforme a 2NF e rimuovere le duplicazioni, ogni attributo non della chiave candidata deve dipendere dall’intera chiave candidata, non solo da una parte di essa.
Per normalizzare questa tabella, imposta {Title} una (semplice) chiave candidata (la chiave primaria) in modo che ogni attributo della chiave non candidata dipenda dall’intera chiave candidata e rimuovi Price in una tabella separata in modo che la sua dipendenza dal formato possa essere preservata:
|
|
Ora, la tabella Book è conforme a 2NF.
Soddisfacente 3NFEdit
La tabella Book ha ancora una dipendenza funzionale transitiva ({Author Nationality} dipende da {Author}, che dipende da {Title }). Una violazione simile esiste per il genere ({Genre Name} dipende da {Genre ID}, che dipende da {Title}). Quindi, la tabella Book non è in 3NF. Per farlo in 3NF, utilizziamo la seguente struttura della tabella, eliminando così le dipendenze funzionali transitive inserendo {Author Nationality} e {Genre Name} nelle rispettive tabelle:
| Titolo | Autore | Pagine | Spessore | ID genere | ID editore |
|---|---|---|---|---|---|
| Inizio progettazione database MySQL e Ottimizzazione | Chad Russell | 520 | Thick | 1 | 1 |
| Il modello relazionale per la gestione dei database: versione 2 | EFCodd | 538 | Thick | 2 | 2 |
|
| Autore | Nazionalità dell’autore |
|---|---|
| Chad Russell | Americano |
| EFCodd | Britannico |
| Gen re ID | Nome genere |
|---|---|
| 1 | Tutorial |
| 2 | Scienza popolare |
EKNFEdit soddisfacente
La forma normale della chiave elementare (EKNF) è strettamente compresa tra 3NF e BCNF e non è molto discussa in letteratura. Ha lo scopo di “catturare le qualità salienti di 3NF e BCNF” evitando i problemi di entrambi (vale a dire, che 3NF è “troppo indulgente” e BCNF è “incline alla complessità computazionale”). Poiché è raramente menzionato in letteratura, non è incluso in questo esempio.
Soddisfare 4NFEdit
Si supponga che il database sia di proprietà di un franchising di un rivenditore di libri che ha diversi affiliati che possiedono negozi in luoghi diversi.Pertanto, il rivenditore ha deciso di aggiungere una tabella che contiene i dati sulla disponibilità dei libri in luoghi diversi:
| ID affiliato | Titolo | Località |
|---|---|---|
| 1 | Inizio della progettazione e ottimizzazione del database MySQL | California |
| 1 | Inizio della progettazione e ottimizzazione del database MySQL | Florida |
| 1 | Inizio della progettazione e ottimizzazione del database MySQL | Texas |
| 1 | Il modello relazionale per la gestione dei database: versione 2 | California |
| 1 | Il modello relazionale per la gestione dei database: versione 2 | Florida |
| 1 | Il modello relazionale per la gestione dei database: versione 2 | Texas |
| 2 | Inizio della progettazione e ottimizzazione del database MySQL | California |
| 2 | Inizio della progettazione e ottimizzazione del database MySQL | Florida |
| 2 | Inizio della progettazione e ottimizzazione del database MySQL | Texas |
| 2 | Il modello relazionale per la gestione del database: versione 2 | California |
| 2 | Il modello relazionale per la gestione dei database: versione 2 | Florida |
| 2 | Il modello relazionale per la gestione dei database: versione 2 | Texas |
| 3 | Inizio della progettazione e ottimizzazione del database MySQL | Texas |
Poiché questa struttura di tabella consiste in una chiave primaria composta, non contiene attributi non chiave ed è già in BCNF (e quindi soddisfa anche tutte le forme normali precedenti). Tuttavia, se assumiamo che tutti i libri disponibili siano offerti in ciascuna area, potremmo notare che il titolo non è vincolato in modo univoco a una determinata posizione e quindi la tabella non soddisfa 4NF.
Ciò significa che, per soddisfare la quarta forma normale, anche questa tabella deve essere scomposta:
|
|
||||||||||||
| ID affiliato | Località | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | California | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | California | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Ora, ogni record è identificato in modo inequivocabile da un superkey, quindi 4NF è soddisfatto.
ETNFEdit soddisfacente
Supponiamo che gli affiliati possano anche ordinare libri da diversi fornitori. Lascia che la relazione sia anche soggetta al seguente vincolo:
- Se un determinato fornitore fornisce un determinato titolo
- e il titolo è fornito all’affiliato
- e l’affiliato viene rifornito dal fornitore,
- quindi il fornitore fornisce il titolo all’affiliato.
| ID fornitore | Titolo | ID affiliato |
|---|---|---|
| 1 | Inizio progettazione e ottimizzazione del database MySQL | 1 |
| 2 | Il modello relazionale per la gestione dei database: versione 2 | 2 |
| 3 | Apprendimento di SQL | 3 |
Questa tabella è in 4NF, ma l’ID fornitore è uguale all’unione delle sue proiezioni: {{ID fornitore, libro}, {libro, ID affiliato}, {ID affiliato, fornitore ID}}.Nessun componente di quella dipendenza dal join è una superchiave (l’unica superchiave è l’intera intestazione), quindi la tabella non soddisfa l’ETNF e può essere ulteriormente scomposta:
|
|
|
La scomposizione produce conformità ETNF.
Soddisfare 5NFEdit
Per individuare una tabella che non soddisfa il 5NF, di solito è necessario esaminare i dati a fondo. Supponiamo che la tabella dell’esempio 4NF con una piccola modifica nei dati ed esaminiamo se soddisfa 5NF:
| ID affiliato | Titolo | Località |
|---|---|---|
| 1 | Inizio della progettazione e ottimizzazione del database MySQL | California |
| 1 | Apprendimento di SQL | California |
| 1 | Il modello relazionale per la gestione dei database: versione 2 | Texas |
| 2 | Il modello relazionale per la gestione dei database: versione 2 | California |
Se scomponiamo questa tabella, riduciamo le ridondanze e otteniamo le seguenti due tabelle:
|
|
Cosa succede se proviamo a unire queste tabelle? La query restituirà i seguenti dati:
| ID affiliato | Titolo | Posizione |
|---|---|---|
| 1 | Inizio della progettazione del database MySQL e Ottimizzazione | California |
| 1 | Apprendimento di SQL | California |
| 1 | Il modello relazionale per la gestione dei database: versione 2 | California |
| 1 | Il modello relazionale per la gestione dei database: versione 2 | Texas |
| 1 | Apprendimento di SQL | Texas |
| 1 | Inizio progettazione e ottimizzazione di database MySQL | Texas |
| 2 | Il modello relazionale per la gestione dei database: versione 2 | California |
Apparentemente, JOIN restituisce tre righe in più di quanto dovrebbe – proviamo ad aggiungere ano la tabella per chiarire la relazione.Finiamo con tre tabelle separate:
|
|
|
Cosa restituirà ora il JOIN? In realtà non è possibile unire questi tre tavoli. Ciò significa che non è stato possibile scomporre il franchisee – Posizione libro senza perdita di dati, quindi la tabella soddisfa già 5NF.
CJ Date ha affermato che solo un database in 5NF è veramente “normalizzato”.
DKNFEdit soddisfacente
Diamo un’occhiata alla tabella Book degli esempi precedenti e vediamo se soddisfa la forma normale della chiave di dominio:
| Titolo | Pagine | Spessore | ID genere | ID editore | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Inizio progettazione e ottimizzazione del database MySQL | 520 | Thick | 1 | 1 | ||||||||||||||||||||||||||
| Il modello relazionale per la gestione dei database: versione 2 | 538 | Thick | 2 | 2 | ||||||||||||||||||||||||||
| Apprendimento di SQL | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| SQL Cookbook | 636 | Spesso | 1 | 3 |
|
|
In questo modo, la violazione dell’integrità del dominio è stata eliminata e la tabella è in DKNF.
Soddisfare 6NFEdit
Una definizione semplice e intuitiva della sesta forma normale è che “una tabella è in 6NF quando la riga contiene la chiave primaria, e al massimo un altro attributo”.
Ciò significa, ad esempio, la tabella Publisher progettata durante la creazione di 1NF
| Publisher_ID | Nome | Paese |
|---|---|---|
| 1 | Apress | USA |
deve essere ulteriore scomposto in due tabelle:
|
|
L’ovvio svantaggio di 6NF è la proliferazione di tabelle necessarie per rappresentare le informazioni su una singola entità. Se una tabella in 5NF ha una colonna chiave primaria e N attributi, la rappresentazione delle stesse informazioni in 6NF richiederà N tabelle; gli aggiornamenti multi-campo a un singolo record concettuale richiederanno aggiornamenti a più tabelle; e gli inserimenti e le eliminazioni richiederanno analogamente operazioni su più tabelle. Per questo motivo, nei database destinati a soddisfare le esigenze di elaborazione delle transazioni online, 6NF non dovrebbe essere utilizzato.
Tuttavia, nei data warehouse, che non consentono aggiornamenti interattivi e che sono specializzati per query veloci su grandi volumi di dati , alcuni DBMS utilizzano una rappresentazione 6NF interna, nota come archivio dati a colonne. In situazioni in cui il numero di valori univoci di una colonna è molto inferiore al numero di righe nella tabella, l’archiviazione orientata alla colonna consente un notevole risparmio di spazio grazie alla compressione dei dati. L’archiviazione a colonne consente anche l’esecuzione rapida di query di intervallo (ad esempio, mostra tutti i record in cui una particolare colonna è compresa tra X e Y, o inferiore a X.)
In tutti questi casi, tuttavia, il progettista del database non lo fa eseguire manualmente la normalizzazione 6NF creando tabelle separate. Alcuni DBMS specializzati per il magazzinaggio, come Sybase IQ, utilizzano l’archiviazione a colonne per impostazione predefinita, ma il progettista vede ancora solo una singola tabella a più colonne. Altri DBMS, come Microsoft SQL Server 2012 e versioni successive, consentono di specificare un “indice columnstore” per una determinata tabella.
