Corso di Complementi di Basi di dati A.A Data Warehouse

Transcript

1 Riferimenti Corso di Complementi di Basi di dati A.A Data Warehouse Queste trasparenze parte 4 Testo di Atzeni et al. Basi di dati R.Kimball, The Data Warehouse Lifecycle Toolkit, 2nd Ed., Wiley, 2003 M. Golfarelli, S. Rizzi Data Warehouse, seconda edizione, McGraw Hill, /24/ Sommario 1. Introduzione: On Line Transaction Processing e On Line Analytical Processing 2. Data warehouse: generalita Processo di generazione, struttura di un data warehouse e modelli per la sua descrizione: il modello star schema e il modello cube 3. Il modello star schema: struttura e operazioni 4. Il modello data cube: struttura e operazioni 5. Un esempio 6. Progettazione di data warehouse - Fasi - Progettazione concettuale - Cenni alla progettazione logico fisica 1. Introduzione: On Line Transaction Processing e On Line Analytical Processing 1/24/ /24/ Processi di una organizzazione classificazione Processi di una organizzazione Decisionali: Per le decisioni a lungo termine, fortemente integrati. Es. processi di decisione di apertura di nuovi punti vendita processi decisionali processi decisionali processi gestionali processi operativi Gestionali: per il controllo dei processi operativi, settoriali Es. analisi degli scostamenti a breve termine tra costi e ricavi Operativi, per costruire prodotti e servizi nella catena di fornitura, molto specifici Es. prenotazione di un viaggio in treno processi gestionali processi operativi 1/24/ /24/

2 On Line Transaction Processing Tradizionale elaborazione di transazioni, che realizzano i processi operativi dell azienda-ente Operazioni predefinite e relativamente semplici Ogni operazione coinvolge pochi dati Queries senza aggregazioni o con aggregazioni semplici Es. Prenotazioni online, ricerche per chiave Dati elementari, aggiornati Frequenti, molti utenti Le proprietà ACID (atomicità, correttezza, isolamento, durabilità) delle transazioni sono essenziali Ottimizzano il throughput di transazioni di lettura e scrittura in presenza di concorrenza Sistemi di supporto alle decisioni Richiedono operazioni non previste a priori Coinvolgono spesso grandi quantità di dati, anche storici e aggregati Coinvolgono dati provenienti da varie fonti, anche esterne processi decisionali processi gestionali processi operativi Istat 1/24/ /24/ On Line Analytical Processing Elaborazione di operazioni per i processi decisionali Operazioni complesse e casuali Queries con aggregazioni contemporanee su piu dimensioni Es.: totale posti prenotati aggregati per regione e per tipo di cliente, oppure totale posti prenotati per periodo e per agenzia Ogni operazione può coinvolgere molti dati Dati aggregati, storici, anche non attualissimi Utenti selezionati Le proprietà ACID non sono rilevanti, perché le operazioni sono di sola lettura OLTP e OLAP I requisiti sono quindi contrastanti Le applicazioni dei due tipi possono danneggiarsi a vicenda I Data Warehouse sono sistemi di supporto all On Line Analytical Processing 1/24/ /24/ Data warehouse 2. Data warehouse Generalita 1/24/ Una base di dati di tipo On Line Analytical Processing utilizzata principalmente per il supporto ai processi decisionali integrata aziendale e non dipartimentale orientata ai dati non alle applicazioni orientata a dati storici con un ampio orizzonte temporale non volatile i dati sono caricati e acceduti fuori linea mantenuta separatamente dalle basi di dati operazionali 1/24/

3 Integrata I dati di interesse provengono da tutte le sorgenti informative ciascun dato proviene da una o più di esse Il data warehouse rappresenta i dati in modo univoco riconciliando le eterogeneità dalle diverse rappresentazioni nomi codifiche formati significato 1/24/ Orientata ai dati Le basi di dati operazionali sono costruite a supporto dei singoli processi operativi o applicazioni, ad esempio: produzione vendita Il data warehouse è costruito attorno alle principali entità del patrimonio informativo aziendale, ad esempio: prodotto cliente 1/24/ Orientata a dati storici Le basi di dati operazionali mantengono il valore corrente delle informazioni L orizzonte temporale di interesse è dell ordine di pochi mesi, o giorni. Nel data warehouse è di interesse l evoluzione storica delle informazioni L orizzonte temporale di interesse è dell ordine degli anni Non volatile In una base di dati operazionale, i dati vengono inseriti, modificati, cancellati, interrogati pochi record alla volta Nel data warehouse, abbiamo operazioni di accesso e interrogazione diurne operazioni di caricamento e aggiornamento dei dati notturne che possono riguardare milioni di record 1/24/ /24/ Base dati separata Per tanti motivi non esiste un unica base di dati operazionale che contiene tutti i dati di interesse Nel Data Warehouse la base di dati deve essere integrata non è tecnicamente possibile fare l integrazione in linea i dati di interesse sarebbero comunque diversi devono essere mantenuti dati storici devono essere mantenuti dati aggregati l analisi dei dati richiede per i dati organizzazioni speciali e metodi di accesso specifici (vedi in seguito) Visti i diversi obiettivi, ci sarebbe un degrado generale delle prestazioni senza la separazione L analisi multidimensionale e i modelli descrittivi di DW: il modello star schema e il modello cube dalle 1/24/2006 basi di dati operazionali 17 1/24/

