Misure Calcolate

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
ING1
ING1
ING2
DATA
GEN1
GEN2
GEN2
BASE
20
40
30
ALTRO
RAPPORTO
10
10
5
TOTALE
22
44
36
SUM
SUM
AVG
SUM
2
4
6
FACOLTA
ING
ING
DATA
GEN1
GEN2
BASE
20
70
ALTRO
2
10
RAPPORTO
10
7,5
TOTALE
22
80
FACOLTA
ING
MESE
GEN
BASE
90
ALTRO
12
RAPPORTO
8,33
TOTALE
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
ING1
ING1
ING2
DATA
GEN1
GEN2
GEN2
BASE ALTRO
20
2
40
4
30
6
SUM
SUM
TOT_DER
22
44
36
TOT_CAL
C 22
44
36
SUM
FACOLTA
ING
ING
DATA
GEN1
GEN2
BASE
20
70
ALTRO
2
10
TOT_DER TOT_CALC
22
22
80
80
FACOLTA
ING
MESE
GEN
BASE
90
ALTRO
12
TOT_DER TOT_CALC
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
ING1
ING1
ING2
DATA
GEN1
GEN2
GEN2
BASE ALTRO
20
2
40
4
30
6
SUM
SUM
RAP_DER RAP_CALC
10
10
10
10
5
5
AVG
FACOLTA
ING
ING
DATA
GEN1
GEN2
BASE
20
70
ALTRO
2
10
RAP_DER
10
7,5
RAP_CALC
10
7
FACOLTA
ING
MESE
GEN
BASE
90
ALTRO
12
RAP_DER
8,33
RAP_CALC
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
Tipo
T1
T2
" 
QuantitƉ
12
9
AVG
Prezzo
1,25
0,80
Sum
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:
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
1. 
" 
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)
DATA
TIPO
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
v1 = {prodotto, data, negozio}!
v2 = {tipo, data, città}!
v4 = {tipo, mese, regione}!
v3 = {categoria, mese,
città}!
v5 = {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}
{a',b'}
{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)
COD
TIPO
prezzo
unitario
quantità
(0,N)
PRODOTTO
in
(1,1)
(1,1)
VENDITA
Identificatori Fatto Vendita:
I1 = {PRODOTTO,NUM.SCONTRINO}
data
in
(1,N)
prodotto
I2 = {COD}
SCONTRINO
num. scontrino
PRODOTTO
SCONTRINO
PRODOTTO
TIPO
NUMERO
DATA
ALIM_1
Alimentare
Scontr12
02/02/02
ALIM_2
Alimentare
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
quantità
prezzo-unitario
data
prodotto
prodotto +
num.scontrino
! 
Dimensioni =
{ prodotto, num.scontrino }
num.scontrino
! 
Tipologia dello Schema: transazionale (le dimensioni coincidono con I1)
! 
Definizione delle misure: di ogni misura si deve
Definire la tipologia: esplicita/derivata/calcolata
Per le misure esplicite
1.  (alimentazione) definire il suo calcolo a partire dal DBO
2.  (aggregabilità) definire l’operatore di aggregazione degli eventi
Per le misure derivate
1.  definire il suo calcolo per ogni evento primario
2.  (aggregabilità) definire l’operatore di aggregazione
Per le misure calcolate
1.  definire il suo calcolo per ogni evento, primario e secondario
1. 
2. 
3. 
4. 
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(*)
DATA
TIPO
VENDITA
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
"
from "
group by
" 
" 
"PRODOTTO, NUM.SCONTRINO,
"SUM(QUANTITA) AS QUANTITA
"DBO.VENDITA
"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
PRODOTTO
prodotto
quantità
(0,N)
in
(1,1)
prezzo
unitario
VENDITA
(1,1)
data
in
(1,N)
SCONTRINO
Identificatori Fatto Vendita:
I1 = {PRODOTTO,NUM.SCONTRINO}
I2 = {COD}
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
VENDITA
QUANTITA
DATA
NUM_VENDITE
TIPO
NUM_CLIENTI
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