Definizione e calcolo delle misure

Definizione e calcolo delle misure! Misure Derivate! Misure Calcolate! Misure Derivate e Progetto Logico! Calcolo delle Misure! Aggregabilità Misure Derivate " Sono misure definite a partire da altre misure dello schema di fatto applicando operatori matematici : # Nell esempio delle vendite incasso è una misura derivata : incasso = prezzo_unitario * quantità_venduta " Una misura derivata viene calcolata sugli eventi primari, ovvero prima di effettuare l aggregazione; quindi, al pari delle altre misure (normali o esplicite), anche per le misure derivate si deve definire un operatore di aggregazione # La misura derivata incasso è additiva, in quanto - l incasso annuale è la somma degli incassi mensili - l incasso di una categoria di prodotto è la somma degli incassi dei relativi tipi - l incasso dei negozi in uno stato è la somma degli incassi dei negozi delle regioni di quello stato # Si noti quindi che la misura derivata incasso è additiva anche se una sua componente (prezzo_unitario) non è additiva 2

Misure Derivate : Esempio " Schema di Fatto ESAMI # Dimensioni STUD (con in gerarchia FACOLTA) e DATA (con in gerarchia MESE) # Misure BASE (Crediti di tipo Base) e ALTRO (Crediti di tipo ALTRO) # Misure derivate RAPPORTO = BASE/ALTRO TOTALE = BASE + ALTRO STUD DATA BASE ALTRO RAPPORTO TOTALE ING1 GEN1 20 2 10 22 ING1 GEN2 40 4 10 44 ING2 GEN2 30 6 5 36 SUM SUM AVG SUM F AC O L T A DA T A BA S E A L TR O RA P P O RT O T O T A L E I N G G EN 1 20 2 10 22 I N G G EN 2 70 10 7, 5 80 FACOLTA MESE BASE ALTRO RAPPORTO TOTALE ING GEN 90 12 8,33 102 3 Misure Calcolate " Una misura calcolata è una misura il cui valore è calcolato a partire da altre misure dopo aver aggregato i dati, ovvero il valore è valutato sugli eventi secondari :! non si definisce un operatore di aggregazione! " Esempio: schema di Fatto ESAMI # Misura derivata : TOT_DER = BASE + ALTRO (SUM) # Misura calcolata : TOT_CALC= BASE + ALTRO STUD DATA BASE ALTRO TOT_DER TOT_CAL ING1 GEN1 20 2 22 C 22 ING1 GEN2 40 4 44 44 ING2 GEN2 30 6 36 36 SUM SUM SUM FACOLTA DATA BASE ALTRO TOT_DER TOT_CALC ING GEN1 20 2 22 22 ING GEN2 70 10 80 80 FACOLTA MESE BASE ALTRO TOT_DER TOT_CALC ING GEN 90 12 102 102 4

Misure Calcolate vs Derivate " Per una misura derivata non è sempre equivalente calcolare il valore aggregato a partire dal valore aggregato delle misure componenti: $ non è sempre equivalente definire una misura derivata come misura calcolata! " Esempio: schema di Fatto ESAMI # Misura derivata : RAP_DER = BASE/ALTRO (AVG) # Misura calcolata : RAP_CALC = BASE/ALTRO STUD DATA BASE ALTRO RAP_DER RAP_CALC ING1 GEN1 20 2 10 10 ING1 GEN2 40 4 10 10 ING2 GEN2 30 6 5 5 SUM SUM AVG FACOLTA DATA BASE ALTRO RAP_DER RAP_CALC ING GEN1 20 2 10 10 ING GEN2 70 10 7,5 7 FACOLTA MESE BASE ALTRO RAP_DER RAP_CALC ING GEN 90 12 8,33 7,5 5 Misure Calcolate vs Derivate: Esempio " Il progettista deve scegliere se usare una misura derivata oppure calcolata " Esempio: misura INCASSO nello schema di fatto VENDITA Sum AVG Sum Tipo Quantit Prezzo T1 12 1,25 T2 9 0,80 22,70 Incasso_calcolato 15,00 7,20 22,20 " INCASSO deve essere una misura derivata: non è possibile calcolare il valore aggregato della misura derivata Incasso a partire dal valore aggregato delle misure componenti! # l incasso annuale non può essere calcolato moltiplicando la quantità venduta in un anno per il prezzo unitario medio annuale. 6