4 Data Warehouse e analisi multidimensionale Le interrogazioni tipiche effettuate sui data warehouse possono riguardare insiemi di entita, relazioni e attributi (in una terminologia ER), ovvero relazioni e attributi (in una terminologia relazionale) molto ampi. Per questa ragione l analisi sui dati tipica dei sistemi data warehouse e chiamata analisi multidimensionale. Esempioditipicaanalisiper unaaziendadi produzione di automobili Quanto ho incassato a seguito di vendite di automobili per regione per mese per tipo di cliente? 1/24/ /24/ Concetti rilevanti nella analisi multidimensionale L analisi richiede normalmente dimensioni multiple: quanto ho incassato a seguito di vendite di automobili per regione per mese per tipo di cliente? Concetti rilevanti nella analisi multidimensionale L analisi richiede normalmente dimensioni multiple: quanto ho incassato MISURA 1/24/ /24/ Concetti rilevanti nella analisi multidimensionale L analisi richiede normalmente dimensioni multiple: quanto ho incassato MISURA a seguito di vendite di automobili FATTO Concetti rilevanti nella analisi multidimensionale L analisi richiede normalmente dimensioni multiple: quanto ho incassato MISURA a seguito di vendite di automobili FATTO per regione DIMENSIONI per mese per tipo di cliente? 1/24/ /24/

5 Rappresentazione multidimensionale La rappresentazione multidimensionale ha come concetti rilevanti: Fatto un concetto sul quale centrare l analisi Misura/e una/piu proprietà atomica di un fatto che si vuole analizzare Dimensione una prospettiva secondo la quale effettuare l analisi 1/24/ Esempi di fatti/misure/dimensioni Catena di negozi Fatto: vendita di prodotti Misure: unità vendute, incasso Dimensione: prodotto, tempo, zona Compagnia telefonica Fatto: telefonata Misure: costo, durata Dimensione: chiamante, chiamato, tempo, zona. 1/24/ Due modelli per DW Modello logico: Star Schema Per rappresentare fatti, misure, dimensioni rispetto al modello Entita Relazione si dimostra piu espressivo il modello detto Star Schema, che corrisponde a uno schema relazionale di forma particolare Direttamente esprimibile in un DB relazionale Chiamato anche Relational OLAP (ROLAP) Modello operazionale: Data Cube Un Data Cube, che descrive tutte le possibili aggregazioni che possono essere effettuate partendo dalle dimensioni scelte Implementabile su un DB relazionale Chiamato anche Multidimensional OLAP (MOLAP) 1/24/ Processo di costruzione di un data warehouse 1/24/ Fonti Fonti e fasi di: costruzione, aggiornamento e elaborazione di un Data Warehouse Sorgenti esterne Basi di dati operazionali 1. Estrazione 2. Esportazione 3. Allineamento 4. Accesso Data Warehouse Strumenti di analisi Analisi dimensionale Visualizzazione Data mining Fasi di costruzione, aggiornamento, elaborazione 1. Estrazione/Filtraggio dei dati provenienti dalle sorgenti esterne Estrae i dati dalle sergoenti ed effettua una verifica di correttezza dei dati e, in caso di dati scorretti, di pulizia (circa 50% dell intero sforzo) 2. Esportazione dei dati da tutti i dati provenienti dalle sorgenti, sceglie quelli da esportare nel DW 3. Allineamento dei dati Propaga le modifiche sul DW 4. Accesso ai dati Realizza le operazioni di analisi dei dati (vedi in seguito) 1/24/ /24/

6 Struttura di un Data Warehouse e sua organizzazione in Data Mart DW e data mart I data mart sono sottoinsiemi logici dell intero datawarehouse, cioe restrizioni del data warehouse a un particolare processo di supporto alle decisioni Fonti Sorgenti esterne Data Warehouse Strumenti di analisi Analisi dimensionale Basi di dati operazionali Visualizzazione Data mining Data Mart 1/24/ /24/ Pro e contro dei data mart - 1 In genere esprimono un obiettivo fattibile, mentre la realizzazione one shot di un intero DW e spesso un obiettivo improbo Ad esempio per Trenitalia, costruire l intero DW della azienda e molto oneroso, mentre i data mart della sicurezza, dei ritardi, dei clienti, delle tratte che portano piu profitto, sono piu piccoli e fattibili Per il Ministero di Giustizia, e complesso costruire il DW dei processi penali e civili, i due separati sono piu fattibili. Non si segue dunque un approccio top down Data Warehouse Data Mart 1/24/ /24/ Quanto piuttosto bottom up Data Warehouse Pro e contro dei data mart - 2 L approccio bottom-up rende difficile e spesso porta a non realizzare alla fine l intero DW Ad esempio, costruire per Trenitalia il DM della sicurezza a partire da un certo anno, rende poi piu complicato costruire il DM dei profitti per le varie tratte perche e piu complicato ricostruire i dati mancanti. Data Mart 1/24/ /24/

