Il ciclo di vita del Data Warehouse. Prof. Stefano Rizzi

Transcript

1 Il ciclo di vita del Data Warehouse Prof. Stefano Rizzi

2 Perché? Molte organizzazioni mancano della necessaria esperienza e capacità per affrontare con successo le sfide implicite nei progetti di data warehousing Uno dei fattori che maggiormente minaccia la riuscita dei progetti è la mancata adozione di una approccio metodologico, che minimizza i rischi di insuccesso essendo basato su un analisi costruttiva degli errori commessi 2

3 Fattori di rischio 9 Rischi legati alla gestione del progetto 9 Rischi legati alle tecnologie 9 Rischi legati ai dati e alla progettazione 9 Rischi legati all organizzazione Il rischio di ottenere un risultato insoddisfacente nei progetti di data warehousing è particolarmente alto a causa delle elevatissime aspettative degli utenti Nella cultura aziendale contemporanea è infatti diffusissima la credenza che attribuisce al data warehousing il ruolo di panacea In realtà una larga parte della responsabilità della riuscita del progetto ricade sulla qualità dei dati sorgente e sulla lungimiranza, disponibilità e dinamismo del personale dell azienda 3

4 Approccio top-down Analizza i bisogni globali dell intera azienda e pianifica lo sviluppo del DW per poi progettarlo e realizzarlo nella sua interezza & Promette ottimi risultati poiché si basa su una visione globale dell obiettivo e garantisce in linea di principio di produrre un DW consistente e ben integrato ' Il preventivo di costi onerosi a fronte di lunghi tempi di realizzazione scoraggia la direzione dall intraprendere il progetto ' Affrontare contemporaneamente l analisi e la riconciliazione di tutte le sorgenti di interesse è estremamente complesso ' Riuscire a prevedere a priori nel dettaglio le esigenze delle diverse aree aziendali impegnate è pressoché impossibile, e il processo di analisi rischia di subire una paralisi ' Il fatto di non prevedere la consegna a breve termine di un prototipo non permette agli utenti di verificare l utilità del progetto e ne fa scemare l interesse e la fiducia 4

5 Approccio bottom-up Il DW viene costruito in modo incrementale, assemblando iterativamente più data mart, ciascuno dei quali incentrato su un insieme di fatti collegati a uno specifico settore aziendale e di interesse per una certa categoria di utenti & Determina risultati concreti in tempi brevi & Non richiede elevati investimenti finanziari & Permette di studiare solo le problematiche relative al data mart in oggetto & Fornisce alla dirigenza aziendale un riscontro immediato sull effettiva utilità del sistema in via di realizzazione & Mantiene costantemente elevata l attenzione sul progetto ' Determina una visione parziale del dominio di interesse 5

6 Il primo data mart da prototipare... 9 deve essere quello che gioca il ruolo più strategico per l azienda 9 deve ricoprire un ruolo centrale e di riferimento per l intero DW '0 '0 '0 9 si deve appoggiare su fonti dati già disponibili e consistenti '0 Source 3 Source 1 '0 Source 2 6

7 Il ciclo di sviluppo Definizione obiettivi e pianificazione Progettazione dell infrastruttura Progettazione e sviluppo dei data mart individuazione degli obiettivi e dei confini del sistema stima delle dimensioni scelta dell approccio per la costruzione valutazione dei costi e del valore aggiunto analisi dei rischi e delle aspettative studio delle competenze del gruppo di lavoro 7

8 Il ciclo di sviluppo Definizione obiettivi e pianificazione Progettazione dell infrastruttura Si analizzano e si comparano le possibili soluzioni architetturali valutando le tecnologie e gli strumenti disponibili, al fine di realizzare un progetto di massima dell intero sistema. Progettazione e sviluppo dei data mart 8

