Programma
Immagina di lavorare con un enorme database non strutturato, pieno di informazioni ripetute e ridondanti. Ogni aggiornamento o eliminazione diventa un potenziale disastro, con il rischio di errori e inconsistenze. La terza forma normale (3NF) è un metodo comprovato di normalizzazione dei database per evitare questo caos. Implementare la 3NF ripulisce la struttura dei dati, rendendola efficiente, organizzata e priva di ridondanze inutili.
In questo articolo vedremo come funziona la 3NF, perché è utile e come metterla in pratica. Confronteremo anche la 3NF con altre forme e capiremo quando usare ciascuna di esse. Tutti possono trarre vantaggio dall'approfondire queste strutture, ma questa conoscenza è particolarmente preziosa se sei un progettista di database o un data scientist, perché può semplificare notevolmente il tuo lavoro e mantenere affidabili i tuoi database. Se ti interessa il design dei database in generale, dai un'occhiata al nostro corso completo Database Design.
Definizione della Terza Forma Normale (3NF)
La terza forma normale è un concetto chiave della normalizzazione dei database che rimuove le dipendenze indesiderate. La 3NF si basa sulla prima forma normale (1NF) e sulla seconda forma normale (2NF), ereditandone quindi le regole: la 1NF richiede valori atomici (indivisibili) in ogni cella, e la 2NF elimina le dipendenze parziali da una chiave primaria composta. La 3NF fa un passo oltre rimuovendo le dipendenze transitive, una situazione in cui attributi non chiave dipendono indirettamente dalla chiave primaria.
Concentrandosi su questo, la 3NF garantisce che ogni colonna non chiave in una tabella sia direttamente legata alla chiave primaria e a nient'altro. In termini pratici, la 3NF aiuta a ridurre al minimo la ridondanza ed evitare anomalie durante l'inserimento, l'aggiornamento o l'eliminazione dei dati.
Negli anni '70, Edgar F. Codd introdusse la 3NF per formalizzare le condizioni necessarie a ottenere una struttura di database completamente normalizzata. Una riformulazione di Carlo Zaniolo qualche anno dopo fornì una spiegazione più chiara della differenza tra la 3NF “classica” e la più restrittiva Boyce-Codd Normal Form (BCNF). Non preoccuparti troppo della BCNF per ora, ci torneremo più avanti.
Capire le condizioni per la Terza Forma Normale
Quindi, cosa serve esattamente per raggiungere la 3NF? Perché una tabella sia conforme, deve rispettare alcune condizioni:
- Essere in 2NF: significa che è già atomica, senza gruppi ripetuti e senza dipendenze parziali da eventuali chiavi composte.

