Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano

Transcript

1 Sistemi Informativi Avanzati Anno Accademico 2011/2012 Prof. Domenico Beneventano ESERCITAZIONI DEL 20 e 27 APRILE 2012 Sommario 1.1 VENDITA Dimensioni = { PROD, DATA,CASSA,COM } Esercizio A (20 Aprile 2012) : SCHEMA5: NS DATA, {PROD,DATA} CASSA Specifica dei pattern in SQL OLAP Cubo OLAP: Specifica dei pattern per dimensioni degeneri Aggregabilità in presenza di Dipendenze Funzionali tra le dimensioni Nota sulle Dipendenze Funzionali Soluzione Esercizio B (27 Aprile 2012) Cubo OLAP : specifica dei pattern Esercizio C : confronto FD tra dimensioni e attributi cross dimensionali

2 1.1 VENDITA Dimensioni = { PROD, DATA,CASSA,COM } Si considerano 6 differenti DBO, cioè 6 DBO con differente schema. Per confrontarli si effettua uno schema di Fatto che ha SEMPRE le stesse dimensioni : { PROD, DATA,CASSA,COM} In questo modo si potrà in particolare discutere l effetto delle FD tra le dimensioni: infatti, i differenti schemi comportano differenti FD sulle dimensioni. MISURE: NUMEROVENDITE = COUNT(*) NUMEROCLIENTI = COUNT(DISTINCT NS), dove NS è il NumeroScontrino Di ogni DBO si considera il suo schema E/R ed il corrispondente schema relazionale SCHEMA1 VENDITA(NV,PROD,CASSA, COMM,NS,DATA) SCHEMA2 : NS DATA VENDITA(NV,PROD,CASSA, COMM, NS:SCONTRINO) SCONTRINO(NS,DATA) SCHEMA3 : NS DATA, NS CASSA VENDITA(NV,PROD, COMM, NS:SCONTRINO) SCONTRINO(NS,DATA,CASSA) SCHEMA4: NS DATA, PROD CASSA VENDITA(NV,PROD:PRODOTTO COMM, NS:SCONTRINO) SCONTRINO(NS,DATA) PRODOTTO(PROD, CASSA) SCHEMA5: NS DATA, {PROD,DATA} CASSA 2

3 VENDITA(NV,PROD:PRODOTTO COMM, NS:SCONTRINO) SCONTRINO(NS,DATA:DATA) DATA(DATA) PRODOTTO(PROD) ALLACASSA(PROD:PRODOTTO, DATA:DATA, CASSA) SCHEMA6: NS DATA, {PROD,DATA} CASSA, CASSA COMM Si toglie COMM da VENDITA e si reifica ALLACASSA: VENDITA(NV,PROD:PRODOTTO NS:SCONTRINO) SCONTRINO(NS,DATA:DATA) DATA(DATA) PRODOTTO(PROD) ALLACASSA(PROD:PRODOTTO, DATA:DATA, CASSA:CASSA) CASSA(CASSA, COMM) NUMEROCLIENTI = COUNT(DISTINCT NS), dove NS è il NumeroScontrino La presenza della FD: NS DATA comporta che 1) NUMEROCLIENTI è aggregabile rispetto a DATA 2) NUMEROCLIENTI non è aggregabile rispetto alle altre dimensioni Nel seguito si vuole discutere come le FD tra le dimensioni influenzino l aggregabilità della misura NUMEROCLIENTI. 3

