ESERCIZI - Progettazione di un DW

Transcript

1 Sistemi Informativi Avanzati Anno Accademico 2012/2013 Prof. Domenico Beneventano ESERCIZI - Progettazione di un DW ESERCIZI VERSIONE DRAFT APRILE Esercizio: Spedizione Soluzione Variante Esercizio: Spedizione - variante Soluzione Spedizione: Seconda Variante (schema transazionale) Soluzione Soluzioni possibili per la misura NUMERO (conteggio eventi primari) Soluzioni possibili per la misura COSTO (misura con AVG in schema transazionale) Esercizio: Dettaglio Ordine Soluzione Esercizio: Biglietto Soluzione Variante VARIANTE (dimensione derivante da discretizzazione) Esercizio (ESAME con ESAME-STUDENTE ed ESAME-GRUPPO) Soluzione Compiti Scritti (tipologie) Esercizio: Vendita (prima versione) Soluzione Compiti Scritti (tipologie) Esercizio: Vendita (seconda versione) Soluzione Esempi per PROVA SCRITTA Soluzione (solo gli aspetti principali) Ottenere tutti gli elementi di un reticolo in SQL-OLAP ESERCIZI (CON ARCHI MULTIPLI) ESEMPI con Arco multiplo su CORSO-DOCENTE

2 2.1.1 Senza Arco multiplo su CORSO-DOCENTE Con Arco multiplo su CORSO-DOCENTE Esercizio A - Arco multiplo su CORSO-DOCENTE Schema transazionale Schema temporale Aggregabilità delle misure CONVERGENZA IN PRESENZA DI ARCHI MULTIPLI Esercizio B: Arco multiplo su LIBRO-AUTORE (transazionale) Varianti Esercizio C: Arco multiplo su LIBRO-AUTORE (temporale) Esercizio (ESAME con arco multiplo GRUPPO-STUDENTE) Variante con ATTRIBUTO CROSS-DIMENSIONALE Arco multiplo GRUPPO-STUDENTE Dimensioni = { GRUPPO } Dimensioni = { GRUPPO,APPELLO } Dimensioni = {DOCENTE, DATA, GRUPPO} Dimensioni = {DOCENTE, DATA, GRUPPO,APPELLO} Dimensioni = { DOCENTE, GRUPPO } Attributo STUDENTE come dimensione Esercizio (RIPARAZIONE, arco multiplo APPARTAMENTO-PROPRIETARIO) Soluzione Esempi per PROVA SCRITTA Esercizio (Esame di Tecnologia delle Basi di Dati 19/12/2012) Soluzione Esercizio (Esame di Tecnologia delle Basi di Dati 14/01/2013) Soluzione Esercizio (Esame di Tecnologia delle Basi di Dati 11/02/2013) Soluzione

3 Esercizi versione draft - Aprile 2013 Ogni esercizio contiene, in generale, tutti i punti di progettazione (Concettuale, Logica e dell alimentazione) di aggregabilità e calcolo delle misure. Ogni esercizio contiene anche la parte relativa alle interrogazioni SQL-OLAP e costruzione del reticolo di roll-up. Questo argomento non è stato ancora trattato e verrà trattato in modo differente durante il corso. Per alcuni esercizi viene anche riportato il codice SQL per: 1) la generazione del database DBO: In questo modo può essere generato il DBO operazionale e si possono provare le soluzioni date in questa sezione, relative al controllo di condivisione/convergenza e all alimentazione. 2) la generazione dello star schema o della snowflake schema: La Fact Table e le dimension table sono definite come viste nel DBO dato. In questo viene definito lo star schema o lo snowflake schema e si possono provare le soluzioni date in questa sezione, relative alle interrogazioni SQL-OLAP. 3

4 1.1 Esercizio: Spedizione Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale (nello schema relazionale ci possono essere vincoli di integrità aggiuntivi): MAGAZZINO IN REGIONE (0,N) CITTA STATO CITTA(CITTA,REGIONE,STATO) DF: REGIONEà STATO (1,N) IN REPARTO (1,N) DA COSTO SPEDIZIONE DETTAGLIO NRIGA MAGAZZINO REPARTO PRODOTTO DATA MESE ANNO (1,N) CITTA CLIENTE ORDINE DATA ORDINE (0,N) INDIRIZZO CLIENTE (1,N) DEL ORDINE DATA(DATA,MESE,ANNO) DF: MESE à ANNO ORDINE(ORDINE,CLIENTE:CLIENTE,DATA:DATA) REPARTO(REPARTO,MAGAZZINO:MAGAZZINO) MAGAZZINO(MAGAZZINO,CITTA:CITTA) CLIENTE(CLIENTE,CITTA:CITTA) SPEDIZIONE(NRIGA,ORDINE:ORDINE, PRODOTTO, REPARTO:REPARTO DATASPEDIZIONE:DATA, COSTO) AK : { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE } (0,N) DATA SPEDIZIONE DATA (0,N) Viene richiesto di: A) Progettazione concettuale : Progettazione dello schema di fatto SPEDIZIONE con dimensioni {PRODOTTO,MAGAZZINO,CLIENTE,DATASPED} e misure {COSTO,NUMERO}, dove COSTO: è il costo medio di DETTAGLIO.COSTO NUMERO: è il numero complessivo di spedizioni NUMERO_ORDINI: è il numero complessivo di ordini B) Progettazione logica : Progettazione dello STAR SCHEMA e SNOWFLAKE SCHEMA C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP Riportare il reticolo di roll-up del pattern {MAGAZZINO,CLIENTE} supponendo una convergenza su REGIONE; realizzare quindi il pattern in SQL-OLAP con riferimento allo SnowFlake Schema. 4

5 Esempio di istanza del DBO e corrispondente istanza del fatto (eventi primari) Eventi Primari del Fatto SPEDIZIONE con dimensioni PRODOTTO, MAGAZZINO, CLIENTE, DATASPED Riportiamo anche due PATTERN con WITH CUBE, solo allo scopo di illustrare il significato delle misure Pattern {MAGAZZINO_CITTA, CLIENTE_CITTA} Pattern {MAGAZZINO_REGIONE, CLIENTE_REGIONE} 5

6 1.1.1 Soluzione Progettazione Concettuale Nella progettazione concettuale occorre riportare uno schema di fatto con tutte le dimensioni richieste e, per ciascuna dimensione, con tutta la gerarchia derivante dallo schema del DBO. REGIONE CITTA MAGAZZINO STATO CLIENTE SPEDIZIONE NUMERO (C) COSTO (AVG) NUMERO_ORDINI PRODOTTO DATASPED ANNO MESE Fatto: SPEDIZIONE(NRIGA,ORDINE,PRODOTTO,REPARTO, DATASPEDIZIONE,COSTO) AK : { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE } Dimensioni: {PRODOTTO,MAGAZZINO,CLIENTE,DATASPED} Granularità: Temporale Dipendenze funzionale tra le dimensioni: Nessuna Misure normali NUMERO= COUNT(*), additiva NUMERO= NUMERO_ORDINI = count(distinct ORDINE), additiva rispetto a CLIENTE, in quanto ORDINE à CLIENTE Quindi NUMERO_ORDINI è aggregabile solo rispetto a CLIENTE, pertanto l insieme delle dimensioni rispetto alle quali non è aggregabile è NA: {PRODOTTO,MAGAZZINO,DATASPED} Misure calcolate COSTO = COSTO_SUM/COSTO_COUNT dove COSTO_SUM = SUM(COSTO), additiva COSTO_COUNT = COUNT(COSTO), additiva Fact Table FACT_TABLE(PRODOTTO,MAGAZZINO,CLIENTE,DATASPED, NUMERO,COSTO_SUM,COSTO_COUNT, NUMERO_ORDINI) In questa fase viene anche indicata una Fact Table con struttura semplificata (senza riferimenti alle Dimension Table) per riassumere in pratica quali sono le dimensioni del fatto e le misure che si devono considerare. Riassumere quali sono tutte le misure è utile anche per controllare se tra tutte queste misure ce ne sono alcune equivalenti. Ad esempio, nel caso in esame sono state introdotte e riportate nella Fact Table due misure NUMERO= COUNT(*), additiva COSTO_COUNT = COUNT(COSTO), additiva Sono queste due misure equivalenti? Se la risposta è positiva, nella Fact Table verrà inserita una sola misura. 6

7 Progettazione Logica Nella Progettazione logica viene richiesto di delineare sia lo STAR SCHEMA che lo SNOWFLAKE SCHEMA; La Fact Table in questi due tipologie di schemi coincide (mentre quelle che cambiano sono ovviamente le Dimension Table) quindi possiamo riportare la Fact Table una sola volta. La Fact Table ha la seguente struttura FACT_TABLE(PRODOTTO,MAGAZZINO,CLIENTE,DATASPED, NUMERO,COSTO_SUM,COSTO_COUNT, NUMERO_ORDINI) Come detto in precedenza, dobbiamo chiederci se le due misure NUMERO= COUNT(*), additiva COSTO_COUNT = COUNT(COSTO), additiva sono equivalenti, ovvero se il loro valore coincide. Quindi si dovrebbe controllare se COUNT(*) e COUNT(COSTO) restituiscono lo stesso valore: la risposta è negativa se nel DBO il campo COSTO può assumere dei valori NULL, in quanto per definizione un valore NULL viene conteggiato da COUNT(*) ma non viene conteggiato da COUNT(COSTO). Nei nostri esercizi si suppone il caso generale della presenza di NULL pertanto nella Fact Table verranno sempre tenute entrambe le misure. La Fact Table sarà quindi FACT_TABLE(CLIENTE:dtCLIENTE,MAGAZZINO:dtMAGAZZINO,DATASPED:dtDATA,PRODOTTO, NUMERO,COSTO_SUM,COSTO_COUNT, NUMERO_ORDINI) Si noti che la dimensione PRODOTTO è degenere, quindi non viene inserita la relativa Dimension Table. Star Schema dtdata(data,mese,anno) dtcliente(cliente,citta,regione,stato) dtmagazzino(magazzino,citta,regione,stato) SnowFlake Schema dtdata(data,mese:dtmese) dtmese(mese,anno) dtcliente(cliente,citta:dtcitta) dtmagazzino(magazzino,citta:dtcitta) dtcitta(citta,regione:dtregione) dtregione(regione,stato) 7

8 Alimentazione La query di alimentazione della fact table è costituita come segue: FROM: oltre alla tabella SPEDIZIONE, si deve considerare la tabella REPARTO (che contiene MAGAZZINO) e la tabella ORDINE (che contiene CLIENTE). GROUP BY: banale, contiene le dimensioni del fatto SELECT: oltre alle dimensioni del fatto si riporta il calcolo delle misure sulla base di quanto specificato nel glossario CREATE VIEW FACT_TABLE AS SELECT SPEDIZIONE.PRODOTTO, REPARTO.MAGAZZINO, ORDINE.CLIENTE, SPEDIZIONE.DATASPEDIZIONE AS DATASPED, COSTO_SUM =SUM(COSTO), COSTO_COUNT =COUNT(COSTO), NUMERO =COUNT(*) NUMERO_ORDINI =COUNT(DISTINCT ORDINE.ORDINE) FROM SPEDIZIONE NATURAL JOIN REPARTO NATURAL JOIN ORDINE GROUP BY SPEDIZIONE.PRODOTTO, SPEDIZIONE.DATASPEDIZIONE, ORDINE.CLIENTE, REPARTO.MAGAZZINO Per provare la query, dovendola eseguire su un DBMS che non supporta il NATURAL JOIN: FROM SPEDIZIONE JOIN REPARTO ON REPARTO.REPARTO = SPEDIZIONE.REPARTO JOIN ORDINE ON ORDINE.ORDINE = SPEDIZIONE.ORDINE 8

9 SQL-OLAP Riportare il reticolo di roll-up del pattern {MAGAZZINO,CLIENTE} supponendo una convergenza su REGIONE; realizzare quindi il pattern in SQL-OLAP con riferimento allo SnowFlake Schema. Indicando con A=Cliente B=Cliente_Citta C=Magazzino D =Magazzino_CITTA si ricade in un reticolo classico: D altra parte per la convergenza su REGIONE, nel reticolo ci sarà il pattern {REGIONE} ed il pattern {STATO}. Il reticolo di roll-up complessivo è quindi il seguente: {A,C} {B,C} {A,D} {C} {B,D} {A} {D} {B} {Regione} {Stato} {} Realizzare questo reticolo di roll-up in SQL-OLAP significa raggruppare WITH CUBE rispetto a tutti gli attributi dimensionali del reticolo e quindi calcolare tutte le misure; per la misura NUMERO_ORDINI, nessun pattern di tale reticolo contiene il suo insieme NA: {PRODOTTO,MAGAZZINO,DATASPED} quindi per nessun pattern NUMERO_ORDINI è calcolabile e pertanto tale misura viene omessa dalla query. 9

10 SELECT FROM GROUP BY C.CLIENTE, C.CITTA AS CLIENTE_CITTA, F.MAGAZZINO, M.CITTA AS MAGAZZINO_CITTA, R.REGIONE, R.STATO, COSTO = SUM(COSTO_SUM)/SUM(COSTO_COUNT), NUMERO = SUM(NUMERO) FACT_TABLE F JOIN dtmagazzino M ON F.MAGAZZINO = M.MAGAZZINO JOIN dtcliente C ON F.CLIENTE = C.CLIENTE JOIN dtcitta CM ON M.CITTA = CM.CITTA JOIN dtregione R ON CM.REGIONE = R.REGIONE C.CLIENTE, C.CITTA, F.MAGAZZINO, M.CITTA, R.REGIONE, R.STATO WITH CUBE Per la convergenza su REGIONE si può usare una sola volta la dimension table che contiene il riferimento (la foreign key) alla REGIONE, cioè la dimension table dtcitta: tale dimension table può essere legata indifferentemente a dtmagazzino (come nella query) oppure a dtcliente. Nello SnowFlake Schema si possono avere dimension table che hanno foreign key con lo stesso nome (es. dtcliente e dtmagazzino): è più semplice esplicitare la condizione di join che usare il natural join. Aggiungiamo quindi alla precedente query SQL-OLAP la clausola HAVING per eliminare le righe ridondanti dovute alle FD tra gli attributi di raggruppamento. Ricordiamo che per ogni FD : A à B, occorre inserire la condizione HAVING NOT (GROUPING(B)=1 AND GROUPING(A)=0) e queste condizioni devono essere poste in OR nella clausola HAVING : HAVING NOT ( GROUPING(C.CITTA)=1 AND GROUPING(C.CLIENTE)=0 OR GROUPING(M.CITTA)=1 AND GROUPING(F.MAGAZZINO)=0 OR GROUPING(R.STATO)=1 AND GROUPING(R.REGIONE)=0 ) Variante Si cambiano le dimensioni in Dimensioni: {PRODOTTO,MAGAZZINO,CLIENTE,MESE_ORDINE} In questo modo si hanno le seguenti FD ORDINE à CLIENTE ORDINE à MESE_ORDINE Quindi ora NUMERO_ORDINI è aggregabile sia rispetto a CLIENTE che MESE_ORDINE, pertanto NA: {PRODOTTO,MAGAZZINO } Per il reticolo di roll-up del pattern {MAGAZZINO,CLIENTE} non cambia niente: NUMERO_ORDINI continua ad essere non calcolabile per nessun pattern di tale reticolo Riportare e realizzare in SQL-OLAP il reticolo di roll-up del pattern { MAGAZZINO, PRODOTTO, DATASPED, CLIENTE_CITTA } Completare questo esercizio. 10

11 Codice SQL Creazione del DBO (verificare, può non essere completamente aggiornato rispetto all esempio) CREATE TABLE ORDINE(ORDINE INT,CLIENTE INT, DATA INT); CREATE TABLE REPARTO(REPARTO INT,MAGAZZINO INT); CREATE TABLE MAGAZZINO(MAGAZZINO INT,CITTA INT); CREATE TABLE CLIENTE( CLIENTE INT,CITTA INT); CREATE TABLE CITTA(CITTA INT,REGIONE INT,STATO INT); CREATE TABLE DATA( DATA INT, MESE INT, ANNO INT); CREATE TABLE SPEDIZIONE(NRIGA INT,ORDINE INT,PRODOTTO INT,REPARTO INT,DATASPEDIZIONE INT,COSTO FLOAT); INSERT CITTA ( CITTA,REGIONE,STATO ) SELECT 10,10,10 INSERT CITTA ( CITTA,REGIONE,STATO ) SELECT 20,20,10 INSERT CITTA ( CITTA,REGIONE,STATO ) SELECT 30,20,10 INSERT MAGAZZINO ( MAGAZZINO,CITTA ) SELECT 10,10 INSERT MAGAZZINO ( MAGAZZINO,CITTA ) SELECT 20,30 INSERT CLIENTE ( CLIENTE,CITTA ) SELECT 10,10 INSERT CLIENTE ( CLIENTE,CITTA ) SELECT 20,20 INSERT REPARTO ( REPARTO,MAGAZZINO ) SELECT 10,10 INSERT REPARTO ( REPARTO,MAGAZZINO ) SELECT 20,20 INSERT REPARTO ( REPARTO,MAGAZZINO ) SELECT 30,20 INSERT ORDINE ( ORDINE,CLIENTE,DATA ) SELECT 1,10,30 INSERT ORDINE ( ORDINE,CLIENTE,DATA ) SELECT 2,20,30 INSERT ORDINE ( ORDINE,CLIENTE,DATA ) SELECT 3,20,30 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 1,1,1000,10,10,10 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 2,1,1000,10,10,21 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 3,1,1000,10,10,11 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 4,1,3000,10,10,11 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 1,2,3000,20,30,11 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 2,2,3000,30,30,11 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 3,2,1000,20,10,10 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 4,2,1000,30,10,11 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 5,2,1000,20,10,11 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 1,3,3000,20,10,11 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 2,3,3000,30,10,21 INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 3,3,3000,20,30,11 INSERT DATA ( DATA,MESE,ANNO ) SELECT 10,10,10 INSERT DATA ( DATA,MESE,ANNO ) SELECT 20,20,10 INSERT DATA ( DATA,MESE,ANNO ) SELECT 30,20,10 SnowFlake Schema CREATE VIEW DTDATA AS SELECT DATA,MESE FROM DATA CREATE VIEW DTMESE AS SELECT DISTINCT MESE,ANNO FROM DATA CREATE VIEW DTCLIENTE AS SELECT CLIENTE,CITTA FROM CLIENTE CREATE VIEW DTMAGAZZINO AS SELECT MAGAZZINO,CITTA FROM MAGAZZINO CREATE VIEW DTCITTA AS SELECT CITTA,REGIONE FROM CITTA CREATE VIEW DTREGIONE AS SELECT DISTINCT REGIONE,STATO FROM CITTA StarSchema (si riporta solo dtordine che è quella più significativa) CREATE VIEW dtordine AS SELECT ORDINE, CLIENTE.CLIENTE,CITTA.STATO, CITTA.REGIONE, CITTA.CITTA, DATA.DATA, DATA.MESE, DATA.ANNO FROM ORDINE JOIN DATA ON DATA.DATA = ORDINE.DATA JOIN CLIENTE ON ORDINE.CLIENTE = CLIENTE.CLIENTE JOIN CITTA ON CITTA.CITTA = CLIENTE.CITTA 11

12 1.2 Esercizio: Spedizione - variante Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale (nello schema relazionale ci possono essere vincoli di integrità aggiuntivi): MAGAZZINO IN REGIONE (0,N) CITTA STATO CITTA(CITTA,REGIONE,STATO) DF: REGIONEà STATO (1,N) IN REPARTO (1,N) DA COSTO SPEDIZIONE DETTAGLIO NRIGA MAGAZZINO REPARTO PRODOTTO DATA MESE ANNO (1,N) CITTA CLIENTE ORDINE DATA ORDINE (0,N) INDIRIZZO CLIENTE (1,N) DEL ORDINE DATA(DATA,MESE,ANNO) DF: MESE à ANNO ORDINE(ORDINE,CLIENTE:CLIENTE,DATA:DATA) REPARTO(REPARTO,MAGAZZINO:MAGAZZINO) MAGAZZINO(MAGAZZINO,CITTA:CITTA) CLIENTE(CLIENTE,CITTA:CITTA) SPEDIZIONE(NRIGA,ORDINE:ORDINE, PRODOTTO, REPARTO:REPARTO DATASPEDIZIONE:DATA, COSTO) AK : { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE } (0,N) DATA SPEDIZIONE DATA (0,N) Viene richiesto di: A) Progettazione concettuale : Progettazione dello schema di fatto SPEDIZIONE con dimensioni {PRODOTTO,MAGAZZINO,ORDINE,DATASPED} e misure {COSTO,NUMERO}, dove COSTO: è il costo medio di DETTAGLIO.COSTO NUMERO: è il numero complessivo di spedizioni Eventi Primari del Fatto SPEDIZIONE con dimensioni PRODOTTO, ORDINE, CLIENTE, DATASPED 12

13 1.2.1 Soluzione Progettazione Concettuale Rispetto all esempio precedente, si usa come dimensione ORDINE al posto di CLIENTE, pertanto il nuovo fatto è ad un maggiore livello di dettaglio Lo schema di fatto è simile a quello precedente: l aggiunta dell attributo dimensionale ORDINE fa si che DATA sia ora un attributo dimensionale in comune tra la dimensione ORDINE (infatti un ORDINE ha una DATA) e la dimensione DATASPED. Si noti che per questo attributo dimensionale in comune si utilizza il termine più generale DATA e non DATA_SPED (altrimenti verrebbe indicato che un ORDINE ha una DATA_SPED, cosa non vera). Però DATA_SPED deve restare come nome della dimensione, pertanto si mette tale nome sul arco (come avveniva ad esempio nel caso del Fatto Chiamata discusso sulle dispense). Nel seguito verrà discussa la convergenza/condivisione su DATA: il simbolo X che contraddistingue ANNO indica che c è una convergenza su ANNO, ovvero l anno dell ordine coincide con quello della spedizione. SPEDIZIONE NUMERO MAGAZZINO ORDINE CITTA X REGIONE STATO PRODOTTO (C) COSTO (AVG) DATA SPED DATA CLIENTE MESE ANNO X Fatto: SPEDIZIONE(NRIGA,ORDINE,PRODOTTO,REPARTO, DATASPEDIZIONE,COSTO) AK : { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE } Dimensioni: {PRODOTTO,MAGAZZINO,ORDINE,DATASPED} Granularità: Temporale Dipendenze funzionale tra le dimensioni: Nessuna Misure normali NUMERO= COUNT(*), additiva Misure calcolate COSTOMEDIO = COSTO_SUM/COSTO_COUNT dove Fact Table COSTO_SUM = SUM(COSTO), additiva COSTO_COUNT = COUNT(COSTO), additiva FACT_TABLE(PRODOTTO,MAGAZZINO,ORDINE,DATASPED, NUMERO,COSTO_SUM,COSTO_COUNT) 13

14 1.2.2 Spedizione: Seconda Variante (schema transazionale) Fatto SPEDIZIONE con dimensioni {PRODOTTO,REPARTO,ORDINE,DATASPED} Quindi si usa come dimensione REPARTO al posto di MAGAZZINO, pertanto come nella precedente variante - il nuovo fatto è ad un maggiore livello di dettaglio, cioè il nuovo fatto ha una granularità più fine. In termini di dipendenze funzionali abbiamo che La caratteristica fondamentale di questo caso è che le dimensioni coincidono (e quindi contengono) una chiave del fatto, ovvero le dimensioni coincidono con la chiave alternativa AK : { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE } Quindi il nuovo fatto SPEDIZIONE è transazionale; gli eventi primari del nuovo fatto SPEDIZIONE saranno in numero pari al numero di istanze (la cardinalità) della relazione SPEDIZIONE del DBO: Istanza di SPEDIZIONE Eventi Primari del Fatto SPEDIZIONE Nel seguito viene svolto (interamente) questo nuovo caso, mettendo in evidenza come per uno schema di fatto transazionale sia differente la query di alimentazione della fact table ed il calcolo delle misure, in particolare quelle aggregate tramite media. 14