La 3NF include la 2NF e la 1NF. Immagine dell'autore
- Nessuna dipendenza transitiva: questa regola è fondamentale. In una tabella in 3NF, ogni colonna non chiave deve dipendere esclusivamente dalla chiave primaria, non indirettamente attraverso un'altra colonna non chiave.
Vediamo cosa significa in pratica.
Scomporre le tabelle per raggiungere la 3NF
Facciamo insieme il processo di scomposizione delle tabelle per arrivare alla 3NF. Useremo alcuni dati di esempio dai corsi DataCamp per illustrare ogni passaggio.
Passaggio 1: Identificare le dipendenze transitive
Per iniziare, cercheremo eventuali attributi in una tabella che dipendono indirettamente dalla chiave primaria. Come regola pratica, se un attributo dipende da qualcosa di diverso dalla chiave primaria, questo indica una dipendenza transitiva. È il segnale che forse è il momento di dividere la tua tabella.
Dai un'occhiata alle tre tabelle qui sotto. Quale presenta una dipendenza transitiva?
Tabella 1: Course
| Course ID | Course Name | Difficulty |
|---|---|---|
| 201 | SQL Fundamentals | Beginner |
| 202 | Introduction to Python | Beginner |
| 203 | Understanding Data Science | Intermediate |
Tabella 2: Instructor
| Instructor ID | Instructor Name | Expertise |
|---|---|---|
| 1 | Sarah Johnson | Data Science |
| 2 | Tom Williams | Machine Learning |
| 3 | Emily Brown | Python |
Tabella 3: Enrollments
| Enrollment ID | Student Name | Course ID | Course Name |
|---|---|---|---|
| 1001 | Alice Smith | 201 | SQL Fundamentals |
| 1002 | Bob Green | 202 | Introduction to Python |
| 1003 | Charlie Blue | 201 | SQL Fundamentals |
La risposta è… Tabella 3!
In questa tabella, Course Name dipende da Course ID, ma non direttamente da Enrollment ID (la chiave primaria). Questa dipendenza indiretta rende Course Name una dipendenza transitiva.
Passaggio 2: Separare i dati in nuove tabelle
Per affrontare la dipendenza transitiva, divideremo la Tabella 1 in due tabelle. Ogni tabella si concentrerà su dati direttamente dipendenti.
Tabella delle iscrizioni rivista
| Enrollment ID | Student Name | Course ID |
|---|---|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Tabella Courses
| Course ID | Course Name |
|---|---|
| 201 | SQL Fundamentals |
| 202 | Introduction to Python |
Ora, ogni tabella contiene solo informazioni che dipendono direttamente dalla propria chiave primaria: Course ID è ora la chiave primaria per Course Name nella tabella Courses, ed Enrollment ID è la chiave primaria nella tabella Enrollments.
Con questa scomposizione, le tabelle ora soddisfano i requisiti della 3NF, eliminando la ridondanza e garantendo che ogni tabella memorizzi solo informazioni direttamente pertinenti.
Se vuoi fare pratica e creare i tuoi database, dai un'occhiata al nostro corso Creating PostgreSQL Databases. Se sei un po' più avanti, puoi provare Introduction to Data Modeling in Snowflake, che tratta concetti come il modello entità-relazione e il modello dimensionale.
Vantaggi e limiti dell'uso della Terza Forma Normale
Perché impegnarsi tanto per arrivare alla 3NF? Ecco i principali vantaggi:
- Maggiore integrità dei dati: eliminando le dipendenze transitive, la 3NF aiuta a garantire che aggiornamenti ed eliminazioni non portino a dati in conflitto o obsoleti tra le tabelle.
- Riduzione della ridondanza: meno ridondanza significa un database più semplice da mantenere e un minore utilizzo dello storage.
- Manutenzione dei dati più semplice: mantenere informazioni simili in tabelle dedicate rende più facile aggiornare i record senza dover inseguire voci ridondanti.
Detto questo, sebbene le strutture in 3NF favoriscano l'accuratezza dei dati, possono anche portare a dati più segmentati, talvolta rallentando le query complesse a causa di join aggiuntivi tra tabelle. Nei casi in cui la necessità di velocità prevale su quella di normalizzazione, la BCNF o la 4NF possono essere opzioni più pratiche.
Confronto: Prime, Seconde, Terze e BC Normal Forms
Vediamo le differenze tra le forme.
Tabella di confronto: prima, seconda e terza forma normale
Ecco una tabella di confronto per aiutarti a capire i requisiti di 1NF, 2NF e 3NF.
| Feature | 1NF | 2NF | 3NF |
|---|---|---|---|
| Atomic data | ✅ | ✅ | ✅ |
| No partial dependencies | ❌ | ✅ | ✅ |
| No transitive dependencies | ❌ | ❌ | ✅ |
Third normal form vs. Boyce-Codd normal form (BCNF)
La BCNF è una forma “più rigida” della 3NF che elimina ulteriormente le anomalie che sorgono con chiavi candidate sovrapposte. Può essere particolarmente utile in casi complessi in cui la sola 3NF non elimina completamente le dipendenze. La BCNF si applica quando un attributo non primo dipende da un attributo che fa parte di una chiave candidata composta. So che sembra complesso, quindi scomponiamolo con un esempio.
Struttura attuale (in 3NF)
Dopo la scomposizione per raggiungere la 3NF, avevamo queste due tabelle:
Tabella Enrollments
| Enrollment ID | Student Name | Course ID |
|---|---|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Tabella Courses
| Course ID | Course Name |
|---|---|
| 201 | SQL Fundamentals |
| 202 | Introduction to Python |
In questa struttura, ogni tabella è in 3NF senza dipendenze transitive e i dati sono opportunamente normalizzati.
Introduzione di un nuovo requisito
Ora aggiungiamo un nuovo attributo a Courses: l'aula (Classroom) in cui si tiene ciascun corso. Questo nuovo attributo potrebbe generare uno scenario che richiede la BCNF.
Tabella Courses aggiornata (3NF)
| Course ID | Course Name | Classroom |
|---|---|---|
| 201 | SQL Fundamentals | Room 101 |
| 202 | Introduction to Python | Room 102 |
| 203 | Understanding Data Science | Room 101 |
Qui, Course ID è ancora la chiave primaria e tutti gli altri attributi dipendono direttamente da essa. Ma supponiamo che ci sia una nuova regola per cui ogni aula può ospitare un solo argomento alla volta. Supponiamo anche che il Course Name "SQL Fundamentals" possa essere offerto con diversi Course ID (come 201, 204, ecc.), se programmato in orari diversi. In tal caso, ogni edizione di "SQL Fundamentals" si svolgerebbe comunque nella "Room 101", indipendentemente dallo specifico Course ID. Di conseguenza, anche il Course Name determina univocamente l'aula (Classroom).
Questo significa che ora abbiamo due chiavi candidate:
- Course ID
- Course Name
Con entrambe le chiavi candidate, ora abbiamo un problema che la 3NF non affronta: Classroom dipende da Course Name piuttosto che solo da Course ID.
Applicare la BCNF
Per eliminare questo problema di dipendenze, dovremo scomporre ulteriormente la tabella Courses in due tabelle separate che si allineino meglio alla BCNF:
- Una nuova tabella Courses, che includa solo Course ID e Course Name.
- Una tabella CourseDetails, che memorizzi l'associazione tra Course Name e Classroom.
Ecco come appare:
Tabella Courses rivista (BCNF)
| Course ID | Course Name |
|---|---|
| 201 | SQL Fundamentals |
| 202 | Introduction to Python |
| 203 | Understanding Data Science |
Tabella CourseDetails (BCNF)
| Course Name | Classroom |
|---|---|
| SQL Fundamentals | Room 101 |
| Introduction to Python | Room 102 |
| Understanding Data Science | Room 101 |
Con questa nuova struttura, ogni tabella soddisfa le condizioni della BCNF:
- Nella tabella Courses, Course ID è la chiave primaria e tutti gli attributi dipendono esclusivamente da essa.
- Nella tabella CourseDetails, Course Name è la chiave primaria e Classroom dipende solo da Course Name.
Questa configurazione rimuove eventuali problemi di dipendenza causati da chiavi candidate sovrapposte, garantendo una struttura rigorosamente normalizzata.
Conclusione
La terza forma normale è uno strumento prezioso per i progettisti di database che vogliono mantenere i dati puliti, coerenti e privi di dipendenze problematiche. Con la 3NF, l'integrità dei dati è migliorata, la gestione è più fluida e la ridondanza si riduce. Ricorda: sebbene la 3NF funzioni bene nella maggior parte dei casi, i database più complessi potrebbero beneficiare di forme aggiuntive come BCNF o 4NF.
Se hai trovato utile questo articolo, fai il passo successivo ottenendo la nostra SQL Associate Certification. È un ottimo modo per convalidare le tue competenze in SQL e nella gestione dei database e dimostrare la tua esperienza ai potenziali datori di lavoro!