4 Nota. Nella specifica del compito scritto: Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale (nello schema relazionale ci possono essere vincoli di integrità aggiuntivi) Questo significa che viene dato lo schema E/R ma per non complicarlo molto, alcune cose particolari vengono aggiunte solo nello schema relazionale, cioè vengono considerate come aggiunte allo schema relazionale: queste aggiunte riguardano chiavi, FD sia elencate esplicitamente che date attraverso l aggiunta di tabelle Ad esempio nel compito scritto, invece di riportare lo schema E/R dello SCHEMA6 che risulta complicato a causa della reificazione introdotta per esprimere la FD: CASSA COMM, viene dato il seguente schema E/R più semplice senza la FD: CASSA COMM e tale FD viene aggiunta allo schema relazionale (ricordiamo che la FD è un vincolo di integrità) VENDITA(NV,PROD:PRODOTTO NS:SCONTRINO) SCONTRINO(NS,DATA:DATA) DATA(DATA) PRODOTTO(PROD) ALLACASSA(PROD:PRODOTTO, DATA:DATA, CASSA,COMM) FD: CASSA COMM Si noti che ALLACASSA(PROD:PRODOTTO, DATA:DATA, CASSA,COMM) FD: CASSA COMM È equivalente a ALLACASSA(PROD:PRODOTTO,DATA:DATA, CASSA:CASSA) CASSA(CASSA, COMM) Estremizzando il discorso: per specificare lo SCHEMA5 si può considerare uno schema costituito dalla sola entità VENDITA (quindi il relazionale costituito da una sola relazione VENDITA) ed aggiungere nel relazionale le due FD: VENDITA(NV,PROD,CASSA, COMM,NS,DATA) {PROD,DATA} CASSA NS DATA Questo può essere utile per creare i dati di prova del DBO (come abbiamo fatto ad esempio in In questo caso lo schema E/R e del tutto incompleto in quanto non contiene, non esprime praticamente niente. Normalmente nel compito si cerca di dare uno schema E/R il più completo possibile, lasciando fuori due tipologie di FD 1) Quelle più semplici, classico esempio DATA MESE, MESE ANNO 2) Quelle più complicate, quali CASSA COMM nello schema precedente 4

