Design multi-livello

Pertanto, quello che proponiamo è un approccio innovativo rispetto al passato: un approccio basato sull'identificazione e la gestione delle anomalie piuttosto che su una politica di rigetto del dato corrotto.

Per ragioni di performance, può risultare conveniente “replicare” alcuni attributi dimensionali di grande importanza per l’analisi anche sulle tabelle dei fatti a cui quelle informazioni di contesto fanno riferimento. In questo modo si abilita la possibilità di un’interrogazione immediata un’unica tabella, la tabella fatto, evitando di dover agganciare in join le tabelle dimensionali sulla chiave esterna, per recuperare le informazioni di contesto di interesse: la query risultante è più performante, richiede meno risorse macchina e minor tempo di esecuzione.

Nella teoria classica di progettazione di datawarehouse, le tabelle dei fatti sono pensate per contenere fondamentalmente due tipi di informazioni: un primo insieme di campi è composto dalle chiavi esterne, che permettono di recuperare le informazioni anagrafiche e di contesto associate al record del fatto, tramite operazione di join con le relative tabelle dimensionali; un secondo gruppo di campi è costituito dai valori numerici, categorici o booleani delle misure che descrivono l’evento accaduto (ad esempio, il prezzo di una vendita, il tipo di una valuta, un flag di attivazione/disattivazione).