Sistemi Informativi Avanzati Anno Accademico 2013/2014 Prof. Domenico Beneventano Misure In parte dal Capitolo 5 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo Golfarelli, Stefano Rizzi; Editore: McGraw-Hill Definizione delle misure! Definire una misura significa specificarne il suo Calcolo sul DBO e la sua Aggregazione nel Data Mart! Calcolo: definire il suo valore per gli eventi primari Normalmente questo valore viene calcolato sul DBO, in fase di alimentazione del Data Mart. Per le misure derivate invece tale valore è derivato a livello di eventi primari - dal valore di altre misure e/o dimensioni! Aggregazione: definire il suo valore per eventi secondari Normalmente questo valore si ottiene tramite un operatore di aggregazione rispetto alle dimensioni del fatto. Per le misure calcolate invece tale valore è calcolato - a livello di eventi secondari e quindi dopo aver aggregato i dati - dal valore di altre misure: " non c è un operatore di aggregazione! 2
Esempio! Esempio delle vendite con scontrino (nella tabella, per semplicità, il tipo è sottinteso dal nome del prodotto) VENDITA - DB OPERAZIONALE TIPO PREZZO DATA PRODOTTO (1,N) VENDITA (1,N) SCONTRINO! Misure 1. NUMERO_VENDITE = COUNT(*) 2. PREZZO_MEDIO = AVG (PREZZO) 3. NUMERO_CLIENTI = COUNT(DISTINCT SCONTRINO) il numero clienti è valutato contando gli scontrini 4. NUMERO_PRODOTTI = COUNT(DISTINCT PRODOTTO) per valutare quanti differenti prodotti vengono venduti 3 Esempio: Analisi dei dati - aggregazione! Le dimensioni di analisi sono MESE e TIPO VENDITA - DB OPERAZIONALE! Il report completo da ottenere è il seguente: REPORT : MESE-TIPO, tutte le misure, con i totali Legenda 4
Esempio: il report in SQL-OLAP! Il report si può ottenere con i vari strumenti OLAP (cubo multidimensionale, tabelle pivot, SQL-OLAP!) DB OPERAZIONALE! In SQL-OLAP: 5 Esempio : Misure nel Data Mart! Schema di fatto VENDITA! Schema logico con Fact-Table(TIPO,MESE,! TIPO VENDITA NUMERO_VENDITE PREZZO_MEDIO NUMERO_CLIENTI NUMERO_PRODOTTI MESE! Per ogni misura occorre stabilire 1. ALIMENTAZIONE: cosa riportare nella Fact-Table e come calcolarlo a partire dalla sorgente operazionale 2. AGGREGAZIONE: se è possibile (aggregabilità) e come ottenere i valori aggregati a partire da quelli presenti nel Data Mart 6
Esempio: Operatore COUNT(*) ALIMENTAZIONE DATA MART NUMERO_VENDITE = COUNT(*) (DATA MART) ANALISI DEI DATI (AGGREGAZIONE) NUMERO_VENDITE = SUM(NUMERO_VENDITE) # Per l operatore COUNT(*) è corretto calcolare il valore aggregato a partire dai valori presenti nel Data Mart! 7 Esempio: Prezzo Medio tramite AVG ALIMENTAZIONE DATA MART PREZZO_MEDIO= AVG(PREZZO) (DATA MART) ANALISI DEI DATI (AGGREGAZIONE) PREZZO_MEDIO= AVG(PREZZO_MEDIO) NO! (25+17.5)/2 = 21.25 NO! (10+25+17.5)/3 = 16.25 # Per l operatore AVG non è corretto calcolare il valore aggregato a partire dai valori presenti nel Data Mart! 8
Esempio: Prezzo Medio calcolato ALIMENTAZIONE DATA MART NUMERO_VENDITE = COUNT(*) PREZZO_SOMMA = SUM(PREZZO) (DATA MART) ANALISI DEI DATI (AGGREGAZIONE) PREZZO_SOMMA PREZZO_MEDIO = ---------------------- NUMERO_VENDITE OK! (25+35)/(1+2) = 20.0 OK! (20+25+35)/(2+1+2) = 16.0 # PREZZO_MEDIO deve essere una misura calcolata da altre misure componenti 9 Esempio: Operatore COUNT(DISTINCT ) ALIMENTAZIONE DATA MART NUM_CLIENTI= COUNT(DISTINCT SCONTRINO) (DATA MART) ANALISI DEI DATI (AGGREGAZIONE) NUMERO_CLIENTI= SUM(NUMERO_CLIENTI) NO! 1+1=2 OK! 1+2 = 3 NO! 1+1+2=4 # Per l operatore COUNT(DISTINCT ) non è sempre corretto calcolare il valore aggregato dai valori nel Data Mart : NUMERO_CLIENTI è non aggregabile rispetto a TIPO! 10
Esempio: Operatore COUNT(DISTINCT ) ALIMENTAZIONE DATA MART NUMERO_PRODOTTI= COUNT(DISTINCT PRODOTTO) (DATA MART) ANALISI DEI DATI (AGGREGAZIONE) NUMERO_PRODOTTI= SUM(NUMERO_PRODOTTI) OK! 2+1=3 NO! 1+2 = 3 NO! 2+1+2=5 # NUMERO_PRODOTTI è non aggregabile rispetto a MESE: non è possibile calcolare i valori per TOTALE_MESE 11 Per riassumere: DB (SORGENTE OPERAZIONALE) ALIMENTAZIONE DATA MART Pattern Primario {MESE,TIPO} ANALISI DEI DATI (AGGREGAZIONE) Pattern {MESE} Pattern {TIPO} Pattern {} 12
Esempio: Conclusioni e Decisioni! La scelta di un Data Mart con dimensioni TIPO e MESE comporta che alcune delle misure non siano sempre calcolabili!! Se questo non è accettabile a livello di analisi si deve aumentare la granularità del Data Mart!! Per poter sempre calcolare il numero clienti: dimensione SCONTRINO (con TIPO come livello) in modo da poter valutare anche nel Data Mart il numero clienti come NUM_CLIENTI=COUNT(DISTINCT SCONTRINO)! Per poter sempre calcolare anche il numero prodotti: Massima granularità (schema transazionale): dimensioni SCONTRINO e DATA che coincidono con l identificatore del fatto VENDITA TIPO PRODOTTO VENDITA NUMERO_VENDITE PREZZO_MEDIO NUMERO_CLIENTI NUMERO_PRODOTTI MESE SCONTRINO 13 Esempio: Schema Transazionale! La Fact Table corrisponde alla tabella VENDITE. ALIMENTAZIONE DATA MART! La Fact Table non ha più l attributo NUM_CLIENTI (NUM_PRODOTTI) in quanto ora viene aggregato e calcolato come NUM_CLIENTI= COUNT(DISTINCT SCONTRINO)! Per aggregare e calcolare il prezzo medio, due possibili soluzioni 1. PREZZO_MEDIO = AVG(PREZZO) 2. PREZZO_MEDIO = SUM(PREZZO)/NUMERO_VENDITE = SUM(PREZZO)/COUNT(*)! Queste due soluzioni verranno confrontate nel seguito. 14
Esempio: Operatore SUM! Si considera ora anche la quantità venduta QTY (aggregata tramite SUM) e quindi l incasso definito come QTY*PREZZO! Il report completo da ottenere viene ricavato in SQL-OLAP (per semplicità non si riportano alcune delle misure già discusse) DB OPERAZIONALE QTY= SUM(QTY) INCASSO= SUM(QTY*PREZZO) NUMERO_VENDITE = COUNT(*) PREZZO_MEDIO= AVG(PREZZO) 15 Esempio : Misure Derivate! Schema di fatto VENDITA (schema temporale) TIPO VENDITA NUMERO_VENDITE PREZZO_MEDIO QTY INCASSO MESE! INCASSO non è derivabile da altre misure della Fact Table:?! Occorre riportare INCASSO nella Fact Table ed alimentarla: ALIMENTAZIONE DATA MART INCASSO= SUM(QTY*PREZZO) 16
Esempio : Misure Derivate! Schema di fatto VENDITA (schema transazionale) TIPO PRODOTTO VENDITA NUMERO_VENDITE PREZZO_MEDIO QTY INCASSO MESE SCONTRINO! INCASSO è ora derivabile dalle altre misure e quindi non è riportata nella Fact Table: INCASSO=QTY*PREZZO! INCASSO è aggregata tramite SUM ANALISI DEI DATI (AGGREGAZIONE) Pattern {MESE,TIPO} 17 Misure normali e misure derivate! Misure Normali : il valore si ottiene $ per gli eventi primari : dal DBO (alimentazione) $ per gli eventi secondari: tramite operatore di aggregazione $ Una misura normale deve essere inclusa nella Fact Table e deve essere inclusa nel Cubo OLAP! Misure Derivate : il valore si ottiene $ per gli eventi primari: dal valore di altre misure e/o dimensioni $ per gli eventi secondari: tramite operatore di aggregazione $ Una misura derivata non viene normalmente inclusa nella Fact Table (a volte si include per poter fare calcoli particolari o per semplificare) ma deve essere inclusa nel Cubo OLAP 18
Misure calcolate! Misure Calcolate: il valore si ottiene $ per gli eventi primari: dal valore di altre misure $ per gli eventi secondari: dal valore di altre misure $ Per una misura calcolata la Fact Table deve contenere tutte le altre misure usate per il suo calcolo (misure componenti) $ Una misura calcolata non è inclusa direttamente nel Cubo OLAP ma viene definita come membro calcolato $ Generalmente le misure componenti sono delle misure normali, a volte delle misure derivate, raramente altre misure calcolate! Un eccezione a questa classificazione (Normali, Derivate e Calcolate ) è la misura CONTEGGIO (schemi di fatto vuoti) il cui valore $ per gli eventi primari: è 1 $ per gli eventi secondari: operatore di aggregazione COUNT(*) 19 Aggregabilità ed Additività! Una misura è aggregabile su una dimensione se i suoi valori possono essere aggregati lungo la corrispondente gerarchia, altrimenti è non-aggregabile! Una misura è additiva su una dimensione se i suoi valori possono essere aggregati lungo la gerarchia tramite l operatore di somma, altrimenti è non-additiva.! Classificazione delle misure dell esempio: 1. NUMERO_VENDITE: additiva (su tutte le dimensioni) 2. PREZZO_MEDIO: aggregabile ma non-additiva 3. NUMERO_CLIENTI: additiva su MESE, non-aggregabile su TIPO 4. NUMERO_PRODOTTI: additiva su TIPO, non-aggregabile su MESE 5. QTY e INCASSO: additive (su tutte le dimensioni) 20
Aggregabilità ed Additività! Rappresentazione grafica TIPO VENDITA NUMERO_VENDITE (C) PREZZO_MEDIO (AVG) QTY INCASSO NUMERO_CLIENTI NUMERO_PRODOTTI MESE! (AVG) : tra parentesi l operatore di aggregazione! (C) : misura è calcolata! Additività : è il default, cioè è sottointeso (SUM)! Linea tratteggiata: non aggregabilità rispetto alla dimensione 21 Differenti operatori per dimensione! Ipotesi: per ogni misura, è definito un unico operatore di aggregazione valido per ogni dimensione $ Le misure con differenti operatori verranno solo introdotte nel seguito, rimandando il loro trattamento allo specifico sistema OLAP! Esempio di misura con differenti operatori di aggregazione anno mese data peso confezione prodotto tipo INVENTARIO reparto categoria marca unità per pallet indirizzo La misura livello è additiva rispetto alle dimensioni prodotto e magazzino mentre è non-additiva ma aggregabile rispetto a data con operatori quali AVG e MIN AVG, MIN livello quantità ingresso magazzino città stato 22
Schemi di fatto vuoti! In uno schema di fatto vuoto non ci sono misure memorizzate nello schema di fatto (e quindi riportate nello schema logico, cioè nella Fact Table): l unica misura, implicitamente definita, è il conteggio degli eventi primari, nel nostro esempio il numero di presenze dello studente! Un altro modo di rappresentare il verificarsi di un evento è attraverso una misura normale di tipo booleana, additiva: normalmente questa misura assume il solo valore 1 (evento che si è verificato) e non il valore 0 (nello schema di fatto non si rappresentano gli eventi che non si verificano).! Una misura vuota per il conteggio degli eventi primari può essere presente anche con altre misure. Ad esempio, nello schema di fatto FREQUENZA (non più vuoto) si riportano le seguenti misure 1. (COUNT) conteggio degli eventi primari 2. VOTO (AVG) : voto medio riportato 3. NUMERO_ORE: misura additiva, numero complessivo delle ore 23 Schemi di fatto vuoti (CONTEGGIO)! Uno schema di fatto si dice vuoto se non ha misure $ In questo caso, il fatto registra solo il verificarsi di un evento $ Un evento primario rappresenta che si è verificato l evento (uno studente ha frequentato un corso durante un semestre) $ Un evento secondario rappresenta normalmente il numero di eventi primari ad esso corrispondenti, ovvero si usa come operatore di aggregazione il COUNT semestre anno professore indirizzo nome studente nazionalità età sesso FREQUENZA (COUNT) corso area facoltà 24
Operatori di aggregazione! Classificazione degli operatori di aggregazione : 1) Distributivi: permettono di calcolare dati aggregati direttamente da dati parzialmente aggregati (es. somma, massimo, minimo, conteggio) 2) Algebrici: richiedono un numero finito di informazioni aggiuntive (misure di supporto) per calcolare dati aggregati da dati parzialmente aggregati Es. media richiede il numero dei dati elementari che hanno contribuito a formare un singolo dato parzialmente aggregato " una misura da aggregare tramite l operatore media è una misura calcolata come somma/conteggio 3) Olistici: non permettono di calcolare dati aggregati a partire da dati parzialmente aggregati utilizzando un numero finito di informazioni aggiuntive (es. mediana, moda) 25 Operatori Distributivi ed Algebrici! Misure definite con operatori Distributivi ed Algebrici permettono di calcolare dati aggregati a partire da dati parzialmente aggregati. Esempi: 1. operatore SUM - misura additiva QTY; 2. operatore AVG - misura calcolata PREZZO_MEDIO=PREZZO_SUM/PREZZO_COUNT Pattern Primario {MESE,TIPO} Pattern {MESE} Pattern {TIPO} Pattern {} 26
Calcolo delle misure: Viste materializzate! La proprietà di calcolare dati aggregati a partire da dati parzialmente aggregati è fondamentale nei sistemi OLAP:! Nei sistemi OLAP, un aumento delle prestazioni può essere ottenuto pre-calcolando i dati aggregati di uso più comune, cioè pre-calcolando alcuni pattern! L ottimizzazione usa il concetto di vista materializzata: $ Vista : le sue tuple sono determinate da una query $ Materializzata : le sue tuple sono memorizzate in una tabella # Argomento Viste materializzate 27 Schema Transazionale - Operatore AVG! In uno schema transazionale (vedi pag. 14) per aggregare e calcolare il prezzo medio, due possibili soluzioni 1. Si riporta PREZZO nella Fact Table e si utilizza AVG PREZZO_MEDIO = AVG(PREZZO) 2. Come nel caso temporale, si riportano nella Fact Table due misure normali additive PREZZO_SUM e PREZZO_COUNT e si usa la misura calcolata PREZZO_MEDIO=PREZZO_SUM/PREZZO_COUNT! E facile verificare che solo con la seconda soluzione è possibile calcolare dati aggregati a partire da dati parzialmente aggregati!! In alcuni sistemi OLAP (es. Analysis Services) AVG non viene reso disponibile! 28
Nota sul Prezzo Medio calcolato! Nel calcolo del prezzo medio i valori NULL di PREZZO (se consentiti nel DBO) devono essere trascurati!! In SQL, gli operatori AVG() e SUM() e COUNT() trascurano i NULL, che invece vengono contati con COUNT(*).! Per gestire i valori NULL nella misura calcolata: PREZZO_MEDIO=PREZZO_SUM/PREZZO_COUNT Quindi PREZZO_COUNT deve essere calcolata dal DBO come 1. Schema Transazionale: PREZZO_COUNT=WHEN PREZZO IS NULL THEN 0 ELSE 1 2. Schema Temporale: PREZZO_COUNT=COUNT(PREZZO) dove COUNT(PREZZO) coincide con COUNT(*) solo se PREZZO non ammette valori NULL: 29 Operatori distributivi! Distributivi: permettono di calcolare dati aggregati a partire direttamente da dati parzialmente aggregati.! Sia S un insieme di dati ed S1,..., Sn una sua partizione. Una funzione di aggregazione F è distributiva se esiste una funzione G tale che: F(S1,..., Sn) = G(F(S1),!, F(Sn))! Operatore somma: F= sum(); in questo caso G=F sum(s1,..., Sn)=sum(sum(S1),... sum(sn))! Operatore conteggio: F= count(); in questo caso G=sum() (cioè <>F) count(s1,..., Sn)=sum(count(S1),..., count(sn)) 30
Operatori di aggregazione distributivi! Per approfondire: articolo sull operatore WITH CUBE http://arxiv.org/pdf/cs/0701155.pdf! Nel seguito una verifica informale sul nostro esempio Tabella VENDITA nel DBO S = {A,B,C,D,E} A B C D E ALIMENTAZIONE DATA MART Pattern Primario {MESE,TIPO} S1 = { A, B } S2 = { C } S3 = { D, E }! S = {A,B,C,D,E } : tuple di VENDITA nel DBO! La prima tupla della Fact Table raggruppa le tuple A, B quindi S1 = {A,B} e cosi via: S2 = { C} e S3 = {D, E} La Fact Table è quindi una partizione del DBO. 31 Operatori di aggregazione distributivi! Consideriamo le due misure con operatori distributivi: $ PREZZO_SOM con operatore sum: sum(s1,s2,s3) = 80 = sum(sum(s1), sum(s2),sum(s3)) = sum(20,25,35) = 80 $ NUM_VENDITE con operatore count: count(s1,s2,s3) = 5 = sum(count(s1), count(s2), count(s3)) = sum(2,1,2) = 5! Consideriamo la misura NUM_CLIENTE con operatore non distributivo count distinct: $ NUM_CLIENTI con operatore count distinct SCONTRINO: dcount(s1,s2,s3) = 3 " sum(dcount(s1),dcount(s2),dcount(s3)) = sum(1,1,2) = 4 32
Operatori di aggregazione distributivi! Per le misure calcolate con operatori distributivi è possibile stabilire la loro aggregabilità 1. L operatore SUM() è distributivo quindi la misura QTY = SUM (QTY) è additiva rispetto a tutte le dimensioni 2. L operatore COUNT (*) è distributivo quindi la misura NUMERO_VENDITE = COUNT(*) è additiva rispetto a tutte le dimensioni 3. L operatore COUNT (DISTINCT ) non è distributivo quindi NUMERO_CLIENTI = COUNT(DISTINCT SCONTRINO) non è necessariamente additiva rispetto a tutte le dimensioni 33 Operatore COUNT (DISTINCT )! Per una misura calcolata sul DBO tramite l operatore COUNT (DISTINCT) vale la seguente proprietà: Dato uno Schema di Fatto F con dimensioni D ed una Misura M=COUNT(DISTINCT A), con A attributo del DBO, per una dimensione D! D, M è additiva rispetto a D se esiste un insieme X" D tale che X # { A } % D non banale altrimenti è non aggregabile rispetto a D! Esempio Schema VENDITA con D = { TIPO,MESE} 1. NUMERO_CLIENTI = COUNT(DISTINCT SCONTRINO) SCONTRINO % MESE: additiva rispetto a MESE SCONTRINO % TIPO: non aggregabile rispetto a TIPO Intuizione della regola : lo SCONTRINO è associato ad un unico MESE ma non ad un unico TIPO 34
Insieme delle Non-Aggregabilità (NA)! Dato uno Schema di Fatto F con dimensioni D Per una misura M si considera la sua aggregabilità rispetto a ciascuna dimensione D! D e si definisce quindi l insieme delle nonaggregabilità NA " D di M! Dato un generico pattern P, il valore aggregato di M è calcolabile per P se P contiene NA : NA " P! Per questi pattern P il valore aggregato di M viene calcolato usando l operatore di aggregazione specificato per le Di! A! Esempio schema VENDITA con D = { TIPO,MESE} M=NUMERO_CLIENTI = COUNT(DISTINCT SCONTRINO) M additiva rispetto a MESE, in quanto SCONTRINO% MESE Non aggregabilità NA = {TIPO} " M è calcolabile (con SUM) per ogni pattern che contiene {TIPO}. 35 Aggregabilità delle misure: esempio PRODOTTO PRODOTTO (1,N) IN (1,1) DATA VENDITA NS VENDITA QUANTITA DATA TIPO QUANTITA NUM_CLIENTI PRODOTTO TIPO! Misura NUM_CLIENTI = COUNT(DISTINCT NS)! {Data, NS } % PRODOTTO: additiva rispetto a PRODOTTO! NS % DATA: non aggregabile rispetto a DATA! Intuizione della regola di aggregabilità! {Data, NS } % PRODOTTO : per una certa data, c è un associazione tra NS e PRODOTTO di tipo uno-a-molti # Per la misura NUM_CLIENTI l insieme delle non-aggregabilità è NA = { DATA}, quindi il suo valore aggregato è calcolabile (tramite SUM) solo per i pattern che contengono NA, cioè per {DATA} e {DATA, TIPO} 36
Aggregabilità delle misure derivate CATEGORIA PREZZO DATA TIPO (1,N) HA (1,1) PRODOTTO (1,N) VENDITA (1,N) SCONTRINO! Definizione delle Misure: 1. NUMERO_CLIENTI = COUNT(DISTINCT SCONTRINO) 2. NUMERO_PRODOTTI = COUNT(DISTINCT PRODOTTO) CATEGORIA TIPO VENDITA NUMERO_PRODOTTI NUMERO_CLIENTI (COUNT DISTINCT) MESE SCONTRINO! NUMERO_CLIENTI è una misura derivata, aggregabile rispetto a tutte le dimensioni tramite COUNT DISTINCT! NUMERO_PRODOTTI è additiva su TIPO (in quanto PRODOTTO % TIPO) e non aggregabile rispetto alle altre dimensioni (SCONTRINO) $ è calcolabile solo per i pattern che contengono SCONTRINO, quindi non è calcolabile neanche per il pattern {MESE}! 37 Aggregabilità e FD tra le dimensioni! Nel caso particolare di dipendenze funzionali tra dimensioni occorre fare delle precisazioni sull aggregabilità delle misure! La considerazione è semplice: se ho D={D1,!, Dn} con {D1,!, Dn-1} % Dn allora tutte le misure restano invariate in {D1,!, Dn-1}!! Quindi Dn non può appartenere a nessun insieme NA "il calcolo di NA viene fatto rispetto allo schema equivalente senza FD tra le dimensioni! Esempio: allo schema precedente si aggiunge la dimensione IVA con la FD: {PRODOTTO,DATA} % IVA! Le non-aggregabilità si valutano rispetto allo schema equivalente in cui IVA è cross-dimensionale IVA PRODOTTO VENDITA QUANTITA NUM_CLIENTI DATA TIPO 38
Non aggregabilità nei sistemi OLAP! In un sistema OLAP il calcolo delle misure deve essere definito per ogni possibile aggregazione, ovvero per ogni possibile pattern P del reticolo roll-up.! Per le non aggregabilità si deve implementare la regola: M è calcolabile per P se P contiene NA : NA " P! IF (NA " P) THEN <calcolo> ELSE non calcolabile! In SQL-OLAP : NA " P si formula con GROUPING (G): sia NA= {D1,!, Dk}, allora (NA " P) equivale a G(D1)=0 AND! AND G(Dk)=0! Nei sistemi OLAP che usano MDX, intuitivamente si usa il fatto che il livello dimensione corrisponde ad una foglia: (NA " P) equivale a leaf(d1) AND! AND leaf(dk) 39 ESEMPIO! DBO Schema: istanza (relazione universale): STUDENTE(STUDENTE,CITTA) CORSO(CORSO,CFU,FACOLTA) APPELLO(APPELLO,CORSO:CORSO) ESAME(DATA,STUDENTE:STUDENTE,APPELLO:APPELLO,VOTO)! Dimensioni = { DATA, CITTA, CORSO}; schema temporale! Misure 1. NUM_APPELLI=count(DISTINCT APPELLO) Additiva a CORSO in quanto APPELLO % CORSO 2. NUM_STUDENTI=count(DISTINCT STUDENTE) Additiva rispetto a CITTA in quanto STUDENTE % CITTA Additiva rispetto a CORSO in quanto STUDENTE,DATA % CORSO Infatti STUDENTE,DATA # APPELLO e APPELLO % CORSO 3. NUM_ESAMI=count(*), addittiva 4. CFU=SUM(CFU), addittiva 40
ESEMPIO: Schema di fatto e Fact Table! Schema di Fatto FACOLTA CITTA ESAME CORSO NUM_APPELLI NUM_ESAMI CFU NUM_STUDENTI DATA! FACT TABLE c è inoltre la dimension table DT_CORSO(CORSO,FACOLTA)! ALIMENTAZIONE: la è alimentata attraverso la seguente view CREATE VIEW AS SELECT CORSO,CITTA,DATA, CFU=SUM(CFU), NUM_ESAMI=COUNT(*), NUM_APPELLI=COUNT(DISTINCT APPELLO), NUM_STUDENTI=COUNT(DISTINCT STUDENTE) FROM RU GROUP BY CORSO,CITTA,DATA 41 ESEMPIO: pattern {CITTA,DATA}! Misure 1. NUM_APPELLI è additiva rispetto a CORSO, quindi NA={CITTA,DATA} è calcolabile solo per i pattern che contengono CITTA e DATA, quindi i pattern con GROUPING(CITTA)=0 AND GRUPING(DATA)=0; 2. NUM_STUDENTI è addittiva rispetto a CITTA e CORSO, quindi NA={DATA} è calcolabile solo per i pattern che contengono DATA, quindi i pattern con GROUPING(DATA)=0.! Effettuiamo la verifica calcolando il data cube di {CITTA,DATA} sia nel DBO (query sulla relazione RU) che nel Data Mart (query sulla Fact Table) 42
ESEMPIO: query in SQL-OLAP 1. Nel DataBase operazionale, la query risulta la seguente: SELECT CITTA=CASE WHEN GROUPING(CITTA)=1 THEN 'ALL_CITTA' ELSE CITTA END, DATA=CASE WHEN GROUPING(DATA)=1 THEN 'ALL_DATA' ELSE DATA END, CFU=SUM(CFU), NUM_STUDENTI=COUNT(DISTINCT STUDENTE), NUM_ESAMI=COUNT(*), NUM_APPELLI=COUNT(DISTINCT APPELLO) FROM RU GROUP BY CITTA,DATA WITH CUBE 2. Nel DataMart, la query sulla risulta la seguente: SELECT CITTA=CASE WHEN GROUPING(CITTA)=1 THEN 'ALL_CITTA' ELSE CITTA END, DATA=CASE WHEN GROUPING(DATA)=1 THEN 'ALL_DATA' ELSE DATA END, CFU=SUM(CFU), NUM_ESAMI=SUM(NUM_ESAMI), NUM_STUDENTI=SUM(NUM_STUDENTI),NUM_APPELLI=SUM(NUM_APPELLI) FROM GROUP BY CITTA, DATA WITH CUBE 43 ESEMPIO: misure NonCalcolabili! Nel DataMart la query può esplicitare quando una misura è NonCalcolabile (il CONVERT è necessario per uniformare i tipi del CASE): SELECT CITTA=CASE WHEN GROUPING(CITTA)=1 THEN 'ALL_CITTA' ELSE CITTA END, DATA=CASE WHEN GROUPING(DATA)=1 THEN 'ALL_DATA' ELSE DATA END, CFU=SUM(CFU), NUM_APPELLI=SUM(NUM_APPELLI), NUM_STUDENTI=CASE WHEN GROUPING(DATA)=0 THEN CONVERT(CHAR(12),SUM(NUM_STUDENTI)) ELSE 'NonCalcolabile END, NUM_APPELLI=CASE WHEN GROUPING(DATA)=0 AND GROUPING(CITTA)=0 THEN CONVERT(CHAR(12),SUM(NUM_APPELLI)) ELSE 'NonCalcolabile' END FROM GROUP BY CITTA, DATA WITH CUBE 44
Misura aggregabile con differenti operatori! Per una misura si possono definire differenti operatori di aggregazione per le differenti dimensioni anno mese data peso confezione AVG, MIN prodotto tipo INVENTARIO livello quantità ingresso reparto categoria marca unità per pallet indirizzo magazzino città stato! La misura Livello è addittiva sulle dimensioni Prodotto e Magazzino, mentre rispetto alla dimensione Data si possono usare gli operatori AVG e MIN! Se per Data si usa MIN, nel calcolo di Livello per il pattern {Città, Mese} si deve scegliere se applicare prima MIN e poi SUM (somma dei minimi) o viceversa (minimo della somma) 45 Misura aggregabile con differenti operatori! Livello aggregato tramite SUM su Magazzino e tramite MIN su Data! {Magazzino, Data} 3 Citt Magazzino 1 / 3 2 /3 RE M1 10 25 M2 40 30 Mese Data {Magazzino, Mese} Citt Magazzino 3 RE M1 10 M2 30 Mese {Città, Data} 3 Citt 1 / 3 2 /3 RE 50 55 Mese Data! Per il Pattern {Città, Mese} si hanno due possibilità: 1. Minimo della Somma = 50 2. Somma dei Minimi = 40! Nel sistema OLAP di SQL-SERVER (Analysis Services, linguaggio MDX) è possibile definire: # formule personalizzate di rollup per i vari livelli di una dimensione # l ordine di priorità per dire a quale aggregazione dare precedenza 46