Introduzione ai Datawarehouse

Datawarehouse
Architetture, strumenti ETL, modelli dei dati
Giovanni Laboccetta
Contenuti





Introduzione al data warehousing
Architetture per il data warehousing
Strumenti ETL
Modello multidimensionale
Meta-dati
2
Introduzione al data warehousing




Inportanza dell’informazione
Dati = Informazione (?)
Data warehouse cerca di utilizzare al meglio i
dati per creare informazione
Senza DW
 Query
complesse scritte da specialisti su db
aziendale
 Lunghi tempi di esecuzione, appesantimento db
aziendale
 Risultati sotto forma di fogli elettronici
 Scarsa flessibilità
3
Introduzione al data warehousing

Idea del DW:
 Separare
operazioni “analitiche” da
“transazionali”
OLAP, On Line Analytical Processing
 OLTP, On Line Transactional Processing

 Raccoglitore
che integri dati elementari da
sorgenti di varia natura
 Organizzazione dei dati adatta ad analisi e
valutazioni finalizzate al processo decisionale
4
Campi di applicazione del DW

Commercio




Analisi vendite e reclami
Controllo spedizioni e inventari
Customer care
Turismo

Controllo flussi turistici
 Supporto strutture ricettive

Servizi finanziari

Analisi del rischio e delle carte di credito
 Rivelazione frodi

Telecomunicazioni


Analisi flusso chiamate e profili clienti
Sanità

Analisi ricoveri e dimissioni
 Contabilità per centri di costo
5
Sistemi di supporto alle decisioni


Insieme di tecniche e strumenti informatici per
estrarre informazioni da dati memorizzati su
supporti elettronici
Ruolo dei sistemi di supporto alle decisioni
Nel passato
Nel futuro
Descrivere il passato
Anticipare il futuro
Descrivere i problemi
Suggerire i cambiamenti
Ridurre i costi
Aumentare i profitti
6
Sistemi di supporto alle decisioni

Problematiche da affrontare
 Gestione
di grandi moli di dati
 Accesso a diverse fonti su piattaforme
eterogenee
 Gestione dell’accesso di più utenti per
interrogazioni, analisi in tempo reale e
simulazioni
 Gestione di versioni storiche dei dati
7
Il processo di data warehousing
Complesso di attività che consente di
trasformare i dati operazionali in
conoscenza a supporto delle decisioni
 Al centro del processo vi è un repository
dei dati che garantisce i seguenti requisiti:

8
Il processo di data warehousing

Requisiti del processo
 Accessibilità
a utenti con conoscenze limitate di
informatica e strutture dati
 Integrazione dei dati sulla base di un modello
standard dell’impresa
 Flessibilità di interrogazione per trarre il massimo
vantaggio dal patrimonio informativo esistente
 Sintesi per permettere analisi mirate ed efficaci
 Rappresentazione multidimensionale per offrire
all’utente una visione intuititva ed efficacemente
manipolabile delle informazioni
 Correttezza e completezza dei dati integrati
9
Architetture per il data warehousing

Caratteristiche architetturali irrinunciabili
 Separazione:
elaborazione analitica e
transazionale separate
 Scalabilità: architettura HW e SW facilmente
ridimensionabile a fronte della crescita di dati
e/o utenti
 Estendibilità: accogliere nuove applicazioni o
tecnologie senza riprogettare il sistema
 Sicurezza: controllo degli accessi
 Amministrabilità: complessità di
amministrazione non eccessiva
10
Architettura a un livello



Minimizzazione dei dati memorizzati
DW virtuale, ossia implementato come vista
multidimensionale dei dati operazionali da un
apposito middleware
Contro
 No
separazione OLAP/OLTP
 Storicizzazione limitata a livello di quella delle
sorgenti

Adatto in casi in cui si hanno esigenze di analisi
limitate o volumi di dati molto ampi
11
Architettura a un livello
12
Architettura a due livelli
Chiamata così per evidenziare
separazione fra livello delle sorgenti e
livello del DW
 In realtà si hanno quattro livelli
