Normalizzazione in SQL: guida completa dalla 1NF alla 5NF

TL;DR

• La normalizzazione organizza le tabelle di un database relazionale per eliminare la ridondanza e proteggere l'integrità dei dati
• 1NF: Ogni cella contiene un singolo valore atomico; ogni riga è identificabile in modo univoco
• 2NF: Rimuovi le dipendenze parziali: le colonne non chiave devono dipendere dall'intera chiave primaria
• 3NF: Rimuovi le dipendenze transitive: le colonne non chiave dipendono solo dalla chiave primaria, non da altre colonne non chiave
• BCNF, 4NF, 5NF: Affrontano dipendenze funzionali, multivalore e di join per schemi complessi
• La maggior parte dei database in produzione richiede la normalizzazione fino alla 3NF; le forme superiori si applicano a casi d'uso specializzati

Che cos'è la normalizzazione in SQL?

La normalizzazione, in questo contesto, è il processo di organizzazione dei dati all'interno di un database (database relazionale) per eliminare anomalie sui dati, come la ridondanza.

In termini più semplici, significa scomporre una tabella grande e complessa in tabelle più piccole e semplici, mantenendo le relazioni tra i dati.

La normalizzazione è comunemente utilizzata quando si lavora con dataset di grandi dimensioni.

Diamo un'occhiata rapida ad alcuni scenari in cui la normalizzazione è spesso utilizzata.

Integrità dei dati

Immagina un database che contiene informazioni sui clienti. Senza normalizzazione, se un cliente cambia età, dovremmo aggiornarla in più punti, aumentando il rischio di incoerenze. Normalizzando i dati, possiamo avere tabelle separate collegate da un identificatore univoco che garantisce che i dati restino accurati e coerenti.

Query efficienti

Consideriamo un database complesso con più tabelle correlate che memorizzano informazioni ridondanti. In questo scenario, le query che coinvolgono i join diventano più complicate e dispendiose in risorse. La normalizzazione aiuta a semplificare le query scomponendo i dati in tabelle più piccole, ognuna contenente solo le informazioni rilevanti, riducendo così la necessità di join complessi.

Ottimizzazione dello storage

Un grande problema dei dati ridondanti è che occupano spazio di archiviazione inutile. Per esempio, se memorizziamo gli stessi dettagli di un prodotto in ogni record d'ordine, si genera duplicazione. Con la normalizzazione, puoi eliminare la ridondanza suddividendo i dati in tabelle separate.

Perché la normalizzazione in SQL è importante?

La normalizzazione svolge un ruolo cruciale nella progettazione dei database. Ecco perché è essenziale:

• Riduce la ridondanza:La ridondanza si verifica quando la stessa informazione è memorizzata più volte, e un buon modo per evitarla è suddividere i dati in tabelle più piccole.
• Migliora le prestazioni delle query: Puoi eseguire query più velocemente su tabelle più piccole che sono state normalizzate.
• Minimizza le anomalie di aggiornamento: Con tabelle normalizzate, puoi aggiornare facilmente i dati senza influenzare altri record.
• Rafforza l'integrità dei dati: Garantisce che i dati rimangano coerenti e accurati.

Cosa rende necessaria la normalizzazione?

Se una tabella non è correttamente normalizzata e presenta ridondanza, non solo occuperà più spazio di archiviazione ma renderà anche difficile gestire e aggiornare il database.

Ci sono diversi fattori che determinano la necessità della normalizzazione, dalla ridondanza dei dati (come visto sopra) alla difficoltà nel gestire le relazioni. Andiamo dritti al punto:

• Anomalie di inserimento, eliminazione e aggiornamento: Qualsiasi tipo di modifica in una tabella può portare a errori o incoerenze in altre tabelle se non gestita con attenzione. Queste modifiche possono consistere nell'aggiunta di nuovi dati, nell'aggiornamento o nell'eliminazione di record, con possibile perdita involontaria di dati.
• Difficoltà nella gestione delle relazioni: Diventa più impegnativo mantenere relazioni complesse in una struttura non normalizzata.
• Altri fattori che determinano la necessità della normalizzazione sono le dipendenze parziali e le dipendenze transitive: le dipendenze parziali possono portare a ridondanza e anomalie di aggiornamento, mentre le dipendenze transitive possono generare anomalie sui dati. Vedremo come gestire queste dipendenze per garantire la normalizzazione nelle prossime sezioni.

Tipi di normalizzazione del database

Finora abbiamo visto cos'è la normalizzazione in SQL, perché è importante e cosa ne causa la necessità. La normalizzazione del database esiste in diverse forme, ciascuna con livelli crescenti di organizzazione dei dati.

In questa sezione, discuteremo brevemente i diversi livelli di normalizzazione e poi li esploreremo più a fondo nella prossima sezione.

