Le organizzazioni da sempre hanno archiviato i da7 di business ma l'incompleto sfru<amento del loro potenziale ha sempre rappresentato un problema.

Transcript

1 Data warehouse

2 DW Le organizzazioni da sempre hanno archiviato i da7 di business ma l'incompleto sfru<amento del loro potenziale ha sempre rappresentato un problema. Sorge dunque la necessità di ges7re la considerevole quan7tà di da7, normalizzandoli indipendentemente dalla fonte di provenienza e rendendoli disponibili all'organizzazione. A questa esigenza, sempre più sen7ta nel mondo delle aziende, offre una risposta concreta il data warehouse 2

3 DataWarehouse Il DW è la base di da/ concepita per sistemi a supporto delle decisioni. o$mizzata per il recupero di da1 e non per il normale processamento di transazioni (vr DB) Federica Cena 3

4 DW: definizioni Immon (1992): collezione di da7 integrata, non vola7le, orientata ai soggei, e variabile nel tempo, a supporto delle decisioni dei dirigen7 Dayal (1997): un insieme di tecnologie di supporto alle decisioni, proge<ate per consen7re al knowledge worker di prendere decisioni migliori e rapide Chyr(2001): una collezione di da7 integra7,organizzata per soggei, che riguardano una serie di fai accadu7 nel tempo finalizzata al recupero di informazione a supporto di processi decisionali Federica Cena 4

5 DW: definizioni Un data warehouse è una base di daa persistente e condivisa u7lizzata principalmente per il supporto alle decisioni direzionali Orientata al sogge<o (al decisore) Integrata (aziendale e non dipar7mentale) con da7 storici (con un ampio orizzonte temporale) con da7 7picamente aggrega7 per effe<uare s7me mantenuta separatamente dalle basi di da7 operazionali Federica Cena- 5

6 DB vr DW DW forniscono funzionalità aggiun7ve rispe<o a quelle delle basi di da7 orientate alle transazioni, in termini di: Funzionalità (7po di risposta) Integrazione di da7 eterogenei Le basi di da7 tradizionali garan7scono: velocità di accesso integrità dei da7 (controllo concorrenza) Federica Cena 6

7 DB: OLTP OLTP: On-Line TransacAon Processing: elaborazione online delle transazioni, comprende la ges7one delle operazioni di inserimento, aggiornamento, cancellazione, interrogazione di una base di da7. Le basi di da7 relazionali sono oimizzate per eseguire query OLTP: coinvolgono una piccola parte della base di da7. le transazioni sono predefinite e di breve durata i da7 di interesse sono de<aglia7, aggiorna7 e recent i da7 risiedono su una unica base di da7 Federica Cena 7

8 DB: OLTP: operatori Inserimento (insert into) Aggiornamento (update) Cancellazione (delete) Interrogazione (select, from, where) Linguaggio SQL query interfaccia grafica di Access dammi il nome concerto che si è tenuto al conservatorio dammi la matricola dello studente con cognome rossi Federica Cena 8

9 DW: OLAP OLAP: On-Line AnaliAcal Processing: elaborazione distribuita delle informazioni sugli uten7 al fine di analisi per ricavare nuova conoscenza usabile per prendere decisioni strategiche operatori di manipolazione dei da7 modella7 con stru<ure mul7dimensionali I datawarehouse memorizzano i da7 in modo da oimizzare le operazioni OLAP: I da7 sono aggrega7 I da7 sono storici I da7 sono integra7 Federica Cena 9

10 OLAP: operatori Drill-down/roll-up: zoom in/ zoom out Dice/slice: sezionare i da7 No linguaggi standard Vedremo più avan7 Federica Cena 10

11 DW vr DB Diversamente dalle basi di da7 transazionali, i dw supportano serie temporali una tecnica che richiede più da7 storici di quelli che sono presen7 nelle basi di da7 transazionali una serie temporale si definisce come un insieme di variabili casuali ordinate rispe<o al tempo, ed esprime la dinamica di un certo fenomeno nel tempo Le informazioni sono a granularità più grossa nel DW, nei DB invece sono atomiche Federica Cena 11

