Definizione e calcolo delle misure - DBGroup

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 : 

# Nellesempio 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 

- lincasso annuale è la somma degli incassi mensili 

- lincasso di una categoria di prodotto è la somma degli 

incassi dei relativi tipi 

- lincasso 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! 

# lincasso 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 

laltra 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 

" Lottimizzazione 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 



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) 


! 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(*) 


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,  




"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(NUM_CLIENTI) AS NUM_CLIENTI,  

" "SUM(NUM_NUMVENDITE) AS NUM_VENDITE  

"from "EP_VENDITA   

"group by DATA" 

28 


! Aggregabilità rispetto a DATA: deve essere valutata considerando il 

raggruppamento rispetto a DATA 

! Raggruppamento rispetto a DATA calcolato sul DBO 

select "PRODOTTO, "DATA,  




"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(NUM_CLIENTI) AS NUM_CLIENTI,  

" "SUM(NUM_NUMVENDITE) AS NUM_VENDITE  

"from "EP_VENDITA   

"group by PRODOTTO" 

29


! Consideriamo le seguenti istanze del DBO e la relativa EP_VENDITA 

EP_VENDITA 

SCONTRINO 

PRODOTTO 

VENDITA 

30 


! 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

Definizione e calcolo delle misure - DBGroup

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?