5 1.2 Esercizio A (20 Aprile 2012) : SCHEMA5: NS DATA, {PROD,DATA} CASSA La presenza della FD: NS DATA comporta che 1) NUMEROCLIENTI è aggregabile rispetto a DATA 2) NUMEROCLIENTI non è aggregabile rispetto alle altre dimensioni Quindi NUMCLIENTI è calcolabile per i pattern che contengono { PROD, CASSA,COMM } P0= {PROD, CASSA,COMM,DATA} P1= {PROD, CASSA,COMM } A questi pattern verranno aggiunti quelli equivalenti grazie alla FD tra le dimensioni. Il risultato finale sarà che NUMCLIENTI è calcolabile per tutti i pattern che contengono {PROD,COM}. Prendendo in considerazione le FD tra le dimensioni, cioè la sola FD2: {PROD,DATA} CASSA e per ciascuno dei due pattern P0 e P1 si controlla se grazie a tali FD si possono ricavare dei pattern equivalenti e quindi tali per cui NUMCLIENTI sia calcolabile anche per tali pattern. Per FD2: {PROD,DATA} CASSA il primo pattern P0 è equivalente a P2= {PROD, COMM,DATA}. Quindi NUMCLIENTI è calcolabile per i pattern P0= {PROD, CASSA,COMM,DATA} P1= {PROD, CASSA,COMM } P2= {PROD, COMM,DATA} Individuati l insieme di pattern P per i quali NUMCLIENTI è calcolabile, si vuole ora scrivere una espressione per individuare P sia in SQL OLAP che nel cubo OLAP: in questo modo sarà possibile visualizzare NUMCLIENTI solo per i pattern in P (oppure visualizzarlo in modo diverso per i restanti pattern: segno, indicazione * oppure un colore diverso) Specifica dei pattern in SQL OLAP Ricordiamo che in SQL OLAP, dato un pattern P = {A1,., An}, un suo sub pattern P1={A1,, Ak}, con k <= n è individuato dalla condizione C_P1: G(A1)=0 AND G(Ak)=0 AND G(Ak+1)=1 AND G(An)=1 Dove G =GROUPING. Per individuare un insiemi di pattern, si deve effettuare la somma logica (l OR) delle condizioni. Quindi per individuare l insieme di pattern per i quali NUMCLIENTI è calcolabile P0={PROD, CASSA,COMM,DATA} P1={PROD, CASSA,COMM} P2= {PROD, COMM,DATA} Si dovrà scrivere in SQL OLAP G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 AND G(DATA) = 0 G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 AND G(DATA) = 1 G(PROD)=0 AND G(CASSA)=1 AND G(COMM)=0 AND G(DATA) = 0 OR OR Anche se non necessario, l espressione si può semplificare tramite i teoremi dell Algebra Booleana o con le mappe di Karnaugh ( Ad esempio G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 AND G(DATA) = 0 G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 AND G(DATA) = 1 OR è equivalente a G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 e quindi la precedente espressione si può semplificare in G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 OR G(PROD)=0 AND G(CASSA)=1 AND G(COMM)=0 AND G(DATA) = 0 5

6 La semplificazione non è necessaria, ha il solo scopo di ridurre il codice SQL da scrivere SELECT COM, PROD,CASSA,DATA, NUMCLIENTI = CASE WHEN ( G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 OR G(PROD)=0 AND G(CASSA)=1 AND G(COMM)=0 AND G(DATA) = 0 ) THEN SUM(NC) ELSE END, NVENDITE=SUM(NVENDITE) FROM FACT_TABLE GROUP BY PROD,CASSA,DATA,COM WITH CUBE Oppure, per realizzare solo l insieme di pattern per i quali NUMCLIENTI è calcolabile SELECT COM, PROD,CASSA,DATA, NUMCLIENTI = SUM(NC), NVENDITE=SUM(NVENDITE) FROM FACT_TABLE GROUP BY PROD,CASSA,DATA,COM WITH CUBE HAVING ( G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 OR G(PROD)=0 AND G(CASSA)=1 AND G(COMM)=0 AND G(DATA) = 0) Ricordiamo che lo scopo delle interrogazioni SQL OLAP, oltre a quello di effettuare alcune analisi direttamente in SQL, cioè senza usare uno specifico sistema OLAP, è anche quello di verificare i risultati: ad esempio, nel nostro caso grazie alla precedente interrogazione possiamo verificare se il calcolo della misura NUMCLIENTI è corretta (effettuando un confronto con i risultati ottenuti nel DBO). Inoltre le interrogazioni SQL OLAP servono anche per verificare il passo successivo di realizzazione ed alimentazione del Cubo OLAP Cubo OLAP: Specifica dei pattern per dimensioni degeneri Per scrivere i pattern in Analysis Service si deve riscrivere G(A)=0 e G(A)=1 in termini di condizioni sui membri dei livelli in cui è mappato l attributo A. Nel nostro esempio, vogliamo riscrivere G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 OR G(PROD)=0 AND G(CASSA)=1 AND G(COMM)=0 AND G(DATA) = 0 Nel caso più semplice in cui A corrisponde all unico livello della dimensione D (ovvero nel caso in cui la dimensione sia degenere) e la dimensione D ha il livello speciale (ALL) allora G(A)=0 equivale a D.CURRENTMEMBER.LEVEL.ORDINAL <> 0 G(A)=1 equivale a D.CURRENTMEMBER.LEVEL.ORDINAL = 0 Si noti che senza il livello speciale (ALL) G(A)=1 non può essere ottenuto e quindi non si riesce ad ottenere il totale per quella Dimensione. Quindi per scrivere : G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 OR G(PROD)=0 AND G(CASSA)=1 AND G(COMM)=0 AND G(DATA) = 0 Si deve tradurre ciascun pattern e poi mettere in OR le espressioni ottenute PROD.CURRENTMEMBER.LEVEL.ORDINAL <> 0 AND CASSA.CURRENTMEMBER.LEVEL.ORDINAL <> 0 AND COMM.CURRENTMEMBER.LEVEL.ORDINAL <> 0 OR PROD.CURRENTMEMBER.LEVEL.ORDINAL <> 0 AND CASSA.CURRENTMEMBER.LEVEL.ORDINAL = 0 AND COMM.CURRENTMEMBER.LEVEL.ORDINAL <> 0 AND DATA.CURRENTMEMBER.LEVEL.ORDINAL <> 0 6

7 1.3 Aggregabilità in presenza di Dipendenze Funzionali tra le dimensioni Nella sezione precedente è stato determinato che NUMCLIENTI è calcolabile per i pattern P0= {PROD, CASSA,COMM,DATA} P1= {PROD, CASSA,COMM } P2= {PROD, COMM,DATA} Ora, considerato che NUMCLIENTI è aggregabile rispetto a DATA, verifichiamo se togliendo DATA da P2= {PROD, COMM,DATA} NUMCLIENTI è ancora calcolabile? La risposta è positiva quindi NUMCLIENTI è calcolabile anche per P3= {PROD, COMM } In definitiva NUMCLIENTI è calcolabile per i pattern P0= {PROD, CASSA,COMM,DATA} P1= {PROD, CASSA,COMM } P2= {PROD, COMM,DATA} P3= {PROD, COMM } Espressione SQL OLAP: G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 AND G(DATA) = 0 OR G(PROD)=0 AND G(CASSA)=0 AND G(COMM)=0 AND G(DATA) = 1 OR G(PROD)=0 AND G(CASSA)=1 AND G(COMM)=0 AND G(DATA) = 0 OR G(PROD)=0 AND G(CASSA)=1 AND G(COMM)=0 AND G(DATA) = 1 Semplificando questa espressione si ottiene G(PROD)=0 AND G(COMM)=0. In definitiva NUMCLIENTI è calcolabile per tutti i pattern che contengono PROD e COMM, cioè che contengono {PROD,COM}. Riassumendo: la FD: NS DATA comporta che NUMCLIENTI è calcolabile per i pattern che contengono { PROD, CASSA,COMM }. Questo insieme si può estendere considerando la FD tra le dimensioni FD2: {PROD,DATA} CASSA concludendo che NUMCLIENTI è calcolabile per tutti i pattern che contengono {PROD,COM}. E' possibile calcolare questo risultato con un altro procedimento, che generalmente risulta più semplice : il procedimento è quello di semplificare prima P0 sulla base delle FD tra le dimensioni e quindi considerare le non aggregabilità; In presenza di FD tra le dimensioni, per calcolare l insieme dei pattern per i quali NUMCLIENTI è calcolabile si procede come segue: 1) Si considera l insieme delle dimensioni, cioè il pattern primario P0= {PROD, CASSA,COMM,DATA} 2) Si semplifica P0 considerando le FD tra le dimensioni, nell esempio FD2:{PROD,DATA} CASSA P0_key= {PROD, CASSA,COMM,DATA} Per semplificazione si intende l eliminazione di una dimensione Di tale che esista una FD tra le dimensioni X Di. Con queste eliminazioni si individua tra tutti i pattern equivalenti a P0 quello più piccolo ; tale insieme viene indicato con P0_key. 3) Si considera P0_key ; dato che NUMCLIENTI è non aggregabile rispetto a PROD, CASSA e COMM allora è calcolabile per tutti i pattern di P0_key che contengono PROD, CASSA e COMM. In termini più generali, data una misura M sia M_NA = { D1,, Dk } l insieme delle dimensioni per le quali M è non aggregabile; allora M può essere calcolato per ogni sottoinsieme che contiene M_NA P0_key Nel nostro esempio NUMEROCLIENTI_NA = {PROD, CASSA,COMM } e quindi l intersezione risulta {PROD, COMM }: Si ottiene quindi lo stesso risultato visto in precedenza. 7

8 Questo discorso può essere generalizzato: si può verificare che una qualsiasi misura è sempre aggregabile rispetto ad una dimensione in P0 ma non in P0_key (nel nostro esempio rispetto a CASSA) e pertanto il controllo delle non aggregabilità può essere effettuato rispetto a P0_key. In definitiva il procedimento che seguiremo è così schematizzabile: 1) Si considera l insieme delle dimensioni, cioè il pattern primario P0 = {D1,, Dn }. 2) Si semplifica P0 considerando le FD tra le dimensioni. Per semplificazione si intende l eliminazione di una Di tale che esista una FD tra le dimensioni X Di. Con queste eliminazioni si individua tra tutti i pattern equivalenti a P0 quello più piccolo ; tale insieme viene indicato con P0_key. Algoritmo di semplificazione di P0 P0_key = P0; FOR i=1 to i=n, se esiste una FD : X Di, dove X P0, Di P0 togliere Di da P0_key : P0_key = P0_key { Di } 3) Si valutano le aggregabilità delle misure rispetto alle sole dimensioni in P0_key : misura M non aggregabile per M_NA = {D1,, Dk }, Di P0_key 4) allora M si può calcolare per i pattern di P0 che contengono M_NA = { D1,, Dk }. Tale insieme è caratterizzato da Nota sulle Dipendenze Funzionali G(D1) = 0 AND AND G(Dk) = 0 Dato P0 = {D1,, Dn } se consideriamo P0 come una relazione P0(D1,, Dn) l operazione di semplificare P0 = {D1,, Dn } equivale a calcolare una chiave P0_key di P0: intuitivamente P0_key è tra tutti i pattern equivalenti a P0 quello più piccolo (ricordiamo il concetto di chiave: una chiave deve essere minimale pag 74 del libro di Sistemi Informativi) Si noti che P0_key Di, per ogni i. Il problema di individuare P0_key è quindi riconducibile al problema di trovare una chiave (e, più in generale, le chiavi) di una relazione, dato un insieme di FD. Il problema è discusso in Sezione 5.2. RAGIONAMENTO SULLE DIPENDENZE FUNZIONALI del libro di Sistemi Informativi dove è anche presentato un algoritmo generale per individuare le chiavi (Algoritmo KEY) Esempio: P0(A,B,C) con le seguenti tre FD: A B, B C, C A P0 ha tre chiavi : chiave1 = A, chiave2=b e chiave3=c In questo caso il nostro algoritmo di semplificazione di P0 dato in precedenza non funzionerebbe, in quanto restituirebbe P0_key vuoto! Questo è dovuto alla particolarità dell esempio: si ha un ciclo sulle FD, cioè partendo da A si arriva ad A. In definitiva, l algoritmo dato per la semplificazione di P0 funziona salvo casi particolari. 8

