Cos'è la normalizzazione del database?

La normalizzazione del database è un processo di progettazione del database che organizza i dati in strutture di tabelle specifiche. Aiuta a migliorare l'integrità dei dati, prevenire le anomalie dei dati, ridurre al minimo la ridondanza dei dati e migliorare le prestazioni delle query.

La normalizzazione ottimizza le tabelle nei sistemi di gestione dei database (DBMS) per soddisfare le cosiddette forme normali: insiemi di regole che regolano l'organizzazione degli attributi all'interno di una tabella. Queste regole si basano in gran parte sulle relazioni tra gli attributi (colonne), comprese le chiavi utilizzate per identificare in modo univoco le righe.

Di fatto, la normalizzazione dei database, talvolta chiamata normalizzazione dei dati, aiuta le aziende e le istituzioni a organizzare, interrogare e mantenere in modo più efficace grandi volumi di dati complessi, correlati e dinamici. Sebbene le aziende generino e memorizzino i dati su una scala senza precedenti, la necessità di normalizzare i database non è nuova. È anteriore al cloud storage e persino all'invenzione dei data warehouse.

Dagli anni '60, le aziende hanno difficoltà a gestire set di dati di grandi dimensioni. Negli anni '70, Edgar F. Codd, il matematico IBM noto per il suo storico articolo sull'introduzione dei database relazionali, propose che la normalizzazione dei database potesse evitare dipendenze "indesiderate" tra gli attributi (colonne) e i problemi che possono creare.

In altre parole, quando i record di dati sono correlati tra di loro in una struttura di database, le modifiche a singoli valori o righe in una tabella grande e complicata potrebbero produrre conseguenze indesiderate, come incoerenza e perdita di dati. La normalizzazione del database è progettata per ridurre al minimo tali rischi.

I benefici della normalizzazione del database includono:

La normalizzazione delle strutture di dati può prevenire tre tipi principali di anomalie:

Anomalie di inserimento: un'anomalia di inserimento si verifica quando un record di dati non può essere inserito in una tabella perché mancano i valori richiesti da una o più colonne della tabella.

Anomalie di cancellazione: un'anomalia di cancellazione si verifica quando la cancellazione di un record provoca la cancellazione involontaria di dati importanti inclusi in quel record.

Anomalie di aggiornamento: un'anomalia di aggiornamento si verifica quando un'istanza di dati viene aggiornata in una posizione del database ma non in altre posizioni in cui quel valore dei dati è memorizzato, con conseguente mancanza di coerenza dei dati.

Nei database relazionali, una chiave è una colonna o un insieme ordinato di colonne utili per identificare le righe di dati in una tabella. Le chiavi nei modelli relazionali stabiliscono anche associazioni tra tabelle correlate. Queste funzionalità supportano query di SQL Database efficienti ed efficaci. Le chiavi che rivestono un ruolo importante nelle regole di normalizzazione dei database includono:

• Chiavi primarie
• Chiavi composite
• Chiavi candidate
• Chiavi esterne
• Super chiavi

Una chiave primaria è costituita da una o più colonne in una tabella di database con valori che fungono da identificatori univoci per ogni riga o record. Ad esempio, una colonna ID studente potrebbe essere una chiave primaria in una tabella di informazioni sugli studenti. Le chiavi primarie si distinguono principalmente per il fatto di escludere i valori Null, non avere valori duplicati ed essere costituite da una o più colonne.

Le chiavi costituite da due o più colonne sono denominate chiavi composite. Quando le chiavi primarie sono chiavi composite, possono essere chiamate chiavi primarie composite.

Una chiave candidata è una colonna o un gruppo di colonne che ha le caratteristiche di una chiave primaria ma a cui non è stato assegnato lo stato di chiave primaria.

Una chiave esterna in una tabella si riferisce a una chiave primaria specifica in un'altra tabella per definire una relazione tra le tabelle. Quando le tabelle più grandi vengono suddivise in tabelle più piccole durante la normalizzazione, le chiavi esterne e le chiavi primarie stabiliscono un'associazione tra le nuove tabelle.

Le super chiavi, pur essendo simili alle chiavi primarie composite, sono costituite da un numero di colonne superiore a quello necessario per identificare in modo univoco i record.