corrispondenti a stadi diversi del flusso di
dati

13
Architettura a due livelli
14
Livello delle sorgenti



Fonti di dati
eterogenee
Database aziendali
relazionali o legacy
Sistemi informativi
esterni all’azienda
15
Livello dell’alimentazione



I dati delle sorgenti
devono essere estratti,
ripuliti, completati e
integrati secondo uno
schema comune
Strumenti ETL
(Extraction,
Transformation, Loading)
Problematiche tipiche di
sistemi informativi
distribuiti (gestione dati
inconsistenti e strutture
dati incompatibili)
16
Livello del warehouse



Informazioni raccolte in un
singolo contenitore
centralizzato: il DW
DW consultabile direttamente
o usato per costruire data mart
(parziale replica orientata
verso specifiche aree
dell’azienda)
Il contenitore di meta-dati
contiene informazioni su:
sorgenti, meccanismi di
accesso, procedure pulitura e
alimentazione, utenti, schemi
data mart, etc…
17
Livello di analisi



Consultazione efficiente e
flessibile dei dati integrati
Reportistica, analisi,
simulazioni, etc…
Utilizzate tecniche per:
ottimizzazione
interrogazioni complesse,
indicizzazioni avanzate,
interfacce visuali
amichevoli.
18
Data mart “dipendenti”



DW primario o aziendale è il “contenitore” centrale
DM sono DW “locali” che replicano, ed eventualmente
sintetizzano ulteriormente, la porzione di DW primario di
interesse per una particolare area applicativa
Anche se non strettamente necessari i DM sono molto
utili in realtà medio-grandi:



Come blocchi costruttivi durante la realizzazione incrementale
del DW
Perché delineano i contorni delle informazioni necessarie a un
particolare tipo di utenti
Perché permettono di raggiungere prestazioni migliori essendo
di dimensioni inferiori al DW primario
19
Data mart “indipendenti”
20
Architettura a due livelli: motivazioni





A livello del warehouse è sempre disponibile
informazione di buona qualità, indipendentemente dalla
disponibilità delle sorgenti
L’interrogazione effettuata sul DW non interferisce con la
gestione delle transazioni a livello operazionale
L’organizzazione logica del DW è basata su modello
multidimensionale mentre le sorgenti offrono in genere
modelli relazionali
Differenza temporale e di granularità fra OLTP (dati
correnti e al massimo livello di dettaglio) e OLAP (dati
storici e di sintesi)
A livello di DW si possono usare tecniche specifiche per
ottimizzare analisi e reportistica
21
Architettura a tre livelli



Introduce il livello dei dati riconciliati che contiene dati integrati,
consistenti, corretti, volatili, correnti e dettagliati
Il DW viene alimentato non dalle sorgenti ma dai dati riconciliati
Vantaggi:
Crea un modello dei dati comune e di riferimento per l’intera azienda
 Separazione fra estrazione, integrazione e pulitura e alimentazione del
DW


Svantaggi

Introduzione di ulteriore ridondanza
Note: esistono anche architetture ibride oltre quella a uno e due/tre
livelli in cui alcune interrogazioni vengono fatte nel DW e altre
ricondotte alle sorgenti operazionali
22
Architetture a tre livelli
23
Strumenti ETL




Alimentano il DW o il livello dei dati riconciliati. Le
operazioni svolte vengono chiamate riconciliazione
La riconciliazione è fra le fasi più impegnative del
processo di warehousing
La riconciliazione avviene quando il DW viene popolato
per la prima volta e, periodicamente, quando viene
aggiornato
La riconciliazione è composta da quattro processi:




Estrazione (extraction, capture)
Pulitura (cleaning, cleansing, scrubbing)
Trasformazione (transformation)
Caricamento (loading)
24
Strumenti ETL
25
Estrazione