9 1.3.2 Soluzione Per i 6 differenti schemi dati in precedenza si riporta la discussione per le dipendenze funzionali tra le dimensioni e la misura NUMCLIENTI SCHEMA1 Non ci sono FD tra le dimensioni, quindi P0_key = P0 = {PROD, CASSA,COMM,DATA} Non ci sono FD del tipo NS Dimensione: NUMCLIENTI è non aggregabile rispetto a PROD, CASSA,COMM,DATA NUMCLIENTI è calcolabile per i pattern che contengono {PROD, CASSA,COMM,DATA} cioè solo per P0 = {PROD, CASSA,COMM,DATA} Tale insieme di pattern (che in questo caso è un unico pattern) è caratterizzato da G(PROD) = 0 AND G(CASSA) = 0 AND G(COMM) = 0 AND G(DATA) = 0 SCHEMA2 : NS DATA Non ci sono FD tra le dimensioni, quindi P0_key = P0 = {PROD, CASSA,COMM,DATA} Per la FD NS DATA: NUMCLIENTI è non aggregabile rispetto a PROD, CASSA,COMM NUMCLIENTI è calcolabile per i pattern che contengono {PROD, CASSA,COMM }. Tale insieme di pattern è caratterizzato da G(PROD) = 0 AND G(CASSA) = 0 AND G(COMM) = 0 SCHEMA3 : NS DATA, NS CASSA Non ci sono FD tra le dimensioni, quindi P0_key = P0 = {PROD, CASSA,COMM,DATA} Per le FD NS DATA e NS CASSA: NUMCLIENTI è non aggregabile rispetto a PROD, COMM NUMCLIENTI è calcolabile per i pattern che contengono {PROD, COMM }. Tale insieme di pattern è caratterizzato da G(PROD) = 0 AND G(COMM) = 0 9