7 Contenuti 3. Il modello Star Schema Struttura del modello Operazioni di aggregazione sul modello star schema 1/24/ /24/ Due tipi di tabelle per lo Star Schema Tabella dei fatti Tabelle delle dimensioni Definiamole formalmente utilizzando anche un esempio, riguardante una catena di negozi di prodotti alimentari Fatti: vendite dei singoli prodotti (es bottiglia di olio Spremi) nei diversi negozi ai diversi clienti Misure Unita vendute Incassi Dimensioni Orario, ad esempio ogni ora di ogni giorno di un insieme di anni Luogo, dove e localizzato ogni negozio della catena Prodotto venduto, ad esempio una certa bottliglia di olio Cliente che ha una carta fedelta, e di cui e noto cog, 1/24/ ecc Modello star schema Tabella Fatti Vendite Codice orario Codice luogo Codice prodotto Codice cliente Unità Incasso Chiave composta dalle chiavi delle dimensioni Gli altri campi rappresentano le misure Rappresenta l evento di vendita del singolo prodotto al singolo cliente in un particolare negozio in un particolare orario, con unita vendute (es. tre bottiglie di olio) e incasso 1/24/ Modello star schema Dimensioni Modello star schema Tempo Codice orario Ora Giorno Settimana Mese Trimestre Anno Luogo Tabella Fatti Vendite Codice orario Codice luogo Codice prodotto Codice cliente Unità Incasso Prodotto Codice prodotto Descrizione Colore Modello Codice categoria Categoria Cliente Tabelle Dimensioni Codice luogo Codice cliente Negozio Chiave semplice Nome Indirizzo Cog Codice Città Gli attributi Indirizzo Città rappresentano Età Codice Regione gli attributi della Codice professione Regione dimensione Professione Codice 1/24/2006 Stato 41 Stato Tempo Codice orario Ora Giorno Settimana Mese Trimestre Anno Luogo Fatti Vendite Codice orario Codice luogo Codice prodotto Codice cliente Unità Incasso Prodotto Codice prodotto Descrizione Colore Modello Codice categoria Categoria Cliente Codice luogo Negozio Codice cliente Indirizzo Nome Codice Città Città Misure Cog Codice Regione Indirizzo Regione Età Codice 1/24/2006 Stato Codice professione 42 Stato Professione 7

8 Modello snowflake schema (a fiocco di neve) Modello snowflake schema (a fiocco di neve) Le tabelle sono normalizzate in Boyce Codd Normal form Ha piu tabelle rispetto allo schema star Luogo Codice luogo Negozio Indirizzo Codice Città Città Codice Regione Regione Dipendenze funzionali Cod. luogo Citta Citta Cod. Regione Cod Regione Regione Luogo Codice luogo Negozio Indirizzo Codice Città Città Codice Regione Luogo CodiceLuogo Codice Citta Citta Regione Codice Citta Codice Regione 1/24/ /24/ Citta CodiceCitta Citta Codice Regione Regione Codice Regione Regione Modello snowflake schema Tempo Codice orario Ora Giorno Settimana Mese Trimestre Anno Luogo Codice luogo Negozio Indirizzo Codice Città Vendite Codice orario Codice luogo Codice prodotto Codice cliente Unità Incasso Prodotto Codice prodotto Descrizione Colore Modello Codice categoria Cliente Codice cliente Nome Cog Indirizzo Età Codice professione Categoria Codice categoria Categoria Professione Codice professione Professione 1/24/ Dimensioni e gerarchie di livelli Ciascuna dimensione puo essere organizzata in una gerarchia che rappresenta i possibili livelli di aggregazione per i dati relativi alla dimensione regione provincia città negozio categoria prodotto marca anno trimestre mese giorno 1/24/ Alcune categorie possono avere forma di reticolo settimana anno trimestre mese giorno Costruzione delle aggregazioni nel modello star schema 1/24/ /24/

9 Forma generale delle aggregazioni - 1 La forma generale delle query per il modello star schema usa la clausola GROUP BY gia vista nel corso di Elementi di Basi di dati 1/24/ Forma generale delle aggregazioni - 2 SELECT insieme degli attributi di raggruppamento e delle aggregazioni (SUM, etc) FROM Tabella dei fatti insieme a zero o piu tabelle delle dimensioni in join con la tabella dei fatti WHERE condizioni di join tra le tabelle citate nella FROM piu condizioni di selezione sugli attributi (in genere ATTR = Valore oppure ATTR compreso in un intervallo) GROUP BY insieme degli attributi di raggruppamento 1/24/ Contenuti 4. Modello Data cube Il modello Data cube Operazioni di aggregazione/ disaggregazione nel modello data cube 1/24/ /24/ Data Cube Rappresenta tutte le possibili aggregazioni di fatti (e relative misure) calcolabili a partire dalle dimensioni Esempio utilizzato Fatti: automobili vendute Misure: incassi Dimensioni: Modello (model) Anno (Year) Colore (Color) 1/24/ /24/

