Introduzione al Data Warehousing per Sistemi Informativi Aziendali

Transcript

1 Università La Sapienza di Roma AA Prof. Introduzione al Data Warehousing per Cos è il Data Warehousing Collezione di metodi, tecnologie e strumenti di ausilio al lavoratore della conoscenza (manager, gestore, analista) per condurre analisi dei dati finalizzate all attuazione di processi decisionali e/o a migliorare la gestione del patrimonio informativo. 2

2 Cos è un Data Warehouse Un Datawarehouse è una collezione di dati integrati (anche oltre l orizzonte dell organizzazione) consistenti (nonostante l origine eterogenea) focalizzati su un area di interesse articolati su un orizzonte temporale significativo permanenti (non volatili, storicizzati) Finalità del Data Warehouse 3 L analisi dei dati in un Data Warehouse consente di prendere decisioni individuare ed interpretare fenomeni fare previsioni sul futuro controllare un sistema complesso 4

3 Valore e quantità di informazione valore informazione strategica logistica marketing vendite BD concorrenti prezzi rapporti informazioni selezionate $$$ $ fonti informative primarie quantità Ruolo del DW nell organizzazione 5 sistema direzionale obiettivi risultati sistema operativo dati esterni KPI KPI sistemi di servizio sistema direzionale DSS DSS MKT MKT CRM CRM Datawarehouse sistemi ETL sistemi ERP HR HR Datamart-1 Datamart-2 Datamart-3 reportistica OLAP data mining internet / extranet sistema operativo 6

4 OLTP & OLAP OLTP - On-Line Transaction Processing transazioni, recovery, consistenza (scrittura e/o lettura) brevi, frequenti, elevato livello di concorrenza intervento su piccole quantità di dati dati accurati aggiornati all istante OLAP - On-Line Analitical Processing operazioni di sola lettura poche operazioni, basso livello di concorrenza intervento su grandissime quantità di dati dati articolati nel tempo ma essenzialmente statici 7 Separazione tra DataBase operazionale e Data Warehouse carico computazionale completamente differente accorgimenti differenti: DB: delicata sincronizzazione delle attività DW: dati statici (aggiornamenti occasionali) integrazione con attività aziendale: DB operazionale: integrazione DW: descrizione, storicizzazione dati di interesse DB: minimale DW: massimale 8

5 Alcuni ambienti per il Data Warehouse Oracle 10g IBM DB2-UDB Microsoft SQL-Server Sybase IQ Microstrategy Teradata (NCR) Netezza Cognos Business Objects (parte di SAP, Ottobre 2007) Architettura per il Datawarehouse: aspetti in gioco 9 separazione OLTP, OLAP scalabilità estendibilità sicurezza amministrabilità 10

6 Scelta architettura per il Datawarehouse determinata da scelte progettuali condizionata da / condiziona scelta del prodotto condiziona costo / rende possibile alternative ed integrazioni future (quantitative e/o qualitative) condiziona costo del trattamento dati condiziona effettiva PERMANENZA dati 11 Data Mart Collezione di dati focalizzata su particolare profilo di utente o su particolare obiettivo di analisi Alternative: 1.Data Mart dipendente: il DM è sottoinsieme e/o aggregazione di dati presenti nel DW primario DM estratto da DW 2.Data Mart indipendente: il DM è sottoinsieme e/o aggregazione di dati presenti nel DB operazionale DW=Ui(DMi), ossia il DM è parte del DW 3. soluzione ibrida, combinando le precedenti 12

7 Architettura DW: 1 Livello esiste solo il DB operazionale DW virtuale (non rispetta separazione OLTP-OLAP) dati coincidenti con DB operazionale difficile integrazione con altre sorgenti dati - livello 1 dati - livello 1 middleware (copia di) BD operazionale sorgenti esterne sorgenti sorgenti warehouse warehouse analisi analisi 13 Architettura DW: 2 Livelli DM dipendenti fonti dati integrate con sorgenti esterne esecuzione su piattaforma software dedicata ETL: Extraction, Transformation, Loading materializzazione del DW realizzazione e materializzatione di Data Mart dati --livello 1 dati --livello 2 oper BD ext BD ETL DW Data Mart Data Mart sorgenti sorgenti alimentazione alimentazione warehouse warehouse analisi analisi 14

