Sviluppo di un Data Warehouse

Transcript

1 Sviluppo di un Data Warehouse Fase Ingresso Uscita Analisi e riconciliazione fonti Requisiti Prog. concettuale Raffinamento e validazione SS: Schemi delle sorgenti Obiettivi strategici SR: Schema Riconciliato RQ: Requisiti CL: carico lavoro Figure coinvolte + progettista dba operazionali Utenti finali SR + RQ SF: Schemi di Fatto Utenti finali SF + CL CL2: Carico lavoro, SFV: Schemi di fatto validati Prog. logica SFV + CL2 SL: Schema logico Alimentazione SS+ SR+SL Procedure alimentazione Prog. fisica Schema fisico data SL+CL2+dbms mart Utenti finali dba operazionali 1

2 Analisi e riconciliazione delle fonti dei dati La fase è particolarmente critica se le fonti presentano un alta eterogeneità. Schema riconciliato Schema esportato R1 Modello ER Schema esportato R2 Schema locale 1 Modello locale Schema locale 2 Fonte dati 1 Fonte dati 2 Architettura analoga quella delle basi di dati federate 2

3 Possibili relazioni tra due rappresentazioni R1 e R2 Identità: R1 coincide con R2, è il caso fortunato. Equivalenza: Se le istanze di R1 e R2 possono essere messe in corrispondenza uno a uno, isomorfismo tra attributi: stessi attributi, a meno di ridenominazione, stesso insieme di dipendenze funzionali. Esempio: ISBN ISBN Libro (1,1) Titolo Titolo Libro Casa Ed. Edito da (1,n) Casa Editrice Nome Indirizzo Con vincolo: Casa Ed Indirizzo Casa Ed. Ind. 3

4 Comparabilità: Schemi non in contrasto, ma con punti di vista diversi, Esempio: Dipendente assegnato a Dipartimento Lavora a Dipendente (0,1) CF Nome CF Dipendente (0,1) Nome Assegnato (1,n) Progetto (1,1) Cod Descrizione (1,n) Dipartimento Nome Ind. Appartiene (1,n) Dipartimento Nome Ind. La diversità risiede nel diverso Grado di dettaglio 4

5 Incompatibilità, quando R1 e R2 sono in contrasto Esempio: personale tecnico e amministrativo dell Università R1 Dipendente (1,1) CF Nome R2 Dipendente (0,n) CF Nome Afferenza Afferenza (1,n) Dipartimento Nome Ind. (0,n) Dipartimento Nome Ind. R1 modella il personale tecnico di laboratorio. R2 modella anche il personale dell Amministrazione Centrale e amministrativo a scavalco. 5

6 Analisi comparativa per scoprire le relazioni tra R1 e R2 svolta in stretta collaborazione con gli esperti del dominio. L aspetto critico consiste nell individuare i possibili conflitti: Eterogeneità dei formalismi con diverso potere espressivo negli schemi locali (relazionale, Object Oriented, formati di file, ER, UML, ) Conflitti di nome: Omonimie Nome Dipartimento (0,n) Ind. Biblioteca (0,n) N Ind. Possiede Contiene (1,1) Attrezzatura Inventario Tipo (1,1) Attrezzatura Inventario Tipo scientifica scaffali 6

7 Conflitti di nome: Sinonimie Nome Cliente (0,n) Ind. Detiene Acquirente (0,n) Emette Nome Ind. (1,1) Credito Codice Tipo (1,1) Ordine N Data E opportuno istituire un dizionario dati che annoti tutte le omonimie e sinonimie riscontrate comparando i vari schemi. 7

8 Conflitti semantici, quando si modella la stessa realtà con diverso livello di astrazione in schemi comparabili. (1,n) Edificio N Ind. Edificio (1,n) Contiene (1,1) Piano Appartamento (1,1) Possiede (1,n) Proprietario N Ind. N Descrizione CF Nome (1,1) Piano N (1,n) Contiene (1,1) N Appartamento Descrizione (1,1) Possiede (1,n) CF Proprietario Nome 8