10 Esempio di data cube SALES Model Year Color Sales Chevy 1990 red 5 Chevy 1990 white 87 Chevy 1990 blue 62 Chevy 1991 red 54 Chevy 1991 white 95 Chevy 1991 blue 49 Chevy 1992 red 31 Chevy 1992 white 54 Chevy 1992 blue 71 Ford 1990 red 64 Ford 1990 white 62 Ford 1990 blue 63 Ford 1991 red 52 Ford 1991 white 9 Ford 1991 blue 55 Ford 1992 red 27 Ford 1992 white 62 Ford 1992 blue 39 CUBE DATA CUBE Model Year Color Sales ALL ALL ALL 942 chevy ALL ALL 510 ford ALL ALL 432 ALL 1990 ALL 343 ALL 1991 ALL 314 ALL 1992 ALL 285 ALL ALL red 165 ALL ALL white 273 ALL ALL blue 339 chevy 1990 ALL 154 chevy 1991 ALL 199 chevy 1992 ALL 157 ford 1990 ALL 189 ford 1991 ALL 116 ford 1992 ALL 128 chevy ALL red 91 chevy ALL white 236 chevy ALL blue 183 ford ALL red 144 ford ALL white 133 ford ALL blue 156 ALL 1990 red 69 ALL 1990 white 149 ALL 1990 blue 125 ALL 1991 red 107 ALL 1991 white 104 ALL 1991 blue 104 ALL 1992 red 59 ALL 1992 white 116 ALL 1992 blue 110 1/24/ Gruppo di valori nella tabella DATA CUBE Model Year Color Sales ALL ALL ALL 942 chevy ALL ALL 510 Esempio ford ALL ALL 432 ALL 1990 ALL 343 ALL 1991 ALL 314 ALL 1992 ALL Tutti gli elementi (incassi ALL ALL white 273 ALL ALL red 165 ALL ALL blue 339 da auto vendute, sales) in chevy 1990 ALL 154 chevy 1991 ALL 199 un area che corrispondono a chevy 1992 ALL 157 una stessa coppia di valori, ad ford 1990 ALL 189 ford 1991 ALL 116 esempio, di anno(year) e colore ford 1992 ALL 128 chevy ALL red 91 (color) chevy ALL white 236 chevy ALL blue 183 ford ALL red Tutti gli incassi di un anno ford ALL white 133 ford ALL blue 156 ALL 1990 red Tutti gli incassi di sempre ALL 1990 white 149 ALL 1990 blue 125 ALL 1991 red 107 ALL 1991 white 104 ALL 1991 blue 104 ALL 1992 red 59 ALL 1992 white 116 1/24/2006 ALL 1992 blue Cubo iniziale Costruzione del data cube per strati successivi SALES Model Year Color Sales Chevy 1990 red 5 Chevy 1990 white 87 Chevy 1990 blue 62 Chevy 1991 red 54 Chevy 1991 white 95 Chevy 1991 blue 49 Chevy 1992 red 31 Chevy 1992 white 54 Chevy 1992 blue 71 Ford 1990 red 64 Ford 1990 white 62 Ford 1990 blue 63 Ford 1991 red 52 Ford 1991 white 9 Ford 1991 blue 55 Ford 1992 red 27 Ford 1992 white 62 Ford 1992 blue 39 Cubo iniziale CHEVY FORD RED WHITE BLUE 1/24/ /24/ Aggiungiamo Group by per ogni coppia di attributi Aggiungiamo Group by per singoli attributi By Model & Year FORD CHEVY By Model & Year FORD CHEVY By Year By Make By Color & Year RED WHITE BLUE By Model & Color By Color & Year By Color RED WHITE BLUE By Model & Color 1/24/ /24/

11 Aggiungiamo Group by totale By Year By Color & Year By Model & Year FORD CHEVY Sum By Color By Make RED WHITE BLUE By Model & Color 1/24/ Struttura del data cube Il data cube può essere visto come un reticolo di cuboidi calcolati attraverso Group-By 1 cubo base su n =3 dimensioni (color, year, model), 3 cubioidi su n-1 dimensioni (year, model),(model, color), (color, year) 3 cuboidi su n-2 dimensioni (color), (year), (model) 1 cuboide su n-3 dimensioni () aggregazione applicata all intero insieme di fatti () (year ) (year, model) (model) (model, color) (color) (color, year) (color, year, model) 1/24/ Operazioni di aggregazione/disaggregazione sulla rappresentazione Cube 1/24/ Operazioni su cube Roll up aggrega i dati, 1. salendo in una gerarchia per una dimensione (es da mese a trimestre) o 2. attraverso una riduzione di una dimensione (es eliminando mese) Es. Da volume di vendita totale per mese, categoria di prodotto e regione A volume di vendita totale per trimestre, categoria di prodotto e regione Oppure A volume di vendita totale per categoria di prodotto e regione 1/24/ L operazione di Roll Up Operazioni su dati multidimensionali Drilldown disaggrega i dati, cioe passa da un livello di dettaglio basso ad un livello di dettaglio alto, 1. scendendo in una gerarchia o 2.introducendo una nuova dimensione. Es. Da vendite mensili dettagliate per negozio, categoria di prodotto e regione A vendite giornaliere dettagliate per negozio, categoria di prodotto e regione mensile bimensile 1/24/ bimensile mensile 1/24/

12 Operazioni tipiche - 2 Slice e selezione Slice: esegue una selezione su una dimensione del cubo, fissando un valore per una dimensione Operazioni tipiche - 2 Slice e selezione Selezione: generalizzazione della Slice, in cui la selezione e di tipo generale, portando alla selezione di un sottocubo Tutti i mesi Mese = gennaio Tutti i mesi e tutte le citta Mesi da marzo a giugno e citta = Milano o Roma 1/24/ /24/ Specifiche generali del DW 5. Un esempio di DW e delle diverse parti di interesse per diversi ruoli aziendali Un azienda che vende prodotti di varia natura vuole realizzare un DW sulle vendite, aggregate secondo diverse dimensioni, per permettere a diversiruoliaziendalidiprenderele opportune decisioni sulla evoluzione temporale delle proprie azioni nella azienda 1/24/ /24/ Struttura della azienda Due tipi di divisioni Per regioni Per prodotti A livello centrale Divisione strategica Divisione finanziaria Ruoli aziendali Manager regionale per n regioni Manager di prodotto per m prodotti Manager strategico: uno Manager finanziario: uno 1/24/ /24/