8 Architettura DW: 2 Livelli DM indipendenti vengono materializzati i soli Data Mart non esiste un DW primario materializzato DW = unione dei DM dati --livello 1 dati --livello 2 oper BD ETL Data Mart ext BD Data Mart sorgenti sorgenti alimentazione alimentazione warehouse warehouse analisi analisi Architettura DW: 3 Livelli 15 viene introdotto il livello dei dati riconciliati (operational data store) separazione in due fasi delle attività ETL: 1. estrazione/trasformazione 2. caricamento dati --livello 1 dati --livello 2 dati --livello 3 oper BD ext BD ET(L) DW dati riconciliati caricamento Data Mart Data Mart sorgenti sorgenti alimentazione alimentazione warehouse warehouse analisi analisi 16

9 Metadati metadati interni riguardano l amministratore del DW (es.: sorgenti, trasformazioni, schemi, utenti, etc.) metadati esterni di interesse degli utenti (es.: unità di misura, le possibili aggregazioni) STANDARD CWM - Common Warehouse Model (OMG), definito mediante: UML (Unified Modeling Language) XML (extensible Markup Language) XMI (XML Metadata Interchange) 17 ETL: Extraction, Transformation, Loading Dati Operazionali, Dati Esterni estrazione pulitura - validazione - filtraggio trasformazione Dati Riconciliati caricamento Data Warehouse 18

10 Estrazione iniziale: finalizzata alla creazione del DW successiva: statica (integrale rispetto alle sorgenti) incrementale log timestamp 19 Pulitura intervento a livello di VALORI: duplicati inconsistenze violazione dominio violazione dipendenze funzionali valori nulli uso improprio campi ortografia abbreviazioni (non omogenee) 20

11 Trasformazione intervento a livello di FORMATI: disallineamento formati overloading campi codifiche non omogenee 21 Caricamento (Loading) Refresh: caricamento ex-novo dell intero DW Update: modifiche intervenute 22

12 Modello multidimensionale evento nella realtà progetto DB selezione dei soli aspetti di interesse operativo dato nel DB aziendale (rappresentazione dell evento) progetto DW aggregazione di interesse analitico fatto nel DW aziendale (misura in uno spazio n-dimensionale) U. Pippo, Nanni, di di anni 32, 28, U. Paperino, Nanni, Pluto, di anni 77, di di anni 28, 16, uno acquista brillantante scopettone detersivo lucido dentifricio da per scarpe piatti vendita di uno vendita scopettone di detersivo per piatti N vendite di X presso il negozio Y il giorno Z Eventi e Fatti 23 EVENTO (nella realtà) e FATTO (di interesse) sono termini il cui significato è determinato dalla granularità (livello di dettaglio) della rappresentazione multidimensionale del Data Warehouse Esempio di FATTO: il giorno 02/05/2004 a Roma sono stati venduti 278 scopettoni con un incasso di 745 Euro 24

13 Cubo multidimensionale 05/11/ /11/ /11/ /11/ /11/ /11/ /11/2002 brillantanti detersivi piatti scopettoni dentifricio Roma Firenze L Aquila Torino Venezia scopettoni 05/05/2004 Roma Palermo Foggia numero: 278 totale: 745 Dimensioni 25 tempo brillantanti detersivi piatti scopettoni dentifricio merce 05/11/ /11/ /11/ /11/ /11/ /11/ /11/2002 Roma Firenze L Aquila Torino Venezia luogo Palermo Foggia 26

14 Schema relazionale per il cubo multidimensionale TABELLA(dimens-1,, dimens-k, misura-1,, misura-h) Esempio: VENDITE(prodotto, città, data, numvendite, incasso) dimensioni (o attributi di classificazione) misure (o variabili, o metriche, o indicatori, ) CHIAVE IDENTIFICATIVA Dipendenza Funzionale: dimensioni misure Nell esempio: prodotto, città, data numvendite, incasso Gerarchia dimensionale 27 Ad ogni dimensione viene associata una gerarchia che ne raggruppa i valori a diverso livello di aggregazione (anche in modo ortogonale). Ciascun nodo della gerarchia è detto ATTRIBUTO (DIMENSIONALE) Esempio di gerarchia (dimensione temporale): mese giorno quadrimestre trimestre anno settimana Valgono le DIPENDENZE FUNZIONALI: giorno settimana giorno mese mese trimestre mese quadrimestre trimestre anno quadrimestre anno ALL 28