9 Il ciclo di sviluppo Definizione obiettivi e pianificazione Progettazione dell infrastruttura Ciascuna iterazione comporta la creazione di un nuovo data mart e di nuove applicazioni, che vengono via via integrate nel sistema di data warehousing. Progettazione e sviluppo dei data mart 9

10 Il Business Dimensional Pianificazione Definizione dei requisiti Lifecycle (Kimball) Gestione progetto Progetto dell architettura Selezione e installazione prodotti TECNOLOGIA Modellazione dimensionale Progettazione fisica Progettazione e sviluppo alimentazione DATI Specifica applicazioni utente Sviluppo applicazioni utente APPLICAZIONI Attuazione Manutenzione 10

11 La Rapid Warehousing Accertamento Requisiti Methodology (SAS) Riesame Progettazione Costruzione Attuazione Amministrazione e manutenzione 11

12 La progettazione del data mart Analisi e riconciliazione delle sorgenti amministratore db Analisi dei requisiti utente finale Progettazione concettuale Raffinamento del carico di lavoro Progettazione logica progettista Progettazione dell alimentazione Progettazione fisica 12

13 La progettazione del 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 13

14 Analisi e riconciliazione delle sorgenti operazionali Prof. Stefano Rizzi

15 Progettazione del livello riconciliato Schemi sorgenti operazionali Campioni dei dati Schema riconciliato, Mapping sorgenti operazionali Analisi e riconciliazione Meta-dati Progettazione del cleaning Schema riconciliato, Mapping sorgenti operazionali Progettazione della trasformazione Procedure per strumenti ETL Strumenti ETL 9 La fase di integrazione è incentrata sulla componente intensionale delle sorgenti operazionali, ossia riguarda la consistenza degli schemi che le descrivono 9 Pulizia e trasformazione dei dati operano a livello estensionale, ossia coinvolgono direttamente i dati veri e propri 15

16 Analisi e riconciliazione delle sorgenti operazionali Sorgente I Sorgente II Ricognizione e normalizzazione Schema logico (locale) Schema logico (locale) Ricognizione e normalizzazione Schema concettuale (locale) trasformato Schema concettuale (globale) riconciliato Integrazione degli schemi Schema concettuale (globale) riconciliato Schema concettuale (locale) trasformato Meta-dati Definizione corrispondenza con le sorgenti Schema logico (globale) riconciliato e corrispondenza 16

17 Ricognizione e normalizzazione Il progettista, confrontandosi con gli esperti del dominio applicativo, acquisisce un approfondita conoscenza delle sorgenti operazionali attraverso: 9 ricognizione, che consiste in un esame approfondito degli schemi locali mirato alla piena comprensione del dominio applicativo; 9 normalizzazione, il cui obiettivo è correggere gli schemi locali al fine di modellare in modo più accurato il dominio applicativo Ricognizione e normalizzazione devono essere svolte anche qualora sia presente una sola sorgente dati; qualora esistano più sorgenti, l operazione dovrà essere ripetuta per ogni singolo schema 17

18 Ricognizione e normalizzazione descrizionecategoria nomecategoria codicecategoria PRODOTTO descrizioneprod nomeprod codiceprod PRODOTTO (1,1) descrizione nome codice appartiene a (1,n) CATEGORIA descrizione nome codice 18

19 Integrazione L integrazione di un insieme di sorgenti dati eterogenee (basi di dati relazionali, file dati, sorgenti legacy) consiste nell individuazione delle corrispondenze tra i concetti rappresentati negli schemi locali e nella risoluzione dei conflitti evidenziati, finalizzate alla creazione di un unico schema globale i cui elementi possano essere correlati con i corrispondenti elementi degli schemi locali (mapping) La fase di integrazione non si deve limitare a evidenziare le differenze di rappresentazione dei concetti comuni a più schemi locali, ma deve anche identificare l insieme di concetti distinti e memorizzati in schemi differenti che sono correlati attraverso proprietà semantiche (proprietà interschema) Per poter ragionare sui concetti espressi negli schemi delle diverse sorgenti dati è necessario utilizzare un unico formalismo in modo da fissare i costrutti utilizzabili e la potenza espressiva 19