15 1.2.3 Soluzione Progettazione Concettuale Lo schema di fatto è simile a quello precedente: l aggiunta dell attributo dimensionale ORDINE fa si che DATA sia ora un attributo dimensionale in comune tra la dimensione ORDINE (infatti un ORDINE ha una DATA) e la dimensione DATASPED. Nel seguito verrà discussa la convergenza/condivisione su DATA. SPEDIZIONE NUMERO REPARTO MAGAZZINO ORDINE CITTA X REGIONE STATO PRODOTTO (C) COSTO (AVG) DATA SPED DATA CLIENTE MESE ANNO X Fatto SPEDIZIONE(NRIGA,ORDINE,PRODOTTO,REPARTO, DATASPEDIZIONE,COSTO) AK : { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE } Dimensioni = {PRODOTTO,REPARTO,ORDINE,DATASPED} Granularità: Transazionale Dipendenze funzionale tra le dimensioni: Nessuna Progettazione Logica Star Schema FACT_TABLE(ORDINE:dtORDINE,REPARTO: dtreparto,datasped:dtdata,prodotto, <verrà completato dopo la discussione sulle misure>) SnowFlake Schema dtdata(data,mese,anno) dtordine(ordine,data,mese,anno,cliente,citta,regione,stato) dtreparto(reparto, MAGAZZINO,CITTA,REGIONE,STATO) dtdata(data,mese:dtmese) dtmese(mese,anno) dtordine(ordine,data:dtdata,cliente:dtcliente) dtcliente(cliente,citta:dtcitta) dtcitta(citta,regione:dtregione) dtregione(regione,stato) dtreparto(reparto,magazzino:dtmagazzino) dtmagazzino(magazzino,citta:dtcitta) 15

16 1.2.4 Soluzioni possibili per la misura NUMERO (conteggio eventi primari) La misura NUMERO nel caso di schema transazionale corrisponde a quanto discusso nel caso di Schemi di fatto vuoti, ovvero NUMERO è una misura che serve per il conteggio degli eventi primari. Come era stato già fatto notare e come evidenzieremo nell esempio, il nome Schemi di fatto vuoto deriva dal fatto che in questo caso una possibile soluzione è quella di non inserire esplicitamente nessuna misura nello schema di fatto per il conteggio degli eventi primari, ovvero non memorizzare nessun valore : questo concetto di non inserire nessuna misura e non memorizzare nessun valore comporta che nella fact table corrispondente non ci sia nessun attributo per questa misura. D altra parte, lo schema di fatto e quindi la fact table possono contenere altre misure (come capita in questo caso per la misura COSTO) Prima Soluzione : misura conteggio per il conteggio degli eventi primari Misure normali (COUNT) à per indicare appunto una misura vuota per il conteggio degli eventi primari Fact Table FACT_TABLE(PRODOTTO,REPARTO,ORDINE,DATASPED) Alimentazione CREATE VIEW FACT_TABLE AS SELECT PRODOTTO, REPARTO,ORDINE, DATASPEDIZIONE AS DATASPED FROM SPEDIZIONE Come esempio di utilizzo di questa misura, calcoliamo il pattern {MAGAZZINO_CITTA,CLIENTE_CITTA} e tutti i suoi sub-pattern nello SNOW-FLAKE schema: SELECT M.CITTA AS MAGAZZINO_CITTA,C.CITTA AS CLIENTE_CITTA, NUMERO = COUNT(*) FROM FACT_TABLE F JOIN dtreparto R ON R.REPARTO = F.REPARTO JOIN dtmagazzino M ON R.MAGAZZINO = M.MAGAZZINO JOIN dtordine O ON F.ORDINE = O.ORDINE JOIN dtcliente C ON O.CLIENTE = C.CLIENTE GROUP BY M.CITTA, C.CITTA WITH CUBE Si può verificare che il risultato è corretto, confrontandolo con quanto ottenuto begli schemi di fatto precedenti. Seconda Soluzione : misura booleana per il conteggio degli eventi primari Un altro modo di rappresentare il verificarsi di un evento è attraverso una misura ti tipo booleana, additiva: normalmente quando si tratta di effettuare un semplice conteggio degli eventi primari 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). Vedremo comunque in un prossimo esercizio che a volte è necessario contare solo determinati eventi (ad esempio, nel caso dell esercizio sul fatto BIGLIETTO, si vogliono rappresentare tutti i biglietti ma si vogliono contare solo quelli che hanno fatto anche il check-in dei bagagli); in questo caso la misura di conteggio booleana assume entrambi i valori 1 e 0. Misure normali NUMERO = 1, additiva Fact Table FACT_TABLE (PRODOTTO,REPARTO,ORDINE,DATASPED, NUMERO) 16

17 NUMERO è una misura normale : tale misura ha un valore per ogni evento primario in questo caso costante pari a 1 e un operatore di aggregazione per determinarne il valore per gli eventi secondari Se lo riportassi nella fact table, poi per le aggregazioni dovrei utilizzare ovviamente NUMERO = SUM(NUMERO) Ma essendo NUMERO=1, questo equivale a fare NUMERO = SUM(1) Pertanto non è necessario riportare NUMERO come attributo della fact table. Come esempio di utilizzo di questa misura, calcoliamo il pattern {MAGAZZINO_CITTA,CLIENTE_CITTA} e tutti i suoi sub-pattern nello SNOW-FLAKE schema: SELECT M.CITTA AS MAGAZZINO_CITTA,C.CITTA AS CLIENTE_CITTA, NUMERO = SUM(1) FROM FACT_TABLE F JOIN dtreparto R ON R.REPARTO = F.REPARTO JOIN dtmagazzino M ON R.MAGAZZINO = M.MAGAZZINO JOIN dtordine O ON F.ORDINE = O.ORDINE JOIN dtcliente C ON O.CLIENTE = C.CLIENTE GROUP BY M.CITTA, C.CITTA WITH CUBE Si può verificare che il risultato è corretto, confrontandolo con quanto ottenuto negli schemi di fatto precedenti. In definitiva, abbiamo due soluzioni simili, in entrambi i casi non si riporta niente nella fact table per la misura numero (è questo giustifica il termine Schema di Fatto vuoto utilizzato in questi casi). Quello che cambia è l operatore di aggregazione, nel senso che possiamo usare due operazioni equivalenti oppure NUMERO = COUNT(*) NUMERO = SUM(1) 17

18 1.2.5 Soluzioni possibili per la misura COSTO (misura con AVG in schema transazionale) In uno schema transazionale, per una misura quale COSTO che deve essere aggregata tramite media ci sono due soluzioni possibili 1) misura normale con operatore di aggregazione AVG 2) misura calcolata COSTO = COSTO_SUM/COSTO_COUNT dove COSTO_SUM = COSTO, additiva COSTO_COUNT = COUNT(COSTO), additiva La soluzione seguita normalmente è la seconda; nel seguito comunque presentiamo entrambe le soluzioni, verificando che sono equivalenti. Prima Soluzione : misura normale con operatore di aggregazione AVG Fact Table : FACT_TABLE(PRODOTTO,REPARTO,ORDINE,DATASPED,COSTO) Alimentazione CREATE VIEW FACT_TABLE AS SELECT PRODOTTO, REPARTO,ORDINE, DATASPEDIZIONE, COSTO AS DATASPED FROM SPEDIZIONE Come esempio di utilizzo di questa misura, calcoliamo il pattern {MAGAZZINO_CITTA,CLIENTE_CITTA} e tutti i suoi sub-pattern nello SNOW-FLAKE schema: SELECT M.CITTA AS MAGAZZINO_CITTA, C.CITTA AS CLIENTE_CITTA, COSTO = AVG(COSTO), FROM <come prima> Si può verificare che il risultato è corretto, confrontandolo con quanto ottenuto negli schemi di fatto precedenti. Seconda Soluzione : misura calcolata COSTO = COSTO_SUM/COSTO_COUNT In questo caso abbiamo due misure normali COSTO_SUM = COSTO, additiva COSTO_COUNT = COUNT(COSTO), additiva Che verranno poi usate per il calcolo della misura calcolata COSTO. In questo caso, essendo lo schema transazionale, gli eventi primari verranno calcolati senza raggruppare e quindi non ha ovviamente senso definire una misura attraverso un operatore di aggregazione: in COSTO_COUNT = COUNT(COSTO) è stato indicato COUNT corsivato proprio per indicare che concettualmente devo fare un conteggio ma questo conteggio è unitario, cioè COSTO_COUNT=1. Di conseguenza questa misura COSTO_COUNT coincide con la misura NUMERO e pertanto può essere definita e calcolata come già discusso in precedenza: COUNT(*) oppure SUM(1). Fact Table FACT_TABLE(PRODOTTO,REPARTO,ORDINE,DATASPED,COSTO_SUM) Alimentazione CREATE VIEW FACT_TABLE AS SELECT PRODOTTO, REPARTO,ORDINE, DATASPEDIZIONE AS DATASPED, COSTO FROM SPEDIZIONE Come esempio si calcola il pattern {MAGAZZINO_CITTA,CLIENTE_CITTA} e tutti i suoi sub-pattern nello SNOW-FLAKE schema utilizzando per COSTO_COUNT le due possibilità SELECT M.CITTA AS MAGAZZINO_CITTA, C.CITTA AS CLIENTE_CITTA, COSTO = SUM(COSTO_SUM)/ COUNT(*) oppure COSTO = SUM(COSTO_SUM)/ SUM(1) FROM <come prima> 18

19 Si può verificare che il risultato è corretto, confrontandolo con quanto ottenuto negli schemi di fatto precedenti. Le due soluzioni per il calcolo di COSTO come valore medio coincidono nell ipotesi che nello schema operazionale il valore di COSTO non sia NULL; infatti un valore NULL di COSTO non viene considerato, cioè non partecipa al calcolo, nella prima soluzione in quanto, per definizione la funzione AVG viene calcolata sui valori non nulli. Nella seconda soluzione invece il valore NULL di COSTO viene considerato in quanto non viene sommato (per definizione anche la funzione SUM sui valori non nulli) ma viene conteggiato, sia attraverso COUNT(*), in quanto per definizione COUNT(*) conta anche i valori nulli, sia attraverso SUM(1). Modifichiamo la tabella SPEDIZIONE con alcuni NULL su COSTO, quindi verifichiamo la differenza per un semplice pattern {ORDINE} DBO: tabella SPEDIZIONE COSTO calcolato come COSTO=AVG(COSTO) COSTO calcolato come COSTO=SUM(COSTO_SUM)/SUM(1) Nel caso di COSTO come misura calcolata, per considerare che COSTO può essere nullo e quindi non deve partecipare alla media, non possiamo usare più come COSTO_COUNT l espressione SUM(1) (stesso discorso per l espressione COUNT(*)) ma dobbiamo conteggiare in maniera diversa i valori NULL, pertanto si inserisce una misura normale COSTO_COUNT che sarà 1 se COSTO è non NULL, 0 altrimenti. Fact Table Alimentazione FACT_TABLE(PRODOTTO,REPARTO,ORDINE,DATASPED,COSTO_SUM,COSTO_COUNT) CREATE VIEW FACT_TABLE AS SELECT PRODOTTO, REPARTO,ORDINE, DATASPEDIZIONE AS DATASPED, COSTO_SUM=COSTO, COSTO_COUNT= CASE WHEN COSTO IS NULL THEN 0 ELSE 1 END FROM SPEDIZIONE Verifichiamo nell esempio della pagina precedente: DBO: tabella SPEDIZIONE COSTO calcolato come COSTO=AVG(COSTO) COSTO calcolato come COSTO=SUM(COSTO_SUM)/ SUM(COSTO_COUNT) 19

20 1.3 Esercizio: Dettaglio Ordine Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale (nello schema relazionale ci possono essere vincoli di integrità aggiuntivi): AZIENDA IN REGIONE (0,N) STATO CITTA CITTA(CITTA,REGIONE,STATO) DF: REGIONEà STATO AZIENDA (1,N) DI (0,N) CITTA INDIRIZZO DATA(DATA,MESE,ANNO) DF: MESE à ANNO ORDINE(ORDINE,CLIENTE:CLIENTE,DATA:DATA) PREFER PRODOTTO(PRODOTTO,AZIENDA:AZIENDA) PRODOTTO (0,N) CLIENTE AZIENDA(AZIENDA,CITTA:CITTA) (0,N) PRODOTTO DA COSTO DETTAGLIO (1,N) CLIENTE DEL (1,N) ORDINE CLIENTE(CLIENTE,CITTA:CITTA, PREFER:PRODOTTO) DETTAGLIO(NRIGA,ORDINE:ORDINE, PRODOTTO:PRODOTTO, DATASPEDIZIONE:DATA, COSTO) NRIGA DATA MESE ANNO ORDINE DATA ORDINE (0,N) DATA SPEDIZIONE Viene richiesto di DATA (0,N) A) Progettazione concettuale : Progettazione dello schema di fatto DETTAGLIO con dimensioni {PRODOTTO,ORDINE,DATASPED} e misure {COSTO,NUMERO} dove COSTO: è il costo medio NUMERO: è il numero complessivo di spedizioni B) Progettazione logica : Progettazione dello STAR SCHEMA e SNOWFLAKE SCHEMA C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP Lo schema coincide in pratica con quello precedente, l unica aggiunta è l associazione PREFER (un CLIENTE ha un PRODOTTO preferito): una CITTA è raggiungibile anche attraverso il percorso CLIENTE_PRODOTTO. CLIENTE_PRODOTTO_CITTA, CLIENTE_CITTA, PRODOTTO_CITTA CLIENTE_PRODOTTO_REGIONE, CLIENTE_REGIONE, PRODOTTO_REGIONE 20

21 Esempio di istanza del DBO e corrispondente istanza del fatto (eventi primari) Eventi Primari del Fatto SPEDIZIONE con dimensioni PRODOTTO, ORDINE, DATASPED 21

22 1.3.1 Soluzione Progettazione Concettuale Lo schema di fatto è simile a quello del fatto Spedizione seconda variante: l unica aggiunta è l associazione PREFER (un CLIENTE ha un PRODOTTO preferito) che collega CLIENTE a PRODOTTO. Questo comporta che l attributo dimensionale PRODOTTO sia ora comune alle due dimensioni ORDINE e PRODOTTO. In questo caso - a differenza di quanto discusso con DATA e DATA_SPED - non essendoci ambiguità possiamo usare lo stesso nome PRODOTTO sia per la dimensione che per l attributo comune DETTAGLIO NUMERO PRODOTTO PREFER AZIENDA CITTA X REGIONE STATO (C) COSTO (AVG) ORDINE DATA SPED DATA CLIENTE MESE ANNO X Con la nuova associazione PREFER, CITTA è raggiungibile anche con il percorso CLIENTE_PRODOTTO. Fatto: DETTAGLIO(NRIGA,ORDINE, PRODOTTO, DATASPEDIZIONE,COSTO) Dimensioni: {PRODOTTO,ORDINE,DATASPED} Granularità: Temporale Dipendenze funzionale tra le dimensioni: Nessuna Misure normali NUMERO= COUNT(*), additiva Misure calcolate COSTOMEDIO = COSTO_SUM/COSTO_COUNT dove COSTO_SUM = SUM(COSTO), additiva COSTO_COUNT = COUNT(COSTO), additiva Fact Table FACT_TABLE(PRODOTTO,MAGAZZINO,CLIENTE,DATASPED, NUMERO,COSTO_SUM,COSTO_COUNT) Progettazione Logica FACT_TABLE(ORDINE:dtORDINE,PRODOTTO:dtPRODOTTO,DATASPED:dtDATA, NUMERO, COSTO_SUM,COSTO_COUNT) Star Schema dtdata(data,mese,anno) dtordine(ordine,data,mese,anno, CLIENTE, CLIENTE_CITTA, CLIENTE_REGIONE, CLIENTE_STATO, PROD_P_CLIENTE, PROD_P_CLIENTE_AZIENDA, PROD_P_CLIENTE_AZIENDA_CITTA PROD_P_CLIENTE_AZIENDA_REGIONE, PROD_P_CLIENTE_AZIENDA_STATO ) dtprodotto(prodotto,azienda,azienda_citta,azienda_regione,azienda_stato) 22

23 SnowFlake Schema dtdata(data,mese:dtmese) dtmese(mese,anno) dtordine(ordine,cliente:dtcliente,data:dtdata) dtprodotto(prodotto,azienda:dtazienda) dtazienda(azienda,citta:citta) dtcitta(citta,regione:dtregione) dtregione(regione,stato) dtcliente(cliente, CITTA:dtCITTA,PREFER:dtPRODOTTO) Alimentazione CREATE VIEW FACT_TABLE AS SELECT PRODOTTO, ORDINE, DATASPED COSTO_SUM =SUM(COSTO), COSTO_COUNT =COUNT(COSTO), NUMERO =COUNT(*) FROM DETTAGLIO GROUP BY PRODOTTO, ORDINE, DATASPED 23

24 SQL-OLAP Riportare e realizzare in SQL-OLAP il reticolo di roll-up del pattern {CLIENTE} nei seguenti 2 casi 1. Convergenza su CITTA 2. Convergenza su REGIONE Riportiamo la parte di gerarchia relativa a CLIENTE (per chiarezza sono indicati anche le direzioni degli archi) STATO CITTA CLIENTE REGIONE PRODOTTO AZIENDA Convergenza su CITTA Per la convergenza su CITTA c è il pattern {CITTA}, e di conseguenza il pattern {REGIONE} e {STATO}. Il reticolo di roll-up è riportato in figura (per semplicità gli insiemi di attributi dimensionali sono indicati senza {}) CLIENTE PRODOTTO AZIENDA SI NOTI CHE MANCA CLIENTE à CITTA CITTA REGIONE STATO { } Nello star-schema, per ottenere il reticolo di roll-up di {CLIENTE } è sufficiente il join con dtordine; evidenziamo nella dtordine gli attributi necessari; dtordine(ordine,data,mese,anno, CLIENTE, CLIENTE_CITTA, CLIENTE_REGIONE, CLIENTE_STATO, PROD_P_CLIENTE, PROD_P_CLIENTE_AZIENDA, PROD_P_CLIENTE_AZIENDA_CITTA PROD_P_CLIENTE_AZIENDA_REGIONE, PROD_P_CLIENTE_AZIENDA_STATO ) Per quanto discusso prima, in questo caso abbiamo che CLIENTE à PROD_P_CLIENTE à PROD_P_CLIENTE_AZIENDA à CLIENTE_CITTA à CLIENTE_REGIONE à CLIENTE_STATO Quindi ora invece di WITH CUBE con HAVING per ogni FD, si può usare WITH ROLLUP: SELECT CLIENTE, PROD_P_CLIENTE,PROD_P_CLIENTE_AZIENDA, CLIENTE_CITTA, CLIENTE_REGIONE, CLIENTE_STATO COSTO = SUM(COSTO_SUM)/SUM(COSTO_COUNT), NUMERO =SUM(NUMERO) FROM FACT_TABLE F JOIN dtordine O ON F.ORDINE = O.ORDINE GROUP BY CLIENTE, PROD_P_CLIENTE,PROD_P_CLIENTE_AZIENDA, CLIENTE_CITTA, CLIENTE_REGIONE, CLIENTE_STATO WITH ROLLUP 24

25 Convergenza su REGIONE Con la condivisione su città (due città: CLIENTE_CITTA e AZIENDA_CITTA) e la convergenza su REGIONE la gerarchia su CLIENTE risulta essere la seguente CLIENTE PRODOTTO,CLIENTE_CITTA CLIENTE CLIENTE_CITTA REGIONE PRODOTTO AZIENDA AZIENDA_CITTA STATO AZIENDA,CLIENTE_CITTA AZIENDA_CITTA,CLIENTE_CITTA AZIENDA_CITTA CLIENTE_CITTA REGIONE Il reticolo di roll-up contiene quindi {REGIONE} e {STATO} STATO { } Anche ora, nello star-schema, per ottenere il reticolo di roll-up di {CLIENTE } è sufficiente il join con dtordine; evidenziamo nella dtordine gli attributi necessari; dtordine(ordine,data,mese,anno, CLIENTE, CLIENTE_CITTA, CLIENTE_REGIONE, CLIENTE_STATO, PROD_P_CLIENTE, PROD_P_CLIENTE_AZIENDA, PROD_P_CLIENTE_AZIENDA_CITTA PROD_P_CLIENTE_AZIENDA_REGIONE, PROD_P_CLIENTE_AZIENDA_STATO ) In questo caso è necessario utilizzare WITH CUBE con HAVING per ogni FD: SELECT CLIENTE, PROD_P_CLIENTE,PROD_P_CLIENTE_AZIENDA, CLIENTE_CITTA, CLIENTE_REGIONE, CLIENTE_STATO, PROD_P_CLIENTE_AZIENDA_CITTA COSTO = SUM(COSTO_SUM)/SUM(COSTO_COUNT), NUMERO =SUM(NUMERO) FROM FACT_TABLE F JOIN dtordine O ON F.ORDINE = O.ORDINE GROUP BY CLIENTE, PROD_P_CLIENTE,PROD_P_CLIENTE_AZIENDA, CLIENTE_CITTA, CLIENTE_REGIONE, CLIENTE_STATO WITH CUBE HAVING NOT ( GROUPING(CLIENTE)=0 AND GROUPING(PROD_P_CLIENTE)=1 OR GROUPING(PROD_P_CLIENTE)=0 AND GROUPING(PROD_P_CLIENTE_AZIENDA)=1 OR ) 25

26 Codice SQL Creazione del DBO CREATE TABLE ORDINE ( ORDINE INT, CLIENTE INT, DATA INT); CREATE TABLE PRODOTTO ( PRODOTTO INT, AZIENDA INT); CREATE TABLE AZIENDA ( AZIENDA INT, CITTA INT); CREATE TABLE CLIENTE ( CLIENTE INT, CITTA INT, PREFER INT); CREATE TABLE CITTA ( CITTA INT, REGIONE INT, STATO INT); CREATE TABLE DATA ( DATA INT, MESE INT, ANNO INT); CREATE TABLE DETTAGLIO ( NRIGA INT, ORDINE INT, PRODOTTO INT, DATASPED INT, COSTO FLOAT ); INSERT CITTA ( CITTA,REGIONE,STATO ) SELECT 10,10,10 INSERT CITTA ( CITTA,REGIONE,STATO ) SELECT 20,20,10 INSERT CITTA ( CITTA,REGIONE,STATO ) SELECT 30,20,10 INSERT AZIENDA ( AZIENDA,CITTA ) SELECT 10,10 INSERT AZIENDA ( AZIENDA,CITTA ) SELECT 20,30 INSERT CLIENTE ( CLIENTE,CITTA,PREFER ) SELECT 10,10,10 INSERT CLIENTE ( CLIENTE,CITTA,PREFER ) SELECT 20,20,30 INSERT CLIENTE ( CLIENTE,CITTA,PREFER ) SELECT 30,20,30 INSERT PRODOTTO ( PRODOTTO,AZIENDA ) SELECT 10,10 INSERT PRODOTTO ( PRODOTTO,AZIENDA ) SELECT 20,20 INSERT PRODOTTO ( PRODOTTO,AZIENDA ) SELECT 30,20 INSERT ORDINE ( ORDINE,CLIENTE,DATA ) SELECT 1,10,30 INSERT ORDINE ( ORDINE,CLIENTE,DATA ) SELECT 2,20,30 INSERT ORDINE ( ORDINE,CLIENTE,DATA ) SELECT 3,20,30 INSERT ORDINE ( ORDINE,CLIENTE,DATA ) SELECT 4,30,30 INSERT DATA ( DATA,MESE,ANNO ) SELECT 10,10,10 INSERT DATA ( DATA,MESE,ANNO ) SELECT 20,20,10 INSERT DATA ( DATA,MESE,ANNO ) SELECT 30,20,10 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 1,4,10,30,22 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 2,4,20,30,22 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 3,4,30,30,22 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 1,1,10,30,16 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 2,1,20,20,15 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 3,1,30,30,13 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 1,2,10,20,13 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 2,2,20,30,13 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 3,2,30,20,12 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 1,3,10,20,11 INSERT DETTAGLIO ( NRIGA,ORDINE,PRODOTTO,DATASPED,COSTO ) SELECT 2,3,30,30,22 Creazione dello StarSchema CREATE VIEW [DTDATA] AS SELECT * FROM DATA CREATE VIEW [DTORDINE] AS SELECT ORDINE.ORDINE, ORDINE.CLIENTE, ORDINE.DATA, DATA.MESE, DATA.ANNO, CLIENTE.CITTA AS CLIENTE_CITTA, CITTA.REGIONE AS CLIENTE_REGIONE, CITTA.STATO AS CLIENTE_STATO, PRODOTTO.PRODOTTO AS PROD_P_CLIENTE, PRODOTTO.AZIENDA AS PROD_P_CLIENTE_AZIENDA, AZIENDA.CITTA AS PROD_P_CLIENTE_AZIENDA_CITTA, CITTA_1.REGIONE AS PROD_P_CLIENTE_AZIENDA_REGIONE, CITTA_1.STATO AS PROD_P_CLIENTE_AZIENDA_STATO FROM AZIENDA JOIN ORDINE INNER JOIN DATA ON ORDINE.DATA = DATA.DATA INNER JOIN CLIENTE ON ORDINE.CLIENTE = CLIENTE.CLIENTE INNER JOIN CITTA ON CLIENTE.CITTA = CITTA.CITTA INNER JOIN PRODOTTO ON CLIENTE.PREFER = PRODOTTO.PRODOTTO ON AZIENDA.AZIENDA = PRODOTTO.AZIENDA INNER JOIN CITTA AS CITTA_1 ON AZIENDA.CITTA = CITTA_1.CITTA CREATE VIEW [DTPRODOTTO] AS SELECT PRODOTTO.PRODOTTO, PRODOTTO.AZIENDA, AZIENDA.CITTA AS AZIENDA_CITTA, CITTA_1.REGIONE AS AZIENDA_REGIONE, CITTA_1.STATO AS AZIENDA_STATO FROM PRODOTTO JOIN AZIENDA ON AZIENDA.AZIENDA = PRODOTTO.AZIENDA JOIN CITTA AS CITTA_1 ON CITTA_1.CITTA = AZIENDA.CITTA 26

