Ritengo di avere "abbastanza bene" chiaro il concetto di normalizzazione, e le forme normali non sono 3 (sono parecchie di più).
Non è affatto un processo necessario per far sì che il db sia funzionale, anzi spesso si denormalizza per ottenere prestazioni nettamente superiori o funzionalità pressochè impossibili (o molto difficili).
Sono concetti che risalgono agli anni '70 e vengono ancor oggi insegnati come articolo di fede, ma al livello dei primi corsi universitari o giù di lì.
La differenza è tra chi non sa cosa sia un db normalizzato, e chi sa perchè lo è, perchè lo deve essere, quando può essere meglio non normalizzare, e come si gestisce un progetto "vero" con qualche centinaio di tabelle e qualche terabyte di dati, invece del progettino tipico della libreria o qualcosa del genere.
Poi ci vuole la consapevolezza della semantica del database, perchè normalizzare in maniera automatica significa spegnere il cervello (cioè applicando le regolette che vengono insegnate si perde di vista che a monte ci dovrebbe sempre essere la comprensione piena).
Altrimenti se scrivo questo semplicissimo esempio di studio (supponiamo siano fatture)
(progressivo,data,nome,indirizzo,imporot)
1,2015-06-06,pippo baudo,via roma 34, 100
2,2015-06-06,pippo baudo,via roma 34, 200
3,2015-06-06,mario rossi,via milano 12, 50
4,2015-06-06,mario rossi,via milano 12, 30
a qualcuno verrebbe in mente di normalizzare, dimostrando di non aver capito minimamente la teoria, che invece di essere riferita all'algebra o entità e relazioni, è riferita a problemi.
![]()