13 Data warehouse su vendite Fatto: vendite Misura: quantita Dimensioni Aree di mercato (Regione, Zona goegrafica) Prodotti (NomeP, TipoP, Sett. merceologico) Periodi di tempo (Mese-di-anno, Anno) Struttura dello star schema Tabella dei fatti Vendite (Regione, NomeP, Mese-di-anno, Quantita ) Tabelle delle Dimensioni Aree di mercato (Regione, Zona geografica) Prodotti (NomeP, TipoP, Settore merceologico) Periodi di tempo (Mese-di-anno, Anno) 1/24/ /24/ Rappresentazione Star Schema Rappresentazione data cube Periodo Temporale #Mese Anno Vendita #Regione #Prodotto #Mese Quantita Area di mercato #Regione #Zona Geografica Prodotto #Prodotto Nome Tipo Settore Aree di mercato Vendite Quantità Periodi di tempo Prodotti 1/24/ /24/ Viste su dati multidimensionali Aree di mercato Il manager regionale e interessato alla vendita dei prodotti in tutti i periodi temporali relativamente alla propria regione Nel modello cube operazione Roll up seguita da Slice Aree di mercato Prodotti Prodotti Tempo 1/24/ Tempo 1/24/

14 La precedente analisi si puo effettuare nel modello star schema con la query Schema coinvolto Vendite(Regione, NomeP, Mese-di-anno, Quantita ) SELECT NomeP, Mese-di-Anno, SUM (Quantita ) From VENDITE WHERE REGIONE = Lombardia GROUP BY NomeP, Mese-di-Anno In questo caso non dobbiamo fare join Se si vuole modificare la precedente aggregando per area geografica Schema coinvolto Vendite (Regione, NomeP, Mese-di-anno, Quantita ) Aree di mercato (Regione, Zona goegrafica) SELECT NomeP, Zona geografica, Mese-di-anno SUM (Quantita ) From VENDITE, AREE_DI_MERCATO WHERE VENDITE. Regione.= AREE_DI_MERCATO.Regione GROUP BY NomeP, Zona geografica, Mese-di-anno 1/24/ /24/ Il manager di prodotto e interessato alla vendita di un prodotto in tutti i periodi e in tutte le aree geografiche Nel modello cube operazione roll up Aree di mercato Prodotti Il manager finanziario e interessato alla vendita dei prodotti in tutti i mercati nel tempo o relativamente al periodo corrente e quello precedente Nel modello cube operazione di selezione Aree di mercato Prodotti Tempo 1/24/ Tempo 1/24/ Il manager strategico si concentra su una categoria di prodotti, una area regionale e un orizzonte temporale medio Nel modello cube operazioni di slice e selezione Aree di mercato Prodotti Esercizio Completare le formulazioni delle interrogazioni nel modello star schema per i casi mancanti Tempo 1/24/ /24/

15 Progettazione di data warehouse 6. Progettazione di data wharehouse La progettazione di un data warehouse è diversa dalla progettazione di una base di dati operazionale i dati da memorizzare hanno caratteristiche eterogenee vincolata dalle basi di dati esistenti guidata da criteri progettuali diversi Attività principali analisi delle sorgenti informative esistenti integrazione progettazione concettuale, logica e fisica 1/24/ /24/ Fasi della progettazione di un DW Input: Requisiti degli utenti, basi di dati aziendali, altre fonti informative esterne Fase 1: Analisi 1.1. Selezione e analisi delle sorgenti informative 1.2. Traduzione delle sorgenti informative in un modello concettuale comune Fase 2: Integrazione 2.1 INTENSIONALE - Produzione dello schema concettuale integrato 2.2 ESTENSIONALE - Integrazioni delle sorgenti informative Fase 3 Progettazione logico fisica 3.1 Identificazione di fatti e dimensioni 3.2 Progettazione logico fisica 0. Informazioni in ingresso Le informazioni in ingresso necessarie alla progettazione di un data warehouse requisiti le esigenze aziendali di analisi descrizione delle basi di dati con una documentazione sufficiente per la loro comprensione descrizione di altre sorgenti informative esterne l analisi richiede spesso la correlazione con dati non di proprietà dell azienda ma comunque da essa accessibili ad esempio, dati ISTAT o sull andamento dei concorrenti 1/24/ /24/ Selezione e analisi delle sorgenti informative analisi preliminare del patrimonio informativo aziendale analisi di qualità delle singole sorgenti correlazione del patrimonio informativo con i requisiti identificazione di priorità tra schemi 1.2. Traduzione in un modello concettuale comune Uno schema ER è più espressivo di uno schema relazionale è necessario conoscere la realtà di interesse per recuperare la conoscenza persa nella fase di progettazione logica Puo utilizzare tecniche di reverse engineering Il reverse engineering è l attività di: comprensione concettuale di uno schema di dati (tipicamente relazionale) rappresentazione di uno schema relazionale in un modello concettuale 1/24/ /24/