10 SCHEMA4: NS DATA, PROD CASSA Per la FD PROD CASSA tra le dimensioni, P0_key ={PROD, COMM,DATA} Si noti che questo è lo SCHEMA2 con in più la FD PROD CASSA tra le dimensioni; le non aggregabilità vengono valutate direttamente con riferimento a P0_key Per la FD NS DATA: NUMCLIENTI è non aggregabile rispetto a PROD, COMM NUMCLIENTI è calcolabile per i pattern di P0_key che contengono {PROD, COMM }. Tale insieme di pattern è caratterizzato da: G(PROD) = 0 AND G(COMM) = 0 Nello schema di Fatto risultante verrà indicata per NUMCLIENTI la non aggregabilità rispetto a PROD, COMM. SCHEMA5: NS DATA, {PROD,DATA} CASSA Per la FD {PROD,DATA} CASSA tra le dimensioni, P0_key ={PROD, COMM,DATA} Si noti che questo è lo SCHEMA2 con in più la FD PROD CASSA tra le dimensioni; le non aggregabilità vengono valutate direttamente con riferimento a P0_key Per la FD NS DATA: NUMCLIENTI è non aggregabile rispetto a PROD, COMM NUMCLIENTI è calcolabile per i pattern di P0_key che contengono {PROD, COMM }. Tale insieme di pattern è caratterizzato da G(PROD) = 0 AND G(COMM) = 0 Nello schema di Fatto risultante verrà indicata per NUMCLIENTI la non aggregabilità rispetto a PROD, COMM. (vedere eserciziob ) SCHEMA6: NS DATA, {PROD,DATA} CASSA, CASSA COMM Per le FD {PROD,DATA} CASSA e CASSA COMM tra le dimensioni, P0_key ={PROD, DATA} Si noti che questo è lo SCHEMA2 con in più le due FD tra le dimensioni; le non aggregabilità vengono valutate direttamente con riferimento a P0_key Per la FD NS DATA: NUMCLIENTI è non aggregabile rispetto a PROD NUMCLIENTI è calcolabile per i pattern di P0_key che contengono {PROD }. Tale insieme di pattern è caratterizzato da G(PROD) = 0 Nello schema di Fatto risultante verrà indicata per NUMCLIENTI la non aggregabilità rispetto a PROD, COMM. (vedere esercizioc ) 10