20 Problemi: diversa prospettiva DIPENDENTE (0,1) DIPENDENTE (0,1) partecipa a (1,n) PROGETTO (1,1) assegnato a (1,n) DIPARTIMENTO appartiene a (1,n) DIPARTIMENTO 20

21 Problemi: costrutti equivalenti LIBRO (1,1) titolo ISBN edito da titolo ISBN LIBRO (1,n) CASA EDITRICE indirizzo nome casa editrice indirizzo casa editrice 21

22 Problemi: incompatibilità PROFESSORE nome PROFESSORE nome (0,1) (2,n) insegna insegna (1,1) (1,1) CORSO titolo CORSO titolo 22

23 Relazioni tra concetti comuni Identità: vengono utilizzati gli stessi costrutti, il concetto è modellato dallo stesso punto di vista e non vengono commessi errori di specifica Equivalenza: sono stati utilizzati costrutti diversi (ma equivalenti) e non sussistono errori di specifica o diversità di percezione Comparabilità: i costrutti utilizzati e i punti di vista dei progettisti non sono in contrasto tra loro Incompatibilità: gli schemi sono in contrasto a causa dell incoerenza nelle specifiche 23

24 Fasi dell integrazione 1. Preintegrazione 2. Comparazione degli schemi 3. Allineamento degli schemi 4. Fusione e ristrutturazione degli schemi 24

25 1. Preintegrazione Viene definita la strategia di integrazione Processo di integrazione Binario Ennario A scala Bilanciato A un passo Iterativo 25

26 2. Comparazione degli schemi Un analisi comparativa dei diversi schemi che mira a identificare le correlazioni e i conflitti tra i concetti in essi espressi DIPARTIMENTO (0,n) EDIFICIO (0,n) sinonimia CLIENTE (0,n) ACQUIRENTE (0,n) possiede contiene detiene fa (1,1) ATTREZZATURA (1,1) ATTREZZATURA omonimia (1,1) CREDITO (1,1) ORDINE UOMO UOMO conflitto di dipendenza (0,1) sposa (0,1) DONNA (0,n) sposa (0,n) DONNA 26

27 3. Allineamento degli schemi Scopo di questa fase è la risoluzione dei conflitti evidenziatisi al passo precedente, che si ottiene applicando primitive di trasformazione agli schemi sorgenti o allo schema riconciliato temporaneamente definito 9 Tipiche primitive di trasformazione riguardano il cambio dei nomi e dei tipi degli attributi, la modifica delle dipendenze funzionali e dei vincoli esistenti sugli schemi 9 Non sempre i conflitti possono essere risolti, poiché derivano da inconsistenze di base del sistema informativo; in questo caso la soluzione deve essere discussa con gli utenti che dovranno fornire indicazioni su qual è la più fedele interpretazione del mondo reale 9 In caso di incertezza si preferiscono le trasformazioni che avvantaggiano gli schemi ritenuti centrali nella struttura del data mart 27

28 4. Fusione degli schemi Gi schemi allineati vengono fusi a formare un unico schema riconciliato; l approccio più diffuso è quello di sovrapporre i concetti comuni a cui saranno collegati tutti i rimanenti concetti provenienti dagli schemi locali. Dopo questa operazione si renderanno necessarie ulteriori trasformazioni mirate a migliorare la struttura dello schema riconciliato rispetto a: 9 Completezza 9 Minimalità 9 Leggibilità 28

