Data warehouse Progettazione

Transcript

1 Database and data mining group, Data warehouse Progettazione DATA WAREHOUSE: PROGETTAZIONE - 1 Pag. 1

2 Fattori di rischio Database and data mining group, Aspettative elevate degli utenti il data warehouse come soluzione dei problemi aziendali Qualità dei dati e dei processi OLTP di partenza dati incompleti o inaffidabili processi aziendali non integrati e ottimizzati Gestione politica del progetto collaborazione con i detentori delle informazioni accettazione del sistema da parte degli utenti finali DATA WAREHOUSE: PROGETTAZIONE - 2 Pag. 2

3 Database and data mining group, Progettazione di data warehouse Approccio top-down realizzazione di un data warehouse che fornisca una visione globale e completa dei dati aziendali costo significativo e tempo di realizzazione lungo analisi e progettazione complesse Approccio bottom-up realizzazione incrementale del data warehouse, aggiungendo data mart definiti su settori aziendali specifici costo e tempo di consegna contenuti focalizzato separatamente su settori aziendali specifici DATA WAREHOUSE: PROGETTAZIONE - 3 Pag. 3

4 Gestione progetto TECNOLOGIA DATI APPLICAZIO NI Data warehouse: progettazione Database and data mining group, Business Dimensional Lifecycle Pianificazione (Kimball) Definizione dei requisiti Progetto dell architettura Modellazione dimensionale Selezione e installazione prodotti Progettazione fisica Specifica applicazioni utente Progettazione e sviluppo alimentazione Sviluppo applicazioni utente Attuazione Manutenzione DATA WAREHOUSE: PROGETTAZIONE - 4 Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 Pag. 4

5 Database and data mining group, Progettazione di data mart requisiti utente schema riconciliato PROGETTAZIONE CONCETTUALE carico di lavoro volume dati modello logico schemi delle sorgenti operazionali RICONCILIAZIONE schema riconciliato schema di fatto PROGETTAZIONE LOGICA schema logico carico di lavoro volume dati DBMS PROGETTAZIONE DELL ALIMENTAZIONE PROGETTAZIONE FISICA schema dell alimentazione schema fisico Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 5 Pag. 5

6 Database and data mining group, Analisi dei requisiti DATA WAREHOUSE: PROGETTAZIONE - 6 Pag. 6

7 Raccoglie Analisi dei requisiti Database and data mining group, le esigenze di analisi dei dati che dovranno essere soddifatte dal data mart i vincoli realizzativi dovuti ai sistemi informativi esistenti Fonti business users amministratori del sistema informativo Il data mart prescelto è strategico per l azienda alimentato da (poche) sorgenti affidabili DATA WAREHOUSE: PROGETTAZIONE - 7 Pag. 7

8 Requisiti applicativi Database and data mining group, Descrizione degli eventi di interesse (fatti) ogni fatto rappresenta una categoria di eventi di interesse per l azienda esempi: (per il CRM) reclami, servizi caratterizzati da dimensioni descrittive (granularità), intervallo di storicizzazione, misure di interesse informazioni raccolte in un glossario Descrizione del carico di lavoro esame della reportistica aziendale interrogazioni espresse in linguaggio naturale esempio: numero di reclami per ciascun prodotto nell ultimo mese DATA WAREHOUSE: PROGETTAZIONE - 8 Pag. 8

9 Requisiti strutturali Periodicità dell alimentazione Spazio disponibile Database and data mining group, per i dati per le strutture accessorie (indici, viste materializzate) Tipo di architettura del sistema numero di livelli data mart dipendenti o indipendenti Pianificazione del deployment avviamento formazione DATA WAREHOUSE: PROGETTAZIONE - 9 Pag. 9

10 Database and data mining group, Progettazione concettuale DATA WAREHOUSE: PROGETTAZIONE - 10 Pag. 10

11 Database and data mining group, Progettazione concettuale Non esiste un formalismo di modellazione comunemente accettato il modello ER non è adatto Dimensional Fact Model (Golfarelli, Rizzi) per uno specifico fatto, definisce schemi di fatto che modellano dimensioni gerarchie misure modello grafico a supporto della progettazione concettuale offre una documentazione di progetto utile sia per la revisione dei requisiti con gli utenti, sia a posteriori DATA WAREHOUSE: PROGETTAZIONE - 11 Pag. 11

12 Dimensional Fact Model Database and data mining group, Fatto modella un insieme di eventi di interesse (vendite, spedizioni, reclami) evolve nel tempo Dimensione descrive le coordinate di analisi di un fatto (ogni vendita è descritta dalla data di effettuazione, dal negozio e dal prodotto venduto) è caratterizzata da numerosi attributi, tipicamente di tipo categorico Misura descrive una proprietà numerica di un fatto, spesso oggetto di operazioni di aggregazione (ad ogni vendita è associato un incasso) prodotto fatto dimensione Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 data DATA WAREHOUSE: PROGETTAZIONE - 12 VENDITA quantità v enduta incasso num. clienti prezzo unitario misura negozio Pag. 12