Misure Calcolate vs Derivate " Se la misura derivata e le sue componenti sono distributive è possibile calcolare il valore aggregato a partire dal valore aggregato delle misure componenti e quindi si ottiene lo stesso risultato definendo la misura come calcolata. " Verifica negli esempi precedenti: 1. Misura additiva TOTALE, con componenti additive: il valore aggregato si può calcolare a partire dal valore aggregato delle componenti 2. Misura additiva INCASSO, con una componente additiva e l altra no: il valore aggregato non si può calcolare a partire dal valore aggregato delle componenti 3. Misura non-additiva RAPPORTO, con componenti additive: il valore aggregato non si può calcolare a partire dal valore aggregato delle componenti " La scelta si basa sull efficienza del calcolo: intuitivamente una misura calcolata è più efficiente in quanto il calcolo avviene sui dati aggregati 7 Misure Derivate generalizzate " Nel caso generale, una misura derivata si può definire a partire da altre misure dello schema di fatto applicando oltre che operatori matematici anche operatori logici " Esempio: Misura additiva NumVenditePromo per il conteggio delle vendite effettuate in promozione, calcolata sulla base di una misura Sconto NUMVENDITEPROMO = CASE WHEN SCONTO=0 THEN 0 ELSE 1 END " Esempio: Misura additiva NumVoliInRitardo per il conteggio dei voli in ritardo, calcolata sulla base di una misura Ritardo NUMVOLIINRITARDO= CASE WHEN RITARDO > 5 THEN 1 ELSE 0 END 8

Misure Calcolate generalizzate " Nel caso generale, una misura calcolata è una misura il cui valore è calcolato dopo aver aggregato i dati, a partire da altre misure e/o usando i valori degli attributi dimensionali " Esempi (l esempio completo è a pagina???): Misura calcolata per il conteggio degli eventi primari di VENDITA: NUM_VENDITE = count(*) Misura calcolata per il conteggio degli scontrini in VENDITA: NUM_CLIENTI = COUNT (DISTINCT NUM.SCONTRINO) TIPO DATA VENDITA Una misura calcolata può essere indicata nello schema di fatto con (C) PRODOTTO QUANTITA (C) NUM_VENDITE (C) NUM_CLIENTI NUM. SCONTRINO 9 Misure Derivate e progetto logico " Per definizione, una misura derivata non dovrebbe essere inserita nella fact table, in quanto derivabile appunto dai valori delle altre misure e pertanto il calcolo può essere demandato al sistema OLAP " Una misura derivata può essere inserita nella fact table, e calcolata quindi in fase di alimentazione per 1. Motivi di efficienza 2. Assenza nel sistema OLAP degli operatori che definiscono la misura derivata. Ad esempio, in Analysis Services è conveniente definire le misure derivate con operatori logici in fase di alimentazione e quindi inserirle nella fact table. 10

Calcolo delle misure: Progetto Fisico e Viste " Un significativo aumento delle prestazioni può essere ottenuto precalcolando i dati aggregati di uso più comune " Misure definite con operatori Distributivi ed Algebrici permettono di calcolare dati aggregati a partire direttamente da dati parzialmente aggregati " L ottimizzazione usa il concetto di vista materializzata: # Ogni pattern secondario corrisponde ad una vista sul pattern primario # Vengono materializzate le viste (ovvero pre-calcolate e memorizzate in tabelle o altre strutture dati) corrispondenti ad alcuni pattern secondari, ovvero a quelli maggiormente utilizzati (carico di lavoro) # La scelta delle viste da materializzare è basata sul compromesso tra diversi vincoli, i principali dei quali sono Tempo di costruzione ed aggiornamento delle viste materializzate, ovvero tempo di calcolo al momento del caricamento/refresh del DW Spazio aggiuntivo richiesto 11 Le viste " Le viste possono essere identificate in base al livello (pattern) di aggregazione che le caratterizza v 1 = {prodotto, data, negozio}! v 2 = {tipo, data, città}! v 4 = {tipo, mese, regione}! v 3 = {categoria, mese, città}! v 5 = {trimestre, regione}! " Viste primarie: corrispondono al pattern di aggregazione primario (non aggregato) " Viste secondarie: corrispondono ai pattern di aggregazione secondari (aggregati)