9 Conflitti strutturali Conflitti di tipo, stesso concetto modellato con diversi costrutti. Es.: Piano nella diapositiva precedente. Conflitti di dipendenza, due o più concetti associati con cardinalità diverse. Es.: uomo (sposa n:m) donna con possibilità di storicizzare, uomo (sposa 1:1) donna. Conflitti di chiave, identificatori diversi. Es.: matricola in uno schema, CF in un altro Conflitti di comportamento, politiche di cancellazione/modifica diverse nei vari schemi. Es.: Cancellazione studente nella base dati borsisti EDISU se reddito superiore di una data soglia, mentre nella base dati universitaria viene registrata la non assegnazione. L individuazione delle correlazioni tra R1 e R2 e dei conflitti richiede una approfondita conoscenza del dominio, per questo motivo la documentazione degli schemi operazionali deve essere accurata e formale. 9

10 Riconciliazione e integrazione degli schemi Mapping tra gli elementi degli schemi sorgenti e quelli dello schema riconciliato. Schema R1 Schema R2 Editore Nome Ind Pubblicazione Cod Titolo Editore Libro Cod Titolo Parola chiave Testo Area Argomento Testo Area 10

11 Allineamento degli schemi Editore Nome Ind Pubblicazione Cod Titolo Editore Libro Cod Titolo Argomento Testo Area Soggetto Testo Area Argomento sinonimo di Soggetto ; Editore conflitto di tipo 11

12 Allineamento degli schemi Editore Nome Ind Pubblicazione Cod Titolo Editore Libro Cod Titolo Argomento Testo Area Argomento Testo Area Argomento sinonimo di Soggetto, scegliamo Argomento ; Editore conflitto di tipo, scegliamo la forma più espressiva: 12

13 Fusione Editore Nome Ind Pubblicazione Cod Titolo Libro Cod Titolo Argomento Testo Area La fusione spesso introduce ridondanze, Es.: le entità Pubblicazione e Libro : non sono esattamente sovrapponibili, bensì una entità è sotto entità dell altra. 13

14 Fusione, è possibile che Cod_Id soppianti gli attributi originali Cod Editore Nome Ind Pubblicazione Cod_Id Titolo Argomento Testo Area Libro Ancora ridondanze: le associazioni superflue 14

15 Fusione Schema integrato o Schema Globale (GAV: Globel As View). Editore Nome Ind Pubblicazione Cod_Id Titolo Argomento Testo Area Libro In generale ad ogni concetto dello schema globale corrisponde una vista sugli schemi sorgente Proprietà desiderate dello schema globale: Completezza, dopo la sovrapposizione occorre scoprire tutte le relazioni tra le varie entità (associazioni e gerarchie) Minimalità, cancellazione delle eventuali ridondanze, come da esempio. Leggibilità, nel contesto decisionale dell organizzazione. 15

16 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. 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.: quantità 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

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

