DENORMALIZZARE E’ UN CONSIGLIO DISCUTIBILE
PRESUPPOSTI ERRATI PORTANO A FALSI VANTAGGI
Molto spesso si sente pronunciare la seguente frase: “Normalizzate a livello logico, ma
denormalizzate a livello fisico. Quando le strutture dati sono denormalizzate è possibile
soddisfare una richiesta SQL usando molto meno I/O fisico di quanto sarebbe
altrimenti necessario”.
Alla base di questa affermazione vi sono presupposti sbagliati.
Infatti per quanto possa essere appropriato denormalizzare in certe situazioni, coloro
che seguissero ciecamente il consiglio, molto probabilmente otterrebbero una Banca
Dati poco efficiente.
Vediamo quali sono i presupposti sbagliati e quale è invece la realtà.
Presupposto 1: “Normalizzato significa in terza forma normale (3NF)”.
La teoria della normalizzazione costituisce una disciplina collaterale al modello
relazionale. Le forme normali conosciute sono 6, corrispondenti ad altrettanti stati in
cui può trovarsi una relazione.
La 3NF è quella preferibile, in termini di flessibilità del database a lungo termine e di
manutenzione delle applicazioni. L’utilizzo di uno strumento CASE per la disegnare un
modello concettuale dei dati, porta alla realizzazione di un modello in 3NF, quindi privo
di ridondanze.
Presupposto 2: “Il controllo sulle prestazioni è a carico del programmatore”.
Questo è un concetto obsoleto.
L’ottimizzazione di una Banca Dati è di pertinenza del DBA.
Ciò non significa che nello sviluppo delle applicazioni si debba ignorare l’aspetto delle
prestazioni in quanto esse derivano sia dal disegno dei dati che dal disegno delle
applicazioni.
Inoltre, se si usano compromessi sul disegno dati, sarà molto difficile ottenere vantaggi
dal miglioramento delle prestazioni di future versioni del DBMS.
Presupposto 3: “Tutte le attività sul database implicano I/O fisico”.
In teoria è possibile che un intero Database risieda in memoria per lunghi periodi.
In tal caso le operazioni di SELECT, INSERT, UPDATE, DELETE non richiederebbero I/O
fisico.
E adesso, la realtà.
Affermare che “denormalizzare equivale a ridurre I/O fisico” non è corretto.
Un disegno normalizzato talvolta può richiedere meno I/O in quanto le righe di una
tabella normalizzata sono più corte e quindi in una pagina fisica ce ne stanno di più.
Inoltre tramite la tecnica di “clusterizzazione” di tabelle, molte righe correlate possono
essere recuperate con un’unica operazione di I/O.
Viceversa le righe di una tabella denormalizzata, sono più lunghe e quindi occupano
più spazio e consentono a meno righe correlate di essere salvate nella stessa pagina
fisica.
Più importante delle prestazioni è l’ulteriore difficoltà che la denormalizzazione
introduce nello sviluppo applicativo e nell’interrogazione della base dati.
Conclusioni.
Consentire la denormalizzazione significherebbe avere banche dati progettate per
fornire buone prestazioni alle applicazioni iniziali ma con buone probabilità di essere
responsabili di creare effetti svantaggiosi alle applicazioni successive.
Piuttosto che denormalizzare, è preferibile adottare un insieme di misure di tuning
fisico, che coprono aspetti di indicizzazione, ottimizzazione delle query, strategia di
locking, attività di manutenzione, selezione di appropriati parametri di sistema.
Infatti non bisogna dimenticare che i “miglioramenti in termini di prestazioni” per i
prodotti relazionali sono sempre più significativi con il rilascio di nuove release.
Le banche dati progettate con la filosofia relazionale di approccio ai dati risultano
essere le più flessibili.
Sono semplici, non ridondanti, condivisibili ed espandibili.
Quando la progettazione logica e fisica di un database è fatta seguendo
scrupolosamente la rappresentazione concettuale, il sistema è concepito per
rispondere non solo ai bisogni immediati, ma anche a quelli di applicazioni future.