Risolvibilità delle interrogazioni " Una vista v sul pattern p non serve solo per le interrogazioni con pattern di aggregazione p ma anche per tutte quelle che richiedono i dati a pattern p' più aggregati di p (p! p') {a,b} b' a' b a {a',b} {a,b'} {b} {a',b'} {a} {b'} {a'} { } Reticolo di roll-up Scelta delle viste materializzate " È utile materializzare una vista quando: # Risolve direttamente una interrogazione frequente # Permette di ridurre il costo di esecuzione di molte interrogazioni " Non è consigliabile materializzare una vista quando: # Il suo pattern di aggregazione è molto simile a quello di una vista già materializzata # Il suo pattern di aggregazione è molto fine # La materializzazione non riduce di almeno un ordine di grandezza il costo delle interrogazioni % Tecniche di scelta delle viste da materializzare sono generalmente già implementate nei sistemi OLAP e allutente viene solo chiesto di configurare alcuni parametri, quali lo spazio a disposizione per la memorizzazione delle viste da materializzare

Analysis Services: archiviazione cubo " In Analysis Services e possibile precalcolare tutte le possibili aggregazioni # Nel cubo Sales di FoodMart ci sono 1036 aggregazioni: Analysis Services: archiviazione cubo " Oppure si fissa un limite allo spazio di archiviazione stimato # Nel cubo Sales di FoodMart fissando 100MB si ottengono 398 aggregazioni:

Analysis Services: operatore AVG " AVG è un operatore di aggregazione algebrico che ha come misura di supporto COUNT " Nel sistema OLAP Analysis Services: AVG non è disponibile come operatore ma deve essere calcolato tramite SUM e COUNT " Esempio : prezzo_unitario (PU) aggregato tramite AVG 1. Si definisce PUBase aggregando PU con SUM; 2. Si definisce la misura di supporto Conteggio, aggregata con COUNT 3. Si definisce PU come misura calcolata PUBase/Conteggio 17

Alimentazione: calcolo delle misure! L alimentazione definisce le istanze di un Data Mart a partire dalle istanze del DataBase operazionale DBO! Nel progetto dell alimentazione si definisce il calcolo effettivo delle misure (normali o esplicite) di uno Schema di Fatto e le istanze che costituiranno le dimensioni! Nel seguito tratteremo il calcolo delle misure e l analisi della loro aggregabilità rispetto alle dimensioni! Dato uno Schema di Fatto F, con dimensioni D = {D1,!, Dn } e misure M = {M1,!, Mk}; per ogni misura Mi si deve definire una view F_Mi sul DBO, con schema F_Mi(D1,!,Dn,Mi)! Il join naturale di tutte le view F_Mi risulta nella vista F, che chiameremo vista degli Eventi Primari, con schema : F(D1,!,Dn,M1,!, Mk) 18 Alimentazione: calcolo delle misure! Dal punto di vista operativo, salvo casi in cui una o più misure richiede un calcolo particolare, è possibile definire direttamente solo la vista degli Eventi Primari F sul DBO : nel seguito considereremo questo caso, calcolando la view F! Spesso, nei casi reali, per semplificare la definizione di F, occorre definire prima altre view.! La struttura della view F dipende dal tipo di schema: 1. Negli schemi temporali è una query con raggruppamento sulle dimensioni, mentre negli schemi transazionali è una query senza raggruppamento! La vista degli Eventi Primari verrà anche chiamata FACT_TABLE, in quanto definisce appunto le istanze della FACT_TABLE nella schema logico relazionale del Data Mart 19

Esempio: DBO (schema E/R e logico) TIPO quantità COD prezzo unitario data Identificatori Fatto Vendita: I1 = {PRODOTTO,NUM.SCONTRINO} PRODOTTO (0,N) (1,1) in VENDITA (1,1) (1,N) in SCONTRINO I2 = {COD} prodotto num. scontrino PRODOTTO PRODOTTO ALIM_1 ALIM_2 TIPO Alimentare Alimentare SCONTRINO NUMERO DATA Scontr12 02/02/02 Scontr13 02/02/02 VENDITA COD PRODOTTO N_SCONTRINO QUANTITA PREZZO_UNITARIO 3 ALIM_1 Scontr12 12 25 2 ALIM_2 Scontr12 13 12 1 ALIM_2 Scontr13 24 13 20 Esempio: progettazione concettuale tipo prodotto quantità prezzo-unitario prodotto + num.scontrino data num.scontrino! Dimensioni = { prodotto, num.scontrino }! Tipologia dello Schema: transazionale (le dimensioni coincidono con I1)! Definizione delle misure: di ogni misura si deve 1. Definire la tipologia: esplicita/derivata/calcolata 2. Per le misure esplicite 1. (alimentazione) definire il suo calcolo a partire dal DBO 2. (aggregabilità) definire l operatore di aggregazione degli eventi 3. Per le misure derivate 1. definire il suo calcolo per ogni evento primario 2. (aggregabilità) definire l operatore di aggregazione 4. Per le misure calcolate 1. definire il suo calcolo per ogni evento, primario e secondario 21