18 Un fatto è ben espresso da un associazione molti a molti tra le dimensioni Es.: fatto Vendita giornaliera (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

19 Un fatto è ben espresso da un associazione molti a molti tra le dimensioni Es.: fatto Vendita giornaliera (notazione ER) 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

20 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 facilmente con dipendenze funzionali Negozio Città Regione Responsabile, Città, Distretto Regione Stato In generale è superfluo orientare gli archi. 20

21 Uno schema di fatto molto più ricco 21

22 Costrutti addizionali usati nello schema precedente Attributo descrittivo: aggiunge informazione all attributi dimensionale Es.: con notazione relazionale (Negozio, indirizzo, telefono) (Prodotto, peso). Attributo cross dimensionale: è un attributo dimensionale o descrittivo identificato dalla combinazione di due attributi dimensionali. Es.: categoria, stato IVA IVA dipende dalla categoria del prodotto e dallo stato. Gli attributi e le dimensioni possono essere opzionali, come indicato in figura con un trattino. 22

23 Convergenza: Negozio Responsabile Città Regione Stato Negozio Città Regione Distretto Distretto Responsabile, Città, Distretto Regione Stato Stato La gerarchia diventa un grafo aciclico Regione Attenzione: Città Stato Città stato è ridondante per la transitività delle df 23

24 Schema ER da cui Si può derivare lo schema di fatto Vendite Nel caso di dimensioni tutte obbligatorie. 24

25 Se qualche dimensione è opzionale il fatto è più correttamente modellato da una entità debole: Prodotto (0,n) (1,1) Negozio (0,n) (1,1) (1,1) Vendita (0,n) Data (0,1) (0,n) Promozione 25

26 Altri aspetti della modellazione concettuale Le gerarchie condivise SPEDIZIONE Prodotto Costo Magazzino Ordine Data sped. Responsabile Città Regione Stato Cliente Residenza Data emissione Data consegna Data Mese Anno Le gerarchie condivise da più dimensioni sono denotate da un pallino pieno o altro simbolo (doppio pallini sul testo di riferimento). Gli archi entranti sono in questo caso orientati per disambiguare la struttura gerarchica. Gli archi entranti di inizio dimensione condivisa devono essere etichettati con un ruolo per specificarne il significato. 26

27 Archi multipli SPEDIZIONE Prodotti Costo Magazzino Ordine Data sped. Responsabili Città Regione Stato Cliente Residenza Data emissione Data consegna Data Mese Anno 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 27

28 Gerarchie incomplete Nazione Regione Provincia Italia Rep. S. Mariono Città del Vaticano Piemonte Torino Comune Poirino Serravalle S. Marino Attenzione Con gerarchia incompleta si intende la possibile assenza di valori lungo il percorso gerarchico, mentre un arco opzionale, ad esempio l arco Promozione in Vendite, denota che un evento del fatto Vendita può non essere associato a nessun valore della dimensione Promozione (l intera gerarchia è assente). 28

29 Gerarchie ricorsive Una gerarchia è ricorsiva se la profondità di qualche ramo è indefinita. Direttore produzione Ruolo Impiegato Caporeparto CapoMarketing Data inizio ATTIVITA Ore lavorate Tipo attività Ing. Produzione Tecnico Pubblicitario Commessa Impiegato 29

30 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 prodotti sono cambiati di reparto, dipendenze funzionali con periodo di validità [Data Inizio, Data Fine] 30

31 Per dare concretezza alla discussione conviene modellare le dimensioni come classi di oggetti con identificatore [x, 01] Negozio1 [02, x] Negozio1 [x, 02] Negozio1 [03, x] Negozio1 ResponsabileRossi ResponsabileBianchi DistrettoPiemonteLiguria DistrettoPiemonte [anno_inizio, anno_fine] Più che la modellazione concettuale, la dinamica delle gerarchie influenza la progettazione logica (tavole relazionali) del data warehouse in funzione di come tale dinamica sarà utilizzata dalle interrogazioni che si possono classificare in quattro scenari. 31

32 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

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

34 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 E di interesse quando lo stato corrente diventa il referente anche per il passato 34

35 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 responsabil 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. 35

36 Additività delle misure L aggregazione delle misure lungo una gerarchia 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 Operatori di aggregazione validi: Ger. Temporale Ger. Non temporale Flusso SUM, AVG, MIN, MAX SUM, AVG, MIN, MAX Livello AVG, MIN, MAX SUM, AVG, MIN, MAX Mis. Unitaria AVG, MIN, MAX AVG, MIN, MAX 36

37 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 (in fig. pag 21, SUM è sottinteso, è esplicitato solo AVG per ragioni di spazio e la non additività è segnata con una linea tratteggiata): 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. 37

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

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

40 Schema ER con ciclo Schema di fatto con e senza ciclo Struttura organizzativa Budget (1, n) (1, 1) Budget Aff Responsabile (1, 1) (0, 1) Budget Struttura organizzativa Impiegato (1, n) Impiegato Resp. 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. 40

41 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) Responsabile Responsabile Reparto Data (0, n) (0, n) Da A (1, 1) (1, 1) Impiegato (1, 1) Responsabile (0, 1) Reparto Da A Trasferimenti Num per anno Reparto Da A Trasferimenti Anno Impiegato Data NB.: sono possibili schemi di fatto vuoti, privi di misure come in (b), che si limitano a registrare gli eventi di interesse. 41

42 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 (a), grana annuale (data = anno) Grana transazionale, ciascun evento primario coincide con una transazione operazionale. Es.: Incarico, Attività, Trasferimenti (b), Spedizione Gli schemi di fatto con grana transazionale possono essere vuoti. 42

43 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 (tempo validità) sia del tempo di notifica dell evento (tempo notifica). Es.: Richiesta di pensionamento (tempo notifica), inizio pensione (tempo validità) noto all atto della richiesta. Notifica morte (tempo notifica), data morte (tempo validità) notificata. Anno Mese Data Richiesta A riposo Pensione Fatto transazionale Per semplicità 43