15 Accesso al Data Warehouse Reportistica esigenze predefinite (ev., parametrizzate) estrazione automatica di informazioni OLAP esigenze di analisi non identificabili a priori esplorazione interattiva dei dati, alla ricerca di informazioni di interesse Data Mining esigenze di analisi non identificabili a priori esplorazione (semi) automatica dei dati Reportistica 29 Rapporti/Report di struttura e forma predefinita interrogazione tipicamente basata su restrizioni e/o aggregazioni presentazione intercalata con testo dati in forma tabellare e/o grafica personalizzata con variabili d ambiente (data, utente, ) generazione richiesta esplicita dell utente periodica in base a condizioni predefinite distribuzione preview/stampa, , web, 30

16 OLAP modalità di attuazione: costruzione di una sessione di analisi, articolata in una serie di passi, ciascuno dipendente dai risultati ottenuti in precedenza utenti tipici: esperti del dominio, non necessariamente esperti informatici 31 OLAP: cubo di esempio brillantanti detersivi piatti scopettoni 05/11/ /11/ /11/ /11/ /11/ /11/2002 Roma Firenze L Aquila Torino Palermo 32

17 OLAP Operazioni base nel modello multidimensionale RESTRIZIONE (limitazione puramente quantitativa) selezione su specifici valori di attributi dimensionali nel caso si imponga l uguaglianza con un singolo valore, l operatore prende il nome di SLICING (scompare una dimensione) AGGREGAZIONE (aumento del livello di astrazione) considerata 1 dimensione, raggruppare un attributo dimensionale ad un livello di maggiore granularità se, al limite, si aggrega al massimo livello (il più generico, costituito da un singolo valore), scompare una dimensione OLAP: Operatore Roll-Up 33 Aggregazione lungo una dimensione uso di un operatore aggregativo su valori di misura Esempi: a. vendite di ciascun prodotto per città e per mese b. vendite giornaliere per città (totale su tutti i prodotti) c. vendite giornaliere per prodotto (Nord/Centro/Sud) prodotto giorno città (a) prodotto mese città 34

18 OLAP: Operatori di aggregazione DISTRIBUTIVI: calcolabili a partire da: 1. aggregati parziali Esempi: SUM, MAX, MIN, ALGEBRICI: calcolabili a partire da: 1. aggregati parziali 2. insieme finito di misure di supporto Esempi: AVG, deviazione standard, OLISTICI: calcolabili a partire da: 1. dati originari Esempio: rango di una matrice 35 OLAP: Operatore Drill-Down Disaggregazione lungo una dimensione comporta la disponibilità dei dati disaggregati Esempi: a. passare dalle vendite di ciascun prodotto per città e per mese alle vendite giornaliere b. passare dalle vendite mensili per città (totale su tutti i prodotti) alle vendite giornaliere per città e per prodotto prodotto mese città (a) prodotto giorno città 36

19 OLAP: Cuboidi (dimensioni) dato un cubo di dati, è possibile effettuare diverse operazioni di roll-up che conducono alla scomparsa di una dimensione dato un cubo con k dimensioni, esistono 2 k possibili cuboidi tutti prodotto data città roll-up drill-down prodotto, data prodotto, città data, città prodotto, data, città OLAP: Cuboidi (livelli aggregazione) 37 dato un cubo di dati, è possibile effettuare diverse operazioni di roll-up che aumentano il livello di aggregazione (con o senza la scomparsa di una dimensione) dato un cubo con k dimensioni di n 1, n 2,, n k livelli di aggregazione, esistono n 1 n 2 n k possibili cuboidi {} roll-up drill-down marca marca,mese mese giorno,mese marca,giorno,giorno 38

20 OLAP: Operatori Slice-and-Dice Selezione (o, al limite, slicing) Esempi: passare dalle vendite mensili dei prodotti per città a. alle vendite mensili dei prodotti per le sole città del centro b. alle vendite mensili per città di detersivi per piatti brillantanti detersivi piatti scopettoni Ago-02 Sett-02 Ott-02 Roma Firenze L Aquila Torino Palermo (b) detersivi piatti Ago-02 Sett-02 Ott-02 Roma Firenze L Aquila Torino Palermo OLAP: Operatori di Pivoting 39 Rotazione delle dimensioni su una tabella bidimensionale Esempio passare da: vendite di (prodotti per mese) per (città) a: vendite di (prodotti per città) per (mese) RM FI AQ TO PA brillantanti ago set ott detersivi piatti ago set ott scopettoni ago set ott due operazioni ago-02 set-02 ott-02 brillantanti RM FI AQ TO PA detersivi piatti RM FI AQ TO PA scopettoni RM FI AQ TO PA