13 Gerarchia Dimensional Fact Model DATA WAREHOUSE: PROGETTAZIONE - 13 Database and data mining group, rappresenta una relazione di generalizzazione tra un sottoinsieme di attributi di una dimensione (gerarchia geografica per la dimensione negozio) è una dipendenza funzionale (relazione 1:n) attributo dimensionale Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 anno trimestremese giorno v acanza settimana data gruppo di marketing prodotto tipo VENDITA quantità v enduta incasso num. clienti prezzo unitario categoria reparto città della marca marca responsabile delle v endite distretto di v endita negozio città del stato negozio regione gerarchia Pag. 13

14 Corrispondenza con l ER stato regione città STATO (1,n) (1,1) REGIONE (1,n) (1,1) CITTÀ (1,n) reparto tipo REPARTO (1,n) (1,1) categoria CATEGORIA (1,n) (1,1) (1,n) TIPO (1,1) gruppo marketing GRUPPO MARKETING (1,n) CITTÀ MARCA (1,n) (1,1) MARCA (1,1) prodotto (1,n) PRODOTTO (1,1) Database and data mining group, città marca marca ANNO (1,n) (1,1) TRIMESTRE trimestre (1,n) (1,1) MESE (1,n) anno mese negozio (1,1) NEGOZIO (0,n) (0,n) vendita (0,n) (1,1) DATA data (1,1) (1,n) (1,1) (1,n) qtà venduta incasso prezzo unitario num. clienti (1,1) (1,n) (1,1) (1,n) Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 RESP. VENDITE responsabile delle vendite DISTRETTO VENDITA distretto di vendita DATA WAREHOUSE: PROGETTAZIONE - 14 VACANZA vacanza (1,1) (1,n) SETTIMANA GIORNO giorno settimana Pag. 14

15 DFM: costrutti avanzati Database and data mining group, non-additività anno trimestre mese giorno vacanza settimana responsabile data peso capo reparto gruppo di marketing prodotto tipo VENDITA categoria quantità venduta incasso num. clienti prezzo unitario (AVG) reparto città della marca marca dieta negozio arco opzionale responsabile delle vendite distretto di vendita città del stato negozio regione indirizzo telefono convergenza Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 data inizio data fine costo promozione pubblicità sconto dimensione opzionale attributo descrittivo DATA WAREHOUSE: PROGETTAZIONE - 15 Pag. 15

16 Aggregazione Database and data mining group, Processo di calcolo del valore di misure a granularità meno fine di quella presente nello schema di fatto originale la riduzione del livello di dettaglio è ottenuta risalendo lungo una gerarchia operatori di aggregazione standard: SUM, MIN, MAX, AVG, COUNT Caratteristiche delle misure additive non additive: non aggregabili lungo una gerarchia mediante l operatore di somma non aggregabili DATA WAREHOUSE: PROGETTAZIONE - 16 Pag. 16

17 Database and data mining group, Classificazione delle misure Misure di flusso possono essere valutate cumulativamente alla fine di un periodo di tempo sono aggregabili mediante tutti gli operatori standard esempi: quantità di prodotti venduti, importo incassato Misure di livello sono valutate in specifici istanti di tempo (snapshot) non sono additive lungo la dimensione tempo esempi: livello di inventario, saldo del conto corrente Misure unitarie sono valutate in specifici istanti di tempo ed espresse in termini relativi non sono additive lungo nessuna dimensione esempio: prezzo unitario di un prodotto DATA WAREHOUSE: PROGETTAZIONE - 17 Pag. 17

18 Database and data mining group, Operatori di aggregazione anno trim. I 99 II 99 III 99 IV 99 I 00 II 00 III 00IV 00 categoria tipo prodotto Brillo detersivo Sbianco pulizia casa Lucido sapone Manipulite Scent Latte F Slurp latticino Latte U Slurp alimentari Yogurt Slurp bibita Bevimi Colissima anno trim. I 99 II 99 III 99 IV 99 I 00 II 00 III 00 IV 00 categoria pulizia casa alimentari anno categoria tipo pulizia detersivo casa sapone anno alimentari latticino bibita categoria pulizia casa alimentari Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 18 Pag. 18

19 Distributivi Database and data mining group, Operatori di aggregazione sempre possibile il calcolo di aggregati da dati a livello di dettaglio maggiore esempi: sum, min, max DATA WAREHOUSE: PROGETTAZIONE - 19 Pag. 19