Diversi vincoli di normalizzazione del database si basano sulle relazioni (note anche come dipendenze) tra le chiavi primarie e le colonne che non sono né chiavi primarie né chiavi candidate. Questi ultimi sono noti come attributi non-chiave o attributi non-primi.

Le relazioni tra gli attributi nei database in cui un attributo (il determinante) determina il valore di un altro attributo sono note come dipendenze funzionali. I tipi di dipendenze funzionali tra gli attributi includono la dipendenza parziale, la dipendenza transitiva, la dipendenza multivalore e la dipendenza join. Queste relazioni sono meglio comprese se discusse nel contesto di insiemi pertinenti di regole di normalizzazione, o forme normali.

L'esecuzione della normalizzazione nei modelli di dati comporta la progettazione di tabelle conformi a uno o più livelli di normalizzazione, noti anche come forme normali. Le forme più comuni includono:

• Prima forma normale
• Seconda forma normale
• Terza forma normale e forma normale di Boyce-Codd
• Quarta forma normale
• Quinta forma normale

La prima forma normale, ovvero il criterio di normalizzazione del database più elementare, richiede che lo schema di una tabella di database includa una chiave primaria escludendo la ripetizione tra le colonne. Per essere più precisi, una tabella in prima forma normale non dovrebbe contenere campi con matrici di valori, ad esempio una singola cella con tre nomi diversi, né dovrebbe includere gruppi ripetuti, che sono colonne diverse che memorizzano lo stesso tipo di dati.

Per comprendere meglio la prima forma normale, utilizziamo come esempio il seguente set di colonne:¹

Le colonne comprendono una tabella di un gruppo di genitori, inclusi i loro nomi, date di nascita, anniversari di matrimonio, indirizzi e-mail e nomi dei figli.

Questa tabella è in violazione del primo modulo normale perché contiene tre colonne separate che memorizzano lo stesso tipo di informazioni, ovvero i nomi dei bambini. In questo caso specifico, la struttura della tabella potrebbe causare errori di inserimento. Ad esempio, nel mondo reale, molti genitori hanno meno di tre figli.

Nella nostra tabella di esempio, non è possibile aggiungere i record di tali genitori alla tabella. Inoltre, l'esecuzione di query su questa tabella per il nome di un bambino sarebbe inefficiente e richiederebbe la ricerca di dati in tre colonne diverse in ogni riga.

Per ottenere la prima forma normale per i dati nella tabella è necessario separare la tabella originale in due. Una tabella includerebbe la maggior parte degli attributi della tabella originale, mentre l'altra si concentrerebbe sui figli.

TABELLA 1

TABELLA 2

rec_num         child_name

In questo esempio, le nuove tabelle rimangono collegate tramite la colonna "rec_num", che è la chiave primaria nella Tabella 1 e fa riferimento alla colonna "rec_num" della Tabella 2, che funge da chiave esterna.

Anche se soddisfare il primo modulo normale potrebbe non ridurre i dati ridondanti (i valori "rec_num" appariranno in più righe della Tabella 2 quando i genitori hanno più di un figlio), l'eliminazione dei gruppi ripetuti può semplificare le query.

In seconda forma normale, nessun attributo non chiave ha una dipendenza parziale dalla chiave primaria nella tabella. In altre parole, se una chiave primaria è una chiave composita, l'attributo non chiave deve dipendere da ogni colonna in tale chiave composita.

Consideriamo per esempio una tabella di inventario che contiene record sulle quantità di articoli specifici conservati presso determinati magazzini. La seguente figura mostra gli attributi dell'entità di inventario.²

In questo esempio, le colonne "articolo" e "magazzino" formano una chiave primaria composita. Tuttavia, l'attributo "indirizzo_magazzino" dipende solo dal valore di "magazzino", quindi la tabella è in violazione della seconda forma normale.

Questa tabella è inoltre soggetta a ridondanza dei dati, poiché il valore di indirizzo_magazzino è elencato ogni volta che nella tabella appare un record per una parte dello stesso magazzino. Ciò aumenta il rischio di errori di aggiornamento nel caso in cui l'indirizzo venga aggiornato in una riga e non in altre. Un errore di cancellazione può verificarsi anche se un magazzino smette di memorizzare le parti: se i record di tali parti venissero eliminati, verrebbe eliminato anche l'indirizzo del magazzino.