21 OLAP: Operatore Drill-Through accesso ai dati ad un livello di aggregazione più basso di quello offerto dal Data Warehouse accesso ai dati riconciliati (architettura a tre livelli) o al DB operazionale costituisce un caso estremo di Drill-Down 41 OLAP: Operatori Drill-Across Correlare i dati provenienti da due o più cubi in base ai valori dimensionali, calcolando un espressione in un nuovo cubo Esempio: A partire da vendite per prodotto, data, città dipendenti per città calcolare: vendite medie per prodotto per dipendente 42

22 Data Mining nasce prima del Data Warehouse collezione di tecniche derivanti da Intelligenza Artificiale, Pattern Recognition, e tecniche statistiche di vario tipo (es.: algoritmi genetici, logiche fuzzy, sistemi esperti, reti neurali, etc.) obiettivi: descrittivi: individuare schemi di comportamento, rapporti di causa-effetto, classificare individui, etc. predittivi: predire andamenti, classificare individui in base al rischio, etc. 43 Alcune applicazioni del Data Mining Analisi dei dati e Supporto alle Decisioni Analisi di mercato e marketing Target Marketing, Customer Relationship Management (CRM), Market Basket Analysis (MBA), segmentazione del mercato Analisi e gestione del rischio previsioni di affidabilità, fidelizzazione di utenti, controllo di qualità, individuazione di frodi e di pattern inusuali (outliers) Text Mining Web Mining, ClickStream Analysis Ingegneria genetica: ricerca sequenze in DNA 44

23 Data Mining: regole associative SE viene acquistato il prodotto birra (X), ALLORA viene acquistato anche il prodotto pannolino (Y) X Y Supporto (quale frazione di soggetti verifica la regola): s = X Y all Confidenza (quale frazione di soggetti soddisfa la regola tra quelli in cui è applicabile): c = X Y X Campi di applicazione: economico (market basket analysis), telecomunicazioni, medico, s(x Y) = F(X Y) c(x Y) = F( Y X ) 45 Data Mining: clustering individuazione di similarità, cogliendo disomogeneità nella distribuzione per definire gruppi omogenei (apprendimento senza supervisione) ricerca gruppi (cluster) basata su distribuzione della popolazione una funzione di distanza Esempio: ILM - Intervallo Libero da Malattia (a 5 anni) (collaborazione con Ist. Regina Elena di Roma) 46

24 Data Mining: alberi di decisione determinare le cause di un fenomeno di interesse in ordine di importanza nodo interno: test di un attributo diramazione: valore (o intervallo) di un attributo foglia: assegna una classificazione (decisione finale) Esempio: il cliente acquisterà un computer? età? <= >40 studente? si credito? no si basso alto no si no si 47 Data Mining: serie temporali individuazione pattern ricorrenti / atipici in sequenze temporali predizione caratteristiche Esempio (Least Cost Routing): instradamento traffico telefonico su operatore a costo minimo (collaborazione con Between azienda di consulenza) DOMANDA CHIAVE: data una telefonata in uscita da un numero interno X diretta verso un numero esterno Y, quanto durerà la telefonata? costo Tariffe: con scatto alla risposta flat rate durata 48

25 Data Mining: risultati interessanti Semplicità - Ad esempio: lunghezza delle regole (associative) taglia (albero di decisione) Certezza - Ad esempio: confidenza (regole associative): c(x Y) = #(X and Y) / #(X) affidabilità della classificazione Utilità - Ad esempio: supporto (regole associative): s(x Y) = #(X and Y) / #(ALL) Novità - Ad esempio: non nota in precedenza sorprendente matrice di confusione val.predetto sussunzione di altre regole (incluse come casi particolari) val.effettivo esatto errore 49 Progetto di Data Warehouse Definizione di obiettivi e pianificazione fattibilità (confini, dimensione, sorgenti, ) team piano operativo Progetto dell infrastruttura alternative architetturali alternative tecnologiche Progetto e sviluppo dei Data Mart analisi con esperti del dominio 50

26 Ciclo di vita (Kimball, 1998) pianificazione definizione requisiti progetto architettura modellazione dimensionale specifica applicazioni gestione progetto tecnologia selezione e installazione prodotti dati progetto fisico progetto e sviluppo alimentazione applicazioni sviluppo applicazioni realizzazione manutenzione Flussi dati & Evoluzione progettuale 51 DW Flusso dati Logica di progettazione 52