Esempio: Definizione delle misure! Misura QUANTITA : è una misura esplicita; essendo lo schema transazionale coincide con il valore dell attributo quantità del DBO. Operatore di aggregazione degli eventi: SUM! Misura NUM_CLIENTI: è una misura calcolata definita come COUNT(DISTINCT NUM.SCONTRINO)! Misura NUM_VENDITE: è una misura calcolata definita come COUNT(*) TIPO VENDITA DATA Una misura calcolata verrà indicata nello schema di fatto con (C) PRODOTTO QUANTITA (C) NUM_VENDITE (C) NUM_CLIENTI NUM. SCONTRINO 22 Esempio: Alimentazione! Schema transazionale : vista degli Eventi Primari senza alcun raggruppamento: create view EP_VENDITA as "select "PRODOTTO, " " "NUM.SCONTRINO, " " "QUANTITA "from " "DBO.VENDITA"! Se si considera solo l identificatore I2 : le dimensioni non contengono alcun identificatore e quindi viene assunto erroneamente lo schema come temporale: vista degli Eventi Primari con raggruppamento " select "PRODOTTO, NUM.SCONTRINO, " "SUM(QUANTITA) AS QUANTITA from " "DBO.VENDITA group by "PRODOTTO,NUM.SCONTRINO" " Il calcolo risulta corretto, però si effettua un raggruppamento, un calcolo di funzione aggregata inutile. " Si devono considerare tutti gli identificatori! 23

Esempio B : Vendita con schema temporale COD TIPO quantità prezzo unitario data Identificatori Fatto Vendita: I1 = {PRODOTTO,NUM.SCONTRINO} PRODOTTO (0,N) (1,1) in VENDITA (1,1) (1,N) in SCONTRINO I2 = {COD} prodotto num. scontrino tipo quantità prezzo-unitario data prodotto prodotto + num.scontrino num.scontrino! Dimensioni = { prodotto, data}! Tipologia dello Schema: temporale (le dimensioni non contengono nessuno dei due identificatori) 24 Esempio B: Definizione delle misure! Misura QUANTITA : è una misura esplicita; essendo lo schema temporale si deve definire tramite un opportuno operatore di aggregazione dei dati del DBO: QUANTITA = SUM (quantità) Operatore di aggregazione degli eventi : SUM! Misura NUM_CLIENTI: il significato è ancora quello di conteggio distinto degli scontrini, però adesso num.scontrino non sarà più disponibile nello schema di fatto. Allora si considera come misura esplicita e definita sui dati del DBO come: NUM_CLIENTI= COUNT(DISTINCT num.scontrino) Operatore di aggregazione degli eventi : SUM! Misura NUM_VENDITE: il significato è ancora quello di conteggio delle vendite, però adesso lo schema è temporale quindi si considera come misura esplicita e definita sui dati del DBO come: NUM_VENDITE= COUNT(*) Operatore di aggregazione degli eventi : SUM 25

Esempio B : alimentazione! Schema temporale : vista degli Eventi Primari con raggruppamento create view EP_VENDITA as "select "PRODOTTO, " "DATA, " "SUM(QUANTITA) AS QUANTITA, " "COUNT(DISTINCT NUM.SCONTRINO) AS NUM_CLIENTI, " "COUNT(*) AS NUM_VENDITE "from "DBO.VENDITA V join DBO.SCONTRINO S " " "on V.NS = S.NS" "group by PRODOTTO, DATA ""! La vista di alimentazione VENDITA deve essere ovviamente definita considerando lo schema logico del DBO. Nell esempio abbiamo supposto che " VENDITA(NS:SCONTRINO, PRODOTTO:PRODOTTO, COD, " "QUANTITA,PREZZO_UNITARIO) " "" SCONTRINO(NS,DATA)" "" PRODOTTO(PRODOTTO,TIPO) " "" 26 Aggregabilità delle misure! Dopo aver definito il calcolo effettivo di una misura a partire dalle istanze del DBO, è possibile valutare la sua aggregabilità! Informalmente, una misura è aggregabile su una dimensione se i suoi valori possono essere aggregati rispetto a tale dimensione! Per valutare l aggregabilità rispetto ad una dimensione Di, si considera il pattern ottenuto da quello primario eliminando Di! Si può valutare l aggregabilità considerando alcune istanze d esempio oppure fare delle interrogazioni e confrontare il risultato 27