12 DW vr DB Poiché racchiudono grandi volumi di da7, i dw generalmente sono un ordine di grandezza più grandi delle basi di da7 tradizionali. Ques7 volumi di da7 possono essere ges77: Dw a livello di impresa: grandi progei che richiedono un cospicuo inves7mento di tempo e risorse Data mart: rivol7 ad un so<oinsieme dell organizzazione, ad esempio, un reparto e risultano quindi stre<amente focalizza7 Federica Cena 12

13 DW vr BD DW basa7 sul conce<o di FATTO di INTERESSE Storicizza da7 che nei sistemi operazionali sono sovrascrii L arco temporale considerato (4 anni o piu) è superiore al lasso temporale ges7to dai sistemi operazionali (1-2 anni) Ampia quan7tà di da7 cardinalita delle relazioni: db: 1:m, 1:1, 1:n dw: m:n Federica Cena 13

14 14

15 Business Intelligence Modello dei dati

16 Datawarehousing Basi dati dei sistemi decisionali:! Insieme di dati +! strumenti per effettuare vari tipi di interrogazioni a carattere statistico e analitico (operatori OLAP) Federica Cena 2

17 Modello dei dati! DW basati sul concetto di FATTO di INTERESSE! Si basa su modello dei dati multidimensionale! Modello dimensionale - Semplice da capire - Non ambiguo - Riflette il modo in cui i decision maker pensano Federica Cena 3

18 Analisi dimensionale Domande cui vogliono rispondere i decisori:! Informazioni riassuntive, con la possibilità di dettagliare i riassunti! Analisi delle informazioni riassuntive in base a componenti organizzative come aree e dipartimenti! Possibilità di slice (affettare) and dice (tagliare a dadini) delle informazioni! Possibilità di vedere le informazioni nel tempo! Vedere le informazioni sia in forma tabulare che grafica 4 Federica Cena-

19 Analisi dimensionale È un metodo di progettazione del DW Consiste nell intervistare i decision maker e chiedere in quale - Subject area sono maggiormente interessati - Quali sono le più importanti dimensioni di analisi 5 Federica Cena-

20 Modello dei dati multidimensionale! Fatto: concetto di interesse per il processo decisionale (ad esempio, vendite)! Misure: proprietà numerica di un fatto, descrive un aspetto quantitativo (quantità venduta, incasso)! Dimensioni: proprietà con un dominio finito di un fatto, descrive una coordinata di analisi (luogo, prodotto)! Un fatto è analizzato attraverso tante dimensioni. Federica Cena 6

21 Modello multidimensionale Fatti: behavioural, dati comportamentali, derivano da interazione utente con il sistema, dinamici, cambiano Dimensioni: circumstances (attributi), cambiano meno Ma i cambiamenti dei behavioural dipendono da circumstances: bisogna gestire il cambiamento delle dimensioni - Tempo di validità: da.. A.. - Tabella in relazione 1:m con la dimensione 7 Federica Cena-

22 Esempio di analisi! Possibili dimensioni " Prodotto (tipo di prodotto) " Tempo (mese, bimestre, anno) " Cliente (dettaglio, grossista, diretto) " Responsabilità (punto vendita, rivenditore)! Lo schema multidimensionale favorisce la multidimensionalità del ragionamento " Che cosa? chi? Quanto? Come? Dove? 8

23 Esempio di analisi I dati vengono analizzati per identificare tendenze e, quindi, facilitare il processo decisionale " Quale e il mese con le maggiori vendite? " Quali sono stati i primi cinque prodotti venduti a Pisa? Interessano non solo i dati ma anche le loro aggregazioni (media, il minimo, massimo, somma, etc) 9

24 Esempio di analisi 10