16 Esempio di reverse engineering Relazione Persona Codice Fiscale, Nome, Cog, Citta di Nascita Relazione Dipendente Codice Fiscale, Nome, Cog, Citta di Nascita, Dipartimento, Stipendio Relazione Citta Citta, Regione Persona Città 2.1 Integrazione di schemi concettuali L integrazione di schemi concettuali è l attività di fusione dei dati rappresentati in più sorgenti in un unica base di dati globale che rappresenta l intero patrimonio informativo aziendale, rappresentato a livello concettuale Dipendente 1/24/ /24/ Integrazione di schemi concettuali Schema 1 Schema 2 Schema n Schema 2 Schema 1 Schema n Schema integrato 1/24/ Esempio utilizzato nella fase di integrazione codice sesso anno nascita città residenza marca categoria Cliente Occupazione Schema clienti Articolo codice prezzo costo scontrino data Vendita numero pezzi negozio incasso Schema vendite Vendita Negozio città Schema organizzazione 1/24/ Problemi nella integrazione di schemi concettuali Lo scopo principale dell integrazione è l identificazione di tutte le porzioni dei diversi schemi concettuali che si riferiscono a uno stesso aspetto della realtà di interesse, per unificare la loro rappresentazione Fasi rilevanti della integrazione di schemi Requisiti 1 Requisiti 2 A B E B C D F D A B E 1/24/ C F D 1/24/

17 Problemi nella integrazione di schemi concettuali Lo scopo principale dell integrazione è l identificazione di tutte le porzioni dei diversi schemi concettuali che si riferiscono a uno stesso aspetto della realtà di interesse, per unificare la loro rappresentazione L approccio è orientato alla identificazione, analisi e risoluzione di conflitti terminologici, strutturali, di codifica Schema 1 Persona Esempio di conflitto Citta di nascita Schema 2 Persona Nato Citta 1/24/ /24/ Conflitti: due tipi! L integrazione di schemi richiede la risoluzione dei conflitti relativi a: rappresentazione concettuale e rappresentazione dei dati Esempio di conflitto concettuale: un attributo sesso può essere rappresentato: con un carattere M/F con una cifra 0/1 implicitamente nel codice fiscale non essere rappresentato Esempio di conflitto sul formato dei dati: il e cog di una persona Mario, Rossi Mario Rossi Rossi, Mario Rossi, M. Integrazione di schemi - esempi di conflitti tra due schemi Omonimia Sinonimia Prodotto prezzo (di produzione) Impiegato Impiegato Prodotto prezzo (di vendita) Dipartimento Progetto Dipartimento Divisione Progetto Libro Libro editore Persona Persona sesso Uomo Donna Editore 1/24/ /24/ Differenti concetti Esempio marca categoria Articolo codice prezzo costo Nel nostro esempio marca categoria Articolo codice prezzo costo codice sesso anno nascita città residenza Cliente Occupazione Schema clienti scontrino data Vendita numero pezzi negozio incasso Schema vendite Vendita Negozio città Schema organizzazione 1/24/ codice sesso anno nascita città residenza Cliente (0,1) Occupazione Schema clienti scontrino data Vendita numero pezzi negozioincasso Schema vendite Vendita Negozio città Schema organizzazione 1/24/

18 Soluzione marca categoria (0,1) Articolo Vendita codice prezzo costo scontrino data numero pezzi incasso Schema vendite Schema integrato finale marca categoria Articolo codice prezzo costo codice sesso anno nascita città residenza Cliente Occupazione Negozio Vendita Negozio città codice sesso anno nascita città residenza Cliente Occupazione percentuale tempo Vendita Negozio scontrino data numero pezzi incasso città Schema clienti Schema organizzazione 1/24/ /24/ Una metodologia di integrazione Esempio di proprieta interschema Passo 1 - Trova i conflitti tra i concetti degli schemi Omonimie Sinonimie Conflittiditipo Risolvi i conflitti Passo 2 - Fondi gli schemi ed evidenzia le parti comune degli schemi Passo 3. Cerca le proprieta interschema, definite cioe su concetti nelle parti non in comune Schema 1 Persona Uomo Schema 2 1/24/ /24/ Integrazione di basi di dati Integrazione delle sorgenti informative Per ogni dato presente in piu basi di dati, occorre risolvere i conflitti presenti e arrivare ad una unica rappresentazione. I conflitti possono derivare da: differenza di formato (esempi precedenti) oppure da scarsa qualita dei dati, cioe errori nei dati. Vedi pagina successiva Tecnica tipicamente utilizzata: record matching, cioe ricerca per corrispondenza esatta, approssimata o probabilistica dei record relativi allo stesso oggetto della realta 1/24/ /24/

19 Id Diverse rappresentazioni dei nomi Tipo di attivita Citta Indirizzo Nome Esempio: Diverse rappresentazioni degli identificatori RI Registro imprese delle camere di commercio INPS INAIL 1/24/ /24/ Esempio: Diverse rappresentazioni del tipo di attivita 3.1 Identificazione fatti e dimensioni Linea guida 1: Un DW o Data Mart dovrebbe cogliere le esigenze di uno o piu processi aziendali Il DW va progettato in funzione del processo da supportare, piuttosto che in funzione dei soli dati di partenza disponibili In un DW di un supermercato, scegliamo di modellare il processo di vendita: Quali prodotti vengono venduti in quale negozio, in quali giorni e secondo quali promozioni 1/24/ /24/ Identificazione di fatti e dimensioni, e della loro granularita Esempio Linea guida 2: il modello dimensionale deve gestire l informazione piu granulare possibile richiesta dal processo di business I dati atomici sono quelli che non possono essere ulteriormente suddivisi Nell esempio del supermercato: il dato atomico e una singola voce di spesa di una transazione di cassa Transazione = carrello che attraversa la cassa Voce dispesa= singolotipoprodottosulcarrello(es. Bottiglia di olio Spremi, che il cliente puo aver acquistato in quantita pari a una o piu ) codice sesso anno nascita città residenza Cliente Occupazione percentuale tempo marca categoria Articolo Vendita Negozio codice prezzo costo scontrino data numero pezzi incasso città 1/24/ /24/

