Datawarehouse Architetture, strumenti ETL, modelli dei dati

Presentazione sul tema: "Datawarehouse Architetture, strumenti ETL, modelli dei dati"— Transcript della presentazione:

1 Datawarehouse Architetture, 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 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

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

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

30 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

31 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

32 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

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

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

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

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)

38 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 -> Categoria
Negozio -> 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 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

48 Restrizione

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

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

54 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 I dati sono per provincia, per mese e per settore (alberghiero, extra albeghiero) Sono distinti per arrivi e presenze di italiani e stranieri

55 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

56 Dimensional Fact Model Flussi Turistici

57 Star schema

58 Definizione in Access

59 Definizione in Access

60 Definizione in Access

61 Definizione in Access

62 Definizione in Access

63 Definizione in Access

64 Definizione in Access

65 Definizione in MYSQL

66 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

67 ETL con Pentaho Data Integration
formato in input: file CSV Storico_flussi per territorio_ _dettaglio mesi con settore.csv FLUSSI TURISTICI PER TERRITORIO Dettaglio MESI - Generale con settore.csv flussi_turistici_mensile_2010.csv

68 Analisi delle sorgenti
Storico_flussi per territorio_ _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

69 Analisi delle sorgenti
FLUSSI TURISTICI PER TERRITORIO 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

70 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

71 ETL con Pentaho Data Integration
Insert manuale dim_nazionalita ID NAZIONALITA 1 Italiana 2 Straniera

72 ETL con Pentaho Data Integration
Insert manuale dim_settore ID NOME_SETTORE 1 Alberghiero 2 Extra-Alberghiero

73 ETL con Pentaho Data Integration
dim_periodo

74 ETL con Pentaho Data Integration
dim_territorio

75 ETL con Pentaho Data Integration
Fact_flussi_turistici ( )

76 ETL con Pentaho Data Integration
Fact_flussi_turistici (2009)

77 ETL con Pentaho Data Integration
Fact_flussi_turistici (2010)

78 Definizione del modello multidimensionale

79 Definizione del modello multidimensionale (mondrian)

80 Navigazione cubo