20 Operatori non distributivi Database and data mining group, anno 1999 trim. I 99 II 99 III 99 IV 99 categoria tipo prodotto Brillo 2 2 2,2 2,5 detersivo Sbianco 1,5 1,5 2 2,5 pulizia casa Lucido Manipulite 1 1,2 1,5 1,5 sapone Scent 1,5 1,5 2 categoria pulizia casa anno 1999 trim. I 99 II 99 III 99 IV 9 9 tipo detersivo 1,75 2,17 2,40 2,67 sapone 1,25 1,35 1,75 1,50 media: 1,50 1,76 2,08 2,09 anno 1999 trim. I 99 II 99 III 99 IV 99 categoria pulizia casa 1,50 1,84 2,14 2,38 Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 20 Pag. 20

21 Database and data mining group, Operatori di aggregazione Distributivi sempre possibile il calcolo di aggregati da dati a livello di dettaglio maggiore esempi: sum, min, max Algebrici il calcolo di aggregati da dati a livello di dettaglio maggiore è possibile in presenza di misure aggiuntive di supporto esempi: avg (richiede count) Olistici non è possibile il calcolo di aggregati da dati a livello di dettaglio maggiore esempi: moda, mediana DATA WAREHOUSE: PROGETTAZIONE - 21 Pag. 21

22 DFM: costrutti avanzati Database and data mining group, uso chiamante distretto numero telef onico chiamato CHIAMATA numero durata gerarchia condivisa ora data mese anno uso del num. chiamante distretto del numero chiamante numero chiamante distretto del numero chiamato uso del num. chiamato numero chiamato ruolo CHIAMATA numero durata ora data mese anno Tratti da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 prodotto magazzino città regione stato SPEDIZIONE ordine numero cliente costo data di spedizione data mese anno DATA WAREHOUSE: PROGETTAZIONE - 22 Pag. 22

23 DFM: costrutti avanzati Database and data mining group, genere VENDITA autore libro numero incasso data mese anno arco multiplo data categoria diagnosi reparto RICOVERO costo Tratti da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 codpaz nome cognome sesso f ascia d'utenza città anno nascita reparto nome cognome RICOVERO data categoria costo sesso codpaz diagnosi gruppo fascia d'utenza di diagnosi città anno nascita DATA WAREHOUSE: PROGETTAZIONE - 23 Pag. 23

24 Schemi di fatto vuoti Database and data mining group, L evento può non essere caratterizzato da misure schema di fatto vuoto registra il verificarsi di un evento Utile per conteggio di eventi accaduti rappresentazione di eventi non accaduti (insieme di copertura) anno semestre indirizzo nome nazionalità età FREQUENZA studente (COUNT) corso area facoltà Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 sesso DATA WAREHOUSE: PROGETTAZIONE - 24 Pag. 24

25 Database and data mining group, Rappresentazione del tempo La variazione dei dati nel tempo è rappresentata esplicitamente dal verificarsi degli eventi presenza di una dimensione temporale eventi memorizzati sotto forma di fatti Possono variare nel tempo anche le dimensioni variazione tipicamente più lenta slowly changing dimension [Kimball] esempi: dati anagrafici di un cliente, descrizione di un prodotto necessario prevedere esplicitamente nel modello come rappresentare questo tipo di variazione DATA WAREHOUSE: PROGETTAZIONE - 25 Pag. 25

26 Database and data mining group, Modalità di rappresentazione del tempo (tipo I) Fotografia dell istante attuale esegue la sovrascrittura del dato con il valore attuale proietta nel passato la situazione attuale utilizzata quando non è necessario rappresentare esplicitamente la variazione Esempio il cliente Mario Rossi cambia stato civile dopo il matrimonio tutti i suoi acquisti sono attribuiti al cliente sposato DATA WAREHOUSE: PROGETTAZIONE - 26 Pag. 26

27 Database and data mining group, Modalità di rappresentazione del tempo (tipo II) Eventi attribuiti alla situazione temporalmente corrispondente della dimensione per ogni variazione di stato della dimensione si crea di una nuova istanza nella dimensione i nuovi eventi sono correlati alla nuova istanza gli eventi sono partizionati in base alle variazioni degli attributi dimensionali Esempio il cliente Mario Rossi cambia stato civile dopo il matrimonio i suoi acquisti sono separati in acquisti attributi a Mario Rossi celibe e acquisti attribuiti a Mario Rossi sposato (nuova istanza di Mario Rossi) DATA WAREHOUSE: PROGETTAZIONE - 27 Pag. 27