25 Datawarehouse: obiettivi Federica Cena 11

26 ! Rappresentazione a matrice Federica Cena 12

27

28 Modello multidimensionale! Le dimensioni possono essere più di tre, ma non è intuitivo immaginarlo! Anche le misure possono essere più di una (nella cella ci saranno più valori) 14

29 Federica Cena 15

30 16

31 Cubo Assi: tempo, cliente, prodotto misura: vendita Ogni elemento del cubo (minicubo) contiene i valori di vendita per un particolare cliente, prodotto at un tempo particolare Federica Cena- 17

32 Caratteristiche dei DW Federica Cena 18

33 Gerarchia delle dimensioni! Ogni dimensione può essere strutturata in una gerarchia di variabili che rappresentano diversi livelli di aggregazione! esempio dimensione punto vendita 19

34 Gerarchia delle dimensioni esempio dimensione tempo 20

35 Gerarchia delle dimensioni esempio dimensione prodotto 21

36 Modellazione Concettuale

37 Modello concettuale: 2 tipi! A stella (star)! A fiocco di neve (snowflakes) Federica Cena 23

38 Modello concettuale a stella Punto vendita m:n prodotto vendita tempo m:n 24

39 Modello concettuale a fiocco di neve m:1 region e Prodotto m:n citta m:1 provin cia vendita tempo m:n 25

40 Modello concettuale: modalità di rappresentazione! Si puo disegnare con " Schema E-R (come data base) " DOT model (rappresenta i fatti come punti) 26

41 Modello concettuale dei dati! Dimensional Fact Model [Golfarelli- Rizzi] (DFM) e un modello concettuale grafico per DW che contiene fatti, dimensioni, gerarchie. DFM definisce una visione concettuale astratta di ogni fatto disponibile nel sistema! 27

42 Modello concettuale (Dot Model) Dimensione Operatori Clienti Provincia Regione Regione Provincia_dest Professio ne Categoria Localizz_dest Viaggi Sistemazione Mezzi Periodo

43 Modello concettuale Decisioni riguardanti la costruzione del data base per il dw Passi: 1. Decidere i fatti 2. Decidere le unità di misura 3. Decidere la granularità di analisi: dimensioni 4. Decidere attributi delle dimensioni 5. Decidere quali aggregazioni e partizionamenti (gerarchie) 6. Decisioni riguardo il tempo 7. Costruzione del modello concettuale, scegliendo il formalismo: 1. Dot modeling 2. Fact Dimension Model 1

44 Requisiti Modello concettuale - Semplice da capire - In grado di supportare il tempo - Modello semplificato rispetto a base di dati - La struttura è predicibile (è sempre la stessa): tab dei fatti al centro con le dimensioni collegate - Le relazioni sono sempre 1:m dove : - La dimensione è la parte 1 della relazione e la tabella dei fatti è la parte M - Gerarchia: la dimensione più vicina ai fatti è la parte many, l entità più esterna è la parte 1 Non serve specificare la cardinalità minima La dimensione 1 è sempre facoltativa La dimensione m è sempre obbligatoria Non ci sono sovracclassi 2

45 La progettazione concettuale del data warehouse In conformità con il testo raccomandato, seguiamo il modello DFM: Dimensional Fact Model Realtà rappresentata da un insieme di schemi di fatto Fatto: concetto di interesse per il processo decisionale. I fatti di interesse di norma hanno una frequenza di cambiamento significativa. Ad esempio Vendita è un buon candidato, ma anche Promozione di un prodotto Misura: è una proprietà numerica di un fatto e ne descrive un aspetto di interesse per l analisi. Es.: quantià o valore del venduto, Dimensione: è una proprietà di un fatto, con dominio finito, che descrive una coordinata di analisi. Es.: Tipo prodotto, data, negozio, Evento primario: occorrenza di un fatto individuata da una ennupla costituita da un valore per ciascuna dimensione e misura 16