Dati rilevanti estratti dalle sorgenti
Estrazione statica: fatta solo la prima volta, cattura tutti
dati operazionali
Estrazione incrementale: usata per l’aggiornamento
periodico, cattura solo le variazioni rispetto all’ultima
estrazione (può usare il log del DBMS operazionale)
L’estrazione può essere guidata dalle sorgenti (se le
applicazioni notificano variazioni ai dati) o da trigger del
DB operazionale
La scelta dei dati da estrarre avviene in base alla loro
qualità che dipende da vincoli, formato dei dati,
chiarezza degli schemi, …
26
Pulitura

Migliorare la qualità dei dati eliminando la sporcizia:









Dati duplicati
Inconsistenza fra valori logicamente associati
Dati mancanti
Uso non previsto di un campo
Valori impossibili o errati
Valori inconsistenti per la stessa entità dovuti a diverse
convenzioni o abbreviazioni
Valori inconsistenti per la stessa entità dovuti ad errori di
battitura
Correzione ed omogeneizzazione basata su dizionari per
correggere errori e riconoscere sinonimi
Pulitura basata su regole che applica regole proprie del
dominio applicativo
27
Trasformazione


Converte i dati dal formato operazionale
sorgente a quello del DW
Situazioni critiche da correggere:
 Testi
liberi che nascondono informazioni importanti
 Uso di formati differenti per lo stesso tipo di dato

Fasi della trasformazione
 Conversione,
normalizzazione e matching
 Denormalizzazione e aggregazione

Pulitura e trasformazione sono spesso allacciate
e sovrapposte
28
Esempio pulitura/trasformazione
29
Un modello concettuale per i DW
Per i DBMS relazionali viene usato il modello Entity/Relatioship
(E/R)
Non utilizzabile per i DW perché:
1. I DW utilizzano una visione multidimensionale dei dati, mentre
l'E/R propone una visione piatta degli stessi
2. Non risulta semplice formulare le interrogazioni sullo schema
E/R
3. Il modello E/R è difficilmente comprensibile dai non addetti ai
lavori, quindi non rende semplice il dialogo tra progettista ed
utente
4. L'E/R produce una documentazione non sempre priva di
ambiguità e non sempre sufficientemente espressiva
Dimensional Fact Model (DFM)
Modello
Multidimensionale
Fatto
Dimensione
Gerarchie
Misure
Processo di
business da
modellare
Rappresentazione
della granularità
dei fatti
Aggregazione
delle istanze dei
fatti
Attributo numerico
di un fatto
Esempio di uno schema DFM
Modello multidimensionale
Modello di rappresentazione dei dati molto
diffuso nei DW
 Semplice e intuitivo anche per non esperti
di informatica
 Si presta a interrogazioni orientate al
processo decisionale

33
Modello multidimensionale

Idea base: dati come punti di uno spazio
le cui dimensioni corrispondono alle
dimensioni d’analisi
 Un
punto rappresenta un evento e viene
descritto tramite un insieme di misure di
interesse per il processo decisionale
34
Modello multidimensionale



Gli oggetti che influenzano le decisioni sono fatti
del mondo aziendale (vendite, spedizioni,
ricoveri, interventi chirurgici, etc…)
Le occorrenze di un fatto sono eventi accaduti
(le singole vendite o spedizioni, etc…)
Per ciascun fatto interessano i valori di un
insieme di misure che descrivono gli eventi
(l’incasso di una vendita, la quantità spedita, la
durata di un intervento chirurgico, etc…)
35
Modello multidimensionale


Per analizzare i numerosissimi eventi che
accadono si immagina di collocarli in uno spazio
n-dimensionale i cui assi, le cosiddette
dimensioni di analisi, definiscono diverse
prospettive.
Esempi:
 Le
vendite di una catena di negozi possono essere
collocate in uno spazio 3-d con dimensioni prodotto,
negozio, data
 I ricoveri sono nello spazio reparto, data, paziente
 Le spedizioni possono essere nello spazio con