28 Database and data mining group, Modalità di rappresentazione del tempo (tipo III) Eventi attribuiti alla situazione della dimensione campionata in uno specifico istante di tempo proietta tutti gli eventi sulla situazione della dimensione in uno specifico istante di tempo richiede una gestione esplicita delle variazioni della dimensione nel tempo modifica dello schema della dimensione introduzione di una coppia di timestamp che indicano l intervallo di validità del dato (inizio e fine validità) introduzione di un attributo che consenta di identificare la sequenza di variazioni di una specifica istanza (capostipite o master) ogni variazione di stato della dimensione richiede la definizione di una nuova istanza DATA WAREHOUSE: PROGETTAZIONE - 28 Pag. 28

29 Database and data mining group, Modalità di rappresentazione del tempo (tipo III) Esempio il cliente Mario Rossi cambia stato civile dopo il matrimonio la prima istanza conclude il suo periodo di validità il giorno del matrimonio la nuova istanza inizia la sua validità nello stesso giorno gli acquisti sono separati come nel caso precedente esiste un attributo che permette di ricostruire tutte le variazioni ascrivibili a Mario Rossi DATA WAREHOUSE: PROGETTAZIONE - 29 Pag. 29

30 Carico di lavoro Carico di riferimento definito da Database and data mining group, reportistica standard stime discusse con gli utenti Carico reale difficile da stimare correttamente durante la fase di progettazione se il sistema ha successo, il numero di utenti e interrogazioni aumenta nel tempo la tipologia di interrogazioni può variare nel tempo Fase di tuning dopo l avviamento del sistema monitoraggio del carico di lavoro reale del sistema DATA WAREHOUSE: PROGETTAZIONE - 30 Pag. 30

31 Volume dei dati Database and data mining group, Stima dello spazio necessario per il data mart per i dati per le strutture accessorie (indici, viste materializzate) Si considerano numero di eventi di ogni fatto numero di valori distinti degli attributi nelle gerarchie lunghezza degli attributi Dipende dall intervallo temporale di memorizzazione dei dati Valutazione affetta dal problema della sparsità il numero degli eventi accaduti non corrisponde a tutte le possibili combinazioni delle dimensioni esempio: percentuale dei prodotti effettivamente venduti in ogni negozio in un dato giorno pari circa al 10% di tutte le possibili combinazioni DATA WAREHOUSE: PROGETTAZIONE - 31 Pag. 31

32 Sparsità Database and data mining group, Si riduce al crescere del livello di aggregazione dei dati Può ridurre l affidabilità della stima della cardinalità dei dati aggregati Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 32 Pag. 32

33 Database and data mining group, Progettazione logica DATA WAREHOUSE: PROGETTAZIONE - 33 Pag. 33

34 Progettazione logica Database and data mining group, Si considera il modello relazionale (ROLAP) inputs schema (di fatto) concettuale carico di lavoro volume dei dati vincoli di sistema output schema logico relazionale Basata su principi diversi rispetto alla progettazione logica tradizionale ridondanza dei dati denormalizzazione delle tabelle DATA WAREHOUSE: PROGETTAZIONE - 34 Pag. 34

35 Schema a stella Database and data mining group, Dimensioni una tabella per ogni dimensione chiave primaria generata artificialmente (surrogata) contiene tutti gli attributi della dimensione gerarchie non rappresentate esplicitamente gli attributi della tabella sono tutti allo stesso livello rappresentazione completamente denormalizzata presenza di ridondanza nei dati Fatti una tabella dei fatti per ogni schema di fatto chiave primaria costituita dalla combinazione delle chiavi esterne delle dimensioni le misure sono attributi della tabella DATA WAREHOUSE: PROGETTAZIONE - 35 Pag. 35

36 Schema a stella Categoria Database and data mining group, Fornitore Tipo Prodotto Rappresentante Settimane ID_Settimane Settimana Mese Prodotti ID_Prodotti Prodotto Tipo Categoria Fornitore Mese Settimana VENDITE Quantità Guadagno ID_Negozi ID_Settimane ID_Prodotti Quantità Guadagno Negozio Città DATA WAREHOUSE: PROGETTAZIONE - 36 Stato Negozi ID_Negozi Negozio Città Stato Rappresentante Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 Pag. 36

37 Snowflake schema Database and data mining group, Separazione di (alcune) dipendenze funzionali frazionando i dati di una dimensione in più tabelle si introduce una nuova tabella che separa in due rami una gerarchia dimensionale (taglio su un attributo della gerarchia) una nuova chiave esterna esprime il legame tra la dimensione e la nuova tabella Si riduce lo spazio necessario per la memorizzazione della dimensione riduzione non significativa Aumenta il costo di ricostruzione dell informazione della dimensione è necessario il calcolo di uno o più join DATA WAREHOUSE: PROGETTAZIONE - 37 Pag. 37