11 1.4 Esercizio B (27 Aprile 2012) Si prende in esame lo SCHEMA5: NS DATA, {PROD,DATA} CASSA considerando il caso di una dimensione PRODOTTO non più degenere ma con una gerarchia associata; VENDITA( NV,PROD,CASSA, COMM,NS,DATA) {PROD,DATA} CASSA NS DATA PRODOTTO(PROD,TIPO:TIPO) TIPO(TIPO,CAT:CATEG,GRUPPO) CATEG(CAT,REP) E questo è appunto lo schema del DBO dato ( unimo.it/sia/aprile bak) Si noti che nello schema per laa tabella PRODOTTO ci sono erroneamente anche CAT,REP e GRUPPO; questo è un refuso della costruzione del DB: per costruire c dei dati di prova, si riporta prima una tabella PRODOTTO con tutti gli attributi che servono PRODOTTO(PROD,TIPO,CAT,GRUPPO, REP) Si riempie quindi PRODOTTO rispettando le FD E alla finee riporto tutto nelle tabelle TIPOO e CATEG, Ad esempio: insert into CATEG select DISTINCT CAT, REP R from PRODOTTO Schema di Fatto VENDITA: come discusso in precedenza per NUMCLIENTI viene indicataa la non aggregabilità rispetto a PROD, COMM. SnowFlake Schema FACT_TABLE(PRODOTTO:dtPRODOTTO, DATA,COMM, CASSA, NUMVENDITE, NUMCLIENTI) dtprodotto(prodotto,tipo:dttipo) dttipo(tipo,gruppo, CAT:dtCAT) dtcat(cat, REP) ) 11

12 1.5 Cubo OLAP : specifica dei pattern Nella precedente sezionee abbiamo visto come specificaree i pattern per p dimensioni degeneri. Nel caso generale occorre considerare che una dimensione del cubo ha più di d un livelloo e che per tradurre t una dimensione dello schema di fatto si usano più dimensioni del cubo: Nel nostro Cubo VENDITA si avranno quindi due dimensioni GRUPPO, con livelli GRUPPO, TIPO, PROD, indicando i livelli da quelloo superiore: GRUPPO (livello= =1), TIPO (livello=2) e PROD (livello=3) REP, con livelli REP (livello= 1), CAT, TIPO, PROD (livello=4) Ogni cella del cubo è individuata da un valore (membro secondo la terminologt gia AS) per ogni dimensione (sia le dimensioni classiche che la dimensione particolare Measures) : Ad esempio l ultima cella in basso a destra (con visualizzato il valore 25) è individuata come segue: Dimensione DATA: membro D5 (del livello DATA.DATA) Dimensione CASSA: membro ALL CASSA (del livello CASSA.( ALL)) Dimensione REP: membro ALL REP (del livello REP.(ALL)) Dimensione COMM: membro COM1 (del livello COMM.COM) Dimensione GRUPPO: membro P5 (del livello GRUPPO.Prod) Dimensione Measures: membro NumVendite (del livello Measures. MeasuresLevel) 12