27 1.4 Esercizio: Biglietto Consideriamo un DBO con il seguente schema relazionale: Viene richiesto di VOLO(CODVOLO,DATA,RITARDO,COMPAGNIA) BIGLIETTO(POSTO,[CODVOLO,DATA]:VOLO,COSTO ) CHECK-IN([POSTO,CODVOLO,DATA]: BIGLIETTO, NCOLLI ) A) Progettazione concettuale : schema di fatto BIGLIETTO con dimensioni {VOLO,NPOSTO} e misure {COSTO,NBIGLIETTI,NBIGLIETTI_CHECK-IN} dove COSTO: costo medio del biglietto NBIGLIETTI: è valutato con il conteggio dei biglietti NBIBLIETTICHECK-IN: è valutato con il conteggio dei biglietti che hanno anche il check-in B) Progettazione logica : Star schema C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP Riportare e realizzare il reticolo di roll-up del pattern {DATA,NPOSTO,COMPAGNIA } Osservazioni: La caratteristica di questo esercizio è la presenza di due misure di conteggio: NBIGLIETTI: valutato con il conteggio dei biglietti NBIBLIETTICHECK-IN: valutato con il conteggio dei biglietti che hanno anche il check-in In sezione abbiamo visto due soluzioni per tali misure. In questo esercizio le useremo entrambe, e quindi NBIGLIETTI : misura conteggio per il conteggio degli eventi primari NBIBLIETTICHECK-IN : misura booleana per il conteggio degli eventi primari Infatti, si vogliono rappresentare tutti i biglietti (contando il loro numero totale tramite NBIGLIETTI e il costo medio tramite COSTO) e si vogliono contare quelli che hanno fatto anche il check-in: NBIBLIETTICHECK-IN sarà una misura di conteggio booleana che assume il valore 1 (c è stato check-in) ed il valore 0 (no check-in). Un altra caratteristica è nell alimentazione: infatti la dimensione VOLO deriva da una coppia di attributi (DATA e CODVOLO) del DBO. 27

28 Esempio di istanza del DBO e corrispondente istanza del fatto (eventi primari) VOLO BIGLIETTO CHECK-IN Eventi Primari del Fatto BIGLIETTO Con dimensioni {VOLO,NPOSTO } Pattern {NPOSTO,COMPAGNIA} e sub-pattern CREATE TABLE [DBO].[VOLO] ([DATA] [DATETIME],[CODVOLO] [INT],[RITARDO] [INT],[COMPAGNIA] [INT] ) CREATE TABLE [BIGLIETTO] ( [DATA] [DATETIME],[CODVOLO] [INT],[POSTO] [INT],[COSTO] [FLOAT]) CREATE TABLE [CHECK-IN] ([DATA] [DATETIME],[CODVOLO] [INT],[POSTO] [INT],[NCOLLI] [INT]) INSERT VOLO ( DATA,CODVOLO,RITARDO,COMPAGNIA ) SELECT 'DEC :00AM',123,25,100 INSERT VOLO ( DATA,CODVOLO,RITARDO,COMPAGNIA ) SELECT 'DEC ',123,15,100 INSERT VOLO ( DATA,CODVOLO,RITARDO,COMPAGNIA ) SELECT 'DEC ',124,0,200 INSERT VOLO ( DATA,CODVOLO,RITARDO,COMPAGNIA ) SELECT 'DEC ',124,5,200 INSERT BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SELECT 'DEC ',123,1,100 INSERT BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SELECT 'DEC ',123,2,159 INSERT BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SELECT 'DEC ',123,3,200 INSERT BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SELECT 'DEC ',123,1,50 INSERT BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SELECT 'DEC ',123,2,50 INSERT BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SELECT 'DEC ',123,3,150 INSERT BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SELECT 'DEC ',124,1,150 INSERT BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SELECT 'DEC ',124,2,50 INSERT [CHECK-IN] ( DATA,CODVOLO,POSTO,NCOLLI ) SELECT 'DEC ',123,2,2 INSERT [CHECK-IN] ( DATA,CODVOLO,POSTO,NCOLLI ) SELECT 'DEC ',123,3,3 INSERT [CHECK-IN] ( DATA,CODVOLO,POSTO,NCOLLI ) SELECT 'DEC ',123,1,2 INSERT [CHECK-IN] ( DATA,CODVOLO,POSTO,NCOLLI ) SELECT 'DEC ',124,2,4 28

29 1.4.1 Soluzione Progettazione Concettuale Per semplicità, si procede effettuando prima il reverse engineering dello schema relazionale Si inizia da VOLO(CODVOLO,DATA,RITARDO,COMPAGNIA) Che corrisponde ad un entità identificata da DATA+CODVOLO. Quindi BIGLIETTO BIGLIETTO(POSTO,[CODVOLO,DATA]:VOLO,COSTO ) Identificata da entità VOLO + NPOSTO; infine CHECK-IN([POSTO,CODVOLO,DATA]: BIGLIETTO, NCOLLI ) Essendo la foreign key sulla sua primary key: è un subset. NPOSTO DATA CODVOLO BIGLIETTO DEL (1,N) VOLO CHECK-IN COSTO RITARDO COMPAGNIA NCOLLI Lo schema di fatto BIGLIETTO con dimensioni {VOLO,NPOSTO} è molto semplice; si noti che con VOLO si intende l attributo dimensionale derivante da CODVOLO + VOLO (come nel caso di DISTRETTO dell esempio VENDITA). L attributo dimensionale CODVOLO è un figlio di VOLO (da CODVOLO si ricavano informazioni quali partenza, destinazione non considerati nell esercizio) NPOSTO BIGLIETTO (C) COSTO (AVG) NBC NB CODVOLO VOLO NB=NBIGLIETTI NBC=NBIGLIETTI_CHECK-IN Fatto BIGLIETTO(VOLO,NPOSTO,COSTO) DATA COMPAGNIA RITARDO Dimensioni = {VOLO,NPOSTO} Granularità: Transazionale (infatti VOLO è CODVOLO + VOLO, quindi si ottiene CODVOLO, VOLO,DATA) Dipendenze funzionale tra le dimensioni: Nessuna Misure normali NB=1, additiva NBC = IF <BIGLIETTO CON CHECK-IN> THEN 1 ELSE 0, additiva Si noti che a questo punto viene solo indicato, ad alto livello, come calcolare NBC; il calcolo effettivo verrà esplicitato in fase di alimentazione Misure calcolate COSTO= COSTO_SUM/COSTO_COUNT dove COSTO_SUM = SUM(COSTO), additiva COSTO_COUNT = COUNT(COSTO), additiva Fact Table FACT_TABLE(VOLO,NPOSTO,NBC, COSTO_SUM,COSTO_COUNT) Si noti che sono già state fatte due scelte progettuali: 1) per la misura NB: non viene introdotta nella Fact Table, verrà aggregata tramite COUNT(*) 2) per la misura COSTO: lo schema è transazionale, si sono due possibilità per definire COSTO (vedere sezione 1.2.2), viene scelto di considerare COSTO come misura calcolata 29

30 Progettazione Logica FACT_TABLE(NPOSTO,VOLO:dtVOLO, NBC, COSTO_SUM,COSTO_COUNT) Star Schema (lo SnowFlake schema coincide con lo star-schema) dtvolo(volo,data,codvolo,compagnia,ritardo) Alimentazione Lo schema è transazionale, quindi la vista di alimentazione non deve raggruppare. Si deve calcolare NBC = IF <BIGLIETTO CON CHECK-IN> THEN 1 ELSE 0, additiva Per controllare se il BIGLIETTO è anche in CHECK-IN : si effettua un left-join SELECT NBC=CASE WHEN C.[CODVOLO] IS NULL THEN 0 ELSE 1 END FROM BIGLIETTO B LEFT JOIN [CHECK-IN] C ON ( B.[DATA]=C.[DATA] AND B.[CODVOLO]=C.[CODVOLO] AND B.[POSTO] = C.[POSTO]) E importante (anche senza eseguirla effettivamente) sapere che questa query restituisce in output lo stesso numero di tuple di BIGLIETTO: infatti BIGLIETTO è nel lato left del join e BIGLIETTO e CHECK-IN condividono la chiave. Pertanto se nella select si mette BIGLIETTO.*, NBC ottengo la tabella BIGLIETTO con in più la colonna NBC e quindi ho tutto quello che mi serve per calcolare la Fact Table. CREATE VIEW FACT_TABLE AS SELECT B.POSTO AS NPOSTO, VOLO= B.DATA + CODVOLO, NBC=CASE WHEN C.[CODVOLO] IS NULL THEN 0 ELSE 1 END, COSTO_SUM=COSTO, COSTO_COUNT =CASE WHEN COSTO IS NULL THEN 0 ELSE 1 END FROM BIGLIETTO B LEFT JOIN [CHECK-IN] C ON ( B.[DATA]=C.[DATA] AND B.[CODVOLO]=C.[CODVOLO] AND B.[POSTO]=C.[POSTO]) In realtà per effettuare la concatenazione VOLO= B.DATA + CODVOLO occorre convertire entrami in stringhe VOLO=CONVERT(CHAR(20),B.DATA) + ' ' +CONVERT(CHAR(20),B.CODVOLO). Anche se non richiesto dal testo, si riporta l alimentazione della dtvolo: CREATE VIEW dtvolo AS SELECT VOLO=CONVERT(CHAR(20),DATA) + ' ' +CONVERT(CHAR(20),CODVOLO), CODVOLO,DATA,COMPAGNIA, RITARDO FROM VOLO SQL-OLAP: Nel pattern {DATA,NPOSTO,COMPAGNIA } tutti gli attributi sono foglie quindi si ricade in un reticolo classico: SELECT DATA,NPOSTO,COMPAGNIA, COSTO=SUM(COSTO_SUM)/ SUM(COSTO_COUNT), NB=COUNT(*),NBC=SUM(NBC) FROM FACT_TABLE F JOIN dtvolo V ON (F.VOLO = V.VOLO) GROUP BY DATA,NPOSTO,COMPAGNIA WITH CUBE 30

31 1.4.2 Variante Nello schema di fatto precedente (transazionale) si introduce la misura GUADAGNO, definita come SUM(COSTO) Cioè il GUADAGNO è definita a partire dall attributo COSTO, così come la misura COSTO, ma è una misura additiva. Si introduce inoltre una misura additiva NCOLLI. Gli eventi primari sono: Fatto BIGLIETTO(VOLO,POSTO,COSTO) Dimensioni = {VOLO,NPOSTO} Granularità: Transazionale Dipendenze funzionale tra le dimensioni: Nessuna Misure normali NB=COUNT(*), additiva NBC = SUM(IF <BIGLIETTO CON CHECK-IN> THEN 1 ELSE 0), additiva NCOLLI = SUM(IF <BIGLIETTO CON CHECK-IN> THEN NCOLLI ELSE 0), additiva GUADAGNO=COSTO, additiva Misure calcolate COSTO= COSTO_SUM/COSTO_COUNT dove COSTO_SUM = SUM(COSTO), additiva COSTO_COUNT = COUNT(COSTO), additiva Progettazione Logica Naturalmente GUADAGNO viene calcolata a partire da COSTO_SUM, quindi non serve un altro attributo: FACT_TABLE(NPOSTO,VOLO:dtVOLO, NBC, COSTO_SUM,COSTO_COUNT,NCOLLI) Alimentazione: si aggiunge il calcolo della misura normale NCOLLI NCOLLI=ISNULL(NCOLLI,0) SQL-OLAP: si aggiungono le misure QUANDAGNO e NCOLLI NCOLLI=SUM(NCOLLI), GUADAGNO = SUM(COSTO_SUM) 31

32 1.4.3 VARIANTE (dimensione derivante da discretizzazione) Si considera un altra variante in cui la precedente dimensione NPOSTO viene discretizzata nell attributo dimensionale CLASSE in questo modo: se NPOSTO <= 1 allora PRIMA altrimenti SECONDA Schema di fatto con dimensioni {VOLO,CLASSE} e misure {COSTO,NBIGLIETTI,NBIGLIETTI_CHECK-IN,GUADAGNO,NCOLLI}. GUADAGNO è ancora definita come SUM(COSTO) Esempio di istanza del DBO e corrispondente istanza del fatto (eventi primari) Eventi Primari del Fatto BIGLIETTO Lo schema di fatto BIGLIETTO con dimensioni {VOLO,CLASSE} si ottiene dal precedente sostituendo NPOSTO con CLASSE (che costituisce una sua discretizzazione) Fatto BIGLIETTO(VOLO,POSTO,COSTO) Dimensioni = {VOLO,CLASSE} Granularità: Temporale Dipendenze funzionale tra le dimensioni: Nessuna CLASSE BIGLIETTO (C) COSTO (AVG) NBC NB GUADAGNO NCOLLI CODVOLO VOLO COMPAGNIA DATA RITARDO Misure normali NB=COUNT(*), additiva NBC = SUM(IF <BIGLIETTO CON CHECK-IN> THEN 1 ELSE 0), additive NCOLLI = SUM(IF <BIGLIETTO CON CHECK-IN> THEN NCOLLI ELSE 0), additiva GUADAGNO : SUM(COSTO), additiva Misure calcolate COSTO= COSTO_SUM/COSTO_COUNT dove COSTO_SUM = SUM(COSTO), additiva COSTO_COUNT = COUNT(COSTO), additiva 32

33 Progettazione Logica Star Schema (lo SnowFlake schema coincide con lo star-schema) FACT_TABLE(CLASSE,VOLO:dtVOLO,NB,NBC,NCOLLI, COSTO_SUM,COSTO_COUNT) dtvolo(volo,data,compagnia,fascia_ritardo) Alimentazione: Essendo lo schema temporale, l alimentazione della Fact Table richiede di raggruppare sulle dimensioni. Però in questo caso entrambe le dimensioni sono calcolate VOLO = DATA + CODVOLO CLASSE = IF POSTO <=1 THEN 'PRIMA' ELSE 'SECONDA' END In SQL il raggruppamento GROUP BY è possibile anche su espressioni generiche quindi CREATE VIEW FACT_TABLE AS SELECT VOLO = CONVERT(CHAR(11), B.DATA) + ' ' + CONVERT(CHAR(3), B.CODVOLO), CLASSE = CASE WHEN B.POSTO <=1 THEN 'PRIMA' ELSE 'SECONDA' END, COSTO_SUM =SUM(COSTO), COSTO_COUNT=COUNT(COSTO), NB=COUNT(*), NBC=SUM(CASE WHEN C.[CODVOLO] IS NULL THEN 0 ELSE 1 END), NCOLLI= SUM(CASE WHEN C.[CODVOLO] IS NULL THEN 0 ELSE NCOLLI END) FROM BIGLIETTO B LEFT JOIN [CHECK-IN] C ON (B.[DATA] = C.[DATA] AND B.[CODVOLO] = C.[CODVOLO] AND B.[POSTO] = C.[POSTO]) GROUP BY CONVERT(CHAR(11), B.DATA) + ' ' + CONVERT(CHAR(3), B.CODVOLO), CASE WHEN B.POSTO <=1 THEN 'PRIMA' ELSE 'SECONDA' END Anche se non richiesto, per ottenere gli eventi primari e la dimension table dtvolo SELECT VOLO, CLASSE, COSTO=COSTO_SUM/COSTO_COUNT, NB, NBC, NCOLLI, GUADAGNO_C = (COSTO_SUM/COSTO_COUNT)*NB, -- misura calcolata GUADAGNO_D = COSTO_SUM *1) -- misura derivata aggregata con SUM FROM FACT_TABLE CREATE VIEW dtvolo AS SELECT VOLO = CONVERT(CHAR(11), DATA) + ' ' + CONVERT(CHAR(3), CODVOLO), DATA,COMPAGNIA, RITARDO FROM VOLO SQL-OLAP: Nel pattern {DATA,CLASSE,COMPAGNIA } tutti gli attributi sono foglie quindi si ricade in un reticolo classico: SELECT DATA, CLASSE,COMPAGNIA, COSTO=SUM(COSTO_SUM)/ SUM(COSTO_COUNT), NB=COUNT(*),NBC=SUM(NBC), NCOLLI=SUM(NCOLLI), GUADAGNO = SUM(COSTO_SUM) FROM FACT_TABLE F JOIN dtvolo V ON (F.VOLO=V.VOLO) GROUP BY DATA,NPOSTO,COMPAGNIA WITH CUBE 33

34 1.5 Esercizio (ESAME con ESAME-STUDENTE ed ESAME-GRUPPO) DI ESAME STUDENTE NUMES (T,E) SEDE: un CDS (CorsoDiStudio) ha sede in una FACOLTA DEL tra DOCENTE e CDS: un DOCENTE è di un CDS CON tra APPELLO e DOCENTE: un APPELLO è con DOCENTE che lo tiene Attributo TIPO_ESAME di ESAME : assume il valore STUD se è un esame di uno studente ed il valore GRUP se è un esame di un gruppo NUMES è un identificatore di ESAME (chiave alternativa nello schema relazionale): è un numero progressivo univoco dell esame. FACOLTA(FACOLTA,REGIONE) CDS(CDS,FACOLTA:FACOLTA,STUDENTE:STUDENTE) DOCENTE(DOCENTE,FACOLTA:FACOLTA,CDL:CDL) STUDENTE(STUDENTE, FACOLTA:FACOLTA) APPELLO(APPELLO,DOCENTE:DOCENTE, GENERE) ESAME(NUMES, APPELLO:APPELLO, DATA, TIPO_ESAME, VOTO) AK: NUMES ESAMEGRUPPO(NUMES:ESAME, GRUPPO:GRUPPO) ESAMESTUDENTE(NUMES:ESAME, STUDENTE:STUDENTE) GRUPPO(GRUPPO,TIPO) Viene richiesto: ESAME DI (1,N) DATA TIPO (0,N) GRUPPO (1,N) DEL ESAME GRUPPO VOTO TIPO_ESAME (STUD/GRUP) A) Progettazione concettuale :Progettazione dello schema di fatto ESAME con dimensioni { GRUPPO, STUDENTE, TIPOESAME,DATA, DOCENTE } dove STUDENTE è lo STUDENTE che ha sostenuto l esame GRUPPO è il GRUPPO che ha sostenuto l esame misure VOTO_MEDIO: è il voto medio dell esame NUM_APPELLI: è il conteggio distinto degli appelli B) Progettazione logica :Progettazione dello STARSCHEMA C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP Riportare e realizzare il reticolo di roll-up del pattern {DOCENTE}, effettuando opportune ipotesi sulla condivisione/convergenza. Esempio di istanze: STUDENTE (0,N) RAPPRES ENTANTE CDS (1,N) ISCRI TTO SEDE DEL (0,N) GENERE (0,N) REGIONE FACOLTA (0,N) AFFERENZA DOCENTE (1,N) CON APPELLO DBO: relazione ESAME DW: Eventi Primari del Fatto ESAME 34

35 1.5.1 Soluzione Progettazione Concettuale Condivisione su STUDENTE: STUDENTE che ha sostenuto l esame STUDENTE rappresentante del CDS del DOCENTE Condivisione su FACOLTA: FACOLTA del DOCENTE FACOLTA dello STUDENTE FACOLTA dello STUDENTE rappresentante Dipendenze funzionali tra le dimensioni: STUDENTE à TIPOESAME GRUPPO à TIPOESAME Pattern primario = {STUDENTE,DATA,GRUPPO} REGIONE STUDENTE TIPO FACOLTA T,E GRUPPO CDS DOCENTE ESAME (C) VOTO_MEDIO (AVG) NUM_APPELLI TIPO_ESAME DATA Per le FD tra le dimensioni, nello schema equivalente si ha (si riporta solo la parte interessata) Si noti la convergenza su TIPO_ESAME STUDENTE TIPO_ESAME TIPO T,E GRUPPO ESAME (C) VOTO_MEDIO (AVG) NUM_APPELLI Fatto ESAME(NUMES, APPELLO:APPELLO, DATA, TIPO_ESAME, MESE,ANNO,VOTO) Dimensioni = { DOCENTE,STUDENTE,GRUPPO,TIPOESAME,DATA } Misure normali COUNT(DISTINCT ESAME.APPELLO), additiva con NA = {STUDENTE,DATA,GRUPPO} Misure calcolate VOTO_MEDIO = VOTO_TOT/ VOTO_COUNT dove VOTO_TOT = SUM(VOTO) VOTO_COUNT = COUNT(*) Fact Table FACT_TABLE(DATA,GRUPPO,STUDENTE,DOCENTE,TIPOESAME, VOTO_TOT, VOTO_COUNT,NUM_APPELLI) Progettazione Logica STARSCHEMA: FACT_TABLE(DATA,GRUPPO:dtGRUPPO,STUDENTE:dtSTUDENTE,DOCENTE:dtDOCENTE TIPOESAME,VOTO_TOT, VOTO_COUNT,NUM_APPELLI) dtgruppo(gruppo,tipo) dtstudente(studente, FACOLTA, FACOLTA_REGIONE, FACOLTA_STATO) dtdocente(docente,facolta, FACOLTA_REGIONE, CDS,CDS_FACOLTA,CDS_FACOLTA_REGIONE, CDS_STUDENTE,CDS_STUDENTE_FACOLTA,CDS_STUDENTE_FACOLTA_REGIONE ) 35

36 Alimentazione L aspetto caratteristico è la presenza di dimensioni opzionali, il cui valore nullo viene opportunamente codificato (si usa sempre 9999) CREATE VIEW VIEW1 AS SELECT ESAME.*, ISNULL(ESAMESTUDENTE.STUDENTE,9999) AS STUDENTE, ISNULL(ESAMEGRUPPO.GRUPPO,9999) AS GRUPPO FROM ESAME LEFT OUTER JOIN ESAMEGRUPPO ON ESAME.NUMES = ESAMEGRUPPO.NUMES LEFT OUTER JOIN ESAMESTUDENTE ON ESAME.NUMES = ESAMESTUDENTE.NUMES CREATE VIEW FACT_TABLE AS SELECT GRUPPO, STUDENTE, TIPOESAME, DATA,DOCENTE, COUNT(*) AS NUM_TOT, SUM(VOTO) AS VOTO_TOT, COUNT(VOTO) AS VOTO_COUNT, COUNT(DISTINCT APPELLO.APPELLO) AS NUM_APPELLI FROM VIEW1 NATURAL JOIN APPELLO GROUP BY GRUPPO, STUDENTE, TIPOESAME, DATA,DOCENTE Per semplicità si usa il NATURAL JOIN (in modo da evitare di scrivere la condizione di join). E possibile usare il NATURAL JOIN anche per i join esterni, ovvero la scrittura della VIEW1 si può semplificare scrivendo: CREATE VIEW VIEW1 AS SELECT ESAME.*, ISNULL(ESAMESTUDENTE.STUDENTE,9999) AS STUDENTE, ISNULL(ESAMEGRUPPO.GRUPPO,9999) AS GRUPPO FROM ESAME LEFT NATURAL JOIN ESAMEGRUPPO LEFT NATURAL JOIN ESAMESTUDENTE 36

