Please enable JavaScript.
Coggle requires JavaScript to display documents.
Progettazione del Data Warehouse - Coggle Diagram
Progettazione del Data Warehouse
Intro
Esistono dei fattori di rischio per la creazione del DW
Aspettative degli utenti
Il DW viene visto come soluzione dei probelbmi aziendali
Qualità dei sistemi OLTP già presenti molto bassa per via di dati incompleti o inaffidabili
Gestione "politica" del progetto
collaborazione con i "detentori" delle informazioni e accettazione del sistema da parte degli utenti
Tipi di approccio
Top down
realizzazione del DW con una visione globale dei dati aziendali
costi e tempi di realizzazione significativi
analisi e progettazione complesse
Bottom up
realizzazione incrementale del DW aggiungendo via via nuovi Data mart
costo e tempo contenuti
focalizzato seperatamente su settori specifici
Progettazione di datamart
Analisi dei requisiti
capire le esigenze d'analisi e i vincoli realizzativi dovuti ai sistemi esistenti
il data mart è strategico per l'azienda e alimentato (preferibilmente) da poche sorgenti
affidabili
Requisiti applicativi
Descrizione degli eventi di interesse (fatti) con la loro relativa granularità e dimensioni
descrizione del carico di lavoro
Progettazione concettuale
Dimensional Fact Model
Il modello ER non è adatto
concetti base
fatto
modella un insieme di eventi di interesse che evolve nel tempo
dimensione
descrive le coordinate di analisi del fatto ed è caratterizzato da numero attributi
misura
descrizione di una proprietà numerica di un fatto
Ogni dimensione ha la sua gerarchia. Ciascuna gerarchia ha i suoi attributi dimensionali
L'
arco multiplo
rappresenta una relazione molti a molti
Un
trattino su un attributo
indica un attributo (o una dimensione) opzionale
Una
freccia verso un attributo
indica una convergenza, ovvero un
pezzo di gerarchia
condiviso
Aggregazione
Il processo per cui si calcola una valore di misure a granularità meno fine rispetto a quella dello schema originale
La riduzione del dettaglio avviene risalendo lungo una gerarchia tramite gli operatori standardSUM, MAX, MIN, AVG e COUNT
Possiamo dividere gli operatori in 3 categorie
distributivi
-sempre possibile il calcolo di aggregati a granularità meno fine (max, min, sum)
algebrici
- il calcolo di aggregati a granularità meno fine è possibile solo in presenza di misure aggiuntive (avg, il quale richiede count)
olistici
- non è possibile il calcolo di aggregati da dati a livello di dettaglio maggiore (mediana, moda)
Le misure possono essere:
additive
non additive
non aggregabili
Classificazione delle misure
misure di flusso
- aggregabili mediante tutti gli operatori standard. possono essere valutate cumulativamente alla fine di un periodo di tempo
misure di livello
- valutate in specifici instanti di tempo e non cumulativi lungo il tempo
misure unitarie
- valutate in specifici istanti di tempo e espresse in termini relativi, non additive lungo nessuna direzione
Rappresentazione del tempo
fotografia dell'istante attuale
Sovrascrive il valore dello stato precedente con quello nuovo. Non esistono informazioni rispetto al cambiamento di stato
Eventi attribuiti alla situazione temporalmente corrispondente alla dimensione
In questo caso si creano più istanze dello stesso oggetto. Ad ogni stato è associato un oggetto diverso
Eventi attribuiti alla situazione della dimensione campionata in uno specifico istante
Ovvero, si tiene traccia del diverso stato della situazione (ad ogni campionamento) e quando è necessario sapere lo stato della situazione, si ripercorre temporalmente fino all'istante interessato
Dettagli implementativi
Carico di lavoro
E' definito da una reportistica standard. E' difficile da stimare in progettazione, perché la tipologia di interrogazioni può variare nel tempo e la mole di utenti può aumentare se il sistema ha successo
Volume dei dati
Si può stimare lo spazio necessario al data mart sia per i dati che per le strutture accessorie. A tale scopo si considera il DFM e un numero orientativo di eventi, valori distinti e lunghezza degli attributi. Inoltre dipende dall'intervallo temporale di memorizzazione e dal problema della sparsità.
Sparsità
Si riduce al crescere del livello di aggregazione dei dati, ma può ridurre l'affidabilità della stima!
Progettazione Logica
Schema a stella
E' il naturale schema ROLAP partendo dal DFM
Si riduce lo spazio di memorizzazione, ma aumenta il costo di ricostruzione
Si separano le dipendenze funzionali assegnando a ciascuna dimensione una tabella diversa
Un suo "parente" è lo snowflake schema. Solitamente sconsigliato ma si usa quando porzioni di una gerarchia sono condivise tra più dimensioni
Archi multipli
Si possono realizzare in due modi
bridge table
- si usa una tabella aggiuntiva che modella la relazione molti a molti
push down
- si aggiunge una nuova dimensione alla tabella dei fatti. Questa soluzione è specialmente efficiente quando si devono fare dei join di tabelle piccole con quelle grandi, anzichè fare 3 join di tabelle grandi
Dimensioni degeneri
Sono quelle dimensioni che hanno un unico attributo
Si può
Integrarli nella tabella dei fatti
Creare una
junk dimension
in cui inserire tutte queste dimensioni
Viste materializzate
Scelta delle viste
Vincoli
spazio disponibile
tempo a disposizione per l'aggiornamento
tempo di risposta
freschezza dei dati
Bisogna scegliere la vista che rispetta tutti i vincoli e ha la maggiore efficienza delle esecuzioni richieste, scegliendo così l'insieme ottimo di viste materializzate che minimizzano le funzioni di costo
Sono delle tabelle precalcolate a partire dalla tabella dei fatti e sono memorizzate nel DW allo scopo di aumentare l'efficienza di interrogazioni che richiedono aggregazioni
Una vista materializzata può essere utilizzata per rispondere a più interrogazioni diverse
Progettazione fisica
Caratteristiche del carico di lavoro
Strutture fsiche
caratteristiche dell'ottimizzatore
Procedimento
Selezione delle strutture più adatte per supportare le interrogazioni più frequenti
scelta di strutture in grado di contribuire al miglioramento di più interrogazioni contemporaneamente
vincoli da osservare: spazio su disco e tempo per l'aggiornamento dei dati
Alimentazione del DW
Estrazione
Modalità
incrementale
: selezione degli aggiornamenti avvenuti dopo l'ultima estrazione
E' assistita dall'applicazione: le modifiche sono catturate da specifiche funzioni applicative
Ad esempio con dei trigger
richiede modifiche delle applicazioni OLTP
aumenta il carico applicativo ma è necessario per i sistemi legacy
Si può usare il log
E' basata sui timestamp
statica
: fotografia dei dati operazionali
Dipende dalla natura dei dati operazionali
storicizzati
semi storicizzati
transitori
Pulitura
Ogni problema richiede una tecnica specifica di soluzione
Problema purge/merge
I record duplicati devono essere identificati ed eliminati. E' necessario un criterio per valutare la somiglianza tra due record
Trasformazione
Conversione dei dati dal formato operazionale a quello del DW. Richiede una rappresentazione uniforme dei dati operazionali
