Sei sulla pagina 1di 18

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 laggregazione; 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 2 4 6 RAPPORTO 10 10 5 TOTALE 22 44 36

SUM
FACOLTA ING ING
FACOLTA ING

SUM
ALTRO 2 10
ALTRO 12

AVG
RAPPORTO 10 7,5
RAPPORTO 8,33

SUM
TOTALE 22 80
TOTALE 102

DATA GEN1 GEN2


MESE GEN

BASE 20 70
BASE 90

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 TOT_DER 22 44 36 TOT_CAL C 22 44 36

"

SUM
FACOLTA ING ING DATA GEN1 GEN2 BASE 20 70

SUM
ALTRO 2 10

SUM
TOT_DER TOT_CALC 22 22 80 80

FACOLTA ING

MESE GEN

BASE 90

ALTRO 12

TOT_DER TOT_CALC 102 102

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 RAP_DER RAP_CALC 10 10 10 10 5 5

SUM
FACOLTA ING ING DATA GEN1 GEN2 BASE 20 70

SUM
ALTRO 2 10

AVG
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

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
Incasso_calcolato 15,00 7,20 22,20

22,70

"

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.

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 sullefficienza 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 (lesempio 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

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' b a' 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


! !

Lalimentazione definisce le istanze di un Data Mart a partire dalle istanze del DataBase operazionale DBO Nel progetto dellalimentazione 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 lanalisi 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
(0,N) quantit (1,1) prezzo unitario (1,1) (1,N)

data

Identificatori Fatto Vendita: I1 = {PRODOTTO,NUM.SCONTRINO} I2 = {COD}

PRODOTTO

in

VENDITA

in

SCONTRINO

prodotto

num. scontrino

PRODOTTO PRODOTTO ALIM_1 ALIM_2 TIPO Alimentare Alimentare

SCONTRINO NUMERO DATA

Scontr12 Scontr13

02/02/02 02/02/02

VENDITA

COD 3 2 1

PRODOTTO ALIM_1 ALIM_2 ALIM_2

N_SCONTRINO

QUANTITA 12 13 24

PREZZO_UNITARIO 25 12 13
20

Scontr12 Scontr12 Scontr13

Esempio: progettazione concettuale


tipo quantit prezzo-unitario data num.scontrino

Dimensioni = { prodotto, num.scontrino }

prodotto

prodotto + num.scontrino

! ! 1. 2.

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 loperatore di aggregazione degli eventi Per le misure derivate 1. definire il suo calcolo per ogni evento primario 2. (aggregabilit) definire loperatore di aggregazione Per le misure calcolate 1. definire il suo calcolo per ogni evento, primario e secondario
21

3.

4.

Esempio: Definizione delle misure


!

Misura QUANTITA : una misura esplicita; essendo lo schema transazionale coincide con il valore dellattributo 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

DATA

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 lidentificatore 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
(0,N) quantit (1,1) prezzo unitario (1,1) (1,N)

data

Identificatori Fatto Vendita: I1 = {PRODOTTO,NUM.SCONTRINO} I2 = {COD}

PRODOTTO

in

VENDITA

in

SCONTRINO

prodotto

num. scontrino

tipo

quantit

prezzo-unitario data num.scontrino

prodotto

prodotto + 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. Nellesempio 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 laggregabilit rispetto ad una dimensione Di, si considera il pattern ottenuto da quello primario eliminando Di Si pu valutare laggregabilit considerando alcune istanze desempio 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


!

Dallanalisi 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