dimensioni prodotto, data, ordine, destinazione,
36
modalità
La metafora del cubo



Gli eventi corrispondono a celle di un cubo (o
ipercubo) i cui spigoli rappresentano le
dimensioni di analisi
Ogni cella del cubo contiene un valore per
ciascuna misura
Il cubo è sparso dato che molti eventi possibili
non si verificano (ad esempio la vendita di un
certo prodotto un certo giorno in un certo
negozio non è detto che si verifichi)
37
Analisi multidimensionale
I dati raccolti vengono visti come un ipercubo in cui ogni
dimensione rappresenta una classe di dati
Vendite di una catena di negozi
39
Rappresentazione di cubi nel modello
relazionale




Si può pensare di rappresentare un cubo con
una relazione avente per attributi tutte le
dimensioni e le misure e per tuple gli eventi
Le dimensioni costituiscono la chiave primaria
C’è una dipendenza funzionale fra le dimensioni
e le misure
Esempio:
VENDITE(negozio, prodotto, data, quantità, incasso)
negozio, prodotto, data -> quantità, incasso
40
Eventi del modello ed eventi del
dominio applicativo




L’insieme delle dimensioni scelte per rappresentare i fatti
identifica eventi del modello multidimensionale ma non
necessariamente del dominio applicativo
Ad esempio nel dominio applicativo un evento di vendita
corrisponde all’acquisto di prodotti da parte di un cliente
(vendita ≈ scontrino)
Nel modello multidimensionale l’evento corrisponde al
venduto giornaliero di un certo prodotto in un certo
negozio in una certa data
L’evento del modello multidimensionale contiene quindi
informazioni aggregate rispetto ai dati operazionali
41
Gerarchie delle dimensioni e livelli di
aggregazione




Ciascuna dimensione è associata a una
gerarchia di livelli di aggregazione (gerarchia di
roll-up)
I livelli che compongono la gerarchia si dicono
attributi dimensionali
In cima a ciascuna gerarchia c’è un livello fittizio
che raggruppa tutti i valori di una dimensione
Una gerarchia è esprimibile nel modello
relazionale con un insieme di dipendenze
funzionali fra attributi dimensionali
42
Esempio
Prodotto -> Tipo -> Categoria
Negozio -> Citta -> Regione
43
Cubo multidimensionale

Un cubo multidimensionale è incentrato su
un fatto di interesse per il processo
decisionale. Esso rappresenta un insieme
di eventi, descritti quantitativamente da
misure numeriche. Ogni asse del cubo
rappresenta una possibile dimensione di
analisi; ciascuna dimensione può essere
vista a più livelli di dettaglio individuati da
attributi strutturati in gerarchie.
44
Terminologia alternativa





Fatto e cubo sono usati intercambiabilmente
Alcuni chiamano dimensioni le intere gerarchie
Le misure sono anche chiamate variabili,
metriche, proprietà, attributi, indicatori
Gli attributi dimensionali sono anche chiamati
livelli o parametri
A seconda del contesto comunque non
dovrebbero esserci ambiguità
45
Accesso ai cubi


Le informazioni nel cubo sono una sintesi dei dati
operazionali ma ancora poco fruibili perché troppo
numerosi
Esempio:

3 anni di transazioni (1000 giorni) per 50 negozi e 1000 prodotti



5 x 107 eventi possibili!
Anche supponendo che i negozi vendano giornalmente solo 100
prodotti diversi restano sempre 5 x 106 eventi da analizzare
Si riduce la quantità di dati (e si ottengono quindi
informazioni utili) utilizzando due tecniche:


Restrizione
Aggregazione
46
Restrizione

Restringere i dati significa ritagliare la
porzione di cubo di interesse
 Concettualmente
simile a selezioni e
proiezioni dell’algebra relazionale

Caso più comune è lo slicing in cui si
riduce la dimensionalità fissando un valore
per una o più dimensioni
47
Restrizione
48
Restrizione