44 Il tempo In genere l evento notificato contiene entrambe le date, ma non sempre: Richiesta di immatricolazione (tempo notifica), so che c è un potenziale nuovo studente all inizio dell anno accademico (tempo validità). Ma c è una nuova data che può assumere rilevanza nei processi decisionali: Data di validazione (tempo validazione), solo dopo la verifica del pagamento delle tasse che può avvenire molto tempo dopo la presentazione della richiesta, addirittura prima o dopo il tempo di validità. Altro esempio: Richiesta di esame clinico (tempo notifica), so che c è un potenziale paziente in una certa data (tempo validità) da esaminare. Data di validazione, al pagamento del ticket che può avvenire molto tempo dopo la richiesta. Possibile scopo del data warehouse: storicizzare le richieste (tempo notifica), le validazioni (tempo validazione), e i servizi (tempo validità). 44

45 Fissato anno accademico (a.a. tempo validità) e corso di studi (ccs), ogni coppia di date registra il numero di studenti che hanno presentato domanda (tempo notifica) in Data Richiesta e sono stati convalidati in Data Convalida (tempo validazione). 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 45

46 Archi multipli Gli archi multipli, poco frequenti negli schemi di fatto, connettono dimensioni che corrispondono ad entità dello schema ER raggiunte via associazioni (x,n) Reparto (0, n) Categoria (1, n) Categoria (1, 1) Ricovero (1, n) (0, n) (1, 1) TipoDiagnosi TipoDiagnosi (1, 1) (0, n) Paziente Reparto CodicePaziente RICOVERO Costo Data 46

47 Sparsità di uno schema Magazzino Prodotto SPEDIZIONE Costo Ordine Data sped. Responsabile Città Regione Stato Cliente Residenza Data emissione Data consegna Data Mese Anno P 0 sia il pattern primario, Es.: P 0 ={Prodotto, Magazzino, Ordine, DataSped, DtaCon} Di cardinalità rispettivamente CardMax(P 0 ) = 1000x100x10000x365x365? 1,3x10 14 Sparsità = Card(P 0 )/CardMax(P 0 ) Dove Card(P 0 ) è l effettiva numerosità degli eventi Più di /km 2 della superficie terrestre (Sup. terrestre circa 5*10 8 km 2 ) 47

48 Pattern primario P 0 ={Prodotto, Magazzino, Ordine, DataSped, DtaCon} Cardinalità domini CardMax(P 0 ) = 1000x100x10000x365x365? 1,3x10 14 La cardinalità massima calcolata con il prodotto delle cardinalità è una sovrastima in generale esagerata. Occorre sempre valutare con attenzione i vincoli del contesto: Non tutti i prodotti si trovano in ogni magazzino, quindi le combinazioni possono ridursi, diciamo, a 2000 La DataSped < DataCon, quindi le combinazioni sono 365x366/2 (vedi pag 45) Tuttavia si può aggiungere: La DataSped deve essere un giorno lavorativo, quindi si riduce a 250 La DataCon è mediamente DataSped + delta che dipende dall ordine (indirizzo cliente) e dal magazzino. Quindi possiamo trascurare le combinazioni. Ne deriva: CardMax(P 0 ) = 2000x10000x250 = 5x10 8 (Riduzione 1/ ) 48

49 Analogamente possiamo stimare la cardinalità di un pattern secondario (roll up con aggregazione di eventi) SPEDIZIONE Magazzino Ordine Cliente Responsabile Città Regione Stato Residenza Prodotto Costo Data sped. Data emissione Data consegna Data Mese Anno Pattern primario P 0 ={Prodotto, Magazzino, Ordine, DataSped, DtaCon} Pattern secondario P ={Prodotto, RegioneMag, RegioneCliente, MeseSped, DtaCon} Cardinalità Card massima (con vincoli) CardMax(P) = 5000x20x12 =

50 P ={Prodotto, RegioneMag, RegioneCliente, MeseSped, DtaCon} Tale pattern secondario serve per calcolare il costo medio di ogni prodotto per ogni regione in cui si trova il magazzino, per ogni regione del cliente, nei vari mesi dell anno. Si noti come il problema di stimare la cardinalità dei pattern sia tanto più complesso quanto più è fine la granularità dei domini. Fine 50