Immagine dell'autore

Confronto rapido delle forme normali

Prima forma normale (1NF)

Questo livello di normalizzazione garantisce che ogni colonna dei tuoi dati contenga solo valori atomici. Valori atomici in questo contesto significa che ogni voce in una colonna è indivisibile. È come dire che ogni cella in un foglio di calcolo deve contenere un'unica informazione. La 1NF garantisce l'atomicità dei dati, con ogni cella che contiene un solo valore e ogni colonna con nomi univoci.

Seconda forma normale (2NF)

Elimina le dipendenze parziali assicurando che gli attributi non chiave dipendano solo dalla chiave primaria. In sostanza, significa che deve esserci una relazione diretta tra ogni colonna e la chiave primaria, e non tra altre colonne.

Terza forma normale (3NF)

Rimuove le dipendenze transitive assicurando che gli attributi non chiave dipendano solo dalla chiave primaria. Questo livello di normalizzazione si basa sulla 2NF.

Forma normale di Boyce-Codd (BCNF)

È una versione più rigorosa della 3NF che affronta ulteriori anomalie. A questo livello, ogni determinante è una chiave candidata.

Quarta forma normale (4NF)

È un livello di normalizzazione che si basa sulla BCNF gestendo le dipendenze multivalore.

Quinta forma normale (5NF)

La 5NF è il livello più alto di normalizzazione che affronta le dipendenze di join. Si usa in scenari specifici per ridurre ulteriormente la ridondanza suddividendo una tabella in tabelle più piccole.

Normalizzazione del database con esempi reali

Abbiamo già evidenziato tutti i livelli di normalizzazione dei dati. Esploriamoli ora più a fondo con esempi e spiegazioni.

Normalizzazione in prima forma normale (1NF)

La 1NF assicura che ogni cella contenga solo valori atomici. Immagina un database di una biblioteca con una tabella che memorizza le informazioni sui libri (titolo, autore, genere e borrowed_by). Se la tabella non è normalizzata, borrowed_by potrebbe contenere un elenco di nomi dei prestatori separati da virgole. Questo viola la 1NF, perché una singola cella contiene più valori. La tabella seguente rappresenta bene una violazione della 1NF, come descritto sopra.

La soluzione?

In 1NF, creiamo una tabella separata per i prestatori e li colleghiamo alla tabella dei libri. Queste tabelle possono essere collegate usando la chiave esterna nella tabella dei prestatori o una tabella di collegamento separata. L'approccio con la chiave esterna nella tabella dei prestatori prevede l'aggiunta di una colonna di chiave esterna alla tabella dei prestatori che fa riferimento alla chiave primaria della tabella dei libri. Questo imporrà una relazione tra le tabelle, garantendo la coerenza dei dati.

Ecco una rappresentazione di questo:

Di seguito trovi l'SQL per creare queste tabelle normalizzate:

CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(255),
    author VARCHAR(100),
    genre VARCHAR(50)
);

CREATE TABLE borrowers (
    borrower_id INT PRIMARY KEY,
    name VARCHAR(100),
    book_id INT,
    FOREIGN KEY (book_id) REFERENCES books(book_id)
);

Tabella Books

Tabella Borrowers

Seconda forma normale (2NF)

Questo livello di normalizzazione, come già descritto, si basa sulla 1NF assicurando che non ci siano dipendenze parziali dalla chiave primaria. In termini più semplici, tutti gli attributi non chiave devono dipendere dall'intera chiave primaria e non solo da una parte di essa.

Dalla 1NF implementata, abbiamo già due tabelle separate (puoi controllare la sezione sulla 1NF).

Ora, supponiamo di voler collegare queste tabelle per registrare i prestiti. L'approccio iniziale potrebbe essere semplicemente aggiungere una colonna borrower_id alla tabella dei libri, come mostrato di seguito:

Potrebbe sembrare una soluzione, ma viola la 2NF semplicemente perché borrower_id dipende solo parzialmente da book_id. Un libro può avere più prestatori, ma un singolo borrower_id può essere collegato a un solo libro in questa struttura. Questo crea una dipendenza parziale.

La soluzione?

Dobbiamo ottenere la relazione molti-a-molti tra libri e prestatori per soddisfare la 2NF. Questo si può fare introducendo una tabella separata:

Tabella Book_borrowings

Questa tabella stabilisce una relazione chiara tra libri e prestatori. book_id e borrower_id fungono da chiavi esterne, facendo riferimento alle chiavi primarie nelle rispettive tabelle. Questo approccio garantisce che borrower_id dipenda dall'intera chiave primaria (book_id) della tabella dei libri, rispettando la 2NF.

Terza forma normale (3NF)