La selezione è una generalizzazione dello
slicing in cui si esprimono condizioni sugli
attributi dimensionali
 Esempio:
la selezione delle vendite del
detersivo Brillo nei negozi di Bologna nei
giorni di Gennaio produce una matrice
bidimensionale facilmente analizzabile

La proiezione è la scelta di mantenere per
ciascun evento solo alcune misure
 Esempio:
l’incasso ma non la quantità
49
Aggregazione

Meccanismo che permette di raggruppare in base a
qualche criterio le celle del cubo




Esempio: analisi delle vendite non a livello giornaliero ma
mensile. Bisogna raggruppare tutte le celle di ciscun mese in
un’unica macro-cella.
Cambia la granularità della dimensione su cui si è
raggruppato
L’evento alla nuova granularità contiene la sintesi degli
eventi che aggrega
Si può aggregare ulteriormente sul tempo o su altre
dimensioni o combinare aggregazione e selezione

Esempio: analisi delle vendite per città nei soli mesi estivi
50
Aggregazione
51
Aggregazione
52
Meta-dati

Dati utilizzati per descrivere altri dati


Meta-dati interni: di interesse per l’amministratore



Sorgenti, trasformazioni, politiche, schemi logici e fisici, vincoli,
profili utenti, etc…
Meta-dati esterni: di interesse per gli utenti


Sorgenti, valore, uso e funzioni dei dati del DW, processi di
trasformazione a cui sono sottoposti, etc…
Definizioni dei dati, qualità, unità di misura, aggregazioni
significative, etc…
Fondamentali per interoperabilità di diversi sistemi di DW
Formati standard per i meta-dati basati su XML
53
Caso di studio: monitoraggio flussi turistici
Progettazione di un DM per monitorare i
flussi turistici del piemonte
 Disponibilità di dati in file csv nel periodo
2006-2010
 I dati sono per provincia, per mese e per
settore (alberghiero, extra albeghiero)
 Sono distinti per arrivi e presenze di
italiani e stranieri

