Quando parliamo di analizzare un database per la conformità alle normal forms, intendiamo studiare la struttura delle tabelle, le loro relazioni e le dipendenze tra gli attributi. L'obiettivo principale dell'analisi è trovare violazioni della normalizzazione e valutare il loro impatto su performance, integrità e facilità di lavoro con i dati.
In parole povere, è come fare un audit della contabilità: controlli che i soldi non siano messi a caso, ma siano distribuiti esattamente dove servono.
Approccio pratico all'analisi di un database
In qualsiasi database, partiamo sempre da tre domande fondamentali, che corrispondono alle tre normal forms.
Supponiamo di avere un database di magazzino con una tabella fatta così:
| product_id | product_name | supplier_name | supplier_phone | stock_quantity |
|---|---|---|---|---|
| 1 | Chiodi | StroyKomplekt | +12301112233 | 150 |
| 2 | Viti | KrepyoshPro | +12306667788 | 200 |
| 3 | Dadi | StroyKomplekt | +12301112233 | 100 |
Come controllare questa tabella per vedere se rispetta le normal forms?
Ricorda, una tabella è in 1NF se:
- Ogni cella contiene un solo valore.
- Nella tabella non ci sono colonne ripetute per lo stesso tipo di dato.
Nel nostro esempio, non ci sono violazioni della 1NF: ogni cella contiene un valore atomico. Quindi la tabella è in 1NF. Grande! Possiamo andare avanti.
Una tabella è in 2NF se:
- È già in 1NF.
- Tutti gli attributi non chiave dipendono solo dall'intera chiave primaria (e non da una sua parte).
In questa tabella vediamo che supplier_name e supplier_phone dipendono solo da product_id — la chiave primaria. Però qui c'è duplicazione di dati: per lo stesso fornitore salviamo nome e telefono in più righe.
Per portare la tabella in 2NF, possiamo dividerla in due tabelle:
Tabella Products:
| product_id | product_name | supplier_id | stock_quantity |
|---|---|---|---|
| 1 | Chiodi | 1 | 150 |
| 2 | Viti | 2 | 200 |
| 3 | Dadi | 1 | 100 |
Tabella Suppliers:
| supplier_id | supplier_name | supplier_phone |
|---|---|---|
| 1 | StroyKomplekt | +78901112233 |
| 2 | KrepyoshPro | +78906667788 |
Ora ogni fornitore è rappresentato una sola volta, e il collegamento tra le tabelle è fatto tramite la foreign key supplier_id.
Una tabella è in 3NF se:
- È già in 2NF.
- Tutti gli attributi non chiave dipendono solo dalla chiave primaria, e non da altri attributi non chiave.
Nel caso delle tabelle normalizzate Products e Suppliers non vediamo dipendenze transitive. Quindi le tabelle sono in 3NF.
Esercizio pratico
Supponiamo di avere la tabella originale "Università"
| student_id | student_name | course_name | professor_name | professor_email |
|---|---|---|---|---|
| 101 | Otto Lin | Matematica | Peter Pen | pen@university.com |
| 102 | Anna Song | Fisica | Alex Sid | sid@university.com |
| 103 | Otto Lin | Fisica | Alex Sid | sid@university.com |
- Controlla la tabella per la conformità alle normal forms.
- Portala in 1NF, 2NF e 3NF, se serve.
Soluzione
PASSO 1: Controllo della 1NF
La tabella è già in 1NF: ogni cella contiene un solo valore.
PASSO 2: Controllo della 2NF
La tabella viola la 2NF: le info sui professori (nome ed email) si ripetono. Possiamo spostarle in una tabella separata:
Tabella Students:
| student_id | student_name |
|---|---|
| 101 | Otto Lin |
| 102 | Anna Song |
Tabella Courses:
| course_id | course_name | professor_id |
|---|---|---|
| 1 | Matematica | 1 |
| 2 | Fisica | 2 |
Tabella Professors:
| professor_id | professor_name | professor_email |
|---|---|---|
| 1 | Peter Pen | pen@university.com |
| 2 | Alex Sid | sid@university.com |
Tabella Enrollments:
| enrollment_id | student_id | course_id |
|---|---|---|
| 1 | 101 | 1 |
| 2 | 102 | 2 |
| 3 | 103 | 2 |
PASSO 3: Controllo della 3NF
Nella nuova struttura non ci sono dipendenze transitive. Le tabelle rispettano la 3NF.
Consigli pratici
- Non puntare alla perfezione se non serve. A volte una normalizzazione eccessiva complica le query.
- Analizza come un detective. Cerca duplicati, dipendenze inutili e altre "anomalie".
- Non dimenticare le performance. La normalizzazione è un equilibrio tra pulizia dei dati e velocità di elaborazione.
Ora che sai trovare i problemi in un database e risolverli, potresti tranquillamente fare una "revisione" di qualsiasi database. Ricorda: un buon database non è solo funzionale, ma anche bello (o normalizzato) come progetto.
GO TO FULL VERSION