Esempio B : Aggregabilità delle misure! Aggregabilità rispetto a PRODOTTO: deve essere valutata considerando il raggruppamento rispetto a PRODOTTO! Raggruppamento rispetto a PRODOTTO calcolato sul DBO select "PRODOTTO, "DATA, " "SUM(QUANTITA) AS QUANTITA, " "COUNT(DISTINCT NUM.SCONTRINO) AS NUM_CLIENTI, " "COUNT(*) AS NUM_VENDITE "from "DBO.VENDITA "group by PRODOTTO, DATA"! Le misure sono aggregabili rispetto a PRODOTTO se si ottiene lo stesso risultato raggruppando gli Eventi Primari rispetto a PRODOTTO: select "DATA, " "SUM(QUANTITA) AS QUANTITA, " "SUM(NUM_CLIENTI) AS NUM_CLIENTI, " "SUM(NUM_NUMVENDITE) AS NUM_VENDITE "from "EP_VENDITA "group by DATA" 28 Esempio B : Aggregabilità delle misure! Aggregabilità rispetto a DATA: deve essere valutata considerando il raggruppamento rispetto a DATA! Raggruppamento rispetto a DATA calcolato sul DBO select "PRODOTTO, "DATA, " "SUM(QUANTITA) AS QUANTITA, " "COUNT(DISTINCT NUM.SCONTRINO) AS NUM_CLIENTI, " "COUNT(*) AS NUM_VENDITE "from "DBO.VENDITA "group by PRODOTTO, DATA"! Le misure sono aggregabili rispetto a DATA se si ottiene lo stesso risultato raggruppando gli Eventi Primari rispetto a DATA: select "PRODOTTO, " "SUM(QUANTITA) AS QUANTITA, " "SUM(NUM_CLIENTI) AS NUM_CLIENTI, " "SUM(NUM_NUMVENDITE) AS NUM_VENDITE "from "EP_VENDITA "group by PRODOTTO" 29

Esempio B : Aggregabilità delle misure! Consideriamo le seguenti istanze del DBO e la relativa EP_VENDITA EP_VENDITA SCONTRINO PRODOTTO VENDITA 30 Esempio B : Aggregabilità delle misure! Confronto raggruppamento rispetto a PRODOTTO! Confronto raggruppamento rispetto a DATA 31

Esempio B : schema di fatto! Dall analisi precedente risulta che : # QUANTITA e NUM_VENDITE sono aggregabili rispetto a tutte le dimensioni # NUM_CLIENTI è aggregabile rispetto a DATA ma non rispetto a PRODOTTO PRODOTTO TIPO VENDITA QUANTITA NUM_VENDITE NUM_CLIENTI DATA 32 Esempio B : Pattern in OLAP! Query SQL-OLAP per visualizzare il pattern {DATA,PRODOTTO} ed i suoi sub-pattern {DATA}, {PRODOTTO} e {} : i pattern per i quali NUM_CLIENTI non è aggregabile non vengono mostrati select DATA, PRODOTTO, SUM(QUANTITA) AS QUANTITA, SUM(NUM_CLIENTI) AS NUM_CLIENTI, SUM(NUM_VENDITE) AS NUM_VENDITE from EP_VENDITA group by DATA, PRODOTTO WITH CUBE having GROUPING(PRODOTTO)<> 1 33

Esempio B : pattern in OLAP! Query SQL-OLAP per visualizzare il pattern {DATA,PRODOTTO} ed i suoi sub-pattern {DATA}, {PRODOTTO} e {} : i pattern per i quali NUM_CLIENTI non è aggregabile vengono segnalati con (NA) select DATA, PRODOTTO, SUM(QUANTITA) AS QUANTITA, NUM_CLIENTI = CASE WHEN GROUPING(PRODOTTO)=1 THEN CAST(SUM(NUM_CLIENTI) AS VARCHAR) + ' (NA)' ELSE CAST(SUM(NUM_CLIENTI) AS VARCHAR) END, SUM(NUM_CLIENTI) AS NUM_CLIENTI, SUM(NUM_VENDITE) AS NUM_VENDITE from EP_VENDITA group by DATA, PRODOTTO WITH CUBE 34