Sono una tech lead orientata al prodotto, specializzata nel far crescere startup nelle fasi iniziali, dal primo prototipo al product-market fit e oltre. Sono instancabilmente curiosa di come le persone usano la tecnologia e adoro lavorare a stretto contatto con founder e team cross‑funzionali per dare vita a idee ambiziose. Quando non costruisco prodotti, inseguo l’ispirazione in angoli nuovi del mondo o scarico le tensioni in una sala yoga.
Domande frequenti sulla Terza Forma Normale
La 3NF può essere applicata a tutti i tipi di database?
Sebbene la 3NF sia efficace nei database relazionali, potrebbe non essere sempre necessaria nei database NoSQL, che spesso privilegiano flessibilità e scalabilità rispetto alla normalizzazione rigorosa. In alcuni casi, per motivi di prestazioni, si può preferire uno schema denormalizzato, specialmente quando si devono interrogare rapidamente grandi quantità di dati.
Quali sono gli svantaggi nel seguire rigorosamente la 3NF?
Un'adesione rigorosa alla 3NF può a volte portare a schemi complessi con molte tabelle, che possono richiedere più join nelle query. Ciò può influire negativamente sulle prestazioni, soprattutto in database di grandi dimensioni o in sistemi con alti volumi di transazioni. In tali casi, approcci alternativi come la denormalizzazione o l'uso della BCNF possono essere più pratici.
La 3NF può essere applicata a database già esistenti, o devo riprogettarli?
La 3NF può sicuramente essere applicata a database esistenti, anche se potrebbe richiedere una ristrutturazione significativa. Questo processo, chiamato refactoring del database, comporta la scomposizione delle tabelle per eliminare ridondanze e dipendenze. A seconda delle dimensioni e della complessità del database, potrebbe essere necessario pianificare e testare per garantire l'integrità dei dati e mantenere le prestazioni del sistema.
Quali strumenti o tecniche possono aiutare ad automatizzare il processo per raggiungere la 3NF?
Esistono diversi strumenti di progettazione di database, come MySQL Workbench, Oracle SQL Developer ed ER/Studio, che aiutano a visualizzare lo schema del database e a identificare i problemi di normalizzazione. Alcuni di questi strumenti possono suggerire o automatizzare i passaggi per raggiungere la 3NF, anche se la supervisione umana resta importante per garantire integrità e coerenza dei dati.
Qual è la differenza tra chiave candidata e chiave primaria?
Una chiave candidata è un insieme minimo di attributi che può identificare univocamente ogni riga in una tabella. In una tabella possono esserci più chiavi candidate. Una chiave primaria, invece, è la specifica chiave candidata scelta dal progettista del database per identificare univocamente le righe. È consentita una sola chiave primaria per tabella e non può avere valori NULL.
Perché abbiamo bisogno della Boyce-Codd normal form (BCNF) se una tabella è già in terza forma normale (3NF)?
La BCNF è più rigorosa della 3NF e affronta i casi in cui esistono dipendenze sulle chiavi candidate. Mentre la 3NF rimuove le dipendenze transitive, può comunque consentire ridondanza se una dipendenza funzionale ha come determinante un attributo che non è una superchiave. La BCNF elimina questo problema assicurando che tutte le dipendenze funzionali abbiano una superchiave sul lato sinistro.
Una tabella può avere più di una chiave candidata?
Sì, una tabella può avere più chiavi candidate. Ogni chiave candidata è un insieme univoco e minimo di attributi che può identificare le righe.