29 Definizione delle corrispondenze // DB1 Magazzino ORDINI2001(chiaveO, chiavec, data ordine, impiegato) CLIENTE(chiaveC, nome, indirizzo, città, regione, stato)... // DB2 Amministrazione CLIENTE(chiaveC, partitaiva, nome, telefono, fatturato) FATTURE(chiaveF, data, chiavec, importo, iva) STORICO_ORDINI2000(chiaveO, chiavec, data ordine, impiegato)... CREATE VIEW CLIENTE AS SELECT CL1.chiaveC, CL1.nome, CL1.indirizzo, CL1.città, CL1.regione, CL1.stato, CL2.partitaIva, CL2.telefono, CL2.fatturato FROM DB1.CLIENTE AS CL1, DB2.CLIENTE AS CL2 WHERE CL1.chiaveC = CL2.chiaveC; CREATE VIEW ORDINI AS SELECT * FROM DB1.ORDINI2001 UNION SELECT * FROM DB2.STORICO_ORDINI2000; 29

30 Analisi dei requisiti Prof. Stefano Rizzi

31 Obiettivi La fase di analisi dei requisiti ha l obiettivo di raccogliere le esigenze di utilizzo del data mart espresse dai suoi utenti finali Essa ha un importanza strategica poiché influenza le decisioni da prendere riguardo: 9 lo schema concettuale dei dati 9 il progetto dell alimentazione 9 le specifiche delle applicazioni per l analisi dei dati 9 l architettura del sistema 9 il piano di avviamento e formazione 9 le linee guida per la manutenzione e l evoluzione del sistema. 31

32 Fonti La fonte principale da cui attingere i requisiti sono i futuri utenti del data mart (business users) 9 La differenza nel linguaggio usato da progettisti e utenti, e la percezione spesso distorta che questi ultimi hanno del processo di warehousing, rendono il dialogo difficile e a volte infruttuoso Per gli aspetti più tecnici, saranno gli amministratori del sistema informativo e/o i responsabili del CED a fungere da riferimento per il progettista 9 In questo caso, i requisiti che dovranno essere catturati riguardano principalmente vincoli di varia natura imposti sul sistema di data warehousing 32

33 Le interviste A piramide. Approccio induttivo: l intervistatore parte da domande molto dettagliate per poi ampliare l argomento dell intervista mediante domande aperte che richiedono risposte più generali. 9 Questo tipo di intervista permette di superare la riluttanza di un intervistato scettico poiché inizialmente non richiede un forte coinvolgimento da parte dell intervistato. A imbuto. Approccio deduttivo: l intervistatore parte da domande molto generali per poi restringere l argomento dell intervista a temi specifici 9 Questo approccio è utile nel caso in cui l intervistato sia emozionato o eccessivamente deferente, poiché il fatto che le domande di carattere generale (normalmente in forma aperta) non prevedano una risposta sbagliata allevia la tensione dell intervistato. 33

34 Le interviste Ritiene interessante vedere in quali negozi i prodotti vengono venduti a prezzi più alti della media? Quali altre informazioni le interessa associare a una vendita? Ci sono altri fatti che ritiene utili ai fini del processo decisionale? Quali sono i fattori fondamentali che influenzano il processo decisionale nel suo reparto? Come misura la soddisfazione di un cliente? Ritiene utile valutare l andamento nel tempo dei reclami effettuati? Le interessa distinguere i clienti per fasce d età? In quale modo pensa che le tecniche di data warehousing potranno giovare al suo reparto? 34

35 Le domande Ruolo Dirigente Direttore di reparto Amministratore del sistema informativo Domande chiave Quali sono gli obiettivi aziendali? Come misuri il successo della tua azienda? Quali sono oggi i principali problemi dell azienda? In che modo ti aspetti che una maggiore disponibilità di informazioni possa migliorare la situazione aziendale? Quali sono gli obiettivi del tuo reparto? Come misuri il successo del tuo reparto? Descrivi i soggetti coinvolti nel tuo settore di interesse. Ci sono colli di bottiglia nell accesso ai dati? Che analisi di routine esegui? Che tipi di analisi ti piacerebbe poter eseguire? A che livello di dettaglio occorre vedere le informazioni? Quanta informazione storica è necessaria? Illustra le caratteristiche delle principali fonti dati disponibili. Che strumenti vengono usati per analizzare i dati? Come vengono gestite le richieste di analisi ad hoc? Quali sono i principali problemi di qualità dei dati? 35

