Sistemi Informativi Aziendali. Sistemi Informativi Aziendali. Sistemi Informativi Aziendali

Transcript

1 DIPARTIMENTO DI INGEGNERIA INFORMATICA AUTOMATICA E GESTIONALE ANTONIO RUBERTI Introduzione al Data Warehousing per b. Progetto di Datawarehouse 1

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

3 Ciclo di vita (Kimball, 1998) pianificazione definizione requisiti progetto architettura modellazione dimensionale specifica applicazioni gestione progetto tecnologia selezione e installazione prodotti realizzazione dati progetto fisico progetto e sviluppo alimentazione manutenzione applicazioni sviluppo applicazioni 3

4 Flussi dati & Evoluzione progettuale DW Flusso dati Logica di progettazione 4

5 Fasi di progetto di un Data Mart 1. Analisi e riconciliazione delle fonti dati schemi delle sorgen schema riconciliato 2. Analisi dei requisiti schema riconciliato fa, carico lavoro 3. Progetto Concettuale schema riconciliato, fa, carico lavoro schemi di fa o 4. Progetto Logico schemi di fa o, carico lavoro schema logico Data Mart 5. Progetto dell Alimentazione schemi di fatto star-schema, snowflakes entità-relazione schemi delle sorgenti, schema riconciliato, schema logico Data Mart procedure alimentazione 6. Progetto Fisico schema logico Data Mart, carico lavoro, DBMS schema fisico DM 5

6 Riconciliazione delle fonti dati Integrazione di schemi: a un passo a scala bilanciato iterativo 6

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

8 Progetto Concettuale 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 8

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

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

11 Schema logico DB operazionale -revisione denormalizzazione ELIMINAZIONE DI ATTRIBUTI: vengono tolti dallo schema gli attributi che non interessano data citta DATA (1,n) emessa VENDITA 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 quantita incasso riferita ARTICOLO 11

12 Schema di fatto (preliminare) DIMENSIONI FATTO data (TEMPO) (SPAZIO) MISURE VENDITA quantità incasso (MERCE) 12

13 Gerarchie dimensionali anno gerarchia TEMPO gerarchia SPAZIO trimestre mese settimana zona regione responsabile distretto citta data Dettagli (granularità) In base a specifiche di utente gerarchia MERCE sottogenere marca genere città_marca 13

14 Schema di fatto DFM (Dimensional Fact Model) anno trimestre mese settimana zona regione responsabile distretto città data VENDITA quantità incasso sottogenere marca genere città_marca 14

15 Schema di Fatto (esempio) ALL trimestre anno Es: vendite mensili per città e per marca mese data settimana ALL zona regione responsabile distretto città VENDITA quantità incasso sottogenere marca genere città_marca ALL 15

16 Schema ER settimana (1,n) SETTIMANA anno trimestre mese data ANNO (1,n) TRIMESTRE (1,n) MESE (1,n) DATA responsabile (1,n) ZONA zona RESPONSABILE (1,n) quantita emessa citta incasso (1,n) REGIONE CITTA situato NEGOZIO presso VENDITA regione distretto DISTRETTO CITTA_MARCA MARCA riferita ARTICOLO citta_marca marca GENERE SOTTOGENERE appartiene genere sottogenere 16

17 Gerarchie condivise e ruoli anno trimestre mese settimana data responsabile distretto VENDITA quantità incasso sottogenere genere città_ città_marca marca zona regione città può essere interessante valutare la distribuzione territoriale dei marchi di successo 17

18 Archi multipli (relazioni n:n) anno trimestre mese settimana un può avere (avuto) più responsabili responsabile distretto data VENDITA quantità incasso sottogenere genere città_ marca città_marca zona regione città 18

19 Attributi cross-dimensionali anno trimestre mese settimana data responsabile VENDITA quantità incasso sottogenere genere zona distretto città_ regione città città_marca marca può esistere una percentuale di provvigione può dipendere dalla marca e dal perc_provvigione 19

20 Schema ER (rivisto) settimana SETTIMANA (1,n) anno trimestre mese data ANNO (1,n) TRIMESTRE (1,n) MESE (1,n) DATA responsabile (1,n) ZONA zona RESPONSABILE (1,n) quantita emessa citta (1,n) incasso (1,n) REGIONE CITTA situato NEGOZIO presso VOCE_V regione percent distretto DISTRETTO riferita PROVVIGIONE ha_sede MARCA ARTICOLO GENERE marca SOTTOGENERE appartiene genere sottogenere 20

21 Manipolazione delle gerarchie zona regione responsabile distretto città potatura innesto città responsabile zona responsabile citta distretto distretto 21

22 Alternative di rappresentazione per DW: *OLAP 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) 22

23 Architettura ROLAP middleware R-DBMS(+) SQL (+) OLAP client metadati DW (DB relazionale) soluzioni dedicate componente modulare 23

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

25 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-keyper ciascuna delle dimension tables un attributo per ciascuna misura Completa DENORMALIZZAZIONE (a parte la fact table) 25

26 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 ID_NEGOZIO distretto responsabile città regione zona 26

27 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 primarianello Star-Schema può essere decomposta dando luogo ad una collezione di dimension table secondarie una singola fact table: chiave primaria: una foreign-keyper ciascuna delle dimensioni (e per ciascuna dimension table primaria) un attributo per ciascuna misura 27

28 Esempio di schema SNOWFLAKE 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 ID_NEGOZIO distretto responsabile ID_CITTA 28

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

30 Reticolo delle Viste mese VENDITE marca giorno quantità incasso prezzo_unit,giorno,mese marca,mese marca,giorno giorno marca mese {} 30

31 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 {} 31

32 Bibliografia M. Golfarelli, S. Rizzi. Data Warehouse Teoria e Pratica della Progettazione (2 a ed.) McGraw-Hill,