27 Fasi di progetto di un Data Mart 1. Analisi e riconciliazione delle fonti dati schemi delle sorgenti schema riconciliato 2. Analisi dei requisiti schema riconciliato fatti, carico lavoro 3. Progetto Concettuale schema riconciliato, fatti, carico lavoro schemi di fatto 4. Progetto Logico schemi di fatto, carico lavoro schema logico Data Mart 5. Progetto dell Alimentazione schemi delle sorgenti, schema riconciliato, schema logico Data Mart procedure alimentazione 6. Progetto Fisico schemi di fatto star-schema, snowflakes entità-relazione schema logico Data Mart, carico lavoro, DBMS schema fisico DM 53 Riconciliazione delle fonti dati Integrazione di schemi: a un passo a scala bilanciato iterativo 54

28 Fatti il punto della situazione FATTO: categoria di eventi che si verificano nella realtà di interesse dell organizzazione. Per ciascun fatto: dimensioni: coordinate di analisi/classificazione misure: proprietà di un fatto, aspetti quantitativi gerarchia dimensionale: per ciascuna dimensione granularità di informazione: compromesso ( * ) tra quantità di informazione ed efficienza ( * ) Per compiti specifici esistono, in ogni caso: il DB operazionale / riconciliato il drill-through Progetto Concettuale 55 Il modello ER non sembra adeguato (anche se resta un fondamentale supporto nella fase di progetto logico) Non esiste un consenso unanime sul modello da adottare Diverse proposte in letteratura: Multidimensional Entity-Relationship Model DFM - Dimensional Fact Model 56

29 Schema ER del DB operazionale data numero importo p_iva negozio citta DATA (1,n) emessa FATTURA_V presso NEGOZIO situato CITTA quantita posizione incasso (1,n) contiene VOCE_V riferita ARTICOLO codice Schema logico del DB operazionale 57 data numero importo p_iva negozio citta DATA (1,n) emessa FATTURA_V presso NEGOZIO situato CITTA quantita posizione incasso (1,n) contiene VOCE_V riferita ARTICOLO codice 58

30 Schema logico DB operazionale - revisione data denormalizzazione ELIMINAZIONE DI ATTRIBUTI: vengono tolti dallo schema gli attributi che non interessano negozio citta DATA (1,n) emessa presso NEGOZIO situato CITTA ACCORPAMENTO: si ipotizza che non interessi il raggruppamento delle vendite in fatture (ossia la Market Basket Analysis) e pertanto collassano le entità FATTURA e VOCE voce_vendita VENDITA quantita incasso riferita ARTICOLO 59 Schema di fatto (preliminare) DIMENSIONI FATTO data (TEMPO) negozio (SPAZIO) MISURE VENDITA quantità incasso (MERCE) 60

31 Gerarchie dimensionali anno gerarchia TEMPO gerarchia SPAZIO trimestre mese settimana zona regione responsabile distretto citta negozio data dettagli su specifiche di utente gerarchia MERCE sottogenere marca genere città_marca Schema di fatto DFM (Dimensional Fact Model) 61 anno trimestre mese settimana zona regione responsabile distretto città negozio data VENDITA quantità incasso sottogenere genere marca città_marca 62

32 Schema di Fatto (esempio) ALL trimestre anno Es: vendite mensili per città e per marca mese data settimana zona regione ALL responsabile distretto città negozio VENDITA quantità incasso genere sottogenere ALL marca città_marca 63 Schema ER ZONA (1,n) REGIONE regione anno ANNO zona (1,n) (1,n) citta CITTA CITTA_MARCA trimestre mese (1,n) TRIMESTRE MESE responsabile RESPONSABILE situato distretto DISTRETTO negozio NEGOZIO settimana MARCA SETTIMANA (1,n) quantita incasso presso (1,n) DATA emessa VENDITA riferita data (1,n) ARTICOLO citta_marca GENERE marca SOTTOGENERE appartiene genere sottogenere 64

33 Gerarchie condivise e ruoli anno trimestre mese settimana data responsabile distretto negozio VENDITA quantità incasso sottogenere genere città_negozio città_marca marca zona regione città può essere interessante valutare la distribuzione territoriale dei marchi di successo Archi multipli (relazioni n:n) 65 anno trimestre mese settimana un negozio può avere (avuto) più responsabili responsabile distretto negozio data VENDITA quantità incasso sottogenere genere città_negozio marca città_marca zona regione città 66