36 I fatti I fatti sono i concetti su cui gli utenti finali del data mart baseranno il processo decisionale; ogni fatto descrive una categoria di eventi che si verificano in azienda 9 Fissare le dimensioni di un fatto è importante poiché significa determinarne la granularità, ovvero il più fine livello di dettaglio a cui i dati saranno rappresentati. La scelta della granularità di un fatto nasce da un delicato compromesso tra due esigenze contrapposte: quella di raggiungere un elevata flessibilità d utilizzo e quella di conseguire buone prestazioni 9 Per ogni fatto occorre definire l intervallo di storicizzazione, ovvero l arco temporale che gli eventi memorizzati dovranno coprire 36

37 Data mart Fatti approvvigionamenti acquisti, inventario di magazzino, distribuzione commerciale/ manufatturiero finanziario sanitario trasporti telecomunicazioni turismo gestionale produzione gestione domanda marketing bancario investimenti servizi scheda di ricovero pronto soccorso medicina di base merci passeggeri manutenzione traffico CRM gestione domanda CRM logistica risorse umane budgeting infrastrutture confezionamento, inventario, consegna, manifattura vendite, fatturazione, ordini, spedizioni, reclami promozioni, fidelizzazione, campagne pubblicitarie conti correnti, bonifici, prestiti ipotecari, mutui acquisto titoli, transazioni di borsa carte di credito, domiciliazioni bollette ricoveri, dimissioni, interventi chirurgici, diagnosi accessi, esami, dimissioni scelte, revoche, prescrizioni domanda, offerta, trasporti domanda, offerta, trasporti interventi traffico in rete, chiamate fidelizzazione, reclami, servizi biglietteria, noleggi auto, soggiorni frequent-flyers, reclami trasporti, scorte, movimentazione assunzioni, dimissioni, promozioni, incentivi budget commerciale, budget di marketing acquisti, opere 37

38 Glossario dei requisiti Fatto Possibili dimensioni Possibili misure Storicità inventario di magazzino prodotto, d ata, magazzino quantità in magazzino 1 anno vendite prodotto, data, negozio quantità ve nduta, importo, sco nto 5 anni linee d ordine prodotto, data, fornitore quantità ordinata, importo, sco nto 3 anni 38

39 Il carico di lavoro preliminare Il riconoscimento di fatti, dimensioni e misure è strettamente collegato all identificazione di un carico di lavoro preliminare. 9 Oltre che dall interazione diretta con l utente, indicazioni al riguardo potranno essere ricavate da un esame della reportistica correntemente in uso in azienda. 9 In questa fase il carico di lavoro può essere espresso in linguaggio naturale; esso sarà comunque utile per valutare la granularità dei fatti e le misure di interesse, nonché per iniziare ad affrontare il problema dell aggregazione 39

40 Il carico di lavoro preliminare Fatto invent ario di magazzino vendite linee d ordine Interrogazione Quantità media di ciascun prodotto presente mensilmente in tutti i magazzini. Prodotti per i quali è stata esaurita la scorta contemporaneamente in tutti i magazzini in almeno un occasione durante la settimana passata. Andamento giornaliero delle scorte complessive per ciascun tipo di prodotto. Quantità totali di ciascun tipo di prodotto vendute durante l ultimo mese. Incasso totale giornaliero di ciascun negozio. Per un dato negozio, incassi relativi alle diverse categorie di prodotti durante un certo giorno. Riepilogo annuale degli incassi per regione relativamente a un dato prodotto. Quantità totale ordinata annualmente presso un certo fornitore. Importo giornaliero ordinato nell ultimo mese per un certo tipo di prodotto. Sconto massimo applicato da ciascun fornitore durante l ultimo anno per ciascuna categoria di prodotto. 40