La 3NF si basa sulla 2NF eliminando le dipendenze transitive. Una dipendenza transitiva si verifica quando un attributo non chiave dipende da un altro attributo non chiave, che a sua volta dipende dalla chiave primaria. In pratica riprende il significato della legge transitiva.

Dalla 2NF che abbiamo già implementato, nel nostro database della biblioteca ci sono tre tabelle:

Tabella Books

Tabella Borrowers

Tabella Book_borrowings

La struttura in 2NF sembra efficiente, ma potrebbe esserci una dipendenza nascosta. Immaginiamo di aggiungere una colonna due_date alla tabella dei libri. Potrebbe sembrare logico a prima vista, ma creerebbe una dipendenza transitiva in cui:

• La colonna due_date dipende da borrowing_id (un attributo non chiave) della tabella book_borrowings.
• A sua volta borrowing_id dipende da book_id (la chiave primaria) della tabella dei libri.

L'implicazione è che due_date dipende da un attributo non chiave intermedio (borrowing_id) invece di dipendere direttamente dalla chiave primaria (book_id). Questo viola la 3NF.

La soluzione?

Possiamo spostare la colonna due_date nella tabella più appropriata aggiornando la tabella book_borrowings per includere le colonne due_date e returned_date.

Ecco la tabella aggiornata:

Inserendo la colonna due_date nella tabella book_borrowing, abbiamo eliminato con successo la dipendenza transitiva.

In pratica, due_date ora dipende direttamente dalla relazione combinata tra book_id e borrower_id. In questo contesto, book_id e borrower_id agiscono come una chiave esterna composta che, insieme, forma la chiave primaria della tabella book_borrowings.

Forma normale di Boyce-Codd (BCNF)

La BCNF si basa su dipendenze funzionali che considerano tutte le chiavi candidate in una relazione.

Le dipendenze funzionali (FD) definiscono le relazioni tra attributi all'interno di un database relazionale. Una FD afferma che il valore di una colonna determina il valore di un'altra colonna correlata. Le FD sono molto importanti perché guidano il processo di normalizzazione identificando le dipendenze e assicurando che i dati siano distribuiti correttamente tra le tabelle.

La BCNF è una versione più rigorosa della 3NF. Garantisce che ogni determinante (un insieme di attributi che identifica univocamente una riga) in una tabella sia una chiave candidata (un insieme minimo di attributi che identifica univocamente una riga). L'idea di fondo è che tutti i determinanti dovrebbero poter fungere da chiavi primarie.

Garantisce che ogni dipendenza funzionale (FD) abbia come determinante una superchiave. In altre parole, se X —> Y (X determina Y) vale, X deve essere una chiave candidata (superchiave) della relazione. Nota che X e Y sono colonne di una tabella dati.

Come estensione della 3NF, abbiamo tre tabelle:

Tabella Books

Tabella Borrowers

Tabella Book_borrowings

Sebbene la struttura in 3NF sia buona, potrebbe esserci un determinante nascosto nella tabella book_borrowings. Ammesso che un prestatore non possa prendere in prestito lo stesso libro due volte contemporaneamente, la combinazione di book_id e borrower_id identifica univocamente un record di prestito.

Questa struttura viola la BCNF poiché l'insieme combinato (book_id e borrower_id) non è la chiave primaria della tabella (che è solo borrowing_id).

La soluzione?

Per raggiungere la BCNF, possiamo scomporre la tabella book_borrowings in due tabelle separate oppure rendere l'insieme di attributi combinato la chiave primaria.

1. Approccio 1 (scomporre la tabella): In questo approccio, scomporremo la tabella book_borrowings in tabelle separate:

• • Una tabella con borrowing_id come chiave primaria, borrowed_date, due_date e returned_date.
  • Un'altra tabella separata per collegare libri e prestatori, con book_id come chiave esterna, borrower_id come chiave esterna e, potenzialmente, ulteriori attributi specifici dell'evento di prestito.

2. Approccio 2 (rendere la combinazione la chiave primaria): Possiamo considerare di rendere book_id e borrower_id una chiave primaria composta per identificare univocamente i record di prestito. Il problema di questo approccio è che non funziona se un prestatore può prendere lo stesso libro più volte.

Alla fine, la scelta tra queste opzioni dipende dalle tue esigenze specifiche e da come vuoi modellare le relazioni di prestito.

Quarta forma normale (4NF)

La 4NF gestisce le dipendenze multivalore. Una dipendenza multivalore esiste quando un attributo può avere più attributi dipendenti, e questi attributi dipendenti sono indipendenti dalla chiave primaria. È piuttosto complesso, ma lo esploreremo più a fondo con un esempio.

L'esempio della biblioteca usato finora non è applicabile a questo livello di normalizzazione. La 4NF si applica tipicamente a situazioni in cui un singolo attributo può avere più attributi dipendenti che non sono direttamente collegati alla chiave primaria.

