Corso
Quando lavori con i database, è comune imbattersi in problemi come dati ridondanti e aggiornamenti incoerenti. La seconda forma normale è una fase della normalizzazione dei database che si basa sulla prima forma normale (1NF) per creare tabelle più pulite ed efficienti.
Capire la 2NF è fondamentale per chi lavora nel design di database o nella gestione dei dati, e pone le basi per forme di normalizzazione superiori come la terza forma normale (3NF). In questo articolo vedremo come funziona la 2NF e come trasformare le tabelle per rispettarne i requisiti, con esempi pratici. Parleremo anche dei vantaggi e degli svantaggi della 2NF e dei casi d’uso per cui è più adatta.
Capire la Seconda Forma Normale
La seconda forma normale è una fase di normalizzazione dei database incentrata sull’eliminazione delle dipendenze parziali. È stata introdotta da Edgar F. Codd, il pioniere dei database relazionali, come parte del suo lavoro sulla normalizzazione.
Prima che una tabella possa essere in 2NF, deve soddisfare le regole della prima forma normale:
- Atomicità: ogni cella deve contenere un singolo valore (niente gruppi ripetuti o array).
- Righe univoche: la tabella deve avere una chiave primaria chiara.
La 2NF fa un passo in più con una regola aggiuntiva: eliminare le dipendenze parziali.
Una dipendenza parziale si verifica quando un attributo non primo (colonna che non fa parte di alcuna chiave candidata) dipende solo da una parte di una chiave composta invece che dall’intera chiave. La regola della 2NF assicura che tutti gli attributi non primi dipendano dall’intera chiave primaria, non solo da una sua parte. Lasciare dipendenze parziali in una tabella significa che dati ridondanti possono insinuarsi nel database, portando a inefficienze e potenziali incoerenze durante aggiornamenti o eliminazioni.
La sola teoria può risultare un po’ arida, quindi vediamo un esempio pratico.
Di seguito c’è una tabella di Iscrizioni ai corsi degli studenti Datacamp.
| ID studente | ID corso | Nome del corso | Nome dell’istruttore |
|---|---|---|---|
| 1001 | 201 | SQL Fundamentals | Ken Smith |
| 1002 | 202 | Introduction to Python | Merlin O’Donnell |
| 1001 | 202 | Introduction to Python | Merlin O’Donnell |
Qui, la chiave primaria è la composizione di ID studente e ID corso. Tuttavia, gli attributi non primi Nome del corso e Costo del corso dipendono solo da ID corso, non dall’intera chiave. Questo viola la 2NF.
Passi per decomporre le tabelle e ottenere la 2NF
Per assicurarti che una tabella segua le regole della 2NF, devi:
- Identificare tutte le chiavi candidate: determina gli insiemi minimi di attributi che identificano in modo univoco le righe nella tabella. Queste sono le tue chiavi candidate.
- Determinare le dipendenze funzionali: identifica tutte le dipendenze funzionali nella tabella. In particolare, cerca dipendenze in cui gli attributi non primi (quelli che non fanno parte di alcuna chiave candidata) dipendono solo da una parte di una chiave composta.
- Eliminare le dipendenze parziali: per ogni dipendenza parziale:
- Sposta gli attributi dipendenti in una nuova tabella insieme alla parte della chiave da cui dipendono.
- Assicurati che la nuova tabella abbia una chiave primaria univoca.
- Ripetere finché non rimangono dipendenze parziali: verifica che ogni attributo non primo in tutte le tabelle dipenda completamente dalla rispettiva chiave primaria.
Esempi di Seconda Forma Normale nella pratica
Vediamo ora due esempi.
Esempio 1: tabella delle iscrizioni ai corsi
Poco fa, abbiamo visto la seguente tabella di iscrizioni ai corsi:
| ID studente | ID corso | Nome del corso | Nome dell’istruttore |
|---|---|---|---|
| 1001 | 201 | SQL Fundamentals | Ken Smith |
| 1002 | 202 | Introduction to Python | Merlin O’Donnell |
| 1001 | 202 | Introduction to Python | Merlin O’Donnell |
Seguiamo i passaggi delineati nella sezione precedente.
1. Identificare la nostra chiave candidata.
In questo caso, la chiave candidata è una chiave composta da ID studente e ID corso. Questa combinazione univoca identifica ogni riga nella tabella.
2. Determinare le nostre dipendenze funzionali
Nome del corso e Nome dell’istruttore dipendono da ID corso, non dall’intera chiave composta (ID studente, ID corso). Questa è una dipendenza parziale perché questi attributi dipendono solo da una parte della chiave composta.
3. Eliminare le dipendenze parziali
Dobbiamo spostare gli attributi che dipendono solo da una parte della chiave (Nome del corso e Nome dell’istruttore) in una nuova tabella basata esclusivamente su ID corso.
Dopo la decomposizione, le nostre nuove tabelle sono così:
Tabella iscrizioni ai corsi
| ID studente | ID corso |
|---|---|
| 1001 | 201 |
| 1002 | 202 |
| 1001 | 202 |
Tabella dettagli del corso
| ID corso | Nome del corso | Nome dell’istruttore |
|---|---|---|
| 201 | SQL Fundamentals | Ken Smith |
| 202 | Introduction to Python | Merlin O’Donnell |
Se vuoi metterti alla prova e creare i tuoi database, dai un’occhiata al nostro corso su PostgresQL. Se sei un po’ più avanzato, puoi provare questo Introduction to Data Modeling in Snowflake, che copre concetti come il modello entità‑relazione e la modellazione dimensionale.
Esempio 2: tabella Ordini
Partiremo da questa tabella Ordini. Prova a seguire i passaggi indicati sopra e a decomporre tu stesso questa tabella!
| ID ordine | ID prodotto | Data ordine | Nome prodotto | Nome fornitore |
|---|---|---|---|---|
| 1 | 201 | 2024-11-01 | Laptop | TechSupply |
| 1 | 202 | 2024-11-01 | Mouse | TechSupply |
| 2 | 201 | 2024-11-02 | Laptop | TechSupply |
| 3 | 203 | 2024-11-03 | Keyboard | KeyMasters |
1. Identificare la nostra chiave candidata
La combinazione di ID ordine e ID prodotto identifica in modo univoco ogni riga, rendendo (ID ordine, ID prodotto) una chiave candidata composta. Nessuna singola colonna può identificare univocamente le righe perché:
- ID ordine da solo non è univoco, poiché più prodotti possono far parte dello stesso ordine.
- ID prodotto da solo non è univoco, poiché lo stesso prodotto può comparire in ordini diversi.
Questo significa che (ID ordine, ID prodotto) è anche la nostra chiave primaria.
2. Determinare le nostre dipendenze funzionali
Data ordine dipende da ID ordine (non dall’intera chiave composta). Questa è una dipendenza parziale.
Nome prodotto e Nome fornitore dipendono da ID prodotto (non dall’intera chiave composta). Anche queste sono dipendenze parziali.
3. Eliminare le dipendenze parziali
Dobbiamo suddividere la tabella in tabelle più piccole, ognuna dedicata a una dipendenza logica.
Per prima cosa, creeremo una tabella per le informazioni dell’ordine, che contiene le informazioni specifiche di ID ordine.
Tabella Ordini
| ID ordine | Data ordine |
|---|---|
| 1 | 2024-11-01 |
| 2 | 2024-11-02 |
| 3 | 2024-11-03 |
Poi creiamo una tabella che contiene le informazioni specifiche di ID prodotto.
Tabella Ordini
| ID prodotto | Nome prodotto | Nome fornitore |
|---|---|---|
| 201 | Laptop | TechSupply |
| 202 | Mouse | TechSupply |
| 203 | Keyboard | KeyMasters |
La tabella originale è ora ridotta alla sola chiave composta e alle relazioni tra ordini e prodotti.
| ID ordine | ID prodotto |
|---|---|
| 1 | 201 |
| 1 | 202 |
| 2 | 201 |
| 3 | 203 |
Ora il nostro database è in 2NF perché 1) tutte le dipendenze parziali sono state eliminate e 2) gli attributi non primi dipendono interamente dalle rispettive chiavi primarie.
Quando implementare la Seconda Forma Normale
Quindi, perché dovresti rifattorizzare il tuo database alla 2NF? È sufficiente da sola o conviene fare un passo in più e puntare alla 3NF?
Vantaggi e limiti della seconda forma normale
La seconda forma normale offre diversi vantaggi, rendendola un passaggio utile nel processo di normalizzazione dei database:
- Maggiore integrità dei dati: eliminando le dipendenze parziali, la 2NF riduce le anomalie di inserimento, aggiornamento ed eliminazione, portando a un database più affidabile.
- Riduzione della ridondanza: la 2NF diminuisce la ripetizione dei dati, ottimizzando l’uso dello storage e semplificando la manutenzione.
- Struttura dei dati migliorata: pone le basi per ulteriore normalizzazione, come il passaggio alla terza forma normale, creando un design del database più pulito ed efficiente.
Ma presenta anche alcuni limiti:
- Aumentata complessità: decomporre le tabelle per soddisfare la 2NF può rendere il processo di progettazione più complesso, soprattutto quando si hanno chiavi composte e dipendenze.
- Join aggiuntivi: la suddivisione delle tabelle può richiedere più join nelle query, con potenziali impatti sulle prestazioni in sistemi con grandi dataset o query complesse — ne parliamo meglio qui sotto.
- Ridondanza residua: sebbene la 2NF riduca le dipendenze parziali, non affronta le dipendenze transitive, lasciando una certa ridondanza finché non si passa alla 3NF.
Considerazioni sulle prestazioni con la seconda forma normale
Decomporre le tabelle per eliminare le dipendenze parziali può avere un impatto diretto sulle prestazioni del database. Da un lato, raggiungere la 2NF riduce la ridondanza e migliora la coerenza, portando a meno anomalie durante le operazioni di insert, update o delete. Dall’altro, la normalizzazione può aumentare il numero di tabelle, il che significa che sono necessari join aggiuntivi quando si recuperano dati correlati. Questo può influire sulle prestazioni delle query con grandi dataset.
Per assicurarti che il tuo database normalizzato rimanga performante, segui queste buone pratiche:
- Indicizzazione: usa indici per velocizzare i join tra tabelle decomposte.
- Ottimizzazione delle query: ottimizza le query per ridurre al minimo il costo dei join aggiuntivi.
- Approccio ibrido: combina normalizzazione e denormalizzazione nelle aree in cui le prestazioni sono importanti, come le tabelle di reporting.
- Monitoraggio regolare: valuta continuamente le prestazioni del database con strumenti di profilazione per intercettare eventuali problemi.
La 2NF è solo un passo di transizione verso la terza forma normale?
Nella maggior parte dei casi, i progettisti di database puntano a raggiungere la terza forma normale, grazie alla sua capacità di ridurre ulteriormente la ridondanza e migliorare l’integrità complessiva dei dati. Tuttavia, arrivare alla 3NF spesso richiede lavoro aggiuntivo, come creare più tabelle e relazioni, il che può introdurre complessità e compromessi prestazionali nell’esecuzione delle query.
Ci sono casi in cui usare la seconda forma normale da sola può essere sufficiente. Se semplicità e rapidità di implementazione sono priorità, come in progetti su piccola scala, prototipi o situazioni in cui la ridondanza dei dati è minima, la 2NF può bastare. Ad esempio, in sistemi in cui tutti gli attributi dipendono già completamente da una chiave primaria semplice, raggiungere la 2NF può soddisfare l’obiettivo principale di ridurre la dipendenza parziale, senza bisogno di ulteriore normalizzazione.
Oltre la seconda forma normale: verso la terza forma normale
Se vuoi normalizzare ulteriormente il tuo database, puoi continuare a rifattorizzare le tabelle per raggiungere la terza forma normale.
La 3NF si basa sulla 2NF affrontando le dipendenze transitive, cioè situazioni in cui gli attributi non chiave dipendono da altri attributi non chiave anziché dalla chiave primaria. Questo passaggio assicura che ogni attributo dipenda direttamente dalla chiave primaria e nient’altro.
Per esempio, in una tabella che tiene traccia delle iscrizioni ai corsi:
- 2NF: garantisce che attributi come il nome del corso e il nome dello studente dipendano interamente dalle rispettive chiavi primarie (ad es., ID studente e ID corso). Questo elimina le dipendenze parziali, in cui gli attributi non chiave dipendono solo da una parte della chiave composta.
- 3NF: assicura che attributi come i dettagli dell’istruttore o le informazioni sul dipartimento siano archiviati in tabelle separate, eliminando le dipendenze transitive.
La 3NF è ideale per sistemi più complessi in cui integrità ed efficienza dei dati sono fondamentali, soprattutto all’aumentare del volume dei dati. Dai un’occhiata al nostro articolo Che cos’è la terza forma normale? se vuoi saperne di più sulla 3NF e sulla sua forma più restrittiva, la BCNF.
Conclusione
La seconda forma normale è un passaggio essenziale nella normalizzazione dei database, che fa da ponte tra la 1NF e forme superiori come la 3NF. Rimuovendo le dipendenze parziali, la 2NF riduce la ridondanza e migliora l’affidabilità dei tuoi dati. Anche se può aggiungere un po’ di complessità, i vantaggi in termini di integrità dei dati e manutenzione semplificata la rendono una parte fondamentale di un design di database efficace.
Se sei pronto a fare un passo avanti, esplora il nostro corso Database Design per approfondire le tecniche di normalizzazione e le loro applicazioni pratiche. Puoi anche convalidare le tue competenze in SQL e gestione dei database e dimostrare la tua esperienza ai potenziali datori di lavoro con la nostra Certificazione SQL Associate!
Infine, se prendi decisioni in azienda e sai che c’è del lavoro da fare per creare database più puliti ed efficienti, valuta di inviare una richiesta demo per DataCamp for Business. Possiamo aiutarti a trasformare le capacità del tuo team in modo da creare sistemi di database scalabili che aumentano l’efficienza e l’innovazione aziendale. Possiamo anche creare percorsi di apprendimento su misura e track personalizzate.

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.
FAQ su 2NF
La seconda forma normale (2NF) può essere applicata a database senza chiavi composte?
Sì! Anche se la 2NF spesso coinvolge chiavi composte, le tabelle con chiave singola possono seguire i principi della 2NF se tutti gli attributi non primi dipendono completamente dalla chiave primaria.
Raggiungere la 2NF garantisce l’eliminazione di tutta la ridondanza in un database?
No. Sebbene la 2NF elimini le dipendenze parziali, non affronta le dipendenze transitive. Per quello, devi passare alla terza forma normale (3NF).
Ci sono situazioni in cui una database in 1NF è sufficiente senza passare alla 2NF?
Sì. In sistemi molto semplici con ridondanza minima dei dati o in prototipi, la 1NF potrebbe essere sufficiente. In generale, non consiglierei di fermarsi alla 1NF a meno che tu non abbia un motivo molto specifico e giustificabile.
Qual è la differenza tra 2NF e terza forma normale (3NF)?
La 2NF rimuove le dipendenze parziali, assicurando che gli attributi dipendano dall’intera chiave. La 3NF va oltre eliminando le dipendenze transitive, garantendo che gli attributi dipendano direttamente dalla chiave primaria e non da altri attributi non chiave.
Come faccio a verificare se il mio database esistente è già in 2NF?
Puoi verificarlo esaminando tutte le tabelle con chiavi composte e controllando che tutti gli attributi non primi dipendano dall’intera chiave composta, non solo da una parte.