41 Altri requisiti Vincoli di progettazione logica e fisica (spazio disponibile) Progetto dell alimentazione (periodicità dell alimentazione) Architettura del sistema di data warehousing (tipo di architettura da implementare, numero dei livelli, presenza di data mart dipendenti o indipendenti, materializzazione del livello riconciliato) Applicazioni per l analisi dei dati (disamina delle tipologie di interrogazioni e dei rapporti analitici normalmente richiesti) Piano di avviamento Piano di formazione 41

42 Progettazione concettuale Prof. Stefano Rizzi

43 Quale formalismo? Mentre è universalmente riconosciuto che un DW si appoggia sul modello multidimensionale, non c è accordo sulla metodologia di progetto concettuale. Il modello Entity/Relationship è molto diffuso nelle imprese come formalismo per la documentazione dei sistemi informativi relazionali, ma non può essere usato per modellare il DW. 43

44 Il Dimensional Fact Model Il DFM è un modello concettuale grafico per data mart, pensato per: 9 supportare efficacemente il progetto concettuale; 9 creare un ambiente su cui formulare in modo intuitivo le interrogazioni dell utente; 9 permettere il dialogo tra progettista e utente finale per raffinare le specifiche dei requisiti; 9 creare una piattaforma stabile da cui partire per il progetto logico (indipendentemente dal modello logico target); 9 restituire una documentazione a posteriori espressiva e non ambigua. La rappresentazione concettuale generata dal DFM consiste in un insieme di schemi di fatto. Gli elementi di base modellati dagli schemi di fatto sono i fatti, le misure, le dimensioni e le gerarchie 44

45 Il DFM: costrutti di base Un fatto è un concetto di interesse per il processo decisionale; tipicamente modella un insieme di eventi che accadono nell impresa (ad esempio: vendite, spedizioni, acquisti,...). È essenziale che un fatto abbia aspetti dinamici, ovvero evolva nel tempo Una misura è una proprietà numerica di un fatto e ne descrive un aspetto quantitativo di interesse per l analisi (ad esempio, ogni vendita è misurata dal suo incasso) Una dimensione è una proprietà con dominio finito di un fatto e ne descrive una coordinata di analisi (dimensioni tipiche per il fatto vendite sono prodotto, negozio, data) prodotto fatto Un fatto esprime una associazione molti-a-molti tra le dimensioni dimensione data VENDITA quantità venduta incasso num. clienti prezzo unitario negozio misura 45

46 Il DFM: costrutti di base Con il termine generale attributi dimensionali si intendono le dimensioni e gli eventuali altri attributi, sempre a valori discreti, che le descrivono (per esempio, un prodotto è descritto dal suo tipo, dalla categoria cui appartiene, dalla sua marca, dal reparto in cui è venduto) Una gerarchia è un albero direzionato i cui nodi sono attributi dimensionali e i cui archi modellano associazioni molti-a-uno tra coppie di attributi dimensionali. Essa racchiude una dimensione, posta alla radice dell albero, e tutti gli attributi dimensionali che la descrivono attributo dimensionale anno trimestre mese giorno vacanza settimana data gruppo di marketing prodotto tipo VENDITA quantità venduta incasso num. clienti prezzo unitario categoria reparto città della marca marca responsabile delle vendite distretto di vendita negozio città del negozio regione stato gerarchia 46