13 Ogni membro ha una Key (per individuare il membro) e un Name (valore che viene visualizzato): nei nostri esempi non usando chiavi surrogate Key e Name coincidono. Per ogni cella del cubo la funzione DIMENSION N.CURRENTMEMBER restituisce il membro di DIMENSIONN corrispondente allaa cella corrente. Ad esempio, se GRUPPO.CURRENTMEMBER è il membro P7 (del livello GRUPPO.Prod) ), allora [GRUPPO].CurrentMember.name : è il nome del membro, ovvero cosa viene visualizzato [GRUPPO].CurrentMember.level: è il i livello ; per un livello si può ottenere il nome e la posizione: [GRUPPO].CurrentMember.level.name = PROD [GRUPPO].CurrentMember.level.ordinal =3 G(PROD)=0 equivale a GRUPPO.CURRENTMEMBER.LEVEL.ORDINAL = 3 REP.CURRENTMEMBER.LEVEL. ORDINAL = 4 OR La condizione GRUPPO.CURRENTMEMBER.LEVEL.ORDINAL = 3 si può scrivere attraverso la funzione booleana IsLeaf che applicata ad un membro è true se il membro è una foglia, false altrimenti, quindi IsLeaf(GRU UPPO. CURRENTMEMBER) equivale a GRUPPO.CURRENTMEMBER.LEVEL.ORDINALL = 3 G(PROD)=0 equivale quindi a IsLeaf(GRUPPO. CURRENTMEMBER) OR IsLeaf(REP. CURRENTMEMBER) G(PROD)=0 AND G(COMM)=0 equivale in definitiva a (IsLeaf(GRUPPO. CURRENTMEMBER) OR IsLeaf( (REP. CURRENTMEMBER) ) AND IsLeaf(COMM. CURRENTMEMBER) Questa espressione definisce quindii i pattern all interno del Cubo Olap O per i quali NUMCLIENTI è calcolabile, allora verrà usata per definire una nuova misura (membro calcolato) come Iif(( (IsLeaf(GRUPPO. CURRENTMEMBER) OR IsLeaf(REP. CURRENTMEMBER) ) AND IsLeaf(COMM. CURRENTMEMBER), [Measures].[Nc], ) 13

14 1.6 Esercizio C : confronto FD tra dimensioni e attributi cross dimensionali Si prende in esame lo SCHEMA6: NS DATA, {PROD,DATA}} CASSA, CASSA COMM C (considerando ancora la dimensione PRODOTTO con una gerarchiaa associata come nell ESERCIZIO B) e si confrontano due differenti soluzioni 1. Schema di Fatto Vendita con dimensioni {PROD,DATA, CASSA, COMM } 2. Schema di Fatto Vendita con dimensioni {PROD,DATA } e attributo cross dimensionale Riportiamo le specifiche: Consideriamo un DBO con il seguente schema E/R edd il corrispondente schema relazionale (nello schema relazionale ci possono essere vincoli di integrità aggiuntivi): VENDITA(NV,PROD: PRODOTTO NS:SCONTRINO) SCONTRINO(NS,DATA:DATA) DATA(DATA) PRODOTTO(PROD,TIPO:TIPO) ALLACASSA(PROD:PRODOTTO, DA ATA:DATA, CASSA,COMM) FD: CASSA COMM TIPO(TIPO,CAT:CATEG,GRUPPO) CATEG(CAT,REP) 1. Progetto Concettuale e Logico dello Schema di Fatto Vendita con dimensioni {PROD,DATA, CASSA, COMM } e misure NUMVENDITEE e NUMCLIENTI. 2. Progetto Concettuale e Logico dello Schema di Fatto Vendita con dimensioni {PROD,DATA, } e misure NUMVENDITE e NUMCLIENTI. 14