37 SQL-OLAP Riportare e realizzare il reticolo di roll-up del pattern {DOCENTE}, effettuando opportune ipotesi sulla condivisione/convergenza Riportiamo la parte di gerarchia relativa a DOCENTE (per chiarezza sono indicati le direzioni degli archi) DOCENTE FACOLTA REGIONE CDS STUDENTE 1 CASO) Convergenza su FACOLTA Il reticolo di roll-up contiene solo una volta il pattern {FACOLTA}, e di conseguenza il pattern {REGIONE} Il reticolo di roll-up è riportato in figura (per semplicità gli insiemi di attributi dimensionali sono indicati senza {}). Questo esempio evidenzia che nella costruzione/rappresentazione grafica del reticolo di roll-up si riportano solo le FD tra pattern che sono dirette e non derivate dalla proprietà transitiva. DOCENTE CDS STUDENTE FACOLTA REGIONE { } Nello star-schema, per ottenere il reticolo di roll-up di {DOCENTE } è sufficiente il join con dtdocente; evidenziamo gli attributi necessari; dtdocente(docente,facolta, FACOLTA_REGIONE,CDS,CDS_FACOLTA,CDS_FACOLTA_REGIONE, CDS_STUDENTE,CDS_STUDENTE_FACOLTA,CDS_STUDENTE_FACOLTA_REGIONE ) Per quanto discusso prima, in questo caso si può usare WITH ROLLUP perché abbiamo che DOCENTE à CDS à CDS_STUDENTE à FACOLTA à REGIONE NUM_APPELLO si omette perché non calcolabile per nessun pattern del reticolo. Quindi SELECT DOCENTE,CDS,CDS_STUDENTE, FACOLTA, FACOLTA_REGIONE, COSTO = SUM(COSTO_SUM)/SUM(COSTO_COUNT), NUMERO =SUM(NUMERO) FROM FACT_TABLE NATURAL JOIN dtdocente GROUP BY DOCENTE,CDS,CDS_STUDENTE, FACOLTA, FACOLTA_REGIONE WITH ROLLUP 37

38 2 CASO) Convergenza su REGIONE le regioni delle tre facoltà coincidono; inoltre la facoltà del CDS coincide con quella dello STUDENTE rappresentante del CDS Con i vincoli imposti la gerarchia che ha come radice DOCENTE può essere esplicitata come: DOCENTE DOCENTE CDS,DOC_FAC DOC_FAC CDS STUD, DOC_FAC ST_FAC, DOC_FAC STUD ST_FAC DOC_FAC REGIONE ST_FAC Il reticolo contiene il pattern {REGIONE} e i due pattern {DOC_FAC} e {ST_FAC} REGIONE { } Rispetto al caso precedente dobbiamo includere sia DOC_FAC (corrispondente a FACOLTA nella dtdocente) che ST_FAC (corrispondente a CDS_STUDENTE_FACOLTA nella dtdocente); dtdocente(docente,facolta, FACOLTA_REGIONE, CDS,CDS_FACOLTA,CDS_FACOLTA_REGIONE, CDS_STUDENTE,CDS_STUDENTE_FACOLTA,CDS_STUDENTE_FACOLTA_REGIONE ) Per quanto discusso prima, in questo caso abbiamo che NUM_APPELLO si omette perché non calcolabile per nessun pattern del reticolo. Quindi SELECT DOCENTE,CDS,CDS_STUDENTE,CDS_STUDENTE_FACOLTA,FACOLTA, FACOLTA_REGIONE, COSTO = SUM(COSTO_SUM)/SUM(COSTO_COUNT), NUMERO =SUM(NUMERO) FROM FACT_TABLE NATURAL JOIN dtdocente GROUP BY DOCENTE,CDS,CDS_STUDENTE,CDS_STUDENTE_FACOLTA,FACOLTA, FACOLTA_REGIONE WITH CUBE HAVING NOT ( GROUPING(DOCENTE)=0 AND GROUPING(CDS)=1 OR GROUPING(CDS)=0 AND GROUPING(CDS_STUDENTE)=1 OR ) 38

39 3 CASO) Convergenza su REGIONE le regioni delle tre facoltà coincidono. DOCENTE Con i vincoli imposti la gerarchia che ha come radice DOCENTE può essere esplicitata come (ora abbiamo tre facoltà distinte): CDS CDS_FAC DOC_FAC STUD ST_FAC REGIONE Ricordiamo che per il pattern {a,b,c} con tutti e tre gli attributi senza figli, il reticolo di roll-up contiene tutti gli elementi dell insieme potenza {a,b,c} e corrisponde al classico cuboide 3- dimensionale: CDS_FAC, ST_FAC,DOC_FAC Tra gli attributi CDS_FAC,ST_FAC,DOC_FAC non ci sono FD quindi { CDS_FAC,ST_FAC,DOC_FAC } è un pattern ed inoltre tutti e tre gli attributi hanno come unico figlio REGIONE CDS_FAC, ST_FAC CDS_FAC CDS_FAC,DOC_FAC ST_FAC,DOC_FAC ST_FAC DOC_FAC REGIONE {} I pattern che restano da aggiungere sono {DOCENTE}, {CDS}, {CDS, DOC_FAC}, {STUD}, { STUD,DOC_FAC}, { STUD, CDS_FAC}, {STUD,DOC_FAC, CDS_FAC}, CDS DOCENTE CDS,DOC_FAC CDS_FAC, STUD,DOC_FAC STUD,CDS_FAC CDS_FAC, ST_FAC,DOC_FAC STUD, DOC_FAC Indichiamo il reticolo relativo a questi elementi, riportando i collegamenti con quelli del precedente reticolo (denotati in grassetto-corsivo) CDS_FAC, ST_FAC STUD ST_FAC,DOC_FAC ST_FAC 39

40 1.5.2 Compiti Scritti (tipologie) Compito di Progettazione Concettuale/Logica/Alimentazione Dato lo schema E/R e/o relazionale viene richiesto: A) Progettazione concettuale :Progettazione dello schema di fatto ESAME con dimensioni { GRUPPO, STUDENTE, TIPOESAME,DATA, DOCENTE } dove STUDENTE è lo STUDENTE che ha sostenuto l esame GRUPPO è il GRUPPO che ha sostenuto l esame misure VOTO_MEDIO: è il voto medio dell esame NUM_APPELLI: è il conteggio distinto degli appelli B) Progettazione logica :Progettazione dello STAR SCHEMA oppure dello SNOWFLAKE SCHEMA C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. Compito di Progettazione Logica ed Interrogazioni SQL-OLAP Dato lo schema di Fatto ESAME: FACOLTA DOCENTE Condivisione su STUDENTE: STUDENTE che ha sostenuto l esame STUDENTE rappresentante del CDS del DOCENTE REGIONE STUDENTE TIPO T,E GRUPPO CDS ESAME (C) VOTO_MEDIO (AVG) NUM_APPELLI TIPO_ESAME DATA Condivisione su FACOLTA: FACOLTA del DOCENTE FACOLTA dello STUDENTE FACOLTA dello STUDENTE rappresentante Dipendenze funzionali tra le dimensioni: STUDENTE à TIPOESAME GRUPPO à TIPOESAM Viene richiesto: A) Progettazione logica :Progettazione dello STAR SCHEMA oppure dello SNOWFLAKE SCHEMA B) SQL-OLAP Riportare e realizzare il reticolo di roll-up del pattern {DOCENTE}, considerando una convergenza su REGIONE (le regioni delle tre facoltà coincidono) e che la facoltà del CDS coincide con quella dello STUDENTE rappresentante del CDS. C) Considerare un arco multiplo tra DOCENTE e FACOLTA (un DOCENTE afferisce a più FACOLTA); descrivere cosa cambia nella progettazione logica. 40

41 1.6 Esercizio: Vendita (prima versione) Sia dato il seguente schema relazionale del DBO VENDITA(VENDITA,PRODOTTO,CASSA, COMMESSO,NUMERO_SCONTRINO,DATA) {PRODOTTO,DATA} à CASSA NUMERO_SCONTRINO à DATA PRODOTTO(PRODOTTO,TIPO:TIPO) TIPO(TIPO, CATEGEGORIA,GRUPPO) Viene richiesto: 1) Reverse Engineering: Schema E/R equivalente 2) Progettazione Concettuale: Schema di Fatto con Dimensioni = {PRODOTTO,CASSA,COMMESSO,DATA} e Misure i. NUMVENDITE = count(*) ii. NUMCLIENTI = count(distinct NUMERO_SCONTRINO) 3) Progettazione logica: SNOWFLAKE SCHEMA 4) SQL- OLAP: Riportare e realizzare in SQL- OLAP a. il reticolo di roll- up del pattern {CASSA,DATA,COMMESSO}; b. il reticolo di roll- up del pattern {PRODOTTO,COMMESSO}; 5) Supponendo che l attributo COMMESSO assume valore NULL per le vendite senza COMMESSO e un valore NON NULLO per le vendite con commesso, considerare lo Schema di Fatto con Dimensioni = {PRODOTTO,CASSA, DATA} e discutere la definizione e l aggregabilità della misura NUMVENDITE_CONCOMMESSO : conteggio delle vendite con COMMESSO 41

42 1.6.1 Soluzione Schema E/R: VENDITA IN (1,N) SCONTRINO CON COMM CATEGORIA GRUPPO DI (1,N) CASSA (1,N) TIPO HA (1,N) PRODOTTO (1,N) ALLA CASSA (1,N) DATA Schema di Fatto VENDITA GRUPPO CAT GRUPPO CAT PRODOTTO TIPO PRODOTTO TIPO VENDITA CASSA VENDITA NUMVENDITE NUMCLIENTI NUMVENDIT E NUMCLIENTI CASSA COMM DATA COMM DATA Fatto VENDITA(VENDITA,PRODOTTO,CASSA, COMMESSO,NUMERO_SCONTRINO,DATA) Dimensioni = { PRODOTTO,CASSA, COMM,DATA } Granularità: Temporale Dipendenze funzionale tra le dimensioni: {DATA,PRODOTTO } à CASSA Misure normali NUMVENDITE= COUNT(*), additiva NUMCLIENTI=COUNT(DISTINCT NUMERO_SCONTRINO), additiva con NA = { PRODOTTO, COMM } Per valutare quali sono i pattern per i quali il valore aggregato di NUMCLIENTI può essere calcolato: si considera lo schema equivalente senza FD tra le dimensioni: NA = { PRODOTTO, COMMESSO}. SnowFlake Schema FACT_TABLE(PRODOTTO:dtPRODOTTO,DATA,COMMESSO,CASSA,NUMVENDITE,NUMCLIENTI) dtprodotto(prodotto,tipo:dttipo) dttipo(tipo,gruppo, CATEGORIA) E possibile limitare la chiave della Fact Table al solo pattern primario {PRODOTTO,DATA,COMMESSO} FACT_TABLE(PRODOTTO:dtPRODOTTO,DATA,COMMESSO,CASSA,NUMVENDITE,NUMCLIENTI) E inoltre possibile normalizzare la Fact Table al solo pattern primario {PRODOTTO,DATA,COMMESSO}: FACT_TABLE(PRODOTTO:dtPRODOTTO, DATA,COMMESSO, NUMVENDITE,NUMCLIENTI) dtprodotto(prodotto,tipo:dttipo) dttipo(tipo,gruppo, CATEGORIA) dtcassa(prodotto:dtprodotto, DATA, CASSA) 42

43 Reticolo di roll-up del pattern {CASSA,DATA,COMMESSO}: Tra gli attributi CASSA,DATA,COMMESSO non ci sono FD ed inoltre nessuno di questi attributi ha figli (DATA non determina CASSA) quindi {CASSA,DATA,COMMESSO} è un pattern costituito da foglie, pertanto il suo reticolo di roll-up contiene tutti gli elementi dell insieme potenza {CASSA,DATA,COMMESSO} e corrisponde al classico cuboide 3-dimensionale: { CASSA, DATA,COMM} { CASSA, DATA} { CASSA,COMM} { DATA,COMM} {CASSA} { DATA} {COMM} { } Realizzazione del reticolo in SQL-OLAP Tutti gli attributi coinvolti sono presenti nella FACT TABLE FACT_TABLE(PRODOTTO:dtPRODOTTO,DATA,COMMESSO,CASSA,NUMVENDITE,NUMCLIENTI) Quindi non occorre nessun join. Inoltre essendo NA = { PRODOTTO, COMMESSO} la misura NUMCLIENTI non è mai calcolabile e non viene quindi riportata: SELECT DATA,COMMESSO,CASSA, NUMVENDITE = SUM(NUMVENDITE) FROM FACT_TABLE F GROUP BY DATA,COMMESSO,CASSA WITH CUBE Si noti che in questo caso con WITH CUBE si realizzano esattamente tutti gli elementi dell insieme potenza {CASSA,DATA,COMMESSO} e quindi non serve eliminarne con HAVING (non ci sono righe ridondanti). 43

44 Reticolo di roll-up del pattern {PRODOTTO,COMMESSO}: Un elemento di tale reticolo è costituito dal pattern {GRUPPO,CATEGORIA,COMMESSO} costituito da foglie, pertanto come in precedenza il suo reticolo di roll-up contiene tutti gli elementi dell insieme potenza {GRUPPO,CATEGORIA,COMMESSO} e corrisponde al classico cuboide 3-dimensionale. In aggiunta abbiamo i pattern {PROD,COMM}, {TIPO,COMM}, {PROD} e {TIPO} {PROD,COMM} { PROD} { TIPO,COMM} {TIPO} {GRUP, CAT,COMM} {GRUP,CAT} {GRUP,COMM} {CAT,COMM} {GRUP} { CAT} {COMM} { } Realizzazione del reticolo in SQL-OLAP Riportiamo lo snowflake schema indicando gli attributi del reticolo FACT_TABLE(PRODOTTO:dtPRODOTTO,DATA,COMMESSO,CASSA,NUMVENDITE,NUMCLIENTI) dtprodotto(prodotto,tipo:dttipo) dttipo(tipo,gruppo, CATEGORIA) E necessario quindi un join con dttipo, passando per dtprodotto: SELECT PRODOTTO,COMMESSO,TIPO,GRUPPO,CATEGORIA NUMVENDITE = SUM(NUMVENDITE), NUMCLIENTI = CASE WHEN ( GROUPING(PRODOTTO)=0 AND GROUPING(COMMESSO)=0 ) THEN CONVERT(CHAR(20),SUM(NUM_ORD) ) ELSE 'NON CALCOLAB' END FROM FACT_TABLE F NATURAL JOIN dtprodotto NATURAL JOIN dttipo GROUP BY PRODOTTO,COMMESSO,TIPO,GRUPPO,CATEGORIA WITH CUBE HAVING NOT ( GROUPING(PRODOTTO)=0 AND GROUPING(TIPO)=1 OR GROUPING(TIPO)=0 AND GROUPING(GRUPPO)=1 OR) GROUPING(TIPO)=0 AND GROUPING(CATEGORIA)=1) Supponendo che l attributo COMMESSO assume valore NULL per le vendite senza COMMESSO e un valore NON NULLO per le vendite con commesso, considerare lo Schema di Fatto con Dimensioni = {PRODOTTO,CASSA, DATA} e discutere la definizione e l aggregabilità della misura NUMVENDITE_CONCOMMESSO : conteggio delle vendite con COMMESSO Come nell esempio 1.4, NUMVENDITE_CONCOMMESSO (NVCC) è una misura additiva rispetto a tutte le dimensioni definita come NVCC=SUM(CASE WHEN COMMESSO IS NULL THEN 0 ELSE 1 END) Ora COMMESSO non è più una dimensione, quindi per NUMCLIENTI l insieme NA è solo { PRODOTTO }. Inoltre {PRODOTTO,COMMESSO} e {CASSA,DATA,COMMESSO} non sono più pattern dello schema. 44

45 1.6.2 Compiti Scritti (tipologie) A) Dato il seguente schema di fatto (schema di destra oppure schema di sinistra): GRUPPO CAT GRUPPO CAT PRODOTTO TIPO PRODOTTO TIPO VENDITA CASSA VENDITA NUMVENDITE NUMCLIENTI NUMVENDIT E NUMCLIENTI CASSA COMM DATA COMM DATA Viene richiesto di 1) Progettazione logica: SNOWFLAKE SCHEMA 2) SQL- OLAP: Riportare e realizzare in SQL- OLAP a. il reticolo di roll- up del pattern {CASSA,DATA,COMMESSO}; b. il reticolo di roll- up del pattern {PRODOTTO,COMMESSO}; 3) (Facoltativo) Supponendo che l attributo COMMESSO assume valore NULL per le vendite senza COMMESSO e un valore NON NULLO per le vendite con commesso, considerare lo Schema di Fatto con Dimensioni = {PRODOTTO,CASSA, DATA} e discutere la definizione e l aggregabilità della misura NUMVENDITE_CONCOMMESSO : conteggio delle vendite con COMMESSO 45

46 B) Sia dato il seguente schema relazionale del DBO VENDITA(VENDITA,PRODOTTO,CASSA, COMMESSO,NUMERO_SCONTRINO,DATA) {PRODOTTO,DATA} à CASSA NUMERO_SCONTRINO à DATA PRODOTTO(PRODOTTO,TIPO:TIPO) TIPO(TIPO, CATEGEGORIA,GRUPPO) Viene richiesto: 1) Reverse Engineering: Schema E/R equivalente 2) Progettazione Concettuale: Schema di Fatto con Dimensioni = {PRODOTTO, COMMESSO,DATA} e Misura i. NUMVENDITE = count(*) 3) Progettazione logica: STAR SCHEMA C) Sia dato il seguente schema E/R del DBO VENDITA IN (1,N) SCONTRINO CON COMM CATEGORIA GRUPPO DI (1,N) CASSA (1,N) TIPO HA (1,N) PRODOTTO (1,N) ALLA CASSA (1,N) DATA Viene richiesto: 1) Progettazione Concettuale: Schema di Fatto con Dimensioni = {PRODOTTO,CASSA,COMMESSO,DATA} e Misura i. NUMVENDITE = count(*) ii. NUMCLIENTI = count(distinct NUMERO_SCONTRINO) 2) Progettazione logica: SNOWFLAKE SCHEMA 3) SQL- OLAP: Riportare e realizzare in SQL- OLAP a. il reticolo di roll- up del pattern {CASSA,DATA,COMMESSO}; 46

47 1.7 Esercizio: Vendita (seconda versione) Sia dato il seguente schema relazionale del DBO VENDITA(VENDITA, COMMESSO, [NS,PRODOTTO]:PRODOTTOSCONTRINO) PRODOTTOSCONTRINO(SCONTRINO:SCONTRINO,PRODOTTO, CASSA) SCONTRINO(SCONTRINO,DATA) Viene richiesto: 1) Reverse Engineering: Schema E/R equivalente 2) Progettazione Concettuale: Schema di Fatto con Dimensioni = {PRODOTTO,CASSA,COMMESSO,DATA} e Misure i. NUMVENDITE = count(*) ii. NUMCLIENTI = count(distinct NUMERO_SCONTRINO) 3) Progettazione logica: SNOWFLAKE SCHEMA 4) SQL- OLAP: Riportare e realizzare in SQL- OLAP il reticolo di roll- up del pattern {CASSA,DATA,COMMESSO}; 47

48 1.7.1 Soluzione Schema E/R: DATA NS SCONTRINO (1,N) PROD CASSA B PRODOTTO SCONTRINO (1,N) B COMM NV VENDITA Schema di Fatto VENDITA PRODOTTO VENDITA NUMVENDITE NUMCLIENTI CASSA FD tra le dimensioni : nessuna {SCONTRINO,PRODOTTO} à CASSA, SCONTRINO à DATA quindi COMM DATA NA = { PRODOTTO, COMMESSO} SnowFlake Schema: c è solo la FACT_TABLE, tutte le dimensioni sono degeneri. FACT_TABLE(PRODOTTO, DATA,COMMESSO, CASSA, NUMVENDITE,NUMCLIENTI) Reticolo di roll-up del pattern {CASSA,DATA,COMMESSO}: già discusso nell esercizio precedente. 48

49 1.8 Esempi per PROVA SCRITTA ESEMPIO1) Consideriamo un DBO con il seguente schema E/R DITTA SCONTO SCONTO (1,N) (1,N) REGIONE STATO DITTA SOCIETA CITTA (0,N) CITTA (1,N) (1,N) (0,N) (0,N) CITTA SOCIETA DITTA SOCIETA CITTA CITTA PROPRIETARIO CON_DITTA IMMOBILE PROPRIETARIO SESSO (1,N) IMMOBILE (1,N) IMMOBILE PROPRIETARIO IMPORTO ANNO MESE CODRIP RIPARAZIONE (1,N) APPARTAMENTO DATA APPARTAMENTO TIPO Significato di alcune associazioni CITTA tra SOCIETA e CITTA: una SOCIETA ha sede in una CITTA CITTA tra IMMOBILE e CITTA: un IMMOBILE è in una CITTA IMMOBILE tra APPARTAMENTO e IMMOBILE: un APPARTAMENTO è in un IMMOBILE PROPRIETARIO tra APPARTAMENTO e PROPRIETARIO: un APPARTAMENTO è di un PROPRIETARIO DITTA tra CON_DITTA e DITTA: una riparazione con ditta è realizzata da una ditta SCONTO : è lo SCONTO applicato da una DITTA sulle riparazioni degli immobili della SOCIETA. Viene richiesto di: A) Progettazione concettuale :Progettazione dello schema di fatto RIPARAZIONE con dimensioni misure { IMMOBILE, DITTA, PROPRIETARIO, TIPO, ANNO} e IMPORTOMEDIO: è l importo (cioè il costo) medio delle riparazioni NUMEROTOTALE: è il numero complessivo delle riparazioni NUMEROAPPARTAMENTI: è il numero di appartamenti riparati, ottenuto attraverso un conteggio distinto di APPARTAMENTO B) Progettazione logica :Progettazione dello STARSCHEMA oppure SNOWFLAKE SCHEMA C) SQL-OLAP : Riportare e realizzare il reticolo di roll-up del pattern {ANNO, PROPRIETARIO} (senza considerare la REGIONE e lo STATO della CITTA). Esempio di istanza del DBO (solo tabelle principali) e corrispondente istanza del fatto (eventi primari) CON_DITTA Fatto RIPARAZIONE 49

50 ESEMPIO2) Consideriamo un DBO con il seguente schema E/R : DITTA SCONTO SCONTO (1,N) (1,N) REGIONE STATO DITTA SOCIETA CITTA (0,N) CITTA (1,N) (1,N) (0,N) (0,N) CITTA SOCIETA DITTA SOCIETA CITTA CITTA PROPRIETARIO CON_DITTA IMMOBILE PROPRIETARIO SESSO (1,N) IMMOBILE (1,N) IMMOBILE PROPRIETARIO IMPORTO ANNO MESE CODRIP RIPARAZIONE (1,N) APPARTAMENTO DATA APPARTAMENTO TIPO Significato di alcune associazioni CITTA tra SOCIETA e CITTA: una SOCIETA ha sede in una CITTA CITTA tra IMMOBILE e CITTA: un IMMOBILE è in una CITTA IMMOBILE tra APPARTAMENTO e IMMOBILE: un APPARTAMENTO è in un IMMOBILE PROPRIETARIO tra APPARTAMENTO e PROPRIETARIO: un APPARTAMENTO è di un PROPRIETARIO DITTA tra CON_DITTA e DITTA: una riparazione con ditta è realizzata da una ditta SCONTO : è il valore di SCONTO applicato da una DITTA sulle riparazioni degli immobili della SOCIETA. Viene richiesto di: A) Progettazione concettuale :Progettazione dello schema di fatto RIPARAZIONE con dimensioni { IMMOBILE, DITTA, PROPRIETARIO, TIPO, ANNO} e misure IMPORTOMEDIO: è l importo (cioè il costo) medio delle riparazioni B) Progettazione logica :Progettazione dello STARSCHEMA oppure SNOWFLAKE SCHEMA C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP : Riportare e realizzare il reticolo di roll-up del pattern {DITTA, IMMOBILE} (senza considerare la CITTA di SOCIETA e la CITTA dell IMMOBILE). E) (facoltativo): discutere cosa cambia aggiungendo SCONTO alle dimensioni. Esempio di istanza del DBO (solo tabelle principali) e corrispondente istanza del fatto (eventi primari) CON_DITTA Fatto RIPARAZIONE 50

