Sistemi Informativi Avanzati Anno Accademico 2012/2013 Prof. Domenico Beneventano Archi multipli Capitoli 5.2.5 e 9.1.4 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo Golfarelli, Stefano Rizzi; Editore: McGraw-Hill Arco Multiplo! Schema di fatto contenente un arco multiplo: genere autore libro VENDITA numero incasso data mese anno arco multiplo (AM) " Per illustrare il concetto di arco multiplo si parte da uno schema di fatto già dato, indipendentemente dalla progettazione concettuale che ha originato tale schema, indipendentemente dal fatto che lo schema sia transazionale o temporale.! Un arco multiplo corrisponde ad un associazione molti-a-molti: il padre (libro) non determina funzionalmente il figlio (autore)! Per definire il valore aggregato delle misure per gli archi multipli è a volte necessario considerare un peso : 1) AM(padre,figlio,peso) 2) per ogni padre la somma dei pesi è unitaria: SELECT padre, SUM(peso) from AM GROUP BY padre 2
Misure Pesate e Misure di impatto genere VENDITA autore libro numero incasso data mese anno arco multiplo (AM)! Gerarchia dell Arco Multiplo : gerarchia contenente il figlio e i discendenti dell arco multiplo; nell esempio solo {autore}.! Per pattern contenenti almeno un attributo della gerarchia dell arco multiplo occorre differenziare tra 1) Misure pesate: il valore aggregato della misura viene calcolato considerando il peso dell arco multiplo 2) Misure di impatto: il valore aggregato della misura viene calcolato senza considerare il peso dell arco multiplo 3 Arco multiplo! Eventi primari del fatto Vendita! Arco Multiplo : AM! Oltre alle misure numero ed incasso, si considerano le misure numero_pesato e incasso_pesato il cui valore aggregato è sempre calcolato attraverso la somma ma considerando il peso numero_pesato = SUM(vendita.numero*AM.peso) incasso_pesato = SUM(vendita.incasso*AM.peso)! Valore delle misure per il pattern { Autore } : 4
Archi multipli: Specifica delle misure! In presenza di un arco multiplo, le misure devono essere classificate ( a livello di specifica, da parte del progettista) in Misure Pesate Misure di Impatto! Questa differenziazione viene utilizzata in fase di calcolo dei valori aggregati per i pattern che contengono almeno un attributo della gerarchia dell arco multiplo.! Esempio: supponiamo che la specifica sia incasso Misura Pesata numero Misura di Impatto! Pattern {Autore,Anno} 5 Archi multipli: Specifica delle misure! Per i pattern che non contengono attributi della gerarchia dell arco multiplo si calcola sempre il valore aggregato senza considerare il peso. Esempio : pattern {Libro}! Esempio Pattern {Genere,Autore}. Il pattern contiene un attributo della gerarchia dell arco multiplo, quindi devo differenziare (Libro1 e Libro3 sono Tecnico mentre Libro2 è Attualita) 6
Archi multipli: per riassumere! Data una misura M con operatore di aggregazione OP! In presenza di un arco multiplo, M deve essere classificata in Misura Pesata oppure Misura di Impatto! Se M è una Misura di Impatto, il suo valore aggregato si calcola sempre come OP(M)! Se M è una Misura Pesata, il suo valore aggregato si calcola come 1) OP(M*AM.Peso) per i pattern con attributi della gerarchia dell arco multiplo. 2) OP(M) per i pattern senza attributi della gerarchia dell arco multiplo. 7 Archi multipli: per riassumere VENDITA (Eventi Primari) AM LIBRO! Pattern {GENERE,AUTORE} e sub-pattern 8
Archi multipli : Progettazione logica! La soluzione progettuale più ovvia è quella di inserire una tabella aggiuntiva (bridge table) che modelli l arco multiplo: # La chiave della bridge table (BT) è composta dalla combinazione degli attributi collegati all arco multiplo! La soluzione progettuale più semplice è quella di rendere più fine la granularità del fatto modellando così l arco multiplo direttamente nella fact table (push-down).! Questa soluzione richiede l aggiunta alla fact table di una nuova dimensione corrispondente al figlio dell arco multiplo 9 Archi multipli: comparazione! Il potere informativo delle due soluzioni è identico! Con la soluzione con push-down il peso è codificato nella fact table ovvero di ogni misura si riporta il suo valore già pesato # Il calcolo degli eventi pesati avviene durante l alimentazione # Forte ridondanza nella fact-table: le righe vanno replicate tante volte quante sono le corrispondenze dell arco multiplo # il valore aggregato di una misura pesata viene calcolato con l operatore di aggregazione, senza più considerare il peso # il valore aggregato di una misura di impatto deve essere calcolato in due passi: prima si aggregano gli eventi primari (per ottenere la misura non pesata) e quindi si applica l operatore di aggregazione: il calcolo risulta più complesso! Con la soluzione con bridge-table: # il valore aggregato di una misura pesata deve essere calcolato applicando all operatore di aggregazione il peso: il calcolo risulta più complesso 10
Archi multipli: soluzione con BRIDGE-TABLE VENDITA = FACT TABLE AM = BRIDGE-TABLE (BT) LIBRO (Dimension table)! Per evidenziare la difficoltà di calcolo, proviamo a scrivere la query SQL-OLAP per ottenere {GENERE,AUTORE} e sub-pattern, ovvero per ottenere: 11 Archi multipli: soluzione con BRIDGE-TABLE! I pattern con attributi della gerarchia dell arco multiplo (ovvero con AUTORE) sono caratterizzati da GROUPING(AUTORE)=0, quindi per la misura pesata INCASSO si differenzia tramite CASE! Però per i pattern che non contengono AUTORE i calcoli risultano errati anche per la misura di impatto NUMERO: il problema è il join con BT che aumenta la molteplicità 12
Archi multipli: soluzione con BRIDGE-TABLE! Si può ottenere come UNION di due query! QueryA per i pattern con GROUPING(AUTORE)=1: non si effettua join con BT (si noti che AUTORE=NULL viene aggiunto nella select)! QueryB per i pattern con GROUPING(AUTORE)=0: si effettua join con BT 13 Archi multipli: soluzione con PUSH-DOWN VENDITA (Eventi Primari) AM LIBRO! Fact Table della soluzione con push-down (FACT_TABLE_PD) LIBRO (Dimension table) 14
Archi multipli: soluzione con PUSH-DOWN! Per evidenziare la difficoltà di calcolo della misura di impatto NUMERO, consideriamo la query per ottenere {GENERE,AUTORE} e sub-pattern! Per la misura pesata INCASSO i calcoli sono corretti! Per la misura di impatto NUMERO, per i pattern che contengono un attributo della gerarchia dell arco multiplo i calcoli non sono corretti appunto perché fatti sul valore pesato! Anche in questo caso si potrebbe ottenere come UNION di due query!! però presentiamo una soluzione più semplice 15 Archi multipli: soluzione con PUSH-DOWN! Considerato che 1. In uno schema con arco multiplo possono essere necessarie sia misure di impatto che pesate 2. La definizione (ed il calcolo) degli operatori di aggregazione delle misure avviene attraverso lo strumento OLAP una soluzione semplice anche se ridondante è quella di riportare nella fact-table per le misure pesate : i valori pesati per le misure d impatto : sia i valori pesati che non pesati ovvero fare un push-down in cui si riportano anche i valori non pesati delle misure d impatto 16
Archi multipli: soluzione con PUSH-DOWN VENDITA (Eventi Primari) AM LIBRO! FACT_TABLE_PD: Per la misura di impatto numero, oltre al valore pesato, si riporta nella fact-table con push down anche il valore non pesato 17 Push-Down: calcolo dei valori aggregati I valori aggregati si ottengono a partire dalla Fact Table con push down in base alle seguenti regole! Per le Misure Pesate: si usa il valore pesato, per tutti i pattern! Per le Misure di Impatto 1. per i pattern che hanno almeno un attributo della gerarchia dell arco multiplo: usare il valore non pesato della misura 2. per i pattern che non contengono attributi della gerarchia dell arco multiplo: usare il valore pesato della misura 18
Push-Down: calcolo dei valori aggregati! Verifichiamo la regola sul nostro esempio! Esempio : {Libro } 1. incasso è pesata quindi uso il suo valore pesato incasso_pesato 2. numero è di impatto quindi siccome {Libro} non contiene attributi della gerarchia dell arco multiplo, uso il suo valore pesato numero_pesato 19 Push-Down: calcolo dei valori aggregati! Verifichiamo la regola sul nostro esempio! Esempio : {Autore, Anno} 1. incasso è pesata quindi uso il suo valore pesato incasso_pesato 2. numero è di impatto quindi siccome {Autore, Anno} contiene attributi della gerarchia dell arco multiplo, uso il suo valore non pesato numero 20
Push-Down: calcolo dei valori aggregati! Applichiamo la regola nella query SQL-OLAP per ottenere {GENERE,AUTORE} e sub-pattern! In definitiva, riportando per le misure di impatto sia il loro valore normale che il valore pesato comporta una ridondanza però semplifica le analisi OLAP, sia a livello di interrogazioni SQL-OLAP (come abbiamo visto in questi esempi) sia a livello di cubo OLAP e interrogazioni MDX (come vedremo realizzando il relativo cubo OLAP 21 Archi multipli: Misure Calcolate VENDITA (Eventi Primari) AM LIBRO! Misura calcolata INCASSO_MEDIO=INCASSO/NUMERO! Misura calcolata PREZZO_MEDIO=INCASSO_TOTALE/NUMERO dove INCASSO_TOTALE è la misura INCASSO ma considerata ora come misura di impatto 22
Push-Down: misure calcolate! Per una misura calcolata MC 1) si devono inserire nella fact table con push down le misure componenti 2) a livello aggregato, nella query SQL-OLAP, viene calcolata MC! Per la misura calcolata INCASSO_MEDIO=INCASSO/NUMERO: FACT_TABLE_PD contiene già le misure componenti! Per la misura calcolata PREZZO_MEDIO=INCASSO_TOTALE/NUMERO: la FACT_TABLE_PD contiene già NUMERO ma non INCASSO_TOTALE, misura INCASSO ma considerata ora come misura di impatto: nella FACT_TABLE_PD si deve avere anche INCASSO non pesato 23 Push-Down: calcolo della FACT_TABLE! L esempio evidenzia che nella FACT_TABLE_PD servono spesso sia la versione pesata che non pesata di una misura. Il calcolo è semplice:! È possibile inserire in FACT_TABLE_PD solo i valori pesati e calcolare successivamente quelli non pesati?! Questo può risultare utile in un architettura a due/tre livelli in cui la FACT_TABLE_PD viene effettivamente memorizzata in una table del Data Mart! La risposta è positiva: 24
Push-Down: calcolo della FACT_TABLE 1. si crea una FACT_TABLE_PD con solo i valori pesati (chiamata FACT_TABLE_PD1) 2. quindi da FACT_TABLE_PD1 si ricavano i valori non pesati (vista NOPESATI) 3. e la FACT_TABLE_PD complessiva si ottiene dal join 25 Push-Down: misure calcolate! Ottenuta FACT_TABLE_PD (si noti che INCASSO_TOTALE è stato chiamato INCASSO)! A livello aggregato, nella query SQL-OLAP, le misure calcolate si possono ottenere direttamente, considerando e differenziando tra i vari pattern di aggregazione! oppure si possono per semplicità formulare in due passi: 26
Push-Down: misure calcolate! Prima si ottengono le componenti! e poi le misure calcolate 27 Arco multiplo sulle dimensioni: Esempio! Fatto RICOVERO: un ricovero è associato a più diagnosi! Nell albero degli attributi si aggiunge un arco multiplo tra la radice CodRicovero e Diagnosi relativo all associazione DI.! Diagnosi viene scelta come dimensione! Schema a granularità temporale; si noti che nello schema E/R Data +Paziente non è indicato come identificatore di Ricovero, ovvero un paziente può essere ricoverato più volte nella stessa data REPARTO categoria data diagnosi data (0,N) (1,1) in RICOVERO (1,N) reparto RICOVERO costo costo (1,1) (0,N) di codpaziente PAZIENTE reparto di codricovero codpaziente (0,N) DIAGNOSI diagnosi arco multiplo (1,1) (1,N) di! Se Data+Paziente risultava invece essere un identificatore di Ricovero (individuato ad esempio in fase di ricognizione), lo schema di fatto risultava a granularità transazionale! CATEGORIA categoria 28
Arco Multiplo sulle dimensioni! In base alle definizioni di fatto e dimensioni, un arco multiplo sulle dimensioni non è ammesso: fissando una ennupla di valori per le dimensioni non si individua più in modo univoco un evento primario. # Nell esempio una ennupla del Pattern Primario {diagnosi, reparto,data,codpaziente} non determina un evento primario ma una sua frazione, ovvero il contributo dato al ricovero di una singola diagnosi! Si trasforma lo schema di fatto nel seguente schema equivalente, introducendo una dimensione fittizia gruppo di diagnosi che ha per dominio tutte le combinazioni di diagnosi abbinate ai ricoveri effettuati: reparto nome categoria data diagnosi gruppo di diagnosi RICOVER O costo cognome sesso codpaz fascia d'utenza città anno nascita 29 Arco Multiplo sulle dimensioni! Con la dimensione fittizia gruppo di diagnosi l arco multiplo viene spostato dalla dimensione ad un suo figlio (la dimensione fittizia) e quindi si ricade nell arco multiplo visto in precedenza; per considerare delle misure pesate, per tale arco multiplo occorre specificare un peso : 30
Progettazione Logica - bridge table! La figura schematizza la soluzione con bridge-table: 31 Progettazione Logica push down! La figura schematizza la soluzione con push-down:! Il costo riportato nella fact table è il costo pesato e quindi rappresenta il costo per diagnosi.! Da questa osservazione deriva che un altro schema di fatto equivalente a quello iniziale è quello in cui viene effettuato il push down di diagnosi: diagnosi viene considerata come una normale dimensione e ciascun evento primario corrisponde non più a un intero ricovero ma alla porzione di ricovero imputabile alla singola diagnosi 32
Arco Multiplo sulle dimensioni: push-down! Schema di fatto equivalente ottenuto tramite push-down di diagnosi! Questo schema di fatto è quello che si sarebbe ottenuto considerando, nel progetto concettuale, come fatto l associazione molti-a-molti DI tra diagnosi e ricovero:! In questo modo l albero degli attributi e lo schema di fatto non conterranno più alcun arco multiplo! La sostanza del problema, ovvero dire quale sia all interno di un ricovero il costo imputabile a ciascuna diagnosi, però resta; infatti nello schema E/R del DB operazionale tale costo non è indicato e quindi deve essere calcolato. 33