Caso di studio: monitoraggio flussi turistici
Porzione del contenuto di un file dati (CSV)
Anno
Provincia
Mesi
Italiani Arrivi
Italiani Presenze
Totale arrivi
presenze
2009 Alessandria
01-gen
11791
22300
2897
5794
14688
28094
2009 Alessandria
02-feb
13139
24508
2821
6280
15960
30788
2009 Alessandria
03-mar
13145
26277
3689
8539
16834
34816
2009 Alessandria
04-apr
13167
27413
5036
11420
18203
38833
2009 Alessandria
05-mag
15989
38141
7736
17806
23725
55947
2009 Alessandria
06-giu
14970
37859
7571
16202
22541
54061
2009 Alessandria
07-lug
13974
41530
9850
20902
23824
62432
2009 Alessandria
08-ago
13791
46432
10400
23378
24191
69810
2009 Alessandria
09-set
15975
45384
8570
19415
24545
64799
2009 Alessandria
10-ott
15976
40325
7497
16716
23473
57041
2009 Alessandria
11-nov
15169
31007
3843
8784
19012
39791
2009 Alessandria
12-dic
13031
22979
2716
5651
15747
28630
01-gen
02-feb
170117
2610
3147
404155
6721
7914
72626
784
991
160887
1867
2096
242743
3394
4138
565042
8588
10010
2009 Alessandria
2009 Asti
2009 Asti
Totale
Stranieri Arrivi Stranieri Presenze
Dimensional Fact Model Flussi Turistici
Star schema
Definizione in Access
Definizione in Access
Definizione in Access
Definizione in Access
Definizione in Access
Definizione in Access
Definizione in Access
Definizione in MYSQL
Analisi delle sorgenti
• Analisi delle sorgenti
• Progettazione delle regole di popolamento
• Individuazione delle trasformazioni e delle
attività di cleaning sui dati
• Sviluppo del processo di ETL tramite PDI
ETL con Pentaho Data Integration
• formato in input: file CSV
• Storico_flussi per territorio_2006-2008_dettaglio mesi con settore.csv
• FLUSSI TURISTICI PER TERRITORIO - 2009 Dettaglio MESI - Generale con settore.csv
• flussi_turistici_mensile_2010.csv
Analisi delle sorgenti
Storico_flussi per territorio_2006-2008_dettaglio mesi con settore.csv
ANN
O
PROVINCIA
Settore
2006ALESSANDRIA Alberghiero
2006ALESSANDRIA Alberghiero
2006ALESSANDRIA
VERBANO2006 CUIO-OSSOLA
VERBANO2006 CUIO-OSSOLA
VERBANO2006 CUIO-OSSOLA
….
….
….
….
2008VERCELLI
2008VERCELLI
2008VERCELLI
Alberghiero
Arrivi - Presenze Arrivi PresenzeArrivi - Presenze Mesi italiani
italiani
stranieri
stranieri
totale
totale
01-gen
351
1257
99
321
450
1578
02-feb
466
1308
277
1080
743
2388
03mar
643
1294
143
480
786
1774
Alberghiero
01-gen
711
4065
71
365
782
4430
Alberghiero
02-feb
03mar
….
….
838
2441
159
625
997
3066
855
2906
413
1180
1268
….
….
4086
Alberghiero
….
….
ExtraAlberghiero
ExtraAlberghiero
ExtraAlberghiero
….
….
….
….
….
….
….
….
….
….
08-ago
1203
8180
560
1229
1763
9409
09-set
403
2131
110
533
513
2664
10-ott
288
1920
26
398
314
2318
Analisi delle sorgenti
FLUSSI TURISTICI PER TERRITORIO - 2009 Dettaglio MESI - Generale con settore.csv
Anno
Provincia
settore
Mesi
Italiani
Arrivi
Italiani
Presenze
Stranieri
Arrivi
Stranieri
Presenze
Totale arrivi
Totale presenze
2009Alessandria Alberghiero
01-gen
8253,7
15610
2027,9
4055,8
10281,6
19665,8
2009Alessandria Alberghiero
02-feb
9197,3
17155,6
1974,7
4396
11172
21551,6
2009Alessandria Alberghiero
03-mar
9201,5
18393,9
2582,3
5977,3
11783,8
24371,2
2009Alessandria Alberghiero
04-apr
9216,9
19189,1
3525,2
7994
12742,1
27183,1
Analisi delle sorgenti
flussi_turistici_mensile_2010.csv
Anno
Provincia
Mesi
Settore
Arrivi italiani
Presenze italiani
Arrivi stranieri
Presenze stranieri
Arrivi totale
Presenze totale
2010ALESSANDRIA
01-genAlberghiero
10581
19153
2882
6202
13463
25355
2010ALESSANDRIA
02-febAlberghiero
11579
20909
2814
6014
14393
26923
2010ALESSANDRIA
03-marAlberghiero
13397
23941
3534
7451
16931
31392
2010ALESSANDRIA
04-aprAlberghiero
13861
28320
6782
13557
20643
41877
2010ALESSANDRIA
05-magAlberghiero
15620
35046
9264
17728
24884
52774
ETL con Pentaho Data Integration
Insert manuale dim_nazionalita
ID
NAZIONALITA
1
Italiana
2
Straniera
ETL con Pentaho Data Integration
Insert manuale dim_settore
ID
NOME_SETTORE
1
Alberghiero
2
Extra-Alberghiero
ETL con Pentaho Data Integration
dim_periodo
ETL con Pentaho Data Integration
dim_territorio
ETL con Pentaho Data Integration
Fact_flussi_turistici (2006-2008)
ETL con Pentaho Data Integration
Fact_flussi_turistici (2009)
ETL con Pentaho Data Integration
Fact_flussi_turistici (2010)
Definizione del modello multidimensionale
Definizione del modello multidimensionale
(mondrian)
Navigazione cubo