- Nessuna dipendenza transitiva: Questa regola è fondamentale. In una tabella 3NF, qualsiasi colonna non chiave dipende esclusivamente dalla chiave primaria, non indirettamente attraverso un’altra colonna non chiave.
Diamo un’occhiata a cosa significa praticamente questo.
Scomposizione delle tabelle per raggiungere la 3NF
Attraversiamo il processo di scomposizione delle tabelle per raggiungere la 3NF. Utilizzeremo alcuni dati di esempio dei corsi di DataCamp per illustrare ogni passaggio.
Passo 1: Identificare le dipendenze trasitive
Per iniziare, cercheremo eventuali attributi in una tabella che dipendono indirettamente dalla chiave primaria. Come regola generale, se un attributo dipende da qualcosa diverso dalla chiave primaria, ciò indica una dipendenza transitiva. Questo è un segno che potrebbe essere il momento di dividere la tabella.
Dai un’occhiata alle tre tabelle qui sotto. Quale di esse ha una dipendenza transitiva?
Tabella 1: Corso
Course ID | Course Name | Difficulty |
---|---|---|
201 | Fondamenti di SQL | Principiante |
202 | Introduzione a Python | Principiante |
203 | Comprensione della Scienza dei Dati | Intermedio |
Tabella 2: Istruttore
Instructor ID | Instructor Name | Expertise |
---|---|---|
1 | Sarah Johnson | Scienza dei Dati |
2 | Tom Williams | Apprendimento Automatico |
3 | Emily Brown | Python |
Tabella 3: Iscrizioni
Enrollment ID | Student Name | Course ID | Course Name |
---|---|---|---|
1001 | Alice Smith | 201 | Fondamenti di SQL |
1002 | Bob Green | 202 | Introduzione a Python |
1003 | Charlie Blue | 201 | Fondamenti di SQL |
La risposta è… Tabella 3!
In questa tabella, Nome del corso dipende da ID del corso, ma non direttamente da ID dell’iscrizione (la chiave primaria). Questa dipendenza indiretta rende Nome del corso 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à sui 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 dei corsi
Course ID | Course Name |
---|---|
201 | Fondamenti di SQL |
202 | Introduzione a Python |
Ora, ciascuna tabella contiene solo informazioni che dipendono direttamente dalla sua chiave primaria: ID Corso è ora la chiave primaria per Nome Corso nella tabella Corsi, e ID Iscrizione è la chiave primaria nella tabella Iscrizioni.
Con questa decomposizione, le tabelle soddisfano ora i requisiti della 3NF, eliminando la ridondanza e garantendo che ciascuna tabella memorizzi solo informazioni direttamente rilevanti.
Se desideri metterti alla prova e creare i tuoi database, dai un’occhiata al nostro corso Creazione di database PostgreSQL. Se sei un po’ più avanzato, potresti provare Introduzione alla modellazione dei dati in Snowflake, che tratta concetti come la modellazione entità-relazione e dimensionale.
Vantaggi e Limitazioni dell’Utilizzo della Terza Forma Normale
Allora, perché sforzarsi tanto per raggiungere la 3NF? Ecco i principali vantaggi:
- Miglioramento dell’integrità dei dati: Eliminando le dipendenze transitive, la 3NF aiuta a garantire che gli aggiornamenti e le eliminazioni non portino a dati in conflitto o obsoleti tra le tabelle.
- Riduzione della ridondanza: Meno ridondanza significa che il tuo database è più facile da mantenere e l’uso dello storage è ridotto.
- Mantenimento dei dati più semplice: Mantenere informazioni simili in tabelle dedicate rende più semplice aggiornare i record senza dover rintracciare voci ridondanti.
Detto ciò, mentre le strutture in 3NF supportano l’accuratezza dei dati, possono anche portare a dati più segmentati, talvolta rendendo le query complesse più lente a causa di ulteriori join delle tabelle. Nei casi in cui la necessità di velocità supera la necessità di normalizzazione, BCNF o 4NF potrebbero essere opzioni più pratiche. Confronto: Forme Normali di Boyce-Codd (BCNF) e Prima, Seconda e Terza
Forme Normali di Primo, Secondo e Terzo Livello: Differenze
Diamo uno sguardo alle differenze delle forme.
Tabella di confronto: Primo, Secondo e Terzo livello delle forme normali
Ecco una tabella di confronto per aiutarti a comprendere i requisiti di 1NF, 2NF e 3NF.
BCNF è una forma “più rigorosa” della 3NF che elimina ulteriormente le anomalie che sorgono con le chiavi candidate sovrapposte. Può essere particolarmente utile nei casi complessi in cui la 3NF da sola non elimina completamente le dipendenze. BCNF si applica quando un attributo non principale dipende da un attributo che fa parte di una chiave candidata composta. So che sembra complesso, quindi vediamolo con un esempio.
Struttura attuale (in 3NF)
Dopo la decomposizione per ottenere la 3NF, avevamo queste due tabelle:
Tabella degli iscrizioni
Tabella dei corsi
Course ID | Course Name |
---|---|
201 | Fondamenti di SQL |
202 | Introduzione a Python |
In questa struttura, ogni tabella è in 3NF senza dipendenze transitive, e i dati sono normalizzati in modo appropriato.
Introduzione di un nuovo requisito
Adesso, aggiungiamo un nuovo attributo a Corsi: la Aula in cui si tiene ciascun corso. Questo nuovo attributo potrebbe comportare uno scenario che richiede BCNF.
Tabella corsi aggiornata (3NF)
Course ID | Course Name | Classroom |
---|---|---|
201 | Fondamenti di SQL | Stanza 101 |
202 | Introduzione a Python | Stanza 102 |
203 | Comprendere la scienza dei dati | Stanza 101 |
Qui, ID Corso è ancora la chiave primaria, e tutti gli altri attributi dipendono direttamente da esso. Ma supponiamo che ci sia una nuova regola secondo la quale ogni aula può ospitare solo una materia alla volta. Supponiamo anche che il Nome del Corso “Fondamenti di SQL” potrebbe essere offerto con diversi ID Corsi (come 201, 204, ecc.), se fossero programmati in momenti diversi. In tal caso, ogni offerta di “Fondamenti di SQL” si svolgerebbe comunque in “Aula 101”, indipendentemente dallo specifico ID Corso. Di conseguenza, il Nome del Corso determina anche in modo univoco la Aula.
Questo significa che ora abbiamo due chiavi candidate:
- ID Corso
- Nome Corso
Con entrambe le chiavi candidate, ora abbiamo un problema che la 3NF non affronta: l’Aula dipende dal Nome del Corso piuttosto che solo dall’ID del Corso.
Applicando BCNF
Per eliminare questo problema di dipendenza, dovremo decomporre ulteriormente la tabella Corsi in due tabelle separate che si allineano meglio con la BCNF:
- Una nuova tabella Corsi, che include solo l’ ID del Corso e il Nome del Corso
. - Una tabella CourseDetails, che memorizza l’Nome del corso e l’associazione Classroom.
Ecco come appare:
Tabella dei corsi rivista (BCNF)
Tabella dei dettagli del corso (BCNF)
Course Name | Classroom |
---|---|
Fondamenti di SQL | Aula 101 |
Introduzione a Python | Aula 102 |
Comprendere la Scienza dei Dati | Aula 101 |
- Nella tabella Corsi, ID corso è la chiave primaria e tutti gli attributi dipendono esclusivamente da esso.
- Nella tabella CourseDetails, Nome del Corso è la chiave primaria, e Aula dipende solo dal Nome del Corso.
Questa configurazione rimuove eventuali problemi di dipendenza causati da chiavi candidate sovrapposte, garantendo una struttura rigorosamente normalizzata.
Conclusioni
La terza forma normale è uno strumento prezioso per i progettisti di database che mirano a mantenere i dati puliti, coerenti e privi di dipendenze problematiche. Con la 3NF, l’integrità dei dati è migliorata, rendendo la gestione più fluida e riducendo la ridondanza. Ricorda, mentre la 3NF funziona bene nella maggior parte delle situazioni, database più complessi potrebbero beneficiare di forme aggiuntive come BCNF o 4NF.
Se hai trovato utile questo articolo, considera di compiere il prossimo passo ottenendo la nostra Certificazione di Associato SQL. È un ottimo modo per convalidare le tue competenze in SQL e gestione di database e dimostrare la tua competenza ai potenziali datori di lavoro!