La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Datawarehouse Architetture, strumenti ETL, modelli dei dati Giovanni Laboccetta.

Presentazioni simili


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

1 Datawarehouse Architetture, strumenti ETL, modelli dei dati Giovanni Laboccetta

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

3 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 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 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 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 passatoNel futuro Descrivere il passatoAnticipare il futuro Descrivere i problemiSuggerire i cambiamenti Ridurre i costiAumentare i profitti

7 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 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 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 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 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 12 Architettura a un livello

13 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 14 Architettura a due livelli

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

16 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 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 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 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 20 Data mart “indipendenti”

21 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 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 23 Architetture a tre livelli

24 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 25 Strumenti ETL

26 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 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 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 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é: 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

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

33 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 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 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 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 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 39 Vendite di una catena di negozi

40 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 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 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 43 Esempio Prodotto -> Tipo -> Categoria Negozio -> Citta -> Regione

44 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 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 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 10 7 eventi possibili!  Anche supponendo che i negozi vendano giornalmente solo 100 prodotti diversi restano sempre 5 x 10 6 eventi da analizzare Si riduce la quantità di dati (e si ottengono quindi informazioni utili) utilizzando due tecniche:  Restrizione  Aggregazione

47 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 48 Restrizione

49 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 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 51 Aggregazione

52 52 Aggregazione

53 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) AnnoProvinciaMesiItaliani ArriviItaliani PresenzeStranieri ArriviStranieri Presenze Totale arrivi presenze 2009Alessandria01-gen Alessandria02-feb Alessandria03-mar Alessandria04-apr Alessandria05-mag Alessandria06-giu Alessandria07-lug Alessandria08-ago Alessandria09-set Alessandria10-ott Alessandria11-nov Alessandria12-dic AlessandriaTotale Asti01-gen Asti02-feb

56 Dimensional Fact Model Flussi Turistici

57 Star schema

58 Definizione in Access

59

60

61

62

63

64

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 ANN OPROVINCIASettoreMesi Arrivi - italiani Presenze - italiani Arrivi - stranieri Presenze- stranieri Arrivi - totale Presenze - totale 2006ALESSANDRIAAlberghiero01-gen ALESSANDRIAAlberghiero02-feb ALESSANDRIAAlberghiero 03- mar VERBANO- CUIO-OSSOLAAlberghiero01-gen VERBANO- CUIO-OSSOLAAlberghiero02-feb VERBANO- CUIO-OSSOLAAlberghiero 03- mar …. 2008VERCELLI Extra- Alberghiero08-ago VERCELLI Extra- Alberghiero09-set VERCELLI Extra- Alberghiero10-ott

69 Analisi delle sorgenti FLUSSI TURISTICI PER TERRITORIO Dettaglio MESI - Generale con settore.csv AnnoProvinciasettoreMesi Italiani Arrivi Italiani Presenze Stranieri Arrivi Stranieri Presenze Totale arrivi Totale presenze 2009AlessandriaAlberghiero01-gen8253, ,94055,810281,619665,8 2009AlessandriaAlberghiero02-feb9197,317155,61974, ,6 2009AlessandriaAlberghiero03-mar9201,518393,92582,35977,311783,824371,2 2009AlessandriaAlberghiero04-apr9216,919189,13525, ,127183,1

70 Analisi delle sorgenti flussi_turistici_mensile_2010.csv AnnoProvinciaMesiSettore Arrivi - italiani Presenze - italiani Arrivi - stranieri Presenze - stranieri Arrivi - totale Presenze - totale 2010ALESSANDRIA01-genAlberghiero ALESSANDRIA02-febAlberghiero ALESSANDRIA03-marAlberghiero ALESSANDRIA04-aprAlberghiero ALESSANDRIA05-magAlberghiero

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

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

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


Scaricare ppt "Datawarehouse Architetture, strumenti ETL, modelli dei dati Giovanni Laboccetta."

Presentazioni simili


Annunci Google