51 ESEMPIO3) Dato il seguente Schema di Fatto CATEGORIA FASCIA_REDDITO STATO PROPRIETARIO CITTA ALIQUOTA _TASSA REGIONE APPARTAMENTO IMMOBILE RIPARAZIONE SOCIETA DITTA (C)IMPORTOMEDIO (AVG) NUMEROSTANZE ANNO Precisazioni: 1) lo schema di fatto, anche essendo simile, non è quello richiesto nei precedenti esercizi 2) La RIPARAZIONE è relativa ad una STANZA di un APPARTAMENTO: nello schema di fatto si considera l appartamento 3) Non aggregabilità della misura NUMEROSTANZE rispetto a ANNO e DITTA Viene richiesto di: B) Progettazione logica :Progettazione dello STARSCHEMA oppure SNOWFLAKE SCHEMA D) SQL-OLAP : 1. Riportare e realizzare il reticolo di roll-up del pattern {ANNO, FASCIA_REDDITO}. 2. Usando lo STAR schema, scrivere una query SQL-OLAP per ottenere il pattern {REGIONE_PROPRIETARIO,DITTA, SOCIETA } ed il pattern {} 51

52 1.8.1 Soluzione (solo gli aspetti principali) Lo schema di fatto è il seguente: STATO REGIONE CITTA PROPRIETARIO IMMOBILE SOCIETA DITTA RIPARAZIONE SCONTO NUMEROTOTALE (C)IMPORTOMEDIO (AVG) NA ANNO TIPO Granularità: Temporale Dipendenze funzionale tra le dimensioni: NESSUNA Misure : NA è additiva rispetto a PROPRIETARIO e IMMOBILE, non aggregabile rispetto alle altre Riportare e realizzare il reticolo di roll-up del pattern {ANNO, PROPRIETARIO} (senza considerare la REGIONE e STATO della CITTA). Un elemento di tale reticolo è costituito dal pattern {ANNO,CITTA,SEX} costituito da foglie, pertanto come discusso in precedenza il suo reticolo di roll-up corrisponde al classico cuboide 3-dimensionale. In aggiunta abbiamo i pattern {PROP,ANNO} e {PROP} {ANNO,SEX} {PROP,ANNO} { PROP} {ANNO, SEX,CITTA} {ANNO,CITTA} {SEX,CITTA} {ANNO} { SEX} {CITTA} { } 52

53 Riportare e realizzare il reticolo di roll-up del pattern {ANNO, PROPRIETARIO} completo Un elemento di tale reticolo è costituito dal pattern {ANNO,SEX,STATO} costituito da foglie, pertanto come in precedenza il suo reticolo di roll-up corrisponde al classico cuboide 3- dimensionale. {ANNO,SEX} {ANNO} {ANNO, SEX,STATO} {ANNO,STATO} {SEX,STATO} { SEX} {STATO} { } L altra parte del reticolo deve essere costruita mettendo in aggiunta i pattern che si ottengono con PROP,CITTA e REG {ANNO, SEX,CITTA} {PROP,ANNO} { PROP} {ANNO, SEX,REG} {CITTA,ANNO} {CITTA,SEX} {ANNO, SEX,STATO} {ANNO, REG} {ANNO} {CITTA} {REG} {REG,SEX} {STATO,SEX} {STATO} Più che complesso è un procedimento lungo, in quanto il reticolo viene costruito su sei elementi. Un altra possibile costruzione è riportata nel seguito 53

54 { PROP} Reticolo corrispondente a PRODà CITTAà REGà STATO (e il cammino più lungo) {CITTA} {REG} {STATO} { } Aggiungendo SEX con PROP à SEX Siccome SEX è indipendente da CITTA, per tutti gli elementi X del precedente reticolo (ad eccezione dell elemento {PROP} in quanto PROP à SEX) se ne deve aggiungere un altro ottenuto come X unito {SEX}; le relazioni sono {CITTA} { PROP} {CITTA,SEX} {REG,SEX} X unito {SEX} à X Dati A= X unito {SEX} e B= X unito {SEX} con Xà X, allora Aà B {REG} {STATO} {STATO,SEX} {SEX} { } Per aggiungere ANNO si deve ripetere lo stesso procedimento In questo modo anche se non si disegna il reticolo completamente, si ottiene un idea della sua struttura, dei pattern che contiene e delle relazioni tra questi pattern. Per ottenere il reticolo in SQL-OLAP: 1) La misura NA non è calcolabile per nessun pattern del reticolo, in quanto NA non è aggregabile rispetto a DITTA e TIPO che non fanno parte del reticolo 2) Per considerare le dipendenza funzionali HAVING NOT ( GROUPING(PROP)=0 AND GROUPING(SEX)=1 OR GROUPING(PROP)=0 AND GROUPING(CITTA)=1 OR GROUPING(CITTA)=0 AND GROUPING(REG)=1 OR GROUPING(REG)=0 AND GROUPING(STATO)=1 ) 3) La parte FROM è semplice SQL-OLAP : Riportare e realizzare il reticolo di roll-up del pattern {ANNO, PROPRIETARIO} (senza considerare la REGIONE e lo STATO della CITTA). In questo caso si deve considerare l attributo cross-dimensionale SCONTO. La soluzione è presentata in sezione 2.8Esercizio (RIPARAZIONE, arco multiplo APPARTAMENTO-PROPRIETARIO). 54

55 1.8.2 Ottenere tutti gli elementi di un reticolo in SQL-OLAP Consideriamo prima il caso più semplice del reticolo di roll-up del pattern { PROPRIETARIO} senza STATO: gli attributi dimensionali sono {PROP,CITTA,REG }. 1) Per ottenere l insieme potenza si utilizza il group by with cube, applicato ad una tabella con una sola riga, contenente tutti gli attributi del reticolo come valori (i nomi delle colonne sono ininfluenti, ma conviene usare ancora i nomi di tali attributi): Chiamiamo tale tabella RETICOLO. Quindi l insieme potenza di {PROP,CITTA,REG } si ottiene con: SELECT PROP,CITTA,REG FROM RETICOLO GROUP BY PROP,CITTA,REG WITH CUBE 2) Per ottenere i pattern occorre eliminare gli insiemi che contengono delle dipendenze funzionali attraverso la clausola HAVING; ad esempio per eliminare gli insiemi che contengono {PROD,CITTA} (dipendenza funzionale PROPà CITTA) si deve utilizzare HAVING NOT (GROUPING(PROP)=0 AND GROUPING(CITTA)=0) Per ogni dipendenza funzionale ci vuole una condizione in OR; occorre mettere una condizione anche per quelle ottenute per transitività, quale ad esempio PROPà REGIONE: HAVING NOT ( GROUPING(PROP)=0 AND GROUPING(CITTA)=0 OR GROUPING(PROP)=0 AND GROUPING(REG)=0 OR GROUPING(CITTA)=0 AND GROUPING(REG)=0 ) È importante notare la differenza della precedente query rispetto a quella che noi utilizziamo per la realizzazione del pattern {PROPRIETARIO} con PROP à CITTA à REG, dove l obiettivo è ottenere: SELECT REG,CITTA,PROP FROM RETICOLO GROUP BY REG,CITTA,PROP WITH ROLLUP nella formulazione equivalente con with cube: SELECT REG,CITTA,PROP FROM RETICOLO GROUP BY REG,CITTA,PROP WITH CUBE HAVING NOT ( GROUPING(PROP)=0 AND GROUPING(CITTA)=1 OR GROUPING(PROP)=0 AND GROUPING(REG)=1 OR GROUPING(CITTA)=0 AND GROUPING(REG)=1 ) La condizione relativa alla dipendenza ottenuta per transitività PROP à REG si può ora togliere grazie al fatto che NOT( P1 AND P2 OR P1 AND P3 OR NOT P2 AND P3) è equivalente a NOT( P1 AND P2 OR P1 AND P3 OR NOT P2 AND P3) 55

56 Nell esempio del reticolo di roll-up del pattern {ANNO, PROPRIETARIO} completo, gli attributi dimensionali sono { ANNO,SEX,STATO,PROP,CITTA,REG }, quindi la tabella RETICOLO è e l insieme potenza si ottiene con SELECT ANNO,SEX,STATO,PROP,CITTA,REG FROM RETICOLO GROUP BY ANNO,SEX,STATO,PROP,CITTA,REG WITH CUBE Per ogni dipendenza funzionale ci vuole una condizione in OR; occorre mettere una condizione anche per quelle ottenute per transitività, quale ad esempio PROPà REG, quindi: HAVING NOT ( GROUPING(PROP)=0 AND GROUPING(SEX)=0 OR GROUPING(PROP)=0 AND GROUPING(CITTA)=0 OR GROUPING(PROP)=0 AND GROUPING(REG)=0 OR GROUPING(PROP)=0 AND GROUPING(STATO)=0 OR GROUPING(CITTA)=0 AND GROUPING(REG)=0 OR GROUPING(CITTA)=0 AND GROUPING(STATO)=0 OR GROUPING(REG)=0 AND GROUPING(STATO)=0 ) Il risultato finale è stato ordinato in modo da ottenere nelle prime 8 tuple il reticolo relativo a { ANNO, SEX, STATO }. 56

57 Esercizi (con Archi Multipli) Nelle prime tre sezioni si illustra il problema e si discutono alcuni esempi. Quindi si presentano alcuni esercizi completi. 57

58 2.1 ESEMPI con Arco multiplo su CORSO-DOCENTE Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale: CITTA(CITTA,STATO) DOCENTE(DOCENTE,CITTA:CITTA) CORSO(CORSO,FACOLTA) PESO(DOCENTE:DOCENTE, CORSO:CORSO,PESO) STUDENTE(MATRICOLA, CITTA:CITTA) ESAME(MATRICOLA:STUDENTE, NUMEROPROG, CORSO:CORSO CFU,VOTO) Prima di fare uno esercizio completo con gli archi multipli, allo scopo di evidenziare la progettazione nel caso di arco multiplo, si considerano e si confrontano i seguenti casi Senza Arco multiplo su CORSO-DOCENTE (ovvero un corso è associato ad un unico docente ) Nello schema relazionale non si considera PESO ma la tabella CORSO_DOCENTE(CORSO:CORSO, DOCENTE:DOCENTE) Sia per il caso transazionale (dimensioni {CORSO, NP,STUDENTE }) che per il caso temporale (dimensioni {CORSO, STUDENTE }) si considera la misura VOTO inteso come voto medio. Con Arco multiplo su CORSO-DOCENTE. Sia per il caso transazionale (dimensioni {CORSO, NP,STUDENTE }) che per il caso temporale (dimensioni {CORSO, STUDENTE }) si considerano le due misure VOTO: Inteso come voto medio, è una misura di impatto, in quanto calcolando la media dei voti per un certo docente si considerano tutti i suoi corsi, indipendentemente dal peso VOTO_P Inteso come voto medio, è una misura pesata, in quanto calcolando la media dei voti per un certo docente si considerano tutti i suoi corsi ma con il relativo peso (vedere esempio) Per un confronto semplice, dato un pattern (es. {DOCENTE,FACOLTA}) non si considera l intero reticolo di roll-up ma solo i suoi sub-pattern (es. {DOCENTE},{FACOLTA} e {}). Per creare le istanze: 58

59 2.1.1 Senza Arco multiplo su CORSO-DOCENTE Eventi Primari del Fatto transazionale, con dimensioni STUDENTE, NP, CORSO Eventi Primari del Fatto temporale, con dimensioni STUDENTE, CORSO {DOCENTE,FACOLTA} e sub-pattern {DOCENTE,CORSO} e sub-pattern 59

60 CASO I) Fatto transazionale, con dimensioni STUDENTE, NP, CORSO (Dipendenze funzionali tra le dimensioni { STUDENTE, NP } à CORSO) La misura VOTO può essere considerata come 1. una misura normale VOTO aggregata tramite AVG 2. una misura calcolata come SUM(VOTO) / COUNT(*) (oppure SUM(VOTO) / SUM(NUMERO=1)) CREATE VIEW FACT_TABLE AS SELECT STUDENTE, NP, CORSO,VOTO FROM ESAME E Nel primo caso: Per il pattern {DOCENTE,FACOLTA} e sub-pattern (la DT_CORSO è di banale definizione) SELECT DOCENTE,FACOLTA, VOTO=AVG(VOTO) FROM FACT_TABLE E JOIN DT_CORSO P ON (E.CORSO=P.CORSO) GROUP BY DOCENTE,FACOLTA WITH CUBE Nel secondo caso: Per il pattern {DOCENTE,FACOLTA} e sub-pattern SELECT DOCENTE,FACOLTA, VOTO=SUM(VOTO)/ COUNT(*) FROM FACT_TABLE E JOIN DT_CORSO P ON (E.CORSO=P.CORSO) GROUP BY DOCENTE,FACOLTA WITH CUBE CASO II) Fatto temporale, con dimensioni STUDENTE, CORSO In caso di schema temporale, una misura aggregata tramite AVG deve essere definita come misura calcolata come somma degli elementi/numero di elementi. Quindi VOTO: misura calcolata come VOTO_SUM/ VOTO_NUM dove CREATE VIEW FACT_TABLE AS SELECT STUDENTE,CORSO, VOTO_SUM=SUM(VOTO), VOTO_NUM=COUNT(*) FROM ESAME E GROUP BY STUDENTE,CORSO VOTO_SUM: somma dei voti, definita come SUM(VOTO), additiva. VOTO_NUM: numero dei voti (degli esami), definita come COUNT(*), additiva. Per il pattern {DOCENTE,FACOLTA} e sub-pattern SELECT DOCENTE,FACOLTA,VOTO=SUM(VOTO_SUM)/SUM(VOTO_NUM) FROM FACT_TABLE E JOIN DT_CORSO P ON (E.CORSO=P.CORSO) GROUP BY DOCENTE,FACOLTA WITH CUBE 60

61 2.1.2 Con Arco multiplo su CORSO-DOCENTE Eventi Primari del Fatto transazionale, con dimensioni STUDENTE, NP, CORSO Eventi Primari del Fatto temporale, con dimensioni STUDENTE, CORSO {DOCENTE,FACOLTA} e sub-pattern {DOCENTE,CORSO} e sub-pattern I due pattern precedenti devono essere calcolabili e dare lo stesso risultato sia nel caso transazionale che in quello temporale. Si noti la differenza tra VOTO e VOTO_P considerando il docente DA. 61

62 CASO III) Fatto transazionale, con dimensioni STUDENTE, NP, CORSO VOTO: Inteso come voto medio, è una misura di impatto à misura calcolata come SUM(VOTO) / COUNT(*) (oppure SUM(VOTO) / SUM(NUMERO=1)) FACT_TABLE normale : CREATE VIEW FACT_TABLE AS SELECT STUDENTE, NP, CORSO,VOTO FROM ESAME E FACT_TABLE con push-down: VOTO è una misura di impatto à nella FACT TABLE sia valore non pesato che pesato delle componenti CREATE VIEW FACT_TABLE_PD AS SELECT STUDENTE,NP,E.CORSO, DOCENTE, VOTO, VOTO_PESATO=VOTO*PESO, NUMERO_PESATO=PESO FROM FACT_TABLE E JOIN PESO P ON (E.CORSO=P.CORSO) Per la misura VOTO, il pattern {DOCENTE,CORSO} e sub-pattern si ottengono come SELECT DOCENTE,CORSO, VOTO = CASE WHEN GROUPING(DOCENTE)=1 THEN SUM(VOTO_PESATO)/SUM(NUMERO_PESATO) ELSE SUM(VOTO)/COUNT(*)END FROM FACT_TABLE_PD GROUP BY DOCENTE,CORSO WITH CUBE 62

63 CASO III) Fatto transazionale, con dimensioni STUDENTE, NP, CORSO VOTO_P : Inteso come voto medio, è una misura pesata à misura calcolata come SUM(VOTO_PESATO) / SUM(NUMERO_PESATO) FACT_TABLE normale : CREATE VIEW FACT_TABLE AS SELECT STUDENTE, NP, CORSO,VOTO FROM ESAME E FACT_TABLE con push-down: VOTO_P: è una misura pesata à nella FACT TABLE solo valore pesato delle componenti CREATE VIEW FACT_TABLE_PD AS SELECT STUDENTE,NP,E.CORSO, DOCENTE, VOTO_PESATO=VOTO*PESO, NUMERO_PESATO=PESO FROM FACT_TABLE E JOIN PESO P ON (E.CORSO=P.CORSO) Per la misura VOTO_P, il pattern {DOCENTE,CORSO} e sub-pattern si ottengono come SELECT DOCENTE,CORSO, VOTO_P = SUM(VOTO_PESATO)/SUM(NUMERO_PESATO) FROM FACT_TABLE_PD GROUP BY DOCENTE,CORSO WITH CUBE Per semplicità sono state trattate separatamente le due misure, VOTO e VOTO_P. Con entrambe le misure VOTO e VOTO_P la FACT_TABLE_PD dovrà contenere Per VOTO le misure VOTO, VOTO_PESATO e NUMERO_PESATO Per VOTO_P le misure VOTO_PESATO e NUMERO_PESATO Quindi in definitiva la FACT_TABLE_PD deve contenere VOTO, VOTO_PESATO e NUMERO_PESATO. Il pattern {DOCENTE,CORSO} e sub-pattern si ottengono come SELECT DOCENTE,CORSO, VOTO = CASE WHEN GROUPING(DOCENTE)=1 THEN SUM(VOTO_PESATO)/SUM(NUMERO_PESATO) ELSE SUM(VOTO)/COUNT(*)END VOTO_P = SUM(VOTO_PESATO)/SUM(NUMERO_PESATO) FROM FACT_TABLE_PD GROUP BY DOCENTE,CORSO WITH CUBE 63

64 CASO IV) Fatto temporale, con dimensioni STUDENTE, CORSO VOTO: Inteso come voto medio, è una misura di impatto à misura calcolata come VOTO_SUM/ VOTO_NUM dove FACT_TABLE normale: CREATE VIEW FACT_TABLE AS SELECT STUDENTE,CORSO, VOTO_SUM=SUM(VOTO), VOTO_NUM=COUNT(*) FROM ESAME GROUP BY STUDENTE,CORSO VOTO_SUM: somma dei voti, definita come SUM(VOTO), additiva. VOTO_NUM: numero dei voti (degli esami), definita come COUNT(*), additiva. FACT_TABLE con push-down: VOTO: è una misura di impatto à nella FACT TABLE sia valore non pesato che pesato delle componenti CREATE VIEW FACT_TABLE_PD AS SELECT STUDENTE,E.CORSO, DOCENTE, VOTO_SUM, VOTO_NUM, VOTO_P_SUM=VOTO_SUM*PESO, VOTO_P_NUM=VOTO_NUM*PESO FROM FACT_TABLE E JOIN PESO P ON (E.CORSO=P.CORSO) Per il pattern {DOCENTE,FACOLTA} e sub-pattern SELECT DOCENTE,FACOLTA, VOTO = CASE WHEN GROUPING(DOCENTE)= 1 THEN SUM(VOTO_P_SUM)/SUM(VOTO_P_NUM) ELSE SUM(VOTO_SUM)/SUM(VOTO_NUM) END, FROM FACT_TABLE_PD E JOIN DT_CORSO P ON (E.CORSO=P.CORSO) GROUP BY DOCENTE,FACOLTA WITH CUBE 64

65 Fatto temporale, con dimensioni STUDENTE, CORSO VOTO_P : Inteso come voto medio, è una misura pesata à misura calcolata come VOTO_SUM*PESO/ VOTO_NUM *PESO FACT_TABLE normale: CREATE VIEW FACT_TABLE AS SELECT STUDENTE,CORSO, VOTO_SUM=SUM(VOTO), VOTO_NUM=COUNT(*) FROM ESAME GROUP BY STUDENTE,CORSO FACT_TABLE con push-down: VOTO_P: è una misura pesata à nella FACT TABLE solo valore pesato delle componenti CREATE VIEW FACT_TABLE_PD AS SELECT STUDENTE,E.CORSO, DOCENTE, VOTO_P_SUM=VOTO_SUM*PESO, VOTO_P_NUM=VOTO_NUM*PESO FROM FACT_TABLE E JOIN PESO P ON (E.CORSO=P.CORSO) Per il pattern {DOCENTE,FACOLTA} e sub-pattern SELECT DOCENTE,FACOLTA, VOTO_P=SUM(VOTO_P_SUM)/SUM(VOTO_P_NUM) FROM FACT_TABLE_PD E JOIN DT_CORSO P ON (E.CORSO=P.CORSO) GROUP BY DOCENTE,FACOLTA WITH CUBE Con entrambe le misure VOTO e VOTO_P FACT_TABLE_PD con VOTO_SUM,VOTO_NUM,VOTO_P_SUM, VOTO_P_NUM Il pattern {DOCENTE,CORSO} e sub-pattern si ottengono come SELECT DOCENTE,FACOLTA, VOTO = CASE WHEN GROUPING(DOCENTE)= 1 THEN SUM(VOTO_P_SUM)/SUM(VOTO_P_NUM) ELSE SUM(VOTO_SUM)/SUM(VOTO_NUM) END, VOTO_P=SUM(VOTO_P_SUM)/SUM(VOTO_P_NUM) FROM FACT_TABLE_PD E JOIN DT_CORSO P ON (E.CORSO=P.CORSO) GROUP BY DOCENTE,FACOLTA WITH CUBE 65

66 2.2 Esercizio A - Arco multiplo su CORSO-DOCENTE Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale: CITTA(CITTA,STATO) DOCENTE(DOCENTE,CITTA:CITTA) CORSO(CORSO,FACOLTA) PESO(DOCENTE:DOCENTE, CORSO:CORSO,PESO) STUDENTE(MATRICOLA, CITTA:CITTA) ESAME(MATRICOLA:STUDENTE, NUMEROPROG, CORSO:CORSO CFU,VOTO) Viene richiesto di A) Progettazione concettuale : Fatto ESAME con dimensioni {CORSO, STUDENTE,NUMERO_PROG } e misure { VOTO,CFU,SOST, REG}, considerando l arco multiplo su CORSO-DOCENTE. B) Progettazione logica : STAR-SCHEMA con PUSH-DOWN C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. Glossario delle Misure VOTO: Inteso come voto medio, è una misura di impatto, in quanto calcolando la media dei voti per un certo docente si considerano tutti i suoi corsi, indipendentemente dal peso CFU: Inteso come numero di CFU complessivo, è una misura pesata, in quanto calcolando i CFU associati ad un certo docente si considerano tutti i suoi corsi ma con il relativo peso REG: numero di esami registrati : uno studente può fare più volte l esame per lo stesso corso ma per uno studente ed un corso si registra un solo esame, quello con NP maggiore. E una misura pesata. SOST: numero di esami sostenuti: uno studente può sostenere più volte l esame per lo stesso corso. E una misura pesata. 66

67 2.2.1 Schema transazionale Eventi Primari del Fatto transazionale, con dimensioni STUDENTE, NP, CORSO {DOCENTE,FACOLTA} e sub-pattern {DOCENTE,CORSO} e sub-pattern 67

68 Soluzione Progettazione Concettuale STATO CITTA STUDENTE DOCENTE CORSO FACOLTA ESAME CFU VOTO (AVG) SOST REG NP Schema Transazionale. Dipendenza Funzionale {STUDENTE,NP} à CORSO Convergenza/condivisione su CITTA? (vedi CONVERGENZA IN PRESENZA DI ARCHI MULTIPLI) Misure CFU : misura normale additiva, definita come CFU=ESAME.CFU ; misura pesata VOTO: Discussa nel CASO III: 1. misura normale aggregata con AVG, definita come VOTO=ESAME.VOTO; misura di impatto 2. una misura calcolata come SUM(VOTO) / COUNT(*) (oppure SUM(VOTO) / SUM(NUMERO=1)) Verrà usata questa seconda scelta; in questo caso si indica nello schema di fatto che voto è una misura calcolata : (C) VOTO (AVG); l operatore (AVG) indica che la misura calcolata serve per ottenere la media di VOTO. REG: misura normale additiva ; misura pesata. REG è il numero di esami registrati : uno studente può fare più volte l esame per lo stesso corso ma per uno studente ed un corso si registra un solo esame, quello con NP maggiore. Allora REG è definita in questo modo: per un evento primario individuato da (studente,np,corso) la misura REG =1 se e solo se non esiste un altro evento primario individuato da (studente,np,corso) con np > np. Questo calcolo verrà esplicitato in SQL nella fase di alimentazione. SOST: misura definita come conteggio ma considerando il peso ovvero è una misura pesata, quindi a differenza dell esempio dei libri transazionale dove NUMERO era un conteggio ma di impatto, e pertanto definibile come calcolata attraverso COUNT(*) qui SOST è pesata pertanto deve essere codificata nella fact table con push down. In definitiva anche SOST è una misura normale additiva, definita come SOST=1; misura pesata. 68