Per soddisfare la seconda forma normale e ridurre la probabilità di errori, i dati possono essere distribuiti tra due nuove tabelle:

TABELLA 1

TABELLA 2

magazzino                                indirizzo_magazzino

Una tabella in terza forma normale soddisfa sia la prima che la seconda forma normale, evitando anche situazioni in cui gli attributi non chiave dipendono da altri attributi non chiave anziché da chiavi primarie. Quando gli attributi non chiave dipendono da altri attributi non chiave, si parla di dipendenza transitiva, una violazione della terza forma normale.

Consideriamo la seguente tabella di informazioni sui dipendenti:³

In questa tabella, la chiave primaria è la colonna “emp_num”. Tuttavia, la colonna “dept_name” dipende dalla colonna “dept_num”, un attributo non chiave. Pertanto, la tabella non soddisfa la terza forma normale e aumenta il rischio di errori come anomalie di aggiornamento: se il nome di un reparto, ad esempio "sistema di produzione", è cambiato, dovrebbe essere aggiornato in più di una riga nello schema della tabella corrente.

L'organizzazione dei dati in una terza forma normale in un database normalizzato potrebbe prevenire tali errori. In questo caso, questo processo comporterebbe la strutturazione dei dati in tre tabelle separate: EMPLOYEE, DEPARTMENT ed EMPLOYEE_DEPARTMENT ⁴

Tabella EMPLOYEE

Tabella DEPARTMENT

Tabella EMPLOYEE_DEPARTMENT

La forma normale di Boyce-Codd, o BCNF, è una forma normale considerata una versione più rigida o più forte della terza forma normale. BCNF richiede l'uso di super chiavi.

Una tabella è in quarta forma normale se non ha dipendenze multivalore. Le dipendenze multivalore si verificano quando i valori di due o più colonne sono indipendenti l'uno dall'altro e dipendono solo dalla chiave primaria.

Un esempio spesso citato nei tutorial riguarda le tabelle dei dipendenti che elencano sia le competenze che le lingue. Un dipendente può avere diverse competenze e parlare più lingue. Esistono due relazioni: una tra dipendenti e competenze e una tra dipendenti e lingue.

Una tabella non è in quarta forma normale se rappresenta entrambe le relazioni. Per convertire i dati nella quarta forma normale, sarebbe necessario strutturarli in due tabelle: una per le competenze dei dipendenti e una per le lingue.

Comunemente considerata il più alto livello di normalizzazione, la quinta forma normale è un criterio basato sulla dipendenza di join. Nella dipendenza di join, dopo che una tabella è stata divisa in tabelle più piccole, è possibile ricostituire la tabella originale riunendo nuovamente le nuove tabelle, il tutto senza perdere dati né creare accidentalmente nuove righe di dati. È paragonabile a un puzzle completato che, una volta scomposto, può essere ricomposto nella sua forma originale.

Nella quinta forma normale, una tabella dovrebbe essere divisa in tabelle più piccole solo quando è possibile realizzare una dipendenza di join. Se, tuttavia, i tentativi di ricostituire la tabella originale da tabelle più piccole portano involontariamente alla creazione di una tabella leggermente diversa, allora la scomposizione della tabella originale non dovrebbe aver luogo. Tornando all'analogia con il puzzle, sarebbe come rimettere insieme un puzzle, solo per scoprire che manca un pezzo o che si è materializzato un pezzo in più.

Nonostante tutti i suoi benefici, la normalizzazione del database comporta dei compromessi. Ad esempio, prima della normalizzazione, un utente che cercava dati specifici poteva dover interrogare solo una tabella. Tuttavia, se un database dispone di più tabelle dopo una normalizzazione, l'utente potrebbe trovarsi a dover eseguire query su più tabelle, il che può essere un processo più lento e costoso.

Inoltre, anche se la normalizzazione semplifica le singole tabelle, può aumentare la complessità del database in generale, richiedendo una notevole esperienza da parte dei progettisti e degli amministratori di database per garantire una corretta implementazione.