Usiamo un altro scenario. Immagina un database che memorizza informazioni sulle pubblicazioni. Considereremo una tabella “Publications” con colonne title, author, publication_year e keywords.

La struttura della tabella sopra viola la 4NF perché:

• La colonna keywords ha una dipendenza multivalore dalla chiave primaria publication_id. Significa che una pubblicazione può avere più parole chiave e queste parole chiave sono indipendenti dall'identificatore univoco della pubblicazione.

La soluzione?

Possiamo creare una tabella separata.

Tabella Publication_keywords

La nuova tabella (Publication_keywords) stabilisce una relazione molti-a-molti tra pubblicazioni e parole chiave. Ogni pubblicazione può avere più parole chiave collegate tramite publication_id, che è una chiave esterna, e ogni parola chiave può essere associata a più pubblicazioni.

In questo modo, abbiamo eliminato con successo la dipendenza multivalore e raggiunto la 4NF.

Quinta forma normale (5NF)

La 5NF è la forma più complessa di normalizzazione che elimina le dipendenze di join. È una situazione in cui i dati devono essere uniti da più tabelle per rispondere a una query specifica, anche quando tali tabelle sono già in 4NF.

In termini più semplici, la 5NF garantisce che non si possa derivare alcuna informazione aggiuntiva unendo le tabelle che non fosse già disponibile nelle tabelle separate.

Le dipendenze di join sono meno probabili quando le tabelle sono già normalizzate (in 3NF o 4NF), da cui la difficoltà nel creare un esempio chiaro e lineare per la 5NF.

Tuttavia, vediamo uno scenario in cui la 5NF potrebbe essere rilevante:

Immagina un database universitario con tabelle normalizzate per “Courses” e “Enrollments”.

Tabella Courses

Tabella Enrollments

Supponendo che queste tabelle siano già in 3NF o 4NF, potrebbe esistere una dipendenza di join a seconda di come sono memorizzati i dati. Per esempio, un corso ha un prerequisito memorizzato nella tabella “Courses” come colonna “prerequisite_course_id”.

Potrebbe sembrare efficiente a prima vista. Tuttavia, considera una query che deve recuperare i corsi a cui è iscritto uno studente e i relativi prerequisiti. In questo scenario, dovresti unire le tabelle “Courses” e “Enrollments”, quindi potenzialmente unire nuovamente la tabella “Courses” per recuperare le informazioni sui prerequisiti.

La soluzione?

Per eliminare potenzialmente la dipendenza di join e raggiungere la 5NF, potremmo introdurre una tabella separata “Course Prerequisites”:

Tabella Course_prerequisite

Questo approccio separa le informazioni sui prerequisiti e consente di recuperare in modo efficiente i corsi a cui si è iscritti e i relativi prerequisiti con un unico join tra le tabelle “Enrollments” e “Course_prerequisites”.

Nota: Supponiamo che uno studente possa avere un solo prerequisito per corso.

La 5NF è una forma di normalizzazione molto complessa e rara, quindi, se stai iniziando ora il tuo percorso nei dati, potresti non trovarne subito applicazione. Tuttavia, è una conoscenza in più che ti preparerà quando incontrerai database complessi.

Normalizzazione vs. denormalizzazione

Sebbene la normalizzazione riduca la ridondanza e migliori l'integrità dei dati, ci sono casi in cui la denormalizzazione è la scelta migliore. La denormalizzazione introduce intenzionalmente ridondanza per migliorare le prestazioni di lettura per carichi specifici.

In pratica, la maggior parte dei database in produzione usa una combinazione di entrambi gli approcci. Parti da uno schema completamente normalizzato, poi denormalizza selettivamente le tabelle dove le prestazioni delle query lo richiedono.

Migliora le tue competenze SQL

Se stai leggendo questo, congratulazioni per essere arrivato fino in fondo. È stato un bel viaggio esplorare cos'è la normalizzazione in SQL, perché è importante, cosa ne causa la necessità e i diversi tipi di normalizzazione del database. Gli scenari usati per spiegare i vari tipi di normalizzazione sono pensati per aiutarti a comprendere a fondo e ad applicare queste conoscenze nel tuo percorso di apprendimento.

La normalizzazione è una competenza fondamentale per chiunque inizi una carriera legata ai dati. Capendo questi principi, sei pronto a creare database efficienti e ben organizzati.

Imparare è fondamentale nel mondo dei dati e, per migliorare le tue competenze SQL, abbiamo alcune risorse per te.

• Corso Creating PostgreSQL Databases
• Normalization in DBMS: A Complete Guide with SQL Examples
• Data Modeling Explained: Techniques, Examples, and Best Practices
• SQL Query Examples and Tutorial
• Denormalization in Databases: When and How to Use It