Riprendendo il punto (2) dell´ottima pillola di Dark Bard, pensavo di parlare un po´ delle ridondanze, la cui presenza é da decidere in fase di progettazione del database.
Il problema é piú complesso di quel che potrebbe si potrebbe in un primo momento pensare.
Per ridondanza si intende una ripetizione di un´informazione, cioé inserire in una certa tabella un dato ricavabile per mezzo di query dal resto del database. Ad esempio un attributo che puķ essere derivato da altri attributi della stessa tabella o di altre.
La presenza di ridondanze porta come vantaggio la semplificazione delle query e un aumento della velocitá di esecuzione.
L´inserimento di queste porta perķ anche notevoli svantaggi come l´appesantimento degli aggiornamenti e un maggiore spazio occupato.
Ma quando conviene inserire una ridondanza in un database?
Prima di inserire una ridondanza all´interno del database é necessario analizzare le sue prestazioni.
I due principali indici di prestazione considerano costo delle operazioni e occupazione di memoria. Nel caso di un database (che é il caso che analizzo), il costo di un´operazione é misurato in funzione del numero di occorrenze delle tabelle e delle associazioni che le coinvolgono. Per fare questa analisi é necessario conoscere il volume di dati, cioé occorrenze e dimensioni degli attributi, e le caratteristiche delle operazioni, cioé tipo di operazione, la frequenza e i dati coinvolti.
In genere é sufficiente limitarsi ad analizzare le prestazioni delle operazioni piú frequenti.
Per desrivere il volume dei dati e le caratteristiche delle operazioni é possibile costruire la tavola dei volumi, in cui vengono riportati tutti i concetti dello schema con i volumi di accessi previsti e la tavola delle operazioni dove sono inserite i tipi di operazioni e loro frequenza.
Per facilitare l´analisi si considera solitamente un accesso in scrittura come il doppio di uno in lettura.
Quindi accedere 2 volte in lettura ad una tabella equivale ad accedere 1 volta in scrittura.
La presenza o meno di una ridondanza é quindi essenziale in termini di prestazione di un database, soprattutto se questo inizia ad avere un numero elevato di dati.
Spero di essermi spiegato. Aspetto le giuste critiche
:gren:
![]()