47 47 vacanza responsabile delle vendite distretto di vendita settimana negozio PRODOTTO NEGOZIO DATA qtà venduta incasso prezzo unitario num. clienti data prodotto MESE mese (1,n) (1,1) TRIMESTRE trimestre (1,n) (1,1) ANNO anno (1,n) (1,1) (1,n) (1,1) città CITTÀ (1,n) (1,1) regione REGIONE (1,n) (1,1) stato STATO (1,n) (1,1) tipo TIPO (1,n) (1,1) categoria CATEGORIA (1,n) (1,1) reparto REPARTO MARCA marca (1,n) (1,1) CITTÀ MARCA città marca (1,n) (1,1) (0,n) (0,n) (0,n) vendita RESP. VENDITE (1,n) (1,1) DISTRETTO VENDITA (1,n) (1,1) giorno VACANZA (1,n) (1,1) GIORNO (1,n) (1,1) (1,n) (1,1) SETTIMANA GRUPPO MARKETING gruppo marketing (1,n) (1,1) Il DFM: corrispondenza con l E/R

48 Naming conventions Tutti gli attributi dimensionali in ciascuno schema di fatto devono avere nomi diversi Eventuali nomi uguali devono essere differenziati qualificandoli con il nome di un attributo dimensionale che li precede nella gerarchia 9 Ad esempio, warehouse city è la città in cui si trova un magazzino, mentre store city è la città in cui si trova un negozio I nomi degli attributi non dovrebbero riferirsi esplicitamente al fatto a cui appartengono 9 Ad esempio, si evitino shipped product e shipment date Attributi con lo stesso significato in schemi diversi devono avere lo stesso nome 48

49 Eventi e aggregazione Un evento primario è una particolare occorrenza di un fatto, individuata da una ennupla costituita da un valore per ciascuna dimensione. A ciascun evento primario è associato un valore per ciascuna misura 9 Con riferimento alle vendite, un possibile evento primario registra per esempio che, il 10/10/2001, nel negozio NonSoloPappa sono state vendute 10 confezioni di detersivo Brillo per un incasso complessivo pari a 25 euro Dato un insieme di attributi dimensionali (pattern), ciascuna ennupla di loro valori individua un evento secondario che aggrega tutti gli eventi primari corrispondenti. A ciascun evento secondario è associato un valore per ciascuna misura, che riassume in sé tutti i valori della stessa misura negli eventi primari corrispondenti 9 Pertanto, le gerarchie definiscono il modo in cui gli eventi primari possono essere aggregati e selezionati significativamente per il processo decisionale; mentre la dimensione in cui una gerarchia ha radice ne definisce la granularità più fine di aggregazione, agli altri attributi dimensionali corrispondono granularità via via crescenti 49

50 Eventi e aggregazione città negozio tipo parte tipo parte mese sparsità mese negozio operatori di aggregazione parte data 50

51 Il DFM: costrutti avanzati Un attributo descrittivo contiene informazioni aggiuntive su un attributo dimensionale di una gerarchia, a cui è connesso da una associazione -a-uno. Non viene usato per l aggregazione poiché ha valori continui e/o poiché deriva da un associazione unoa-uno Alcuni archi dello schema di fatto possono essere opzionali anno trimestre mese giorno vacanza settimana responsabile data peso capo reparto gruppo di marketing prodotto tipo VENDITA categoria marca dieta quantità venduta incasso num. clienti prezzo unitario (AVG) reparto città della marca responsabile delle vendite distretto di vendita negozio città del stato negozio regione indirizzo telefono attributo descrittivo arco opzionale 51

52 Il DFM: costrutti avanzati non-additività anno trimestre mese giorno vacanza settimana responsabile data peso capo reparto gruppo di marketing prodotto tipo VENDITA categoria marca dieta quantità venduta incasso num. clienti prezzo unitario (AVG) reparto città della marca responsabile delle vendite distretto di vendita negozio IVA attributo cross-dimensionale città del stato negozio regione indirizzo convergenza telefono data inizio data fine costo promozione pubblicità sconto dimensione opzionale 52

53 Il DFM: costrutti avanzati copertura di arco opzionale data cliente codord LINEA D ORDINE quantità importo data scadenza taglia P-E tipo prodotto codprod 53