20 Due soluzioni 3.2 Progettazione logico fisica Modello Star schema Relational OLAP (ROLAP) Modello Cube Multidimensional OLAP (MOLAP) 1/24/ /24/ a. Scelta Relational OLAP (ROLAP) Utilizza DBMS relazionale o esteso per memorizzare e gestire i dati del data warehouse SQL strumento principale elevata scalabilità Vista materializzata E definita come un qualunque risultato di interrogazione che si decide di memorizzare permanentemente, piuttosto che ricostruirlo ogni volta in risposta a una nuova interrogazione Nel relational OLAP una vista materializzata e una relazione, risultato di una aggregazione sullo star schema base e/o su un insieme di viste. 1/24/ /24/ Progettazione logica con Relational OLAP si parte dallo star schema (o snowflake) Schema star (o schema snowflake) Progettazione logica Una tabella per la tabella dei fatti + Una tabella per ogni tabella delle dimensioni dello star schema + Un insieme di viste materializzate 1/24/ Scelta tra star e snowflake Nel caso star privilegiamo la disponibilita delle tabelle dimensioni gia aggregate, al costo della ridondanza (non normalizzazione) Nel caso snowflake privilegiamo l occupazione di memoria a scapito di un maggior costo nel calcolo delle interrogazioni Tradeoff spazio/tempo 1/24/

21 3.2.b Multidimensional OLAP (MOLAP) I dati sono fisicamente rappresentati sotto forma di cubo multidimensionale Indicizzazione veloce a dati riassuntivi pre-calcolati Ma: Dati sparsi difficili da gestire (molti ALL ) Memoria sottoutilizzata no interfaccia SQL file molto grandi limitazioni a circa 10GB (problemi scalabilità) Vista materializzata E definita come un qualunque risultato di interrogazione che si decide di memorizzare permanentemente, piuttosto che ricostruirlo ogni volta in risposta a una nuova interrogazione Nel multidimensional OLAP una vista materializzata e un cuboide 1/24/ /24/ Progettazione logica con multidimensional OLAP si parte dallo schema a cubo Schema a cubo Materializzazioni del data cube Per il calcolo efficiente dei data cubes, sono possibili diverse strategie: Progettazione logica Materializza ogni cuboide (materializzazione completa) nessun cuboide (materializzazione nulla) o qualche cuboide (materializzazione parziale) Cubo base + un insieme di viste materializzate (k cubodi) 1/24/ Selezione dei cuboidi da materializzare Basata sulla dimensione, condivisione dei cubi dalle diverse interrogazioni, frequenza di accesso, ecc. 1/24/ Scelta delle viste materializzate in entrambi i casi Strumento: costruzione del reticolo delle interrogazioni e delle viste Query 1 Query 1 Query 1 Vista 1 Calcolabile da Calcolata da Vista 2 Vista 3 Vista 4 Insieme di tabelle (o cubo base) 1/24/ CLIENTE CodCliente Sesso Occupazione Anno nascita Città nascita Provincia nascita Regione nascita 3.2 Progettazione logico fisica Esempio ARTICOLO CodArticolo Marca Categoria Nome VENDITA CodArticolo CodCliente CodTempo CodNegozio Incasso NEGOZIO CodNegozio Indirizzo Città Provincia Regione TEMPO CodTempo Giorno Mese Trimestre Anno 1/24/

22 Progettazione fisica in ambiente Rolap Indice bitmap per l attributo Model Strumenti: indici bitmap e indici di join Vediamo gli indici bitmap Consentono una implementazione efficiente delle congiunzioni o disgiunzioni nelle selezioni Rappresentano ciascun attributo di selezione che abbia nel dominio di definizione n valori, tramite n vettori di k bit dove k e il numero dei record della tabella su cui fare selezioni. Nell esempio SALES, ad esempio il vettore quello associato al valore del modello Ford, avra in posizione i il valore 1 se l i-esimo record ha come modello il valore Ford, 0 altrimenti) Es l intersezione si effettua tramite and di due vettori 1/24/ Ford SALES Model Year Color Sales Chevy Chevy 1990 red 5 Chevy 1990 white 87 0 Chevy 1990 blue 62 1 Chevy 1991 red 54 0 Chevy 1991 white 95 1 Chevy 1991 blue 49 0 Chevy 1992 red 31 1 Chevy 1992 white 54 Chevy 1992 blue 71 Ford 1990 red 64 Ford 1990 white 62 Ford 1990 blue 63 1 Ford 1991 red 52 Ford 1991 white 9 0 Ford 1991 blue 55 Ford 1992 red 27 Ford 1992 white 62 Ford 1992 blue 39 1/24/ Confronto MOLAP - ROLAP Confronto ROLAP & MOLAP MOLAP - Multidimensional OLAP Dati memorizzati in multidimensional cube Richiede trasformazioni dei dati Dati disponibili per l analisi direttamente dai cube analytical processing piu veloce Limitazioni sulle dimensioni dei cubes ROLAP - Relational OLAP Dati memorizzati in relational database come cubes virtuali Non richiede trasformazioni dei dati Dati recuperati tramite SQL per l analisi analytical processing piu lento Nessuna limitazione sulle dimensioni dei cubes Performance Query: MOLAP Caricamento: ROLAP Analisi: MOLAP Dimensione DW: ROLAP MOLAP: problema sparsità Flessibilità nello schema: ROLAP MOLAP: minor numero di dimensioni ammesse 1/24/ Una semplice metodologia di progetto Uno studio di caso Scopi: Mettere in evidenza gli aspetti legati alla scelta delle dimensioni Confrontare la soluzione star schema con la soluzione snowflake schema 1/24/ /24/