46 Un fatto esprime un associazione molti a molti tra le dimensioni Es.: fatto Vendita (notazione ER) Prodotto Prodotto (0,n) Data Negozio Data (0,n) Vendita (0,n) Negozio Qtà venduta Incasso Prezzo unitario Num. clienti 17

47 Un fatto esprime un associazione molti a molti tra le dimensioni Es.: fatto Vendita (notazione ER) Dimensioni Prodotto Prodotto (0,n) Data Fatto Negozio Data (0,n) Vendita (0,n) Negozio Qtà venduta Incasso Prezzo unitario Num. clienti Misure 18

48 Un fatto esprime un associazione molti a molti tra le dimensioni Es.: Schema di fatto Vendita Prodotto Dimensioni Fatto Data Vendita Qtà venduta Incasso Prezzo unitario Num. clienti Negozio Misure Con tale notazione si intende dimensione obbligatoria, cioè ogni vendita dovrà essere obbligatoriamente abbinata ad una data, ad un prodotto e ad un negozio 19

49 Attributo dimensionale: dimensione ed eventuali altri attributi che le descrivono Gerarchia: albero i cui nodi sono attributi dimensionali e i cui archi modellano associazioni molti a uno tra coppie di attributi dimensionali. Una gerarchia racchiude una dimensione e tutti gli attributi che la descrivono. Responsabile Negozio Città Regione Stato Distretto Le gerarchie si formalizzano con dipendenze funzionali Negozio Città Regione Responsabile, Città, Distretto Regione Stato Il valore di regione dipendende da citta, il valore di stato dipende da quello di regione 20

50 Uno schema di fatto molto più ricco 21

51 Costrutti addizionali usati nello schema precedente Attributo descrittivo: aggiunge informazione all attributo dimensionale Es.: con notazione relazionale (Città-del-negozio, indirizzo, telefono) (Prodotto, peso). Gli attributi e le dimensioni possono essere opzionali, come indicato in figura con un trattino. 22

52 Schema ER da cui Si può derivare lo schema di fatto Vendite 24

53 Altri aspetti della modellazione concettuale Le gerarchie condivise SPEDIZIONE Prodotto Costo Magazzino Ordine Data sped. Responsabile Città Regione Stato Cliente Data consegna Data Mese Anno Le gerarchie condivise da più dimensioni sono denotate da un pallino pieno.. Gli archi entranti di inizio dimensione condivisa devono essere etichettati con un ruolo per specificarne il significato. 25