34 Attributi cross-dimensionali anno trimestre mese settimana data responsabile negozio distretto città_negozio zona città regione VENDITA quantità incasso città_marca marca sottogenere genere può esistere una percentuale di provvigione può dipendere dalla marca e dal negozio perc_provvigione 67 Schema ER (rivisto) ZONA (1,n) REGIONE regione anno ANNO zona (1,n) (1,n) citta CITTA negozio quantita incasso settimana (1,n) SETTIMANA trimestre mese data (1,n) (1,n) TRIMESTRE MESE DATA ha_sede responsabile RESPONSABILE (1,n) situato NEGOZIO presso percent distretto DISTRETTO PROVVIGIONE MARCA (1,n) emessa VOCE_V riferita ARTICOLO GENERE marca SOTTOGENERE appartiene genere sottogenere 68

35 Manipolazione delle gerarchie zona regione responsabile distretto città negozio potatura innesto città responsabile negozio zona responsabile citta negozio distretto distretto Alternative di rappresentazione per DW: *OLAP 69 ROLAP - Relational On-Line Analitical Processing dati su DBMS relazionale accesso indicizzato MOLAP - Multidimensional On-Line Analitical Processing dati su strutture multidimensionali accesso calcolato HOLAP - Hybrid On-Line Analitical Processing dati su strutture di entrambe le tipologie introdotta da Oracle (Express Server, 2002) 70

36 Architettura ROLAP middleware R-DBMS(+) SQL (+) OLAP client metadati DW (DB relazionale) soluzioni dedicate componente modulare 71 Modello Logico MOLAP mancanza di uno standard affermato sia per le strutture dati che per i linguaggi di accesso gestione della sparsità dei dati (frazione popolata del cubo multidimensionale) elementi significativi individuati in base ad offset (collezione degli indici degli elementi non nulli) partizionamento in cubi più piccoli a densità quasi uniforme (densi o molto sparsi) strutture dati ad hoc (es.: kd-trees) 72

37 Modello logico (ROLAP): STAR-SCHEMA una DIMENSION TABLE per ciascuna dimensione: chiave primaria (solitamente una chiave surrogata) un insieme di attributi che descrivono i valori per tutti i livelli di aggregazione una singola FACT TABLE: chiave primaria: una foreign-key per ciascuna delle dimension tables un attributo per ciascuna misura Completa DENORMALIZZAZIONE (a parte la fact table) 73 Esempio di STAR-SCHEMA ID_ARTICOLO sottogenere genere marca città_marca regione zona dimension tables fact table vendite ID_ARTICOLO ID_DATA ID_ NEGOZIO quantità incasso data ID_DATA data settimana mese trimestre anno negozio ID_NEGOZIO negozio distretto responsabile città regione zona 74

38 Modello logico (ROLAP): SNOWFLAKE A partire dallo STAR-SCHEMA, si opera una NORMALIZZAZIONE (parziale) delle dimension tables, ottenendo: per ciascuna dimensione, la singola dimension table primaria nello Star-Schema può essere decomposta dando luogo ad una collezione di dimension table secondarie una singola fact table: chiave primaria: una foreign-key per ciascuna delle dimensioni (e per ciascuna dimension table primaria) un attributo per ciascuna misura Esempio di schema SNOWFLAKE 75 ID_ARTICOLO sottogenere genere ID_MARCA marchi ID_MARCA marca ID_CITTA dimension table secondarie dimension table primarie vendite ID_ARTICOLO ID_DATA ID_NEGOZIO quantità incasso città ID_CITTA città regione zona data ID_DATA data settimana mese trimestre anno negozio ID_NEGOZIO negozio distretto responsabile ID_CITTA 76

39 Progetto Fisico e VISTE Il principale problema operativo in un Data Warehouse è quello delle prestazioni Per contro, la ridondanza non costituisce un grave problema, a causa della essenziale staticità del DW Per conseguire migliori prestazioni, si opera una parziale materializzazione delle viste sulla Fact Table La contropartite legate alla materializzazione di viste sono: spazio aggiuntivo (dati completamente ridondanti) tempo di calcolo al momento del refresh del DW 77 Reticolo delle Viste mese VENDITE marca giorno quantità incasso prezzo_unit,giorno,mese marca,giorno marca,mese giorno marca mese {} 78

40 Ottimizzazione del calcolo basata sulle viste materializzate mese giorno VENDITE quantità incasso prezzo_unit marca FATTORI DI COSTO: tempo di calcolo spazio tempo di refresh,giorno data warehouse,mese marca,giorno query ricorrenti marca,mese giorno viste candidate viste materializzate (una ipotesi) marca mese {} Bibliografia 79 M. Golfarelli, S. Rizzi. Data Warehouse Teoria e Pratica della Progettazione (2 a ed.) McGraw-Hill,