69 Progettazione Logica : Soluzione con Push-Down Nella progettazione logica con push-down, si deve considerare ciascuna misura ed in base alla tipologia decidere cosa riportare nella FACT_TABLE_PD CFU : misura normale additiva ; misura pesata In FACT_TABLE_PD viene riportato il valore pesato, indicato ancora con CFU REG: misura normale additiva ; misura pesata In FACT_TABLE_PD viene riportato il valore pesato, indicato ancora con REG SOST: misura normale additiva ; misura pesata In FACT_TABLE_PD viene riportato il valore pesato, indicato ancora con SOST VOTO: Inteso come voto medio, è una misura di impatto à misura calcolata come SUM(VOTO) / COUNT(*) (oppure SUM(VOTO) / SUM(NUMERO=1)) Discussa nel CASO III: In FACT_TABLE_PD viene riportato VOTO,VOTO_PESATO e NUMERO_PESATO. Siccome NUMERO coincide con SOST, allora NUMERO_PESATO coincide con il valore pesato di SOST che è già inserito in FACT_TABLE_PD indicato sempre con SOST. Quindi lo star schema risulta essere FACT_TABLE(STUDENTE:DT_STUDENTE,NP, DOCENTE:DT_DOCENTE,CORSO:DT_CORSO CFU, REG, SOST, VOTO, VOTO_PESATO) DT_CORSO(CORSO,FACOLTA) DT_STUDENTE(STUDENTE,CITTA,STATO) DT_DOCENTE(DOCENTE, CITTA,STATO) mentre nello snowflake schema avremo DT_CORSO(CORSO,FACOLTA) DT_STUDENTE(STUDENTE,CITTA:DT_CITTA) DT_CITTA(CITTA,STATO) DT_DOCENTE(DOCENTE,CITTA:DT_CITTA) 69

70 Alimentazione L aspetto caratteristico è il calcolo della misura REG: per uno studente ed un corso si intende registrato un solo esame, l ultimo, ovvero quello con NUMEROPROG maggiore. Si analizza la tabella ESAME: per definire REG si può prima calcolare, per ogni esame il valore NPMAX corrispondente al massimo valore di NP per una certa coppia STUDENTE, CORSO. Quindi NPMAX è un valore che dipende dalle variabili STUDENTE,CORSO, calcolato attraverso la seguente vista. CREATE VIEW V1 AS SELECT STUDENTE, CORSO, NPMAX=MAX(NP) FROM ESAME GROUP BY STUDENTE, CORSO Quindi ad ogni esame si associa il relativo NPMAX effettuando semplicemente un join tra ESAME e V1 su STUDENTE,CORSO CREATE VIEW V2 AS SELECT ESAME.*,NPMAX FROM ESAME JOIN V1 ON (ESAME.STUDENTE=V1.STUDENTE AND ESAME.CORSO = V1.CORSO) Infine, per un certo esame, REG vale 1 se NP coincide con NPMAX, 0 altrimenti: questo calcolo viene fatto nella seguente vista che chiameremo ESAMI_REG CREATE VIEW ESAMI_REG AS SELECT V2.*, REG = CASE WHEN NP=NPMAX THEN 1 ELSE 0 END FROM V2 70

71 Un altro modo per calcolare la misura REG è il seguente: Si definiscono gli esami registrati nella seguente vista CREATE VIEW ESAMIREGISTRATI AS SELECT * FROM ESAME x WHERE NP = ( SELECT MAX(NP) FROM ESAME Y WHERE X.STUDENTE=Y.STUDENTE AND X.CORSO=Y.CORSO) Quindi utilizzando il left join tra ESAME e ESAMIREGISTRATI SELECT * FROM ESAME LEFT JOIN ESAMIREGISTRATI ON ESAMIREGISTRATI.STUDENTE = ESAME.STUDENTE AND ESAMIREGISTRATI.NP = ESAME.NP Se ad un ESAME non corrisponde un ESAMIREGISTRATI allora REG deve essere 0 altrimenti 1; ad un ESAME non corrisponde un ESAMIREGISTRATI se un attributo di ESAMIREGISTRATI (ad esempio ESAMIREGISTRATI.NP ) è NULL, quindi CREATE VIEW ESAMI_REG AS SELECT ESAME.*, REG= CASE WHEN ESAMIREGISTRATI.NP IS NULL THEN 0 ELSE 1 END FROM ESAME LEFT JOIN ESAMIREGISTRATI ON ESAMIREGISTRATI.STUDENTE = ESAME.STUDENTE AND ESAMIREGISTRATI.NP = ESAME.NP 71

72 Per creare la FACT_TABLE_PD si procede come sempre in due passi: FACT_TABLE normale: (si noti che con SOST=1 si aggiunge un campo che vale 1 per tutte le tuple della FACT_TABLE) CREATE VIEW FACT_TABLE AS SELECT STUDENTE,NP, CORSO, CFU, SOST=1, REG, VOTO FROM ESAMI_SOST_REG FACT_TABLE con push-down: CREATE VIEW FACT_TABLE_PD AS SELECT STUDENTE,NP, DOCENTE,E.CORSO, CFU=CFU*PESO, SOST=SOST*PESO, REG=REG*PESO, VOTO, VOTO_PESATO=VOTO*PESO FROM FACT_TABLE E JOIN PESO P ON (E.CORSO=P.CORSO) Per il pattern {DOCENTE,CORSO} e sub-pattern SELECT DOCENTE,CORSO, SOST= SUM(SOST), REG= SUM(REG), CFU= SUM(CFU), VOTO = CASE WHEN GROUPING(DOCENTE)=1 THEN SUM(VOTO_PESATO)/SUM(SOST) ELSE SUM(VOTO)/COUNT(*)END FROM FACT_TABLE_PD GROUP BY DOCENTE,CORSO WITH CUBE ORDER BY GROUPING(DOCENTE) DESC 72

73 2.2.2 Schema temporale Eventi Primari del Fatto transazionale, con dimensioni STUDENTE, CORSO {DOCENTE,FACOLTA} e sub-pattern {DOCENTE,CORSO} e sub-pattern 73

74 Soluzione Progettazione Concettuale STATO CITTA STUDENTE DOCENTE CORSO FACOLTA ESAME CFU (C) VOTO (AVG) SOST REG Schema Temporale. No Dipendenze Funzionali tra le dimensioni. Convergenza/condivisione su CITTA? (vedi CONVERGENZA IN PRESENZA DI ARCHI MULTIPLI) Misure CFU : misura normale additiva, definita come CFU=SUM(ESAME.CFU) ; misura pesata REG: misura normale additiva ; misura pesata. Ricordiamo che REG è il numero di esami registrati : uno studente può fare più volte l esame per lo stesso corso ma per uno studente ed un corso si registra un solo esame, quello con NP maggiore. REG è quindi una misura normale additiva, definita come REG=1; misura pesata. SOST: misura normale additiva, definita come SOST=COUNT(*) ; misura pesata VOTO: misura normale aggregata con AVG, misura di impatto Discussa nel CASO IV: à misura calcolata come VOTO_SUM/ VOTO_NUM dove VOTO_SUM: somma dei voti, definita come SUM(VOTO), additiva. VOTO_NUM: numero dei voti (degli esami), definita come COUNT(*), additiva. à VOTO_NUM coincide con SOST 74

75 Progettazione Logica : Soluzione con Push-Down Nella progettazione logica con push-down, si deve considerare ciascuna misura ed in base alla tipologia decidere cosa riportare nella FACT_TABLE_PD CFU : misura normale additiva ; misura pesata In FACT_TABLE_PD viene riportato il valore pesato, indicato ancora con CFU REG : misura normale additiva ; misura pesata In FACT_TABLE_PD viene riportato il valore pesato, indicato ancora con REG SOST: misura normale additiva ; misura pesata VOTO: In FACT_TABLE_PD viene riportato il valore pesato, indicato ancora con SOST Discussa nel CASO IV: à misura calcolata come VOTO_SUM/ VOTO_NUM dove VOTO_SUM: somma dei voti, definita come SUM(VOTO), additiva. VOTO_NUM: numero dei voti (degli esami), definita come COUNT(*), additiva. è una misura di impatto à nella FACT TABLE sia valore non pesato che pesato delle componenti VOTO_SUM VOTO_NUM VOTO_P_SUM=VOTO_SUM*PESO VOTO_P_NUM=VOTO_NUM*PESO à VOTO_NUM coincide con SOST che è già in FACT_TABLE_PD in forma pesata, cioè VOTO_P_NUM=SOST e quindi non viene introdotta Quindi lo star schema risulta essere FACT_TABLE(STUDENTE:DT_STUDENTE, DOCENTE:DT_DOCENTE,CORSO:DT_CORSO CFU, REG, SOST, VOTO_SUM,VOTO_NUM,VOTO_P_SUM) DT_CORSO(CORSO,FACOLTA) DT_STUDENTE(STUDENTE,CITTA,STATO) DT_DOCENTE(DOCENTE, CITTA,STATO) Rispetto all esercizio precedente non è più necessario effettuare il calcolo della misura REG, in quanto REG=1 per tutti gli eventi primari Per creare la FACT_TABLE_PD procediamo in due passi: FACT_TABLE normale: 75

76 CREATE VIEW FACT_TABLE AS SELECT STUDENTE,CORSO, CFU=SUM(ESAME.CFU), SOST=COUNT(*), REG=1, VOTO_SUM=SUM(VOTO), VOTO_NUM=COUNT(*) FROM ESAME GROUP BY STUDENTE, CORSO FACT_TABLE con push-down: CREATE VIEW FACT_TABLE_PD AS SELECT STUDENTE,E.CORSO, DOCENTE, CFU=CFU*PESO, SOST=SOST*PESO, REG=REG*PESO, VOTO_SUM, VOTO_NUM, VOTO_P_SUM=VOTO_SUM*PESO FROM FACT_TABLE E JOIN PESO P ON (E.CORSO=P.CORSO) Per il pattern {DOCENTE,FACOLTA} e sub-pattern SELECT DOCENTE,FACOLTA, CFU= SUM(CFU), SOST= SUM(SOST), REG= SUM(REG), VOTO = CASE WHEN GROUPING(DOCENTE)=1 THEN SUM(VOTO_P_SUM)/SUM(SOST) ELSE SUM(VOTO_SUM)/SUM(VOTO_NUM) END FROM FACT_TABLE_PD E JOIN DT_CORSO P ON (E.CORSO=P.CORSO) GROUP BY DOCENTE,FACOLTA WITH CUBE Per il pattern {DOCENTE,CORSO} e sub-pattern SELECT DOCENTE,CORSO, CFU= SUM(CFU), SOST= SUM(SOST), REG= SUM(REG), VOTO = CASE WHEN GROUPING(DOCENTE)=1 THEN SUM(VOTO_P_SUM)/SUM(SOST) ELSE SUM(VOTO_SUM)/SUM(VOTO_NUM) END FROM FACT_TABLE_PD GROUP BY DOCENTE,CORSO WITH CUBE 76

77 2.2.3 Aggregabilità delle misure Le misure sono definite in CREATE VIEW FACT_TABLE AS SELECT STUDENTE,CORSO, CFU=SUM(ESAME.CFU), SOST=COUNT(*), REG=1, VOTO_SUM=SUM(VOTO), VOTO_NUM=COUNT(*) FROM ESAME GROUP BY STUDENTE, CORSO Per CFU,SOST,VOTO_SUM e VOTO_NUM, In base alla tipologia degli operatori usati per il calcolo (SUM e COUNT(*)) si può affermare che sono aggregabili (additive) rispetto a tutte e due le dimensioni e questo può essere facilmente verificato sull esempio dato. Per la misura REG, che ha un valore costante: partendo dall esempio si può verificare che è aggregabile (additiva) rispetto a tutte e due le dimensioni. Un modo per verificare l aggregabilità di REG è quello di constatare che in effetti REG equivale ad effettuare un count distinct della coppia STUDENTE, CORSO: possiamo quindi applicare quanto visto sull operatore COUNT DISTINCT Misura M = COUNT (DISTINCT STUDENTE, CORSO) Dimensioni = STUDENTE, CORSO Essendo { STUDENTE, CORSO } à CORSO : M è aggregabile rispetto a CORSO Essendo { STUDENTE, CORSO } à STUDENTE: M è aggregabile rispetto a STUDENTE 77

78 2.3 CONVERGENZA IN PRESENZA DI ARCHI MULTIPLI STATO CITTA STUDENTE DOCENTE CORSO FACOLTA ESAME CFU VOTO (AVG) SOST REG NP Per convergenza su CITTA (su STATO) si intende che la città (lo stato) del docente e dello studente coinvolti in esame coincidono. Nel caso di arco multiplo, questo concetto di convergenza perde di significato e dovrebbe essere esteso: siccome ci sono più docenti che partecipano a ESAME, cosa si intende per convergenza? La coincidenza vale per un docente dell esame OPPURE per tutti i docenti dell esame? Supponiamo (come verificato sull esempio di istanza) che per CITTA ci sia solo condivisione : la città dello studente non è necessariamente la stessa città dei docenti; per STATO ci sia convergenza per tutti i docenti dell esame, ovvero lo stato dello studente è necessariamente la stesso stato di tutti i docenti; e analizziamo cosa accade con i pattern {CITTA_DOCENTE,CITTA_STUDENTE} e sub-pattern. {STATO_DOCENTE,STATO_STUDENTE} e sub-pattern 78

79 Ricordiamo quanto detto sui pattern in presenza di condivisione/convergenza Nel caso di condivisione, non ha senso considerare il pattern {CITTA} in quanto un esame non è associato univocamente ad un unica città (non ha senso considerare un pattern {CITTA} in quanto con la condivisione si rappresentano due citta) Si deve considerare ESAME STUDENTE CITTA {CITTA_STUDENTE, CITTA_DOCENTE } FACOLTA Nel caso di convergenza, Non ha senso considerare {CITTA_STUDENTE, CITTA_DOCENTE } ha senso considerare {CITTA} in quanto un esame è associato univocamente ad un unica città! ESAME STUDENTE CITTA FACOLTA 79

80 Consideriamo il nostro esempio senza Arco Multiplo Istanza del DBO (alcune tabelle / campi sono omessi) STATO CITTA STUDENTE DOCENTE CORSO FACOLTA ESAME CFU (C) VOTO (AVG) SOST REG Un evento primario è associato ad un unico evento secondario, ovvero Un esame è associato ad un unica coppia {CITTA_STUDENTE, CITTA_DOCENTE } ; essendoci condivisione questa coppia può avere elementi diversi Un esame è associato ad un unica coppia {STATO_STUDENTE, STATO_DOCENTE } ; essendoci convergenza questa coppia non può avere elementi diversi, quindi in definitiva un evento primario è associato ad un unico stato, quindi i valori delle misure per i due pattern {STATO_STUDENTE } e { STATO_DOCENTE } coincidono ed ha senso pertanto considerare solo il pattern { STATO }. Per semplicità, si visualizzano i pattern per la sola misura SOST (esami sostenuti) {CITTA_STUDENTE, CITTA_DOCENTE } e sub- pattern {STATO_STUDENTE, STATO_DOCENTE } e sub- pattern Si considera solo {STATO} 80

81 Ripetiamo gli stessi pattern ma in presenza di arco multiplo Istanza del DBO (alcune tabelle / campi sono omessi) STATO CITTA STUDENTE DOCENTE CORSO FACOLTA ESAME CFU VOTO (AVG) SOST REG NP Per semplicità di confronto, si considera la sola misura SOST (esami sostenuti), sia come misura pesata (SOST_P) che come misura d impatto (SOST_I) {CITTA_STUDENTE, CITTA_DOCENTE } e sub- pattern {STATO_STUDENTE, STATO_DOCENTE } e sub- pattern L esempio mette in evidenza che anche supponendo uno convergenza su STATO (lo stato dello studente è necessariamente la stesso stato di tutti i docenti) in presenza di archi multipli i valori di una misura di impatto per i due pattern {STATO_STUDENTE } e { STATO_DOCENTE } non coincidono In {STATO_STUDENTE } : il valore ITALIA esprime che gli studenti italiani hanno sostenuto 2 esami In {STATO_DOCENTE} : il valore ITALIA esprime che i docenti italiani hanno fatto 3 esami. Si noti anche che nel caso di arco multiplo, un evento primario è associato a più eventi secondari, ovvero un esame del corso C2 è associato ad due eventi secondari del pattern {CITTA_STUDENTE, CITTA_DOCENTE} e {STATO_STUDENTE, STATO_DOCENTE } 81

82 Istanza del DBO (alcune tabelle / campi sono omessi) STATO CITTA STUDENTE DOCENTE CORSO FACOLTA ESAME CFU VOTO (AVG) SOST REG NP { STATO_STUDENTE, STATO_DOCENTE, CITTA_DOCENTE, DOCENTE } e sub- pattern Per ottenere { STATO_STUDENTE, STATO_DOCENTE, CITTA_DOCENTE, DOCENTE } e sub- pattern Siccome DOCENTEà CITTA_DOCENTE à STATO_DOCENTE Si deve utilizzare WITH ROLLUP SELECT CS.STATO AS STATO_STUDENTE, CD.STATO AS STATO_DOCENTE, CD.CITTA AS CITTA_DOCENTE, D.DOCENTE AS DOCENTE, SOST_P= SUM(SOST_P), SOST_I = CASE WHEN GROUPING(CD.STATO)=1 THEN SUM(SOST_P) ELSE SUM(SOST_I) END FROM FACT_TABLE_PD E JOIN DT_STUDENTE S ON (E.STUDENTE=S.STUDENTE) JOIN DT_DOCENTE D ON (E.DOCENTE=D.DOCENTE) JOIN DT_CITTA CD ON (CD.CITTA=D.CITTA) JOIN DT_CITTA CS ON (CS.CITTA=S.CITTA) GROUP BY CS.STATO, CD.STATO, CD.CITTA, D.DOCENTE WITH ROLLUP 82

83 2.4 Esercizio B: Arco multiplo su LIBRO-AUTORE (transazionale) Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale: SCONTRINO ANNO AUTORE(AUTORE,CITTA) (1,N) DI PREZZO IDSCONTRINO LIBRO(LIBRO,GENERE) PESO(AUTORE:AUTORE, LIBRO:LIBRO,PESO) NUMERO PROG LIBRO DETTAGLIO VENDITE DEL (1,N) GENERE AUTORE CITTA AUTORE (1,N) PESO SCONTRINO(IDSCONTRINO,ANNO) DETTAGLIO_VENDITE( IDSCONTRINO:SCONTRINO,NUMEROPROG, LIBRO:LIBRO, PREZZO) LIBRO (1,N) PESO Viene richiesto di A) Progettazione concettuale : Fatto VENDITE con dimensioni {SCONTRINO,NP,LIBRO} e misure NUMERO Inteso come numero complessivo delle vendite, è una misura di impatto, INCASSO: Inteso come incasso totale, è una misura pesata, B) Progettazione logica : STAR-SCHEMA con PUSH-DOWN C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP : Riportare e realizzare il reticolo di roll-up del pattern {AUTORE,ANNO}, Riportare e realizzare il reticolo di roll-up del pattern {LIBRO,ANNO}. 83

84 Istanza del DBO Eventi Primari del Fatto VENDITE con dimensioni SCONTRINO, NP, LIBRO Pattern {AUTORE,ANNO} e sub-pattern 84

85 ANNO SCONTRINO CITTA AUTORE LIBRO VENDITE NUMERO INCASSO NP GENERE Lo schema di fatto è TRANSAZIONALE. Dipendenza Funzionale tra le dimensioni {SCONTRINO,NP} à LIBRO Misure INCASSO: misura normale additiva; definita come INCASSO=PREZZO; misura pesata NUMERO: misura calcolata come NUMERO= COUNT(*); misura di impatto Progettazione Logica : Soluzione con Push-down Fact table normale senza arco multiplo: FACT_TABLE(SCONTRINO:DT_SCONTRINO,NP,LIBRO:DT_LIBRO,INCASSO) (manca NUMERO in quanto misura calcolata come NUMERO= COUNT(*)) Arco multiplo - push-down: le misure vengono riportate nella FACT_TABLE_PD in base al seguente schema PATTERN SENZA ATTRIBUTI gerarchia AM CON ATTRIBUTI gerarchia AM MISURA M IMPATTO Valore Pesato M_P Valore non Pesato X X PESATA Valore Pesato M_P X X Nell esempio: NUMERO è di impatto, quindi metteremo sia il suo valore pesato NUMERO_PESATO, che il suo valore non pesato, NUMERO; d altra parte NUMERO vale 1 quindi il suo valore pesato coincide con PESO, mentre il valore non pesato è ancora 1 e non viene riportato nella FACT_TABLE_PD. INCASSO è pesata (quindi metteremo solo il valore pesato, INCASSO_PESATO) : FACT_TABLE_PD(SCONTRINO:DT_SCONTRINO,NP,LIBRO:DT_LIBRO,AUTORE:DT_AUTORE, INCASSO_PESATO,NUMERO_PESATO,NUMERO) DT_SCONTRINO(SCONTRINO,ANNO) DT_LIBRO(LIBRO,GENERE) DT_AUTORE(AUTORE,CITTA) 85

86 Alimentazione : per semplicità avviene in due passi: prima la FACT_TABLE normale e poi FACT_TABLE_PD FACT_TABLE normale : CREATE VIEW FACT_TABLE AS SELECT IDSCONTRINO AS SCONTRINO, NUMEROPROG AS NP, LIBRO, PREZZO AS INCASSO FROM DETTAGLIO_VENDITE FACT_TABLE con push-down: CREATE VIEW FACT_TABLE_PD AS SELECT SCONTRINO,NP,LIBRO, AUTORE, INCASSO_PESATO=INCASSO*PESO, NUMERO_PESATO=PESO FROM FACT_TABLE NATURAL JOIN PESO Ricordiamo che NUMERO = 1 Non è stata riportata SQL-OLAP: Riportare e realizzare il reticolo di roll-up del pattern {AUTORE,ANNO}. Schema di fatto equivalente con push-down ANNO SCONTRINO Il reticolo di roll-up del pattern {AUTORE,ANNO} è semplice {AUTORE, ANNO} LIBRO VENDITE <valori pesati/non pesati delle misure> NP {CITTA} {CITTA, ANNO} {ANNO} GENERE CITTA AUTORE {} 86

87 Realizziamo prima solo una parte di questo pattern in SQL-OLAP, consideriamo il pattern {AUTORE,ANNO} e sub-pattern, cioè non si considera CITTA. Per una misura di impatto il calcolo viene fatto in base allo schema dato in precedenza: WHEN <PATTERN SENZA ATTRIBUTI GERARCHIA AM> THEN <VALORE PESATO> ELSE <VALORE NON PESATO> END In SQL-OLAP la condizione <PATTERN SENZA ATTRIBUTI GERARCHIA AM> equivale ad una congiunzione di GROUPING(A_AM_i)=1 per tutti gli attributi A_AM_i della gerarchia dell arco multiplo. Quindi Il pattern {AUTORE,ANNO} e sub-pattern si ottengono come SELECT AUTORE,ANNO, SUM(INCASSO_PESATO) AS INCASSO, NUMERO= CASE WHEN GROUPING(AUTORE)=1 THEN SUM(NUMERO_PESATO) -- valore pesato ELSE COUNT(*) -- valore non pesato END FROM FACT_TABLE_PD FT JOIN DT_SCONTRINO S ON S.SCONTRINO = FT.SCONTRINO GROUP BY AUTORE,ANNO WITH CUBE Per realizzare il reticolo di roll-up completo del pattern {AUTORE,ANNO} si deve considerare anche CITTA (dalla DT_AUTORE; per semplicità si usa il natural join). La considerazione principale è che anche CITTA è un attributo della gerarchia dell AM, quindi nel calcolo della misura di impatto si deve usare la congiunzione (GROUPING(AUTORE)=1 AND GROUPING(CITTA)=1 ) Infine, siccome AUTORE à CITTA, si aggiunge anche la clausola HAVING SELECT AUTORE,ANNO,CITTA, SUM(INCASSO_PESATO) AS INCASSO, NUMERO= CASE WHEN (GROUPING(AUTORE)=1 AND GROUPING(CITTA)=1 ) THEN SUM(NUMERO_PESATO) -- valore pesato ELSE COUNT(*) -- valore non pesato END FROM FACT_TABLE_PD NATURAL JOIN DT_SCONTRINO NATURAL JOIN DT_AUTORE GROUP BY AUTORE,ANNO,CITTA WITH CUBE HAVING NOT (GROUPING(CITTA)=1 AND GROUPING(AUTORE)=0) SQL-OLAP: Riportare e realizzare il reticolo di roll-up del pattern {LIBRO,ANNO}. Il reticolo di roll-up del pattern {LIBRO,ANNO} nello schema di fatto equivalente con push-down è semplice e non viene riportato; nella sua realizzazione SQL-OLAP, non è interessato nessun attributo della gerarchia dell AM, quindi si usano sempre i valori pesati SELECT LIBRO,ANNO,GENERE, SUM(INCASSO_PESATO) AS INCASSO, NUMERO = SUM(NUMERO_PESATO) FROM FACT_TABLE_PD NATURAL JOIN DT_LIBRO GROUP BY LIBRO,ANNO,GENERE WITH CUBE HAVING NOT (GROUPING(GENERE)=1 AND GROUPING(LIBRO)=0) 87

