Esercizio con attributo cross-dimensionale - transazionale

Transcript

1 Esercizio con attributo cross-dimensionale - transazionale TIPO (,CITTA) DI QTY CITTA (,ANNO) SCONTRINO(NSC, :) (,TIPO) VENDITA IN VENDITA(NSC:SCONTRINO,:, :,QTY,PU) IN PU NSC ANNO SCONTRINO DEL Viene richiesto di A) Progettazione concettuale : schema di fatto con dimensioni {,SCONTRINO} e misure {QTY,PU,NUMCLIENTI} B) Progettazione logica : (STAR-SCHEMA e SNOW-FLAKE SCHEMA) C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP: Discutere in SQL-OLAP il pattern {SCONTRINO,,CITTA} e sub-pattern. Glossario delle Misure QTY: quantità totale PU: prezzo unitario medio NUMCLIENTI: è valutato con il conteggio DISTINTO degli scontrini 1

2 Esempio di istanza del DBO e corrispondente istanza del fatto (eventi primari) Eventi Primari del Fatto VENDITA Pattern {,,} Pattern {,,TIPO} 2

3 Soluzione Progettazione Concettuale TIPO CITTA VENDITA QTY PU (AVG) (C) NUMCLIENTI SCONTRINO ANNO Lo schema di fatto è TRANSAZIONALE. Non ci sono dipendenze funzionali tra le dimensioni. Misure QTY: misura normale ADDITIVA PU: misura normale aggregata tramite AVG NUMCLIENTI: misura calcolata NUMCLIENTI=COUNT(DISTINCT SCONTRINO) Progettazione Logica Star Schema FACT_TABLE(SCONTRINO:DT_SCONTRINO,:DT_,QTY,PU) DT_(,TIPO) DT_SCONTRINO(SCONTRINO,,ANNO) Ricordiamo che dal punto di vista concettuale, un attributo crossdimensionale b definisce un associazione molti-a-molti tra due o più attributi dimensionali a1..., am. La sua traduzione a livello logico richiede l inserimento di una nuova tabella che includa b e abbia come chiave gli attributi a1..., am. Quindi nel caso in esame DT_(SCONTRINO:DT_SCONTRINO,:DT_,,CITTA) Snow-flake Schema FACT_TABLE(SCONTRINO:DT_SCONTRINO,:DT_,QTY,PU) DT_(,TIPO) DT_SCONTRINO(SCONTRINO,:DT_) DT_(,ANNO) DT_(SCONTRINO:DT_SCONTRINO,:DT_,:DT_2) DT_2(,CITTA) 3

4 Alimentazione : Scrivere in SQL l alimentazione della fact-table. Lo schema è transazionale, la view fact table è banale CREATE VIEW FACT_TABLE AS SELECT NSC AS SCONTRINO,,PU,QTY FROM VENDITA SQL-OLAP: Discutere in SQL-OLAP il pattern {SCONTRINO,,CITTA} e sub-pattern. CITTA è un figlio dell attributo cross-dimensionale, quindi {SCONTRINO,} à CITTA Pertanto il pattern {SCONTRINO,,CITTA} è non significativo e può essere escluso dalla visualizzazione attraverso HAVING not (grouping(scontrino)=0 AND grouping()=0 AND grouping(citta)=0) In questo caso veniva richiesta solo la discussione e non la query SQL-OLAP, quindi quanto detto sopra è sufficiente. Ci si limita alla sola discussione (l unica cosa interessante, il resto è solo SQL) anche perché in SQL 2000 c è una limitazione sull uso di CUBE e ROLLUP : non accettano l operatore COUNT(DISTINCT ) 4

5 Variante esercizio con attributo cross-dimensionale : temporale TIPO DI QTY CITTA (,CITTA) (,ANNO) SCONTRINO(NSC, :) VENDITA IN (,TIPO) IN PU VENDITA(NSC:SCONTRINO,:, :,QTY,PU) NSC ANNO SCONTRINO DEL Viene richiesto di A) Progettazione concettuale : schema di fatto con dimensioni {,, } e misure {QTY,PU,NUMCLIENTI} B) Progettazione logica : (STAR-SCHEMA e SNOW-FLAKE SCHEMA) C) Alimentazione : Scrivere in SQL l alimentazione della fact-table. D) SQL-OLAP: Glossario delle Misure 1) Scrivere e discutere in SQL-OLAP il pattern {,CITTA} e sub-pattern. 2) Scrivere e discutere in SQL-OLAP il pattern {,CITTA,ANNO} visualizzando solo {,CITTA} e {,ANNO} (vedere figura ) QTY: quantità totale PU: prezzo unitario medio NUMCLIENTI: è valutato con il conteggio DISTINTO degli scontrini 5

6 Eventi Primari del Fatto VENDITA Pattern {,,TIPO} Pattern {} Pattern {,CITTA} e {,ANNO} come sub-pattern di {,CITTA,ANNO} 6

7 Progettazione Concettuale TIPO VENDITA QTY (C) PU NUMCLIENTI CITTA ANNO Lo schema di fatto è TEMPORALE. Non ci sono dipendenze funzionali tra le dimensioni. Misure QTY: misura normale ADDITIVA PU: misura calcolata come PU_TOTALE/NVENDITE dove a) PU_TOTALE misura normale additiva, definita come PU_TOTALE = SUM(PU) b) NVENDITE misura normale additiva, definita come NVENDITE = COUNT(*) NUMCLIENTI: misura normale ADDITIVA, non aggregabile rispetto a Progettazione Logica Star Schema (coincide con Snow-flake Schema) FACT_TABLE(:DT_,:DT_, :DT_, QTY,PU_TOTALE,NVENDITE,NUMCLIENTI) DT_(,CITTA) DT_(,TIPO) DT_(,ANNO) Alimentazione : Scrivere in SQL l alimentazione della fact-table. CREATE VIEW FACT_TABLE AS SELECT,,, QTY=SUM(QTY), PU_TOTALE=SUM(PU), NVENDITE=COUNT(*), NUMCLIENTI=COUNT(DISTINCT V.NSC) FROM VENDITA V JOIN SCONTRINO S ON (V.NSC = S.NSC) GROUP BY,, 7

8 SQL-OLAP: 1) Scrivere e discutere in SQL-OLAP il pattern {,CITTA} e sub-pattern. SELECT, CITTA, QTY=SUM(QTY), PU = SUM(PU_TOTALE)/SUM(NVENDITE), NUMCLIENTI = CASE WHEN GROUPING()=1 THEN CAST(SUM(NUMCLIENTI) AS VARCHAR) + ' (NA)' ELSE CAST(SUM(NUMCLIENTI) AS VARCHAR) END FROM FACT_TABLE F JOIN DT_ M ON (F. = M.) JOIN DT_ N ON (F. = N.) GROUP BY, CITTA WITH CUBE 2) Scrivere e discutere in SQL-OLAP il pattern {,CITTA,ANNO} visualizzando solo {,CITTA} e {,ANNO} SELECT, CITTA, ANNO, QTY=SUM(QTY), PU = SUM(PU_TOTALE)/SUM(NVENDITE), NUMCLIENTI = SUM(NUMCLIENTI) FROM FACT_TABLE F JOIN DT_ M ON (F. = M.) JOIN DT_ N ON (F. = N.) GROUP BY, CITTA, ANNO WITH CUBE HAVING GROUPING()=0 AND GROUPING(CITTA)=0 AND GROUPING(ANNO)=1 OR GROUPING()=0 AND GROUPING(CITTA)=1 AND GROUPING(ANNO)=0 8