38 Snowflake schema Fornitore Tipo Categoria Database and data mining group, Prodotto Rappresentante Settimane ID_Settimane Settimana Mese Mese Prodotti ID_Prodotti Prodotto ID_Tipo Fornitore Tipi ID_Tipo Tipo Categoria Settimana VENDITE Quantità Guadagno ID_Negozi ID_Settimane ID_Prodotti Quantità Guadagno Negozio Città Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 38 Stato Negozi DT 1,1 ID_Negozi d 1,1 Negozio ID_Città Chiave esterna Rappresentante DT 1,2 Città ID_Città Città Stato d 1,2 Pag. 38

39 Star o snowflake? Database and data mining group, Lo schema snowflake è normalmente sconsigliato la riduzione di spazio occupato è scarsamente benefica l occupazione maggiore di spazio è dovuta alla tabella dei fatti (la differenza è pari ad alcuni ordini di grandezza) il costo di eseguire più join può essere significativo Lo schema snowflake può essere utile quando porzioni di una gerarchia sono condivise tra più dimensioni (esempio: gerarchia geografica) in presenza di viste materializzate che richiedano una rappresentazione aggregata anche della dimensione DATA WAREHOUSE: PROGETTAZIONE - 39 Pag. 39

40 Archi multipli Database and data mining group, genere VENDITA autore libro numero incasso data mese anno Soluzioni realizzative bridge table tabella aggiuntiva che modella la relazione molti a molti nuovo attributo che consenta di pesare la partecipazione delle tuple nella relazione push down arco multiplo integrato nella tabella dei fatti nuova dimensione corrispondente nella tabella dei fatti DATA WAREHOUSE: PROGETTAZIONE - 40 Pag. 40

41 Archi multipli Database and data mining group, genere VENDITA autore libro numero incasso data mese anno Vendite ID_Libri ID_Date Quantità Incasso Libri ID_Libri Libro Genere Autori ID_Autori Autore BRIDGE ID_Libri ID_Autori Peso Vendite ID_Libri ID_Autori ID_Date Quantità Incasso Libri ID_Libri Libro Genere Autori ID_Autori Autore Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 41 Pag. 41

42 DATA WAREHOUSE: PROGETTAZIONE - 42 Database and data mining group, Archi multipli Tipologie di interrogazione pesate: considerano il peso dell arco multiplo esempio: incasso di ciascun autore con bridge table SELECT ID_Autori, SUM(Incasso*Peso)... group by ID_Autori di impatto: non considerano il peso esempio: numero di copie vendute per ogni autore con bridge table SELECT ID_Autori, SUM(Quantità)... group by ID_Autori Pag. 42

43 Archi multipli Confronto tra le soluzioni realizzative Database and data mining group, il peso è esplicitato nella bridge table, ma integrato nella tabella dei fatti per push down (push down) difficile eseguire interrogazioni di impatto (push down) calcolo del peso durante l alimentazione (push down) modifiche successive difficoltose push down introduce una forte ridondanza nella tabella dei fatti costo di esecuzione delle interrogazioni minore per push down numero minore di join DATA WAREHOUSE: PROGETTAZIONE - 43 Pag. 43

44 Dimensioni degeneri Database and data mining group, Dimensioni rappresentate da un solo attributo Categoria Fornitore Tipo Prodotto Modalità Spedizione LINEA ORDINE Codice ritorno Quantità Importo Stato linea Ordine Cliente Città DATA WAREHOUSE: PROGETTAZIONE - 44 Pag. 44

45 Dimensioni degeneri Soluzioni realizzative integrazione nella tabella dei fatti per attributi di dimensione (molto) contenuta junk dimension Database and data mining group, unica dimensione che integra più dimensioni degeneri non esistono dipendenze funzionali tra gli attributi della dimensione sono possibili tutte le combinazioni attuabile solo per cardinalità limitate del dominio degli attributi DATA WAREHOUSE: PROGETTAZIONE - 45 Pag. 45

46 Junk dimension Database and data mining group, Linea Ordine ID_Ordini ID_Prodotti ID_MCS Quantità Importo Ordine ID_Ordini Ordine Cliente ID_Città MCS ID_MCS Modalità Sped. Codice Ritorno Stato Linea Ordine Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 46 Pag. 46

47 Database and data mining group, Viste materializzate DATA WAREHOUSE: PROGETTAZIONE - 47 Pag. 47

48 Viste materializzate Sommari precalcolati della tabella dei fatti memorizzati esplicitamente nel data warehouse permettono di aumentare l efficienza delle interrogazioni che richiedono aggregazioni Database and data mining group, F 1 = {prodotto, data, negozio} v 2 = {tipo, data, città} v 4 = {tipo, mese, regione} v 3 = {categoria, mese, città} v 5 = {trimestre, regione} Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 48 Pag. 48