54 Archi multipli (x attributi multivalore Prodotti SPEDIZIONE Costo Magazzino Ordine Data sped. Responsabili Città Regione Stato Cliente Data Mese Anno Data consegna Un fatto è caratterizzato di norma da un solo valore per ogni dimensione. Può tuttavia essere utile disporre di dimensioni multivalore (doppio tratto), come da esempio, dove la spedizione riguarda più prodotti e il magazzino è descritto dai suoi responsabili. Altro esempio classico la dimensione libro: Libro Genere Autori 26

55 Gerarchie incomplete Nazione Regione Provincia Italia Rep. S. Mariono Città del Vaticano Piemonte Torino Comune Poirino Serravalle S. Marino. Con gerarchia incompleta si intende la possibile assenza di valori lungo il percorso gerarchico. 27

56 3: TEMPO: Dinamicità delle gerarchie Le gerarchie sono adeguatamente modellate dalle dipendenze funzionali Negozio Responsabile, Distretto Tipo GruppoMarketing Categoria Reparto. Le dipendenze funzionali implicano una visione statica della realtà che invece può modificarsi nel tempo. Es.: si alterano i confini dei distretti, cambiano i responsabili dei negozi, si aggiornano i gruppi marketing dei prodotti, le categorie dei pro dotti sono cambiati di reparto, dipendenze funzionali con periodo di validità [Data Inizio, Data Fine] 29

57 sscenari TEMPORALI. [x, 01] Negozio1 [02, x] Negozio1 [x, 02] Negozio1 [03, x] Negozio1 ResponsabileRossi ResponsabileBianchi DistrettoPiemonteLiguria DistrettoPiemonte Più che la modellazione concettuale, la dinamica delle gerarchie influenza la progettazione logica del data warehouse in funzione di come tale dinamica sarà utilizzata dalle interrogazioni, in quattro scenari: 1. oggi o ieri 2. ieri per oggi 3. oggi per ieri 4. ieri e oggi 30

58 Es.: Siamo interessati agli incassi dei negozi dal 2000 al 2004 [x, 01] Negozio1 [02, x] Negozio1 [x, 02] Negozio1 [03, x] Negozio1 ResponsabileRossi ResponsabileBianchi DistrettoPiemonteLiguria DistrettoPiemonte Oggi o ieri: Ciascun evento è riferito al valore delle gerarchie nell istante di tempo in cui si è verificato. Negozio Responsabile Rossi Rossi - Bianchi- Bianchi Bianchi Distretto PiemonteLiguria PiemonteLiguria PiemonteLiguria Piemonte Piemonte Incassi

59 Es.: Siamo interessati agli incassi del Negozio1 dal 2000 al 2004 [x, 01] Negozio1 [02, x] Negozio1 [x, 02] Negozio1 [03, x] Negozio1 ResponsabileRossi ResponsabileBianchi DistrettoPiemonteLiguria DistrettoPiemonte Ieri per oggi: Ciascun evento è riferito al valore iniziale delle gerarchie. Negozio Responsabile Rossi Rossi Rossi Rossi Rossi Distretto PiemonteLiguria PiemonteLiguria PiemonteLiguria PiemonteLiguria PiemonteLiguria Incassi Se Negozio2 ha iniziato le attività nel 2002 non apparirà nel rapporto 32

60 Es.: Siamo interessati agli incassi del Negozio1 dal 2000 al 2004 [x, 01] Negozio1 [02, x] Negozio1 [x, 02] Negozio1 [03, x] Negozio1 ResponsabileRossi ResponsabileBianchi DistrettoPiemonteLiguria DistrettoPiemonte Oggi per ieri: Eventi ascritti alla situazione delle gerarchie alla data odierna. Negozio Responsabile Bianchi Bianchi Bianchi Bianchi Bianchi Distretto Piemonte Piemonte Piemonte Piemonte Piemonte Incassi lo stato corrente diventa il referente anche per il passato 33

61 Oggi e ieri: Vengono considerati solo gli eventi che si riferiscono a valori immutati della gerarchia. Ad esempio i negozi che hanno mantenuto lo stesso responsabile e lo stesso distretto. Le varie gerarchie è bene siano abbinate agli scenari di analisi possibili. oggi o ieri oggi p ieri ieri p oggi ieri e oggi negozio responsabi x x negozio distretto x x x x categoria reparto x In genere si assume per default oggi per ieri che semplifica il data warehouse in quanto viene memorizzato solo lo stato corrente della gerarchia. 34

62 Additività delle misure L aggregazione delle misure lungo una gerarchia dipende richiede operatori adatti a seconda della categoria della misura proposta da Lenz: Flusso: misure cumulative in una certa quantità di tempo. Es.: incasso giornaliero, numero prodotti venduti, numero clienti, Livello: misurato in un dato istante di tempo. Es.: numero prodotti in magazzino, abitanti di una città, Misura unitaria: valutata in un istante di tempo è una proprietà di qualche oggetto. Es.: prezzo unitario di un prodotto, cambio di una valuta 35

63 In un progetto occorre definire con precisione gli operatori di aggregazione che verranno utilizzati nelle interrogazioni, tuttavia occorre precisare che l aggregazione di una misura lungo una gerarchia non è detto sia sempre possibile o sensata. L esempio Vendite Prodotto Data Negozio Promozione Quantità venduta SUM SUM SUM SUM Incasso SUM SUM, AVG SUM, MIN, MAX SUM N clienti - SUM SUM SUM Prezzo unitario AVG AVG, MIN, MAX AVG AVG Supponiamo di valutare il N clienti contando gli scontrini emessi in una certo giorno (data) e negozio. Se salgo a livello di Reparto nella gerarchia Prodotto non c è modo di desumere il numero totale di clienti con qualche funzione di aggregazione. 36

64 Ed ora accenniamo alla derivazione dello schema di fatto da uno schema ER 37

65 A partire da Vendita, Si percorrono le associazioni (x,1) introducendo una dimensione per ogni entità incontrata. Le dimensioni possono essere arricchite con attributi dell entità e delle associazioni. Categoria Tipo Gruppo marketing Prodotto Vendita Qtà venduta Incasso 38

66 Schema ER con ciclo Schema di fatto con e senza ciclo Budget Struttura organizzativa (1, n) (1, 1) Aff Responsabile (1, 1) (0, 1) Budget Struttura organizzativa Impiegato (1, n) Impiegato Budget Budget Impiegato Divisione Capo reparto Reparto (1, 1) Ore Incarico (1, 1) (1, n) Progetto Data Progetto Data INCARICO Ore lavorate INCARICO Ore lavorate NB.: solo le associazioni (x,1) possono dare origine a dimensioni. 39

67 La confluenza di cammini può dare origine ad un attributo cross dimensionale. Es.: IVA a gerarchie condivise se i percorsi non sono ridondanti. (a) (b) Reparto Responsabile Responsabile Data (0, n) Da A (0, n) (1, 1) Responsabile Da Reparto A Da Reparto A (1, 1) (1, 1) Impiegato (0, 1) Trasferimenti Num per anno Trasferimenti Anno Impiegato Data NB.: sono possibili schemi di fatto vuoti (privi di misure) 40

68 Grana temporale e grana transazionale di uno schema di fatto Grana temporale, ciascun evento primario condensa in sé un insieme di più transazioni (aziendali) in una unità di tempo. Es.: Vendita, grana giornaliera (data = g.m.a.) Trasferimenti, grana annuale (data = anno) Grana transazionale, ciascun evento primario coincide con una transazione operazionale Es.: Incarico, Attività Spedizione 41

69 Il tempo Fattore chiave nei sistemi data warehouse Il tempo appare quasi sempre tra le dimensioni. Il problema nasce se si deve tenere traccia sia del tempo di validità dell evento (valid time) sia del tempo di notifica dell evento che chiameremo (transaction time). Es.: Richiesta di pensionamento (transaction time), inizio pensione (valid time) noto all atto della richiesta. Anno Mese Data Richiesta A riposo Pensione Notifica morte (transaction time), data morte (valid time) notificata. 42

70 Il tempo In genere l evento notificato contiene entrambe le date, ma non sempre: Richiesta di immatricolazione (transaction time), so che c è un potenziale nuovo studente all inizio dell anno accademico (valid time). Data di validazione solo dopo la verifica del pagamento delle tasse che può avvenire molto tempo dopo la presentazione della richiesta, addirittura prima o dopo il valid time. Altro esempio: Richiesta di esame clinico (transaction time), so che c è un potenziale paziente in una certa data (valid time) da esaminare. Data di validazione al pagamento del ticket che può avvenire molto tempo dopo la richiesta. Scopo del data warehouse sia la storicizzazione delle richieste e delle validazioni. 43

71 Fissato anno accademico (a.a.) e corso di studi (ccs), Ogni coppia di date registra il numero di studenti che hanno presentato domanda in Data Richiesta e sono stati convalidata in Data Convalida. I totali sono possibili usi del data ware house. ccs a.a. ISCRIZIONE Num. stud Richiesta Convalida Data Mese Anno Giorno presentazione domanda Validazione L M M G V S L 1 1 M M G V S Tot matricole Totale domante 44