datawarehouse architetture, strumenti etl, modelli dei dati giovanni laboccetta

DatawarehouseArchitetture, strumenti ETL, modelli dei dati

Giovanni Laboccetta

2

Contenuti

Introduzione al data warehousing Architetture per il data warehousing Strumenti ETL Modello multidimensionale Meta-dati

3

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à

4

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

5

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

6

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

7

Sistemi di supporto alle decisioni

Problematiche da affrontareGestione di grandi moli di datiAccesso a diverse fonti su piattaforme

eterogeneeGestione dell’accesso di più utenti per

interrogazioni, analisi in tempo reale e simulazioni

Gestione di versioni storiche dei dati

8

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:

9

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

10

Architetture per il data warehousing

Caratteristiche architetturali irrinunciabiliSeparazione: elaborazione analitica e

transazionale separateScalabilità: 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 accessiAmministrabilità: complessità di

amministrazione non eccessiva

11

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

12

Architettura a un livello

13

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

14

Architettura a due livelli

15

Livello delle sorgenti

Fonti di dati eterogenee

Database aziendali relazionali o legacy

Sistemi informativi esterni all’azienda

16

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)

17

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…

18

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.

19

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

20

Data mart “indipendenti”

21

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

22

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

23

Architetture a tre livelli

24

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)

25

Strumenti ETL

26

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, …

27

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

28

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

29

Esempio pulitura/trasformazione

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

FattoFatto

Processo di business da modellare

DimensioneDimensione

Rappresentazione della granularità

dei fatti

GerarchieGerarchie

Aggregazione delle istanze dei

fatti

MisureMisure

Attributo numerico di un fatto

Esempio di uno schema Esempio di uno schema DFMDFM

33

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

34


Idea base: dati come punti di uno spazio le cui dimensioni corrispondono alle dimensioni d’analisiUn punto rappresenta un evento e viene

descritto tramite un insieme di misure di interesse per il processo decisionale

35


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…)

36


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, modalità

37

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)

Analisi multidimensionale

I dati raccolti vengono visti come un ipercubo in cui ogni dimensione rappresenta una classe di dati

39

Vendite di una catena di negozi

40

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

41

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

42

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

43

Esempio

Prodotto -> Tipo -> CategoriaNegozio -> Citta -> Regione

44

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.

45

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à

46

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

47

Restrizione

Restringere i dati significa ritagliare la porzione di cubo di interesseConcettualmente 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

48

Restrizione

49

Restrizione

La selezione è una generalizzazione dello slicing in cui si esprimono condizioni sugli attributi dimensionaliEsempio: 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 misureEsempio: l’incasso ma non la quantità

50

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

51

Aggregazione

52

Aggregazione

53

Meta-dati

Dati utilizzati per descrivere altri dati Sorgenti, valore, uso e funzioni dei dati del DW, processi di

trasformazione a cui sono sottoposti, etc…

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 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

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 Stranieri Arrivi Stranieri Presenze Totale arrivi presenze

2009Alessandria 01-gen 11791 22300 2897 5794 14688 28094

2009Alessandria 02-feb 13139 24508 2821 6280 15960 30788

2009Alessandria 03-mar 13145 26277 3689 8539 16834 34816

2009Alessandria 04-apr 13167 27413 5036 11420 18203 38833

2009Alessandria 05-mag 15989 38141 7736 17806 23725 55947

2009Alessandria 06-giu 14970 37859 7571 16202 22541 54061

2009Alessandria 07-lug 13974 41530 9850 20902 23824 62432

2009Alessandria 08-ago 13791 46432 10400 23378 24191 69810

2009Alessandria 09-set 15975 45384 8570 19415 24545 64799

2009Alessandria 10-ott 15976 40325 7497 16716 23473 57041

2009Alessandria 11-nov 15169 31007 3843 8784 19012 39791

2009Alessandria 12-dic 13031 22979 2716 5651 15747 28630

2009Alessandria Totale 170117 404155 72626 160887 242743 5650422009Asti 01-gen 2610 6721 784 1867 3394 85882009Asti 02-feb 3147 7914 991 2096 4138 10010

Dimensional Fact Model Flussi Turistici

Star schema

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


Storico_flussi per territorio_2006-2008_dettaglio mesi con settore.csv

ANNO PROVINCIA Settore Mesi

Arrivi - italiani

Presenze - italiani

Arrivi - stranieri

Presenze- stranieri

Arrivi - totale

Presenze - totale

2006ALESSANDRIA Alberghiero 01-gen 351 1257 99 321 450 15782006ALESSANDRIA Alberghiero 02-feb 466 1308 277 1080 743 2388

2006ALESSANDRIA Alberghiero03-

mar 643 1294 143 480 786 1774

2006VERBANO-CUIO-OSSOLA Alberghiero 01-gen 711 4065 71 365 782 4430

2006VERBANO-CUIO-OSSOLA Alberghiero 02-feb 838 2441 159 625 997 3066

2006VERBANO-CUIO-OSSOLA Alberghiero

03-mar 855 2906 413 1180 1268 4086

…. …. …. …. …. …. …. …. …. ….…. …. …. …. …. …. …. …. …. ….

2008VERCELLIExtra-Alberghiero 08-ago 1203 8180 560 1229 1763 9409

2008VERCELLIExtra-Alberghiero 09-set 403 2131 110 533 513 2664

2008VERCELLIExtra-Alberghiero 10-ott 288 1920 26 398 314 2318


FLUSSI TURISTICI PER TERRITORIO - 2009 Dettaglio MESI - Generale con settore.csv

Anno Provincia settore MesiItaliani 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


flussi_turistici_mensile_2010.csv

Anno Provincia Mesi SettoreArrivi - 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


ID NAZIONALITA

1 Italiana

2 Straniera

Insert manuale dim_nazionalita


ID NOME_SETTORE

1 Alberghiero

2 Extra-Alberghiero

Insert manuale dim_settore


dim_periodo


dim_territorio


Fact_flussi_turistici (2006-2008)


Fact_flussi_turistici (2009)


Fact_flussi_turistici (2010)

Definizione del modello multidimensionale

Definizione del modello multidimensionale (mondrian)

Navigazione cubo

datawarehouse architetture, strumenti etl, modelli dei dati giovanni laboccetta

Documents