54 Il DFM: costrutti avanzati gerarchia condivisa uso chiamante CHIAMATA ora distretto numero telefonico chiamato numero durata data mese anno uso del num. chiamante distretto del numero chiamante distretto del numero chiamato uso del num. chiamato numero chiamante numero chiamato ruolo CHIAMATA numero durata ora data mese anno prodotto SPEDIZIONE numero costo magazzino ordine data di spedizione data città regione stato cliente mese anno 54

55 Il DFM: costrutti avanzati genere VENDITA autore libro numero incasso data mese anno arco multiplo reparto reparto categoria data diagnosi RICOVERO costo nome cognome sesso codpaz fascia d utenza città anno nascita categoria data diagnosi gruppo di diagnosi RICOVERO costo nome cognome sesso codpaz fascia d utenza città anno nascita 55

56 Additività L aggregazione richiede di definire un operatore adatto per comporre i valori delle misure che caratterizzano gli eventi primari in valori da abbinare a ciascun evento secondario Da questo punto di vista è possibile distinguere tre categorie di misure: 9 Misure di flusso: si riferiscono a un periodo, al cui termine vengono valutate in modo cumulativo (il numero di prodotti venduti in un giorno, l incasso mensile, il numero di nati in un anno) 9 Misure di livello: vengono valutate in particolari istanti di tempo (il numero di prodotti in inventario, il numero di abitanti di una città) 9 Misure unitarie: vengono valutate in particolari istanti di tempo, ma sono espresse in termini relativi (il prezzo unitario di un prodotto, la percentuale di sconto, il cambio di una valuta) *HUDUFKLHWHPS RUDOL *HUDUFKLHQRQWHPS RUDOL 0LVXUHGLIOX VVR 680$9*0,10$; 680$9*0,10$; 0LVXUHGLO LYHOOR $9*0,10$; 680$9*0,10$; 0LVXUHXQLWDULH $9*0,10$; $9*0,10$; 56

57 Additività Una misura è detta additiva su una dimensione se i suoi valori possono essere aggregati lungo la corrispondente gerarchia tramite l operatore di somma, altrimenti è detta non-additiva. Una misura non-additiva è non-aggregabile se nessun operatore di aggregazione può essere usato su di essa reparto peso confezione prodotto tipo categoria marca unità per pallet indirizzo anno mese data INVENTARIO AVG, MIN livello quantità ingresso magazzino città stato 57

58 Misure additive anno trim. I 99 II 99 III 99 IV 99 I 00 II 00 III 00IV 00 categoria tipo prodotto Brillo detersivo pulizia Sbianco casa Lucido Manipulite sapone 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 pulizia casa alimentari anno categoria tipo pulizia detersivo casa sapone alimentari latticino bibita

59 Misure non-additive 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 sapone Manipulite 1 1,2 1,5 1,5 Scent 1,5 1,5 2 categoria pulizia anno 1999 trim. I 99 II 99 III 99 IV 99 tipo detersivo 1,75 2,17 2,40 2,67 casa 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 59

60 Schemi di fatto vuoti Uno schema di fatto si dice vuoto se non ha misure 9 In questo caso, il fatto registra solo il verificarsi di un evento anno professore semestre indirizzo nome nazionalità età studente FREQUENZA (COUNT) corso area facoltà sesso 60

61 Progettazione concettuale: approcci Basata sui requisiti 9 Il progettista deve essere in grado di enucleare, dalle interviste condotte presso l utente, un indicazione precisa circa i fatti da rappresentare, le misure che li descrivono e le gerarchie attraverso cui aggregarli utilmente. Il problema del collegamento tra lo schema concettuale così determinato e le sorgenti operazionali viene affrontato in un secondo tempo Basata sulle sorgenti 9 È possibile definire lo schema concettuale in funzione della struttura delle sorgenti, evitando il complesso compito di stabilire il legame con esse a posteriori. Inoltre, è possibile derivare uno schema concettuale prototipale dagli schemi operazionali in modo pressoché automatico 61