49 Viste materializzate DATA WAREHOUSE: PROGETTAZIONE - 49 Database and data mining group, Definite da istruzioni SQL Esempio: definizione di v 3 a partire da tabelle di base o viste di granularità superiore group by Città, Mese, Categoria aggregazione (SUM) sulle misure Quantità, Guadagno riduzione dettaglio delle dimensioni Mese ID_Mese Mese Anno Categoria ID_Categoria Categoria Dipartimento ID_ Città ID_Mese ID_Categoria QuantitàTot GuadagnoTot Città ID_ Città Città Stato Pag. 49

50 Viste materializzate Database and data mining group, Una vista materializzata può essere utilizzata per rispondere a più interrogazioni diverse attenzione al tipo di operatore di aggregazione richiesto {a,b} b' a' b a {a',b} {a,b'} {b} {a',b'} {a} {b'} {a'} { } Reticolo multidimensionale Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 50 Pag. 50

51 Scelta delle viste Database and data mining group, Numero di possibili combinazioni di aggregazioni molto elevato quasi tutte le combinazioni di attributi sono eleggibili Scelta dell insieme ottimo di viste materializzate Minimizzazione di funzioni di costo esecuzione delle interrogazioni aggiornamento delle viste materializzate Vincoli spazio disponibile tempo a disposizione per l aggiornamento tempo di risposta freschezza dei dati DATA WAREHOUSE: PROGETTAZIONE - 51 Pag. 51

52 Scelta delle viste Database and data mining group, q 3 q 1 q 2 DATA WAREHOUSE: PROGETTAZIONE = viste candidate, ossia potenzialmente utili a ridurre il costo di esecuzione del carico di lavoro Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 Pag. 52

53 Scelta delle viste Database and data mining group, Minimizzazione di spazio e tempo q 3 Spazio Tempo disco aggiorn. Costo esec. q 1 q 2 Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 53 Pag. 53

54 Scelta delle viste Database and data mining group, Minimizzazione del costo Spazio Tempo disco aggiorn. Costo esec. q 3 q 1 q 2 Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 54 Pag. 54

55 Scelta delle viste Database and data mining group, Rispetto dei vincoli Spazio disco Tempo aggiorn. Costo esec. q 3 q 1 q 2 Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 55 Pag. 55

56 Database and data mining group, Progettazione fisica DATA WAREHOUSE: PROGETTAZIONE - 56 Pag. 56

57 Progettazione fisica Database and data mining group, Caratteristiche del carico di lavoro interrogazioni con aggregati che richiedono l accesso a una frazione significativa di ogni tabella accesso in sola lettura aggiornamento periodico dei dati con eventuale ricostruzione delle strutture fisiche di accesso (indici, viste) Strutture fisiche tipologie di indici diverse da quelle tradizionali indici bitmap, indici di join, bitmapped join index,... l indice B + -tree non è adatto per attributi con dominio a cardinalità bassa interrogazioni poco selettive viste materializzate richiedono la presenza di un ottimizzatore che le sappia sfruttare DATA WAREHOUSE: PROGETTAZIONE - 57 Pag. 57

58 Progettazione fisica Database and data mining group, Caratteristiche dell ottimizzatore deve considerare le statistiche nella definizione del piano di accesso ai dati (cost based) funzionalità di aggregate navigation Procedimento di progettazione fisica selezione delle strutture adatte per supportare le interrogazioni più frequenti (o più rilevanti) scelta di strutture in grado di contribuire al miglioramento di più interrogazioni contemporaneamente vincoli spazio su disco tempo disponibile per l aggiornamento dei dati DATA WAREHOUSE: PROGETTAZIONE - 58 Pag. 58

59 Tuning Progettazione fisica Database and data mining group, variazione a posteriori delle strutture fisiche di supporto richiede strumenti di monitoraggio del carico di lavoro spesso necessario per applicazioni OLAP Parallelismo frammentazione dei dati parallelizzazione delle interrogazioni inter-query intra-query le operazioni di join e group by si prestano bene all esecuzione parallela DATA WAREHOUSE: PROGETTAZIONE - 59 Pag. 59

60 Scelta degli indici Database and data mining group, Indicizzazione delle dimensioni attributi frequentemente coinvolti in predicati di selezione se il dominio ha cardinalità elevata, indice B-tree se il dominio ha cardinalità ridotta, indice bitmap Indici per i join raramente opportuno indicizzare solo le chiavi esterne della tabella dei fatti consigliato bitmapped join index, se disponibile Indici per i group by uso di viste materializzate DATA WAREHOUSE: PROGETTAZIONE - 60 Pag. 60

61 Database and data mining group, Alimentazione del data warehouse DATA WAREHOUSE: PROGETTAZIONE - 61 Pag. 61