88 2.4.1 Varianti Variante : aggiungere al precedente schema di fatto la misura INCASSO_MEDIO, calcolata come INCASSO/NUMERO (in altre parole è l incasso medio calcolato considerando come incasso per un certo autore i suoi libri con il relativo peso, e come numero di libri venduti il numero senza peso) Il risultato che si vuole ottenere, ad esempio per {AUTORE,ANNO} e sub-pattern, è mostrato di seguito: Il calcolo di INCASSO_MEDIO si può aggiungere alla precedente query; siccome nel calcolo c è una misura di impatto (NUMERO) si deve differenziare SELECT AUTORE,ANNO, SUM(INCASSO_PESATO) AS INCASSO, NUMERO= CASE WHEN GROUPING(AUTORE)=1 THEN SUM(NUMERO_PESATO) ELSE SUM(NUMERO) END, INCASSO_MEDIO = CASE WHEN GROUPING(AUTORE)=1 THEN SUM(INCASSO_PESATO)/SUM(NUMERO_PESATO) ELSE SUM(INCASSO_PESATO)/SUM(NUMERO) END FROM FACT_TABLE_PD FT JOIN DT_SCONTRINO S ON S.SCONTRINO = FT.SCONTRINO GROUP BY AUTORE,ANNO WITH CUBE Oppure si definisce la precedente query (quella senza INCASSO_MEDIO) come una vista, diciamo AUTORE_ANNO e quindi si calcola INCASSO_MEDIO come INCASSO/NUMERO SELECT AUTORE_ANNO.*, INCASSO_MEDIO = INCASSO/NUMERO FROM AUTORE_ANNO 88

89 Variante : aggiungere al precedente schema di fatto la misura INCASSO_MEDIO, misura pesata, è l incasso medio calcolato considerando come incasso per un certo autore i suoi libri con il relativo peso, e come numero di libri venduti il numero con il relativo peso Il risultato che si vuole ottenere, ad esempio per {AUTORE,ANNO} e sub-pattern, è mostrato di seguito: Pattern {AUTORE,ANNO} e sub-pattern Nella soluzione con push-down, una misura pesata aggregata tramite AVG deve essere definita come à misura calcolata come SUM(INCASSO_PESATO) / SUM(NUMERO_PESATO) quindi INCASSO_MEDIO può essere calcolato con le misure già presenti nella FACT_TABLE_PD, semplicemende applicando la precedente espressione Backup del DBO : Per provare la soluzione di questo Esercizio Per le query SQL-OLAP occorre avere tutto lo schema logico e non solo la FACT_TABLE, cioè occorre avere anche DT_SCONTRINO(SCONTRINO,ANNO) DT_LIBRO(LIBRO,GENERE) DT_AUTORE(AUTORE,CITTA) Quindi occorre prima crearsi le relative view, che in questo caso sono banali, ad esempio: CREATE VIEW DT_SCONTRINO AS SELECT IDSCONTRINO AS SCONTRINO,ANNO FROM SCONTRINO 89

90 2.5 Esercizio C: Arco multiplo su LIBRO-AUTORE (temporale) Consideriamo un DBO con il seguente schema E/R ed il corrispondente schema relazionale: SCONTRINO ANNO AUTORE(AUTORE,CITTA) (1,N) DI PREZZO IDSCONTRINO LIBRO(LIBRO,GENERE) PESO(AUTORE:AUTORE, LIBRO:LIBRO,PESO) NUMERO PROG LIBRO DETTAGLIO VENDITE DEL (1,N) GENERE AUTORE CITTA AUTORE (1,N) PESO SCONTRINO(IDSCONTRINO,ANNO) DETTAGLIO_VENDITE( IDSCONTRINO:SCONTRINO,NUMEROPROG, LIBRO:LIBRO, PREZZO) LIBRO (1,N) PESO Viene richiesto di A) Progettazione concettuale : Fatto VENDITE con dimensioni { LIBRO,ANNO} e misure NUMERO: Inteso come numero delle vendite, è una misura di impatto, INCASSO: Inteso come incasso totale, è una misura pesata, NUMEROCLIENTI Inteso come conteggio distinto degli scontrini, è una misura di impatto. B) Progettazione logica : STAR-SCHEMA con PUSH-DOWN C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP : Riportare e realizzare il reticolo di roll-up del pattern {AUTORE,ANNO}. 90

91 Istanza del DBO Eventi Primari del Fatto VENDITE con dimensioni LIBRO, ANNO 91

92 Soluzione Progettazione Concettuale CITTA AUTORE LIBRO VENDITE NUMERO INCASSO NUMEROCLIENTI ANNO GENERE Temporale. Nessuna Dipendenza Funzionale tra le dimensioni Misure NUMERO: misura normale additiva, definita come NUMERO =COUNT(*) ; misura di impatto, INCASSO: misura normale additiva, definita come INCASSO =SUM(ESAME.CFU) ; misura pesata NUMEROCLIENTI: misura normale additiva, definita come NUMEROCLIENTI =COUNT(DISTINCT IDSCONTRINO) ; misura di impatto, E facile verificare che mentre INCASSO e NUMERO sono additive rispetto ad entrambe le dimensioni, la misura NUMEROCLIENTI è non aggregabile rispetto alla dimensione LIBRO mentre è additiva rispetto alla dimensione ANNO (in quanto IDSCONTRINO à ANNO). Quindi NA = {LIBRO}. Progettazione Logica : Soluzione con Push-Down Nella progettazione logica con push-down, si deve considerare ciascuna misura ed in base alla tipologia decidere cosa riportare nella FACT_TABLE_PD NUMERO: misura normale additiva ; misura di impatto In FACT_TABLE_PD viene riportato il valore pesato (NUMERO_P) e non pesato (NUMERO) INCASSO: misura normale additiva ; misura pesata In FACT_TABLE_PD viene riportato il valore pesato (INCASSO_P) NUMEROCLIENTI: misura normale additiva ; misura di impatto In FACT_TABLE_PD viene riportato il valore pesato (NUMEROCLIENTI _P) e non pesato (NUMEROCLIENTI) Quindi lo star schema risulta essere FACT_TABLE_PD(ANNO,LIBRO:DT_LIBRO, AUTORE: DT_AUTORE NUMERO_P, NUMERO_P, NUMERO_P, NUMEROCLIENTI _P, NUMEROCLIENTI) DT_LIBRO(LIBRO,GENERE) DT_AUTORE(AUTORE,CITTA) 92

93 Alimentazione FACT_TABLE normale: CREATE VIEW FACT_TABLE AS SELECT ANNO, LIBRO, SUM(PREZZO) AS INCASSO, COUNT(*) AS NUMERO, COUNT(DISTINCT SCONTRINO.IDSCONTRINO) AS NUMEROCLIENTI FROM DETTAGLIO_VENDITE JOIN SCONTRINO ON DETTAGLIO_VENDITE.IDSCONTRINO = SCONTRINO.IDSCONTRINO GROUP BY ANNO, LIBRO FACT_TABLE con push-down: CREATE VIEW FACT_TABLE_PD AS SELECT ANNO, P.LIBRO, AUTORE, INCASSO*PESO AS INCASSO_P, NUMERO*PESO AS NUMERO_P, NUMERO, NUMEROCLIENTI*PESO AS NUMEROCLIENTI_P, NUMEROCLIENTI FROM FACT_TABLE F JOIN Peso P ON F.Libro = P.LIBRO 93

94 SQL-OLAP : Riportare e realizzare il reticolo di roll-up del pattern {AUTORE,LIBRO}. Il reticolo è uguale a quello riportato nel precedente esercizio. Per realizzarlo in SQL-OLAP 1) per la presenza di un arco multiplo ed avendo usato la soluzione con push-down: si deve effettuare il controllo e quindi il calcolo per le misure di impatto 2) per la presenza di una non aggregabilità si deve effettuare il relativo controllo Si vuole ottenere è il seguente risultato (si mostra solo {AUTORE,ANNO} e sub-pattern): Per la misura di impatto NUMERO si procede come nell esercizio precedente secondo lo schema WHEN <PATTERN SENZA ATTRIBUTI GERARCHIA AM> THEN <VALORE PESATO> ELSE <VALORE NON PESATO> END quindi considerato che gli attributi della gerarchia dell AM sono AUTORE e CITTA NUMERO = CASE WHEN (GROUPING(AUTORE)=1 AND GROUPING(CITTA)=1 ) THEN SUM(NUMERO_P) ELSE SUM(NUMERO) END Il caso particolare è la misura di impatto NUMCLIENTI che risulta anche non aggregabile rispetto alla dimensione LIBRO, quindi nel calcolo si deve effettuare il relativo controllo GROUPING(LIBRO)=1 : NUMEROCLIENTI = CASE WHEN (GROUPING(AUTORE)=1 AND GROUPING(CITTA)=1 ) THEN CASE WHEN GROUPING(LIBRO)=1 THEN SUM(NUMEROCLIENTI_P) + '(NA)' a meno del casting ELSE SUM(NUMEROCLIENTI_P) END ELSE CASE WHEN GROUPING(LIBRO)=1 THEN SUM(NUMEROCLIENTI) + '(NA)' a meno del casting ELSE SUM(NUMEROCLIENTI) END END Complessivamente la query SQL- OLAP risulta 94

95 select L.LIBRO, CITTA,A.AUTORE, INCASSO=SUM(INCASSO_P), NUMERO = CASE (GROUPING(A.AUTORE)=1 AND GROUPING(CITTA)=1 ) THEN SUM(NUMERO_P) ELSE SUM(NUMERO) END, NUMEROCLIENTI = CASE WHEN (GROUPING(A.AUTORE)=1 AND GROUPING(CITTA)=1 ) THEN CASE WHEN GROUPING(L.LIBRO)=1 THEN CONVERT(CHAR(10),SUM(NUMEROCLIENTI_P)) + '(NA)' ELSE CONVERT(CHAR(10),SUM(NUMEROCLIENTI_P)) END ELSE CASE WHEN GROUPING(L.LIBRO)=1 THEN CONVERT(CHAR(10),SUM(NUMEROCLIENTI)) + '(NA)' ELSE CONVERT(CHAR(10),SUM(NUMEROCLIENTI)) END END FROM FACT_TABLE_PD F JOIN JOIN AUTORE A ON A.AUTORE=F.AUTORE GROUP BY L.LIBRO,A.AUTORE, CITTA WITH CUBE HAVING NOT (GROUPING(CITTA)=1 AND GROUPING(A.AUTORE)=0) 95

96 2.6 Esercizio (ESAME con arco multiplo GRUPPO-STUDENTE) DI ESAME STUDENTE NUMES (T,E) ESAME DI (1,N) DATA SEDE: un CDS (CorsoDiStudio) ha sede in una FACOLTA DEL tra DOCENTE e CDS: un DOCENTE è di un CDS CON tra APPELLO e DOCENTE: un APPELLO è con DOCENTE che lo tiene Attributo TIPO_ESAME di ESAME : assume il valore STUD se è un esame di uno studente ed il valore GRUP se è un esame di un gruppo NUMES è un identificatore di ESAME (chiave alternativa nello schema relazionale): è un numero progressivo univoco dell esame. FACOLTA(FACOLTA,REGIONE) CDS(CDS,FACOLTA:FACOLTA,STUDENTE:STUDENTE) DOCENTE(DOCENTE,FACOLTA:FACOLTA,CDL:CDL) STUDENTE(STUDENTE, FACOLTA:FACOLTA) APPELLO(APPELLO,DOCENTE:DOCENTE, GENERE) ESAME(NUMES, APPELLO:APPELLO, DATA, TIPO_ESAME, VOTO) AK: NUMES ESAMEGRUPPO(NUMES:ESAME, GRUPPO:GRUPPO) ESAMESTUDENTE(NUMES:ESAME, STUDENTE:STUDENTE) GRUPPO(GRUPPO,TIPO) STUDENTE (1,N) PESO (1,N) GRUPPO TIPO (0,N) GRUPPO (1,N) DEL ESAME GRUPPO VOTO TIPO_ESAME (STUD/GRUP) PESO STUDENTE (0,N) RAPPRES ENTANTE CDS (1,N) ARCO MULTIPLO ISCRI TTO SEDE DEL (0,N) GENERE (0,N) REGIONE FACOLTA (0,N) AFFERENZA DOCENTE (1,N) CON APPELLO tra GRUPPO e STUDENTE che rappresenta il fatto che un GRUPPO è costituito da più studenti e che ogni studente ha nel gruppo un certo PESO Per indicare lo studente che ha sostenuto un esame di gruppo useremo il termine studente_gruppo Allo schema relazionale si aggiunge la relazione PESO(GRUPPO:GRUPPO,STUDENTE:STUDENTE,PESO) Viene richiesto di: A) Progettazione concettuale :Progettazione dello schema di fatto ESAME con dimensioni { CDL,STUDENTE,GRUPPO,TIPOESAME,DATA } dove STUDENTE è lo STUDENTE che ha sostenuto l esame (esame sostenuto dal singolo studente) GRUPPO è il GRUPPO che ha sostenuto l esame misure VOTO_MEDIO: è il voto medio dell esame, misura pesata NUM_TOTALE: è il numero totale degli esami, misura di impatto B) Progettazione logica : Progettazione dello SNOWFLAKE SCHEMA (soluzione con push-down) C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP : 1. Usando lo SNOWFLAKE schema, scrivere una query SQL-OLAP per ottenere i pattern {} e {STUDENTE,STUDENTEGRUPPO} per tutte le misure (vedi esempio dietro) 96

97 ESAME ESAMESTUDENTE ESAMEGRUPPO APPELLO Genere è omesso. PESO Eventi Primari del Fatto ESAME con dimensioni GRUPPO, STUDENTE, TIPOESAME, DATA, CDL pattern {} e {STUDENTE,STUDENTEGRUPPO} : La prima (seconda) tupla dice che lo studente 10 (20) ha fatto 3 (3) esami singolarmente riportando ( ) come voto medio: in tale tuple si usa 9999 come valore fittizio di STUDENTEGRUPPO. La terza (quarte) tupla dice che lo studente 10 (20) ha fatto 6 (2) esami di gruppo riportando 18 (30) come voto medio: in tale tuple si usa 9999 come valore fittizio di STUDENTE. 97

98 Soluzione Progettazione Concettuale Lo schema di fatto è una semplificazione di quello precedente in quanto l attributo dimensionale DOCENTE viene eliminato e si considera solo CDL (quindi CDL è innestato sulla radice dell albero) La particolarità è l arco multiplo tra STUDENTE e GRUPPO (CDS è un sinonimo di CDL) REGIONE FACOLTA CDS STUDENTE T,E ESAME (C) VOTO_MEDIO DATA TIPO GRUPPO NUM_TOTALE TIPO_ESAME Dalle specifiche si rileva che interessa considerare il concetto di studente_gruppo, cioè degli esami sostenuti dagli studenti appartenenti ai gruppi. Si conclude quindi che nell arco multiplo GRUPPO è il padre e STUDENTE è il figlio (questo era deducibile anche ai valori dati nella tabella PESO: un esame di gruppo è assegnato in percentuale ai partecipanti del gruppo, la somma su un gruppo è unitaria) Le particolarità di questo arco multiplo sono le seguenti 1) il padre GRUPPO è una dimensione opzionale 2) il figlio STUDENTE è un attributo dimensionale condiviso: per questo motivo non viene chiamato semplicemente STUDENTE ma STUDENTE_GRUPPO Fatta questa constatazione il progetto segue l iter normale : Fatto ESAME(NUMES, CA:APPELLO, DATA, TIPO_ESAME, VOTO) AK : NUMES Dimensioni = { CDL,STUDENTE,GRUPPO,TIPOESAME,DATA } Granularità : Temporale Dipendenze funzionali tra le dimensioni: STUDENTE à TIPOESAME GRUPPO à TIPOESAME Misure normali : NUM_TOTALE= COUNT(*), additiva, Misura di impatto Misure calcolate : VOTO_MEDIO = VOTO_SUM/ VOTO_COUNT. Misura Pesata dove VOTO_SUM = SUM(VOTO) VOTO_COUNT = COUNT(*) Fact Table FACT_TABLE(DATA,GRUPPO,STUDENTE,CDL,TIPOESAME, VOTO_SUM, VOTO_COUNT,NUM_TOTALE) 98

99 Progettazione Logica Per scrivere FACT_TABLE_PD ricordiamo che VOTO_MEDIO è pesata mentre NUM_TOTALE è di impatto FACT_TABLE_PD(DATA,GRUPPO:DTGRUPPO,STUDENTE:DTSTUDENTE, CDL:DTCDS, TIPOESAME,STUDENTEGRUPPO:DTSTUDENTE VOTO_SUM_P,VOTO_COUNT_P,NUM_TOTALE_P,NUM_TOTALE_NP) STARSCHEMA: DTGRUPPO(GRUPPO,TIPO) DTSTUDENTE(STUDENTE, FACOLTA, FACOLTA_REGIONE, FACOLTA_STATO) DTCDS(CDL, FACOLTA, FACOLTA_REGIONE, FACOLTA_STATO, STUDENTE, STUDENTE_FACOLTA, STUDENTE_FACOLTA_REGIONE, STUDENTE_FACOLTA_STATO,) SNOWFLAKE DTFACOLTA(FACOLTA,REGIONE:DTREGIONE) DTCDS(CDL,FACOLTA:DTFACOLTA,STUDENTE:DTSTUDENTE) DTSTUDENTE(STUDENTE, FACOLTA:DTFACOLTA) Alimentazione Si utilizza quanto già fatto nel punto senza arco-multiplo (cioè la VIEW1), cambia solo il raggruppamento e le misure ed inoltre occorre il join con DOCENTE per prendere il CDL CREATE VIEW FACT_TABLE AS SELECT GRUPPO,STUDENTE,TIPOESAME,DATA,CDL, COUNT(*) AS NUM_TOTALE, SUM(VOTO) AS VOTO_SUM, COUNT(VOTO) AS VOTO_COUNT FROM VIEW1 JOIN APPELLO ON VIEW1.CA = APPELLO.CA JOIN DOCENTE ON DOCENTE.DOCENTE = APPELLO.DOCENTE GROUP BY GRUPPO, CDL, STUDENTE, TIPOESAME,DATA Quindi la FACT_TABLE_PD CREATE VIEW FACT_TABLE_PD AS SELECT P.GRUPPO,F.STUDENTE,TIPOESAME,DATA,CDL, P.STUDENTE AS STUDENTEGRUPPO, VOTO_SUM_P= VOTO_SUM * PESO, VOTO_COUNT_P= VOTO_COUNT * PESO, NUM_TOTALE_P= NUM_TOTALE * PESO, NUM_TOTALE_NP = NUM_TOTALE FROM FACT_TABLE F JOIN PESO P ON F.GRUPPO= P.GRUPPO 99

100 D) SQL-OLAP : A) Usando lo SNOWFLAKE schema, scrivere una (singola) query SQL-OLAP per ottenere i pattern {} e {STUDENTE,STUDENTEGRUPPO} per tutte le misure Ricordiamoci che STUDENTEGRUPPO è nella gerarchia dell arco multiplo, quindi occorre differenziare il calcolo delle misure di impatto: SELECT STUDENTE, STUDENTEGRUPPO, VOTO_MEDIO = SUM(VOTO_SUM_P)/SUM(VOTO_COUNT_P), NUM_TOTALE = CASE WHEN GROUPING(STUDENTEGRUPPO)=1 THEN SUM(NUM_TOTALE_P) ELSE SUM(NUM_TOTALE_NP) END FROM FACT_TABLE_PD GROUP BY STUDENTE, STUDENTEGRUPPO WITH CUBE HAVING ( GROUPING(STUDENTEGRUPPO)=1 and GROUPING(STUDENTE)=1 OR GROUPING(STUDENTEGRUPPO)=0 and GROUPING(STUDENTE)=0) NOTA: la particolarità di questo esercizio - che si riflette poi nel risultato ottenuto nella query OLAP - è la presenza di un arco multiplo su una dimensione OPZIONALE: Essendo l arco multiplo utilizzato su una dimensione opzionale, nella tabella PESO si deve inserire anche la composizione del gruppo fittizio 9999 cioè si deve inserire una tupla (9999,9999,1) : il gruppo fittizio 9999 è costituito da un solo (quindi peso unitario) studente fittizio

101 B) Usando lo SNOWFLAKE schema, scrivere una query SQL-OLAP per ottenere {STUDENTEGRUPPO, TIPOESAME} e sub-pattern per tutte le misure E simile a quella scritta in precedenza, basta sostituire STUDENTE con TIPOESAME. La particolarità di questo pattern è la domanda: STUDENTEGRUPPO à TIPOESAME??? Uno STUDENTEGRUPPO è associato a più gruppi, però ogni gruppo ha TIPOESAME= GRUP Lo STUDENTEGRUPPO fittizio 9999 è associato al gruppo fittizio 9999, che ha TIPOESAME= STUD Quindi vale la FD: STUDENTEGRUPPO à TIPOESAME! Pertanto {STUDENTEGRUPPO, TIPOESAME} non è un pattern; nel realizzare {STUDENTEGRUPPO, TIPOESAME} e sub-pattern si tiene conto della FD: SELECT TIPOESAME, STUDENTEGRUPPO, VOTO_MEDIO = SUM(VOTO_SUM_P)/SUM(VOTO_COUNT_P), NUM_TOTALE = CASE WHEN GROUPING(STUDENTEGRUPPO)=1 THEN SUM(NUM_TOTALE_P) ELSE SUM(NUM_TOTALE_NP) END FROM FACT_TABLE_PD GROUP BY TIPOESAME, STUDENTEGRUPPO WITH CUBE HAVING NOT ( GROUPING(TIPOESAME)=1 AND GROUPING(STUDENTEGRUPPO)=0) 101

102 2.6.1 Variante con ATTRIBUTO CROSS-DIMENSIONALE Consideriamo anche il concetto di CORSO (inteso come insegnamento) e di PianoDiStudi (PDS) di uno studente che indica se per uno STUDENTE un certo CORSO e di TIPO= ASCELTA oppure OBBLIG. CORSO CORSO (1,N) PDS TIPO DEL APPELLO Nel seguito, per non confonderci, chiameremo TIPO di PDS come TIPOPSD (1,N) STUDENTE Nello schema relazionale si aggiunge CORSO, si mette la sua FK in APPELLO e quindi si aggiunge PDS APPELLO(CA,DOCENTE:DOCENTE, GENERE, CORSO:CORSO) CORSO(CORSO) PDS(CORSO:CORSO,STUDENTE:STUDENTE, TIPOPDS) A) Progettazione concettuale :Progettazione dello schema di fatto ESAME con dimensioni { CDL,STUDENTE,GRUPPO,TIPOESAME,CORSO } dove STUDENTE è lo STUDENTE che ha sostenuto l esame (esame sostenuto dal singolo studente) GRUPPO è il GRUPPO che ha sostenuto l esame E stata considerata anche la dimensione CORSO in modo da coinvolgere TIPOPDS : REGIONE FACOLTA CDS STUDENTE T,E ESAME (C) VOTO_MEDIO DATA TIPO GRUPPO NUM_TOTALE TIPO_ESAME TIPOPDS CORSO Fatto ESAME(NUMES, CA:APPELLO, DATA, TIPO_ESAME, VOTO) AK : NUMES Dimensioni = { CDL,STUDENTE,GRUPPO,TIPOESAME,CORSO } Granularità : Temporale Dipendenze funzionali tra le dimensioni: STUDENTE à TIPOESAME GRUPPO à TIPOESAME Misure normali NUM_TOTALE= COUNT(*), additiva, Misura di impatto Misure calcolate VOTO_MEDIO = VOTO_SUM/ VOTO_COUNT. Misura Pesata dove VOTO_SUM = SUM(VOTO) VOTO_COUNT = COUNT(*) Fact Table FACT_TABLE(DATA,GRUPPO,STUDENTE,CDL,TIPOESAME, CORSO, VOTO_SUM, VOTO_COUNT,NUM_TOTALE) 102