23 Case study: progetto di un DW per un supermercato Scenario: Una catena di supermercati ha 100 negozi sparsi su un era geografica che comprende 5 zone Ogni supermercato consiste di un insieme di dipartimenti e gestisce circa prodotti sugli scaffali I prodotti sono chiamati SKU (stock keeping units) Sono circa Case study: progetto di un DW per un supermercato I dati vengono raccolti: Alla cassa, tramite scan dei bar codes All ingresso in magazzino Il sistema di supporto alle decisioni ha come problema principale decidere prezzi e promozioni sui prodotti 1/24/ /24/ Passo di design 1: scelta del processo business su cui prendere decisioni Linea guida 1: Un DW o Data Mart dovrebbe cogliere le esigenze di uno o piu processi aziendali Il DW va progettato in funzione del processo da supportare, piuttosto che in funzione dei soli dati di partenza disponibili Nel nostro esempio, scegliamo di modellare il processo di vendita: Quali prodotti vengono venduti in quale negozio, in quali giorni e secondo quali promozioni Passo di design 2: scelta della granularita dei fatti e delle loro dimensioni Linea guida 2: il modello dimensionale deve gestire l informazione piu granulare possibile richiesta dal processo di business I dati atomici sono quelli che non possono essere ulteriormente suddivisi Nel nostro esempio: il dato atomico e una singola voce di spesa di una transazione di cassa Transazione = carrello che attraversa la cassa Voce dispesa= singolotipoprodottosulcarrello(es. Bottiglia di olio Spremi, che il cliente puo aver acquistato in quantita pari a una o piu ) 1/24/ /24/ Passo di design 3: Scelta delle dimensioni N.B. TBD significa to be done, ancora da fare, da espandere Le dimensioni primarie seguono la granularita dei fatti: Data, prodotto, negozio Altre dimensioni di interesse: Promozione associata alla vendita Passo di design 4: scelta delle misure (nei fatti) Le quantita misurabili seguono la definizione dei fatti Quantita venduta della voce Prezzo unitario della voce venduta Prezzo totale della voce = quantita x prezzo unitario Costo unitario al venditore 1/24/ /24/

24 Misure additive e non-additive - 1 Le quantita individuate sono in genere additive: La somma di quantita additive e valida per qualunque selezione dei valori delle dimensioni Ad es le quantita vendute (Sales quantity) su ogni negozio, o su determinati prodotti per determinati negozi, ecc. Misure additive e non-additive - 2 Non sempre le quantita sono additive: Es il margine lordo (Gross profit Dollar Amount) non e additivo perche e una funzione di altre quantita (rapporto tra prezzo e costo) Dato il margine lordo su due insiemi di negozi, non si puo calcolare il margine lordo sulla loro unione 1/24/ /24/ Dimensionamento delle tabelle - 1 Dimensione temporale: Date - Data Se un record della dimensione Date rappresenta un giorno, possiamo rappresentare 10 anni di vendite con circa record Una dimensione accettabile della tabella Dimensionamento delle tabelle - 2 Dimensione Product - Prodotto: al min record, spesso molti di piu Deve contenere attributi descrittivi di ogni SKU La gerarchia delle merci, per es.: SKU marca categoria dipartimento Normalmente, circa 50 attributi descrittivi 1/24/ /24/ Esempio di tabelle Date e Prodotto Dimensionamento delle tabelle - 3 Rappresentazione delle promozioni in corso La meno ovvia e forse la piu interessante delle dimensioni L analisi serve infatti a chiarire se la promozione e efficace Possiamo scegliere, ad esempio: Media type, mezzo di comunicazione utilizzato Begin date End date Ecc. 1/24/ /24/

25 Lo schema proposto (vista parziale) Snowflaking e normalizzazione La dimensione Prodotto non e normalizzata: esistono dipendenze funzionali tra alcuni attributi: SKU department, SKU tipo package, ecc. Su un insieme di SKU, ci sono solo 50 dipartimenti Quindi ogni valore di dipartimento e ripetuto volte nella tabella Un possibile modello normalizzato per la dimensione Product e il seguente: 1/24/ /24/ Considerazioni sulla normalizzazione - 1 Spesso inutile e inefficiente: La rappresentazione e piu complessa e meno intuitiva da comprendere Cstringe a joins multipli che complicano il lavoro dell ottimizzatore Considerazioni sulla normalizzazione - 2 Lo spazio risparmiato e minimo: Se il valore di dipartimento occupa 20 bytes, e viene sostituito con una chiave di 2 bytes nello schema normalizzato, risparmiamo circa 2.7M La tabella dei fatti ha dimensioni dell ordine dei GB La normalizzazione interviene solo sulle tabelle tabelle dimensionali, che sono quasi sempre ordini di grandezza piu piccole rispetto alle tabelle dei fatti Rende impossibile l uso di indici bitmap (vedi in seguito), usati per indicizzare campi con cardinalita di dominio bassa 1/24/ /24/ Architettura - 2 Resti 1/24/ /24/

26 Esempio di visualizzazione Blue ALL Red 1/24/