62 Database and data mining group, Extraction, Transformation and Loading (ETL) Processo di preparazione dei dati da introdurre nel data warehouse estrazione dei dati dalle sorgenti pulitura trasformazione caricamento semplificato dalla presenza di una staging area eseguito durante il primo popolamento del DW l aggiornamento periodico dei dati DATA WAREHOUSE: PROGETTAZIONE - 62 Pag. 62

63 Estrazione Acquisizione dei dati dalle sorgenti Modalità di estrazione statica: fotografia dei dati operazionali Database and data mining group, eseguita durante il primo popolamento del DW incrementale: selezione degli aggiornamenti avvenuti dopo l ultima estrazione utilizzata per l aggiornamento periodico del DW immediata o ritardata Scelta dei dati da estrarre basata sulla loro qualità DATA WAREHOUSE: PROGETTAZIONE - 63 Pag. 63

64 Estrazione Dipende dalla natura dei dati operazionali Database and data mining group, storicizzati: tutte le modifiche sono memorizzate per un periodo definito di tempo nel sistema OLTP transazioni bancarie, dati assicurativi operativamente semplice semi-storicizzati: è conservato nel sistema OLTP solo un numero limitato di stati operativamente complessa transitori: il sistema OLTP mantiene solo l immagine corrente dei dati scorte di magazzino, dati di inventario operativamente complessa DATA WAREHOUSE: PROGETTAZIONE - 64 Pag. 64

65 Estrazione incrementale Database and data mining group, Assistita dall applicazione le modifiche sono catturate da specifiche funzioni applicative richiede la modifica delle applicazioni OLTP (o delle API di accesso alla base di dati) aumenta il carico applicativo necessaria per sistemi legacy Uso del log accesso mediante primitive opportune ai dati del log formato proprietario del log efficiente, non interferisce con il carico applicativo DATA WAREHOUSE: PROGETTAZIONE - 65 Pag. 65

66 Estrazione incrementale Database and data mining group, Definizione di trigger i trigger catturano le modifiche di interesse non richiede la modifica dei programmi applicativi aumenta il carico applicativo Basata su timestamp i record operazionali modificati sono marcati con il timestamp dell ultima modifica richiede la modifica dello schema della base di dati OLTP (e delle applicazioni) estrazione differita, può perdere stati intermedi se i dati sono transitori DATA WAREHOUSE: PROGETTAZIONE - 66 Pag. 66

67 Database and data mining group, Confronto tra le tecniche di estrazione Gestione dati transitori o semi-storicizzati Supporto per sistemi basati su file Tecnica di realizzazione Costi di sviluppo interno Utilizzo in sistemi legacy Modifiche ad applicazioni Dipendenza delle proedure dal DBMS Impatto sulle prestazioni del sistema operaz. Complessità delle procedure di estrazione Statica Marche temporali Assistita applicazione Trigger Log NO Incompleta Completa Completa Completa SI SI SI NO Raro Prodotti Prodotti o sviluppo interno Sviluppo interno Prodotti Prodotti Nessuno Medi Alti Nessuno Nessuno SI Difficile Difficile Difficile SI Nessuna Probabile Probabile Nessuna Nessuna Limitata Limitata Variabile Alta Limitata Nessuna Nessuna Medio Medio Nessuna Bassa Bassa Alta Media Bassa Tratto da Devlin, Data warehouse: from architecture to implementation, Addisono-Wesley, 1997 DATA WAREHOUSE: PROGETTAZIONE - 67 Pag. 67

68 Database and data mining group, Estrazione incrementale Cod /4/2010 Prodotto Cliente Greco di tufo Malavasi Barolo Maio Barbera Lumini Sangiovese Cappelli Qtà Cod /4/2010 Prodotto Cliente Greco di tufo Malavasi Barolo Maio Sangiovese Cappelli Vermentino Maltoni Trebbiano Maltoni Qtà Cod Differenza incrementale Prodotto Cliente Qtà Barbera Lumini 75 Sangiovese Cappelli 145 Vermentino Maltoni 25 Trebbiano Maltoni 150 Azione D U I I Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 68 Pag. 68

69 Pulitura Database and data mining group, Operazioni volte al miglioramento della qualità dei dati (correttezza e consistenza) dati duplicati dati mancanti uso non previsto di un campo valori impossibili o errati inconsistenza tra valori logicamente associati Problemi dovuti a errori di battitura differenze di formato dei campi evoluzione del modo di operare dell azienda DATA WAREHOUSE: PROGETTAZIONE - 69 Pag. 69

