6. DW_architettura

Argomenti
Business Intelligence
Data warehouse- Architettura Progettazione
!  Architettura
e componenti di un
datawarehouse
!  Costruzione della base di dati per il
datawarehouse
!  Progettazione di un data warehouse
Federica Cena
Architettura di un
datawarehouse
2
Componenti di un dw
Due funzioni principali:
Prendere le informazioni dai sistemi operazionali,
“pulirle” e metterle dentro il dw
2.  Prendere le informazioni dal dw e presentarle
all’utente
1. 
4
Federica Cena-
1
Componenti
Architettura di un dw
Presentation component (interfacce utente)
Aggregatori (operatori OLAP e data mining)
-------------------------------------------------- Warehouse database
-------------------------------------------------!  Integration component (integra dati di diverso
formato e semantica)
!  Extraction component (estrae i dati dai db)
-------------------------------------------------- OLPT databases
--------------------------------------------------
!  segmentazione:
! 
classi
! 
raggruppamento in
5
6
7
8
Federica Cena-
2
DW: cos’è
Costruire il db per il
datawarehose
Data base con le caratteristiche:
!  Subject oriented (dati sono organizzati per
soggetti, come le vendite, invece che processo:
processo degli ordini)
!  Non volatile (i dati una volta messi nel data
base non sono poi soggetti a cambiamento)
!  Integrato (i dati sono consistenti, ossia nello
stesso formato)
!  Time variant (sono memorizzati dati storici.
Tutte le query hanno un elemento tempo
associato). Non possiamo sapere cosa accadrà in
futuro se nn conosciamo il passato
10
Federica Cena-
Costruzione del dw
Query SQL
Dw deve essere separato dal db:
!  Concettualmente diversi
!  Db cambia sempre
!  Db ha complesse relazioni: per ottenere le
informazioni aggregate necessarie molte
operazioni di join
Select nome, sum(quantity), sum(itemCost)
From customerOrder a
orderItem b,
product c
Where a.orderCode = b.oderCode &
a.ProductCode = b.ProductCode &
orderDate = <today_date>
Group by name
11
Federica Cena-
12
Federica Cena-
3
Query SQL
Se questa query viene eseguita alla fine della
giornata, abbiamo il valore degli ordini del giorno.
Ma abbiamo bisogno del TREND.
Dobbiamo eseguirla ogni giorno, e append
(aggiungere come riga, non sovrascrivere) a una
nuova tabella, in modo da costruire l’info storica
che serve
INIZIO DI UN DATA WAREHOUSE
13
14
Federica Cena-
Problemi di sql
Problemi di sql
Time: dati non sovrascritti " ampia mole di dati,
risposte alle query sono lente..
Basato sulla teoria degli insiemi: le tabelle
sono insiemi, nell’algebra relazionale non
si possono:
Soluzione fare un cubo dei dati precalcolati su tutte
le dimensioni
1. 
2. 
aggregazione cliente x prodotti per ciascun mese,
aggregazioni di prodotto per area x ciascun mese
1. 
2. 
3. 
Ordinare gli item
Includere variabili
Funzioni matematiche complesse
" necessario fare dei programmi procedurali che
incorporano sql per manipolare DW
15
Federica Cena-
16
Federica Cena-
4
Warehouse database
Data normalisation
Struttura concettuale: Schema a stella o a fiocco di
neve
Obiettivo:
Stars
snowflakes
denormalizzato
normalizzato
Simple
Flat (no gerarchia)
More complex
Gerarchico (naturale
modo di pensare dei
manager)
(+) piu veloci le query
(–) piu spazio in
memoria
(-) piu lente le query
(+) aggiornamenti a
catena
(+) occupa meno spazio
1. 
Eliminare le duplicazioni non necessarie e
incontrollate di dati (ridondanze)
2. 
Eliminare le dipendenze funzionali tra gli
attributi
17
Federica Cena-
18
Federica Cena-
1) Modello a stella
Data normalisation
Dipendenze funzionali
X" y il valore di y dipende da x
citta" regione il valore di regione dipende da citta’
cliente(citta, regione)
Ogni volta che due clienti vivono nella stesso città, allora
vivono anche la stessa regione
citta[torino]=regione[piemonte]
19
20
Federica Cena-
5
Modello a sowflakes implementato
Warehouse database
1. 
Tabella al centro dei fatti, sui cui vengono
eseguite tutte le query
Relazione 1:m con le altre dimensioni (parte m: tabella dei
fatti, parte 1 dimensione)
2. 
3. 
4. 
Time dimension obbligatori
Una misura singola non interessa: Le misure
devono essere sommabili, solo su alcune
dimensioni ha senso:costo ha senso su prodotti,
ma non su tempo (attributi semisommab)
Aggiungere dati ai precedenti (accodarli) non
sovrascriverli
21
22
Federica Cena-
Progettazione di un
datawarehouse
Sviluppo di un dw
1. 
2. 
3. 
4. 
5. 
6. 
7. 
Analisi e riconciliazione delle fonti "
schema riconciliato + requisiti (obiettivi
strategici)
Analisi dei requisiti
Progettazione concettuale " schema di fatto
Validazione dello schema concettuale
Progettazione logica " schema logico
Progettazione dell’alimentazione
Progettazione fisica " procedure di
indicizzazione e di memorizzazione
24
Federica Cena-
6
Approcci
1. 
2. 
Analisi e riconciliazione
Guidato dai dati (bottom-up)
Guidato dai requisiti (top-down)
1. 
Analisi e riconciliazione delle fonti "
schema riconciliato + requisiti (obiettivi
strategici)
1. 
! 
! 
! 
! 
Definizione degli obiettivi
Progettazione dell’infrastruttura
Progettazione del dw
Sviluppo dei data mart
2. 
3. 
Premesse: non tutti i dati che abbiamo ci
interessano
Alcuni dati sono disallienati
Per ogni fonte disponibie:
1. 
2. 
Passo 1: modello E-R (schema locale)
Passo 2: portare allo schema riconciliato (solo ciò
che serve al db)
25
26
Federica Cena-
Federica Cena-
Analisi e riconciliazione
1. 
Analisi e riconciliazione
Possibili relazioni tra R1 e R2
1. 
2. 
3. 
4. 
1. 
Identità
Equivalenza
Comparabilità
Incompatibilità " analisi dei possibili conflitti
Possibili conflitti tra schemi
1. 
2. 
Eterogeneità
Conflitti
1. 
Di nome
1.  Omonimie
2.  Sinonime
2. 
3. 
Semantici
strutturali
27
Federica Cena-
28
Federica Cena-
7
Processo di riconciliazione
Euristiche:
1.  Riconosco la diversità
2.  Opero una fusione
" schema riconciliato
1. 
2. 
3. 
Completezza
Minimalità
leggibilità
29
Federica Cena-
8

Download Report