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

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à

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

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

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

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

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:

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

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

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

Architettura a un livello

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

Architettura a due livelli

Livello delle sorgenti Fonti di dati eterogenee Database aziendali relazionali o legacy Sistemi informativi esterni all’azienda

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)

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…

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.

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

Data mart “indipendenti”

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

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

Architetture a tre livelli

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)

Strumenti ETL

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

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

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

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é: I DW utilizzano una visione multidimensionale dei dati, mentre l'E/R propone una visione piatta degli stessi Non risulta semplice formulare le interrogazioni sullo schema E/R Il modello E/R è difficilmente comprensibile dai non addetti ai lavori, quindi non rende semplice il dialogo tra progettista ed utente L'E/R produce una documentazione non sempre priva di ambiguità e non sempre sufficientemente espressiva

Dimensional Fact Model (DFM) Modello Multidimensionale Fatto Processo di business da modellare Dimensione Rappresentazione della granularità dei fatti Gerarchie Aggregazione delle istanze dei fatti Misure Attributo numerico di un fatto

Esempio di uno schema DFM Attributo non dimensionale Fatto Mese Semestre Anno Stabilimento Città Regione Nazione Categoria Tipo di Bene Analisi della Concorrenza Q.tà Venduta Investimenti Fatturato Indirizzo Gerarchie Attributo dimensionale Misure Dimensioni

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

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

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

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

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

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

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

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

Esempio Prodotto -> Tipo -> Categoria Negozio -> Citta -> Regione

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.

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à

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

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

Restrizione

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à

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

Aggregazione

Aggregazione

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 2009 Alessandria 01-gen 11791 22300 2897 5794 14688 28094 02-feb 13139 24508 2821 6280 15960 30788 03-mar 13145 26277 3689 8539 16834 34816 04-apr 13167 27413 5036 11420 18203 38833 05-mag 15989 38141 7736 17806 23725 55947 06-giu 14970 37859 7571 16202 22541 54061 07-lug 13974 41530 9850 20902 23824 62432 08-ago 13791 46432 10400 23378 24191 69810 09-set 15975 45384 8570 19415 24545 64799 10-ott 15976 40325 7497 16716 23473 57041 11-nov 15169 31007 3843 8784 19012 39791 12-dic 13031 22979 2716 5651 15747 28630 Totale 170117 404155 72626 160887 242743 565042 Asti 2610 6721 784 1867 3394 8588 3147 7914 991 2096 4138 10010

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 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 ANNO PROVINCIA Settore Mesi Arrivi - italiani Presenze - italiani Arrivi - stranieri Presenze- stranieri Arrivi - totale Presenze - totale 2006 ALESSANDRIA Alberghiero 01-gen 351 1257 99 321 450 1578 02-feb 466 1308 277 1080 743 2388 03-mar 643 1294 143 480 786 1774 VERBANO-CUIO-OSSOLA 711 4065 71 365 782 4430 838 2441 159 625 997 3066 855 2906 413 1180 1268 4086 …. 2008 VERCELLI Extra-Alberghiero 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 2009 Alessandria Alberghiero 01-gen 8253,7 15610 2027,9 4055,8 10281,6 19665,8 02-feb 9197,3 17155,6 1974,7 4396 11172 21551,6 03-mar 9201,5 18393,9 2582,3 5977,3 11783,8 24371,2 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 2010 ALESSANDRIA 01-gen Alberghiero 10581 19153 2882 6202 13463 25355 02-feb 11579 20909 2814 6014 14393 26923 03-mar 13397 23941 3534 7451 16931 31392 04-apr 13861 28320 6782 13557 20643 41877 05-mag 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