70 Pulitura Database and data mining group, Ogni problema richiede una tecnica specifica di soluzione tecniche basate su dizionari adatte per errori di battitura o formato utilizzabili per attributi con dominio ristretto tecniche di fusione approssimata adatte per riconoscimento di duplicati/correlazioni tra dati simili join approssimato problema purge/merge identificazione di outliers o deviazioni da business rules La strategia migliore è la prevenzione, rendendo più affidabili e rigorose le procedure di data entry OLTP DATA WAREHOUSE: PROGETTAZIONE - 70 Pag. 70

71 Join approssimato Database and data mining group, DB Marketing DB Amministrazione CF codice ordine data quantità CLIENTE ORDINE nome indirizzo cliente cliente cognome cliente codice indirizzo cognome cliente cliente cliente CF CLIENTE nome indirizzo cliente cliente cognome cliente fa (0,n) (1,1) codice ordine Data data ORDINE quantità Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 Il join deve essere eseguito sulla base dei campi comuni, che non rappresentano un identificatore per il cliente DATA WAREHOUSE: PROGETTAZIONE - 71 Pag. 71

72 Problema purge/merge Database and data mining group, DB Marketing sede di Roma CF DB Marketing sede di Milano CF CLIENTI SEDE ROMA CLIENTI SEDE MILANO nome indirizzo cliente cliente cognome cliente nome indirizzo cliente cliente cognome cliente CF CLIENTI nome indirizzo cliente cliente cognome cliente Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 I record duplicati devono essere identificati ed eliminati E` necessario un criterio per valutare la somiglianza tra due record DATA WAREHOUSE: PROGETTAZIONE - 72 Pag. 72

73 Esempio di pulitura e trasformazione C.so Duca degli Abruzzi Torino (I) nome: Elena cognome: Baralis Normalizzazione indirizzo: C.so Duca degli Abruzzi 24 CAP: città: Torino nazione: I nome: Elena cognome: Baralis indirizzo: Corso Duca degli Abruzzi 24 CAP: città: Torino nazione: Italia Database and data mining group, Standardizzazione nome: Elena cognome: Baralis Correzione indirizzo: Corso Duca degli Abruzzi 24 CAP: città: Torino nazione: Italia Adattato da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 73 Pag. 73

74 DATA WAREHOUSE: PROGETTAZIONE - 74 Database and data mining group, Trasformazione Conversione dei dati dal formato operazionale a quello del data warehouse (integrazione) Richiede una rappresentazione uniforme dei dati operazionali (schema riconciliato) Può avvenire in due passi dalle sorgenti operazionali ai dati riconciliati nella staging area conversioni e normalizzazioni matching (eventuale) filtraggio dei dati significativi dai dati riconciliati al data warehouse generazione di chiavi surrogate generazione di valori aggregati Pag. 74

75 Caricamento Propagazione degli aggiornamenti al data warehouse Database and data mining group, Per mantenere l integrità dei dati, si aggiornano in ordine 1. dimensioni 2. tabelle dei fatti 3. viste materializzate e indici Finestra temporale limitata per eseguire gli aggiornamenti Richiede proprietà transazionali (affidabilità, atomicità) DATA WAREHOUSE: PROGETTAZIONE - 75 Pag. 75

76 Database and data mining group, Alimentazione delle dimensioni ODS Tuple dimensione aggiornate/inserite Staging area ID1 attr 1 attr 2. ID2 attr 3 attr 4. ID2 attr 1 attr 3 attr 5 attr 6 Identificazione aggiornamenti ID3 attr 5 attr 6. ID2 chiaves Verifica delle corrispondenze identificatori - chiavi surr. Dimension Table chiaves attr 1 attr 3 attr 5 attr 6 Data mart Tabella di look-up Tuple da inserire nella dimensione chiaves attr 1 attr 3 attr 5 attr 6 Caricamento nella dimension table Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 76 Pag. 76

77 Database and data mining group, Alimentazione delle fact table Identificazione aggiornamenti ODS ID5 attr 3 attr 4 Staging area ID4 attr 1 attr 2 Tuple della fact table aggiornate/inserite ID6 attr 5 attr 6 ID4 ID5 ID6 mis 1 mis 3 mis 5 ID4 chiaves4 Data mart Tabelle di look-up ID5 chiaves5 Verifica delle corrispondenze identificatori - chiavi surr. Fact Table chiaves4 chiaves5 chiaves6 mis 1 mis 3 mis 5 mis 6 ID6 chiaves6 Tuple da inserire nella FT chiaves4 chiaves5 chiaves6 mis 1 mis 3 mis 5 mis 6 Caricamento nella fact table Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 77 Pag. 77

78 Alimentazione delle viste materializzate Database and data mining group, {a,b} {a',b} {a,b'} {b} {a',b'} {a} {b'} {a'} { } Tratto da Golfarelli, Rizzi, Data warehouse, teoria e pratica della progettazione, McGraw Hill 2006 DATA WAREHOUSE: PROGETTAZIONE - 78 Pag. 78