103 Progettazione Logica La dimensione CORSO è degenere, quindi si aggiunge semplicemente alla FACT_TABLE_PD FACT_TABLE_PD(DATA,GRUPPO:DTGRUPPO,STUDENTE:DTSTUDENTE,CORSO, CDL:DTCDS, TIPOESAME,STUDENTEGRUPPO:DTSTUDENTE VOTO_SUM_P,VOTO_COUNT_P,NUM_TOTALE_P,NUM_TOTALE_NP) Gli schemi logici (STAR e SNOWFLAKE schema) restano invariati; per l attributo cross-dimensionale si deve aggiungere (ad entrambi) una dimension Table DTTIPOPDS(STUDENTE:DTSTUDENTE,CORSO,TIPOPDS) Alimentazione Si deve semplicemente aggiungere CORSO, prendendolo dalla tabella APPELLO CREATE VIEW FACT_TABLE AS SELECT GRUPPO,STUDENTE,TIPOESAME,DATA,CDL, CORSO, COUNT(*) AS NUM_TOTALE, SUM(VOTO) AS VOTO_SUM, COUNT(VOTO) AS VOTO_COUNT FROM VIEW1 JOIN APPELLO ON VIEW1.CA = APPELLO.CA JOIN DOCENTE ON DOCENTE.DOCENTE = APPELLO.DOCENTE GROUP BY GRUPPO, CDL, STUDENTE, TIPOESAME,DATA,CORSO CREATE VIEW FACT_TABLE_PD AS SELECT P.GRUPPO,F.STUDENTE,TIPOESAME,DATA,CDL,CORSO, P.STUDENTE AS STUDENTEGRUPPO, VOTO_SUM_P= VOTO_SUM * PESO, VOTO_COUNT_P= VOTO_COUNT * PESO, NUM_TOTALE_P= NUM_TOTALE * PESO, NUM_TOTALE_NP = NUM_TOTALE FROM FACT_TABLE F JOIN PESO P ON F.GRUPPO= P.GRUPPO SQL-OLAP : Per poter fare un analisi rispetto ad un attributo cross-dimensionale, ad esempio per considerare il pattern {TIPOPDS}, ad ogni evento primario devo associare il relativo TIPOPDS: Per far questo devo fare il join con la dimension table relativa DTTIPOPDS, considerando entrambe le chiavi di DTTIPOPDS SELECT TIPOPDS, VOTO_MEDIO = SUM(VOTO_SUM_P)/SUM(VOTO_COUNT_P), NUM_TOTALE = SUM(NUM_TOTALE_P) FROM FACT_TABLE_PDS JOIN DTTIPOPDS DTS ON (DTS.STUDENTE=FT.STUDENTE AND DTS.CORSO=FT.CORSO) GROUP BY TIPOPDS WITH CUBE Oppure più semplicemente attraverso natural join: FROM FACT_TABLE_PDS NATURAL JOIN DTTIPOPDS 103

104 PROVA SCRITTA - DICEMBRE 2011 Codice SQL Codice SQL per Generare il DBO CREATE TABLE [ESAME]([NUMES] [INT],[DATA] [INT],[CA] [INT],[TIPOESAME] [CHAR] (5), [VOTO] [INT]) CREATE TABLE [ESAMEGRUPPO] ([NUMES] [INT],[GRUPPO] [INT]) CREATE TABLE [ESAMESTUDENTE] ( [NUMES] [INT],[STUDENTE] [INT]) CREATE TABLE [APPELLO] ([CA] [INT], [DOCENTE] [INT], [GENERE] [CHAR] (10)) CREATE TABLE [CDL] ( [CDL] [INT], [STUDENTE] [INT], [FACOLTA] [CHAR] (10) ) CREATE TABLE [DATA] ( [DATA] [INT], [MESE] [INT], [ANNO] [INT] ) CREATE TABLE [DOCENTE] ([DOCENTE] [INT],[FACOLTA] [CHAR] (10), [CDL] [INT], [SESSO] [CHAR] (2) ) CREATE TABLE [FACOLTA] ([FACOLTA] [CHAR] (10),[REGIONE] [CHAR] (10), [STATO] [CHAR] (10) ) CREATE TABLE [GRUPPO] ( [GRUPPO] [INT], [TIPO] [CHAR] (10) ) CREATE TABLE [PESO] ([GRUPPO] [INT],[STUDENTE] [INT], [PESO] [FLOAT] ) CREATE TABLE [STUDENTE] ([STUDENTE] [INT], [FACOLTA] [CHAR] (10) ) INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 1,1,1,'GRUP ',10 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 2,1,2,'GRUP ',20 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 3,1,3,'GRUP ',10 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 4,2,1,'GRUP ',30 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 5,2,2,'GRUP ',30 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 6,2,3,'GRUP ',20 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 7,1,1,'STUD ',10 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 8,1,2,'STUD ',10 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 9,1,3,'STUD ',30 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 10,2,1,'STUD ',30 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 11,4,2,'STUD ',30 INSERT ESAME ( NUMES,DATA,CA,TIPOESAME,VOTO ) SELECT 12,5,2,'STUD ',10 INSERT ESAMESTUDENTE ( NUMES,STUDENTE ) SELECT 7,20 INSERT ESAMESTUDENTE ( NUMES,STUDENTE ) SELECT 8,20 INSERT ESAMESTUDENTE ( NUMES,STUDENTE ) SELECT 9,20 INSERT ESAMESTUDENTE ( NUMES,STUDENTE ) SELECT 10,10 INSERT ESAMESTUDENTE ( NUMES,STUDENTE ) SELECT 11,10 INSERT ESAMESTUDENTE ( NUMES,STUDENTE ) SELECT 12,10 INSERT ESAMEGRUPPO ( NUMES,GRUPPO ) SELECT 1,10 INSERT ESAMEGRUPPO ( NUMES,GRUPPO ) SELECT 2,10 INSERT ESAMEGRUPPO ( NUMES,GRUPPO ) SELECT 3,10 INSERT ESAMEGRUPPO ( NUMES,GRUPPO ) SELECT 4,20 INSERT ESAMEGRUPPO ( NUMES,GRUPPO ) SELECT 5,20 INSERT ESAMEGRUPPO ( NUMES,GRUPPO ) SELECT 6,10 INSERT GRUPPO ( GRUPPO,TIPO ) SELECT 10,'A ' INSERT GRUPPO ( GRUPPO,TIPO ) SELECT 20,'B ' INSERT PESO ( GRUPPO,STUDENTE,PESO ) SELECT 10,10,1 INSERT PESO ( GRUPPO,STUDENTE,PESO ) SELECT 20,10,0.5 INSERT PESO ( GRUPPO,STUDENTE,PESO ) SELECT 20,20,0.5 INSERT PESO ( GRUPPO,STUDENTE,PESO ) SELECT 9999,9999,1 INSERT DATA ( DATA,MESE,ANNO ) SELECT 1,1,10 INSERT DATA ( DATA,MESE,ANNO ) SELECT 2,2,10 INSERT DATA ( DATA,MESE,ANNO ) SELECT 3,2,10 INSERT DATA ( DATA,MESE,ANNO ) SELECT 4,1,10 INSERT DATA ( DATA,MESE,ANNO ) SELECT 5,1,10 INSERT APPELLO ( CA,DOCENTE,GENERE ) SELECT 1,110,NULL INSERT APPELLO ( CA,DOCENTE,GENERE ) SELECT 2,210,NULL INSERT APPELLO ( CA,DOCENTE,GENERE ) SELECT 3,210,NULL INSERT CDS ( CDL,STUDENTE,FACOLTA ) SELECT 10,10,'MUSICA ' INSERT CDS ( CDL,STUDENTE,FACOLTA ) SELECT 20,20,'LETTERE ' INSERT CDS ( CDL,STUDENTE,FACOLTA ) SELECT 30,20,'MUSICA ' INSERT STUDENTE ( STUDENTE,FACOLTA ) SELECT 10,'MUSICA ' INSERT STUDENTE ( STUDENTE,FACOLTA ) SELECT 20,'LETTERE ' INSERT STUDENTE ( STUDENTE,FACOLTA ) SELECT 9999,'9999 ' INSERT FACOLTA ( FACOLTA,REGIONE,STATO ) SELECT '9999 ','9999 ','9999 ' INSERT FACOLTA ( FACOLTA,REGIONE,STATO ) SELECT 'AGRARIA ','ER ','ITALIA ' INSERT FACOLTA ( FACOLTA,REGIONE,STATO ) SELECT 'LETTERE ','LUCANIA ','ITALIA ' INSERT FACOLTA ( FACOLTA,REGIONE,STATO ) SELECT 'MUSICA ','ER ','ITALIA ' INSERT DOCENTE ( DOCENTE,FACOLTA,CDL,SESSO ) SELECT 110,'MUSICA ',20,'M ' INSERT DOCENTE ( DOCENTE,FACOLTA,CDL,SESSO ) SELECT 210,'LETTERE ',30,'F ' 104

105 Codice SQL per Generare il DataMart -- STARSCHEMA CREATE VIEW DT_GRUPPO AS SELECT * FROM GRUPPO CREATE VIEW STARSCHEMA_DTSTUDENTE AS SELECT STUDENTE.*, REGIONE,STATO FROM STUDENTE JOIN FACOLTA ON FACOLTA.FACOLTA = STUDENTE.FACOLTA CREATE VIEW DT_DOCENTE AS SELECT DOCENTE.DOCENTE, DOCENTE.SESSO, CDL.CDL AS CDL, FACOLTA_STUDENTE_RAPPRESENTANTE.STATO AS CDL_STUDENTE_FACOLTA_STATO, FACOLTA_STUDENTE_RAPPRESENTANTE.REGIONE AS CDL_STUDENTE_FACOLTA_REGIONE, FACOLTA_STUDENTE_RAPPRESENTANTE.FACOLTA AS CDL_STUDENTE_FACOLTA, STUDENTE_RAPPRESENTANTE.STUDENTE AS CDL_STUDENTE, FACOLTA_CDL.FACOLTA AS CDL_FACOLTA, FACOLTA_CDL.REGIONE AS CDL_FACOLTA_REGIONE, FACOLTA_CDL.STATO AS CDL_FACOLTA_STATO, FACOLTA_DOCENTE.FACOLTA AS FACOLTA, FACOLTA_DOCENTE.REGIONE AS FACOLTA_REGIONE, FACOLTA_DOCENTE.STATO AS FACOLTA_STATO FROM STUDENTE STUDENTE_RAPPRESENTANTE JOIN CDL ON STUDENTE_RAPPRESENTANTE.STUDENTE = CDL.STUDENTE JOIN FACOLTA FACOLTA_CDL ON FACOLTA_CDL.FACOLTA = CDL.FACOLTA JOIN DOCENTE ON CDL.CDL = DOCENTE.CDL JOIN FACOLTA FACOLTA_DOCENTE ON DOCENTE.FACOLTA = FACOLTA_DOCENTE.FACOLTA JOIN FACOLTA FACOLTA_STUDENTE_RAPPRESENTANTE ON STUDENTE_RAPPRESENTANTE.FACOLTA = FACOLTA_STUDENTE_RAPPRESENTANTE.FACOLTA -- SNOWFLAKE SCHEMA CREATE VIEW DT_FACOLTA AS SELECT * FROM FACOLTA CREATE VIEW DT_GRUPPO AS SELECT * FROM GRUPPO CREATE VIEW DT_DOCENTE AS SELECT * FROM DOCENTE CREATE VIEW DT_CDL AS SELECT * FROM CDL CREATE VIEW EVENTIPRIMARI2 AS SELECT GRUPPO,STUDENTE,TIPOESAME,DATA,CDL AS CDL, SUM(CAST(VOTO AS FLOAT))/COUNT(*) AS VOTO_MEDIO, COUNT(APPELLO.CA) AS NUM_TOTALE FROM VIEW1 JOIN APPELLO ON VIEW1.CA = APPELLO.CA JOIN DOCENTE ON DOCENTE.DOCENTE = APPELLO.DOCENTE GROUP BY VIEW1.GRUPPO, CDL, VIEW1.STUDENTE, TIPOESAME, DATA CREATE VIEW FACT_TABLE2 AS SELECT GRUPPO,STUDENTE,TIPOESAME,DATA,CDL AS CDL, COUNT(*) AS NUM_TOT, SUM(VOTO) AS VOTO_TOT FROM VIEW1 INNER JOIN APPELLO ON VIEW1.CA = APPELLO.CA INNER JOIN DOCENTE ON DOCENTE.DOCENTE = APPELLO.DOCENTE GROUP BY VIEW1.GRUPPO, CDL, VIEW1.STUDENTE, TIPOESAME, DATA 105

106 2.7 Arco multiplo GRUPPO-STUDENTE Con rifermento all Esercizio (ESAME con arco multiplo GRUPPO-STUDENTE), si consideri il sotto-schema ESAME_GRUPPO(DOCENTE,DATA, APPELLO,VOTO,GRUPPO) con FD: APPELLO à DOCENTE GRUPPO(GRUPPO,STUDENTE,PESO) si considerano le seguenti misure NT_IMPATTO=SUM(CASE WHEN VOTO=30 THEN 1 ELSE 0 END) Come misura di impatto: un voto 30 di un gruppo viene conteggiato per tutti gli studenti del gruppo, indipendentemente dal peso di uno studente nel gruppo. NT_PESATA =SUM(CASE WHEN VOTO=30 THEN PESO ELSE 0 END) Come misura pesata: un voto 30 di un gruppo viene conteggiato per tutti gli studenti del gruppo, in base al peso dello studente nel gruppo. NA_IMPATTO = COUNT(DISTINCT APPELLO) Solo come misura di impatto; infatti NA serve per contare la presenza di uno studente ad un appello, quindi equivale a sommare una misura con valore binario 1 (presenza: cioè lo studente è in almeno un gruppo che ha sostenuto un esame di quell appello) e 0 (assenza: cioè lo studente non è in nessun gruppo che ha sostenuto un esame di quell appello) Vengono quindi considerati i seguenti 5 Schemi di Fatto con dimensioni 1. {GRUPPO } 2. {GRUPPO,APPELLO} 3. {DOCENTE, GRUPPO } 4. {DOCENTE, DATA, GRUPPO } 5. {DOCENTE, DATA, GRUPPO,APPELLO} E per ciascun caso viene richiesto di 1. Delineare lo schema, dire se transazionale/temporale, individuare le FD tra le dimensioni 2. Definizione ed aggregabilità delle tre misure (NT_IMPATTO, NT_PESATA, NA_IMPATTO) 3. Alimentazione : scrivere le view FACT_TABLE e FACT_TABLE_PD 4. Delineare e realizzare il reticolo di roll- up di {GRUPPO, STUDENTE} 5. Delineare e realizzare pattern significativi Verranno successivamente considerati Schemi di Fatto in cui STUDENTE è una dimensione. Nella soluzione vengono dati solo i risultati, lasciando al lettore la realizzazione delle query SQL (nell alimentazione per la realizzazione della FACT_TABLE e FACT_TABLE_PD, per le query SQL- OLAP). Si noti che è possibile usare l operatore COUN(DISTINCT...) in una query di raggruppamento WITH CUBE, solo in SQL SERVER 2005 e successivi, non in SQL SERVER

107 2.7.1 Dimensioni = { GRUPPO } Schema temporale, FD: nessuna. Misure: NA = COUNT(DISTINCT APPELLO), solo di impatto E una misura normale non aggregabile rispetto a GRUPPO (NonAgg = {GRUPPO}) quindi di fatto non aggregabile rispetto a nessuna dimensione. NT=SUM(CASE WHEN VOTO=30 THEN 1 ELSE 0 END) normale, additiva, sia di impatto che pesata Eventi primari = FACT_TABLE FACT_TABLE_PD Il reticolo di roll- up {GRUPPO,STUDENTE} è il classico cuboide con 2- dimensioni; per la realizzazione si procede come nel caso del pattern {L.LIBRO, CITTA,A.AUTORE} Dimensioni = { GRUPPO,APPELLO } Schema temporale, FD: nessuna. Misure: NA = COUNT(DISTINCT APPELLO), solo di impatto misura derivata dal valore di una dimensione; per gli eventi primari vale 1; per gli eventi secondari si usa COUNT(DISTINCT APPELLO). NT=SUM(CASE WHEN VOTO=30 THEN 1 ELSE 0 END) normale, additiva, sia di impatto che pesata Eventi primari FACT_TABLE_PD NA è derivata quindi non è nella FACT_TABLE. Reticolo di roll- up di {GRUPPO,STUDENTE} SELECT GRUPPO,STUDENTE, NA_IMPATTO= COUNT(DISTINCT APPELLO), NT_PESATO=SUM(NT_P), NT_IMPATTO= CASE WHEN GROUPING(STUDENTE)=1 THEN SUM(NT_P) ELSE SUM(NT_I) END FROM FACT_TABLE_PD GROUP BY GRUPPO,STUDENTE WITH CUBE 107

108 2.7.3 Dimensioni = {DOCENTE, DATA, GRUPPO} Schema transazionale, FD: {DOCENTE, DATA } à GRUPPO Misure: NA = COUNT(DISTINCT APPELLO), solo di impatto E una misura derivata (in quanto vale 1 per ogni evento primario), additiva (si usa l operatore SUM per tale misura derivata) non aggregabile rispetto a DATA (NonAgg = { DATA }) in quanto APPELLO à DOCENTE e quindi additiva rispetto a DOCENTE e per {DOCENTE, DATA } à GRUPPO il pattern primario è {DOCENTE, DATA } NT=SUM(CASE WHEN VOTO=30 THEN 1 ELSE 0 END) normale, additiva, sia di impatto che pesata Eventi primari FACT_TABLE_PD NA è derivata quindi non è nella FACT_TABLE. Nella realizzazione del reticolo di roll- up {GRUPPO,STUDENTE}, NA non è mai calcolabile in quanto NonAgg = { DATA }. Quindi NA viene omessa dalla realizzazione di questo reticolo. Per NT : verificare che si ottengono gli stessi risultati del caso precedente Come pattern significativo, consideriamo due pattern che contengono DATA e quindi per i quali NA è calcolabile. SQL- OLAP: realizzare {DOCENTE, DATA, GRUPPO} e {DOCENTE, DATA, GRUPPO,STUDENTE} del DOCENTE=110 in DATA=2 (in figura) e commentare il risultato. {DOCENTE, DATA, GRUPPO} : è equivalente al pattern primario { DOCENTE, DATA }, non c è raggruppamento; non essendo coinvolto l arco multiplo le misure _PESATO e _IMPATTO coincidono. {DOCENTE, DATA, GRUPPO,STUDENTE} ; è coinvolto l arco multiplo STUDENTE: per ogni studente, le misure di impatto corrispondono a quelle del gruppo, mentre le misure pesate tengono conto del peso SELECT DOCENTE,DATA,GRUPPO,STUDENTE, NA_PESATO=SUM(NA_P), NA_IMPATTO= CASE WHEN GROUPING(STUDENTE)=1 THEN SUM(NA_P) ELSE SUM(NA_I) END, NT_PESATO=SUM(NT_P), NT_IMPATTO= CASE WHEN GROUPING(STUDENTE)=1 THEN SUM(NT_P) ELSE SUM(NT_I) END FROM FACT_TABLE_PD where docente=110 and data=2 GROUP BY DOCENTE,DATA,GRUPPO,STUDENTE WITH CUBE HAVING (GROUPING(DOCENTE)=0 AND GROUPING(DATA)=0 and GROUPING(GRUPPO)=0 ) 108

109 2.7.4 Dimensioni = {DOCENTE, DATA, GRUPPO,APPELLO} Schema transazionale, FD: {DOCENTE, DATA } à GRUPPO, {DOCENTE, DATA } à APPELLO e APPELLO à DOCENTE Misure: NA = COUNT(DISTINCT APPELLO), solo di impatto E una misura derivata dal valore di una dimensione; per gli eventi primari vale 1; per gli eventi secondari si usa come operatore di aggregazione COUNT(DISTINCT APPELLO). NT=SUM(CASE WHEN VOTO=30 THEN 1 ELSE 0 END) normale, additiva, sia di impatto che pesata Eventi primari FACT_TABLE_PD NA è derivata quindi non è nella FACT_TABLE. Considerare NA come misura di impatto equivale a calcolare NA=COUNT(DISTINCT APPELLO) (sia nella soluzione con bridge- table che in quella con push- down); nella FACT_TABLE_PD non serve quindi codificare NA. E facile verificare che ora NA è aggregabile rispetto a tutte le dimensioni Nella realizzazione del reticolo di roll- up {GRUPPO,STUDENTE}, NA viene calcolata come COUNT(DISTINCT APPELLO); per NT_IMPATTO si usa sempre CASE WHEN GROUPING(STUDENTE)=1 THEN SUM(NT_P) ELSE SUM(NT_I) END. 109

110 2.7.5 Dimensioni = { DOCENTE, GRUPPO } Schema temporale, FD: nessuna, Misure: NA = COUNT(DISTINCT APPELLO), solo di impatto E una misura normale, additiva rispetto a DOCENTE (in quanto APPELLOà DOCENTE) ma non aggregabile rispetto a GRUPPO (NonAgg = {GRUPPO}) NT=SUM(CASE WHEN VOTO=30 THEN 1 ELSE 0 END) normale, additiva, sia di impatto che pesata Eventi primari = FACT_TABLE FACT_TABLE_PD La realizzazione del reticolo di {GRUPPO,STUDENTE} è come in 2.7.1; verificare che si ottiene lo stesso risultato. SQL- OLAP: realizzare {DOCENTE,GRUPPO} e {DOCENTE, GRUPPO,STUDENTE} del DOCENTE=210 e commentare il risultato. SELECT DOCENTE, GRUPPO,STUDENTE, NA_IMPATTO= CASE WHEN GROUPING(STUDENTE)=1 THEN SUM(NA_P) ELSE SUM(NA_I) END, NT_PESATO=SUM(NT_P), NT_IMPATTO= CASE WHEN GROUPING(STUDENTE)=1 THEN SUM(NT_P) ELSE SUM(NT_I) END FROM FACT_TABLE_PD where docente=210 GROUP BY DOCENTE, GRUPPO,STUDENTE WITH CUBE HAVING (GROUPING(DOCENTE)=0 AND GROUPING(GRUPPO)=0) {DOCENTE, GRUPPO} : è equivalente al pattern primario { DOCENTE, DATA }, non c è raggruppamento; non essendo coinvolto l arco multiplo le misure _PESATO e _IMPATTO coincidono. {DOCENTE, GRUPPO,STUDENTE} ; è coinvolto l arco multiplo STUDENTE: per ogni studente, le misure di impatto corrispondono a quelle del gruppo, mentre le misure pesate tengono conto del peso 110

111 2.7.6 Attributo STUDENTE come dimensione Vengono considerati i seguenti 4 schemi di Fatto in cui STUDENTE è una dimensione 1. {STUDENTE } 2. {DOCENTE, STUDENTE } 3. {DOCENTE, DATA, STUDENTE } 4. {DOCENTE, DATA, STUDENTE,APPELLO} Ora non c è più un arco multiplo; le misure sono definite come in precedenza, in particolare nel definire NT ci sono due possibili interpretazioni NT_IMPATTO=SUM(CASE WHEN VOTO=30 THEN 1 ELSE 0 END) : un voto 30 di un gruppo viene conteggiato per tutti gli studenti del gruppo, indipendentemente dal loro peso. NT_PESATA =SUM(CASE WHEN VOTO=30 THEN PESO ELSE 0 END): un voto 30 di un gruppo viene conteggiato per tutti gli studenti del gruppo, in base al peso dello studente nel gruppo. Interpretando ad esempio NT come NT_IMPATTO, il valore di NT per alcuni pattern è il seguente: { STUDENTE} {DOCENTE,DATA,STUDENTE} {DOCENTE, STUDENTE} { DATA,STUDENTE} Per ciascun caso viene richiesto di 1. Delineare lo schema, dire se transazionale/temporale, individuare le FD tra le dimensioni 2. Definizione ed aggregabilità delle due misure (NT, NA) 3. Alimentazione : scrivere la view FACT_TABLE 4. Realizzare il pattern {STUDENTE} e discutere se NA è calcolabile per tale pattern 5. Delineare e realizzare pattern significativi Indicazioni per la soluzione: Per la misura NA si hanno rispettivamente rispetto ai 4 schemi - le seguenti non aggregabilità 1. NonAgg = { STUDENTE } 2. NonAgg = { DATA,STUDENTE } 3. NonAgg = { STUDENTE } 4. NonAgg = { DATA,STUDENTE } Quindi per il pattern {STUDENTE}, la misura NA è calcolabile solo nel primo e nel terzo caso. 111