ESEMPIO: RITARDI & BIGLIETTI

Transcript

1 ESEMPIO: RITARDI & BIGLIETTI! Fatto Ritardi: l analisi a livello volo giornaliero, considerando l aeroporto di partenza, la città e lo stato di arrivo e la compagnia! Fatto Biglietti: l analisi deve considerare sia l aeroporto di partenza che di arrivo, il check-in, la compagnia e l ora di partenza 1 Ricognizione e normalizzazione del RDB! Lo schema logico relazionale del DB operazionale:! E facile verificare che i due schemi sono equivalenti: lo schema logico relazionale ottenuto da un corretto progetto logico! L unica analisi ragionevole riguarda la dipendenza tra STATO e CITTA 2

2 Ricognizione e normalizzazione del RDB! Valori nulli per l attributo CITTA di AEROPORTO SELECT count(*) FROM AEROPORTO WHERE CITTA is null " Risultato vuoto: CITTA verrà considerato come NOT NULL! Dipendenza funzionale CITTA! STATO SELECT CITTA FROM AEROPORTO GROUP BY CITTA HAVING COUNT(DISTINCT STATO) > 1 " Risultato vuoto: si assume valida la FD! Schema E/R riconciliato: Nuova entità CITTA (con attributo STATO) associata ad AEROPORTO con associazione uno-a-molti! Schema relazionale riconciliato: Nuove relazioni RIC_AEROPORTO e RIC_CITTA " Essendo una modifica estremamente semplice, lo schema relazionale viene lasciato inalterato 3 Ricognizione e normalizzazione del RDB! Convergenza Stato-Arrivo e Stato-Partenza? Tale vincolo avrebbe senso in un DB di voli nazionali; verifichiamolo in ogni caso. 1. Si genera la vista in modo grafico 2. Quindi si aggiunge manualmente all SQL CITTA_PARTENZA.STATO <> CITTA_ARRIVO.STATO 3. Il risultato della query è non vuoto quindi non c è convergenza. 4

3 Progettazione dello schema di Fatto RITARDI! Costruzione Albero degli attributi 1. Si costruisce l albero degli attributi basato sull entità VOLOGIORN (tale entità ha come chiave {DATA,CODVOLO}) 2. Si modifica l albero aggiungendo la dipendenza CITTA! STATO 3. Si modifica l albero eliminando A-SIGLA 5 Ritardi: Progettazione dello Schema di Fatto 4. Si modifica l albero eliminando CODVOLO per CITTA_ARRIVO, ovvero riportando CITTA_ARRIVO come figlio diretto della radice; questa modifica deriva dalla specifica di analizzare i ritardi direttamente rispetto alla città di arrivo e quindi di far diventare CITTA_ARRIVO una dimensione. 5. Scelta delle Dimensioni : {DATA, CODVOLO, CITTA_ARRIVO} quindi tra le dimensioni ho tutti gli attributi chiave ovvero questo è uno schema transazionale. Si noti che tra le dimensioni esiste la dipendenza funzionale CODVOLO! CITTA_ARRIVO Pertanto quando si visualizzerà il cubo (ovvero, quando faremo dei roll-up e drilldown) se visualizzo il livello CODVOLO (ovvero considero un pattern contenente CODVOLO) i roll-up ed i drill-down lungo la dimensione CITTA_ARRIVO non modificheranno il valore visualizzato delle misure: infatti fissato il CODVOLO ho un unica CITTA_ARRIVO e quindi raggruppando su STATO_ARRIVO il valore delle misure non cambia (vedi pag. 40) 6

4 Ritardi: Progettazione dello Schema di Fatto 6. Si definiscono le misure ed il relativo glossario: RITARDO: Essendo lo schema transazionale, tale misura corrisponde all attributo RITARDO del DB operazionale 7. Si definiscono gli operatori di aggregazione delle misure: per ogni coppia dimensione-misura si valuta l additività/aggregabilità e quindi si definisce il relativo operatore di aggregazione RITARDO : può essere considerata una misura di flusso e come tale aggregata sia tramite somma che con altri operatori, sia rispetto alla data che rispetto alle altre dimensioni. Ad esempio, per analizzare il ritardo medio si considera RITARDO (AVG) Oppure, per analizzare sia il ritardo medio che complessivo si potrebbero considerare due misure con differenti operatori di aggregazione RITARDO_MEDIO (AVG) RITARDO_COMPLESSIVO (SUM) - SUM è il default, si può omettere # Per una misura si possono definire differenti operatori di aggregazione per le differenti dimensioni: verrà discusso in Analysis Services 7 Ritardi: Progettazione dello Schema di Fatto 8. Si analizzano eventuali gerarchie condivise/convergenze, attributi crossdimensionali, archi multipli Si considera CITTA, STATO come gerarchia condivisa : si noti che il ruolo della CITTA come figlio di AEROPORTO_PARTENZA è evidente, mentre per la dimensione occorre esplicitare il nome del ruolo CITTA_ARRIVO Tale analisi può essere condotta anche sull albero degli attributi, ma formalmente questi concetti sono definiti per uno schema di fatto. 8

5 Considerazioni! In uno schema transazionale le misure corrispondono ad attributi figli della radice dell albero. Più precisamente il valore di una misura è calcolato partendo dal singolo valore di un attributo figlio della radice Esempio: RITARDO = VOLOGIORN.RITARDO oppure RITARDO = ISNULL(VOLOGIORN.RITARDO,0) per considerare pari a 0 un ritardo non specificato (NULL)! Esempio: Oltre al valore del ritardo voglio analizzare il numero dei voli giornalieri che hanno subito un ritardo, rappresentato tramite una misura NUMRITARDI a valore booleano calcolata come if VOLOGIORN.RITARDO > 5 then NUMRITARDI = 1 else NUMRITARDI = 0! Per come è stata definita NUMRITARDI deve essere aggregata tramite SUM 9 Ritardi - Progettazione Logica! Per semplicità, non verranno introdotte chiavi surrogate.! STAR SCHEMA: " FACT TABLE RITARDI(CODVOLO:VOLO,DATA,CITTA_ARRIVO: CITTAARRIVO,RITARDO,NUMRITARDI) " DIMENSION TABLEs VOLO(CODVOLO,COMPAGNIA,AEROP_PART,CITTA_PART,STATO_PART) CITTAARRIVO(CITTA_ARR,STATO_ARR)! SNOWFLAKE SCHEMA: " FACT TABLE RITARDI(CODVOLO:VOLO,DATA,CITTAARRIVO:CITTA,RITARDO, NUMRITARDI) " DIMENSION TABLEs VOLO(CODVOLO,COMPAGNIA, AEROP_PART:AEROPORTO) AEROPORTO(SIGLA, CITTA_PART:CITTA) CITTA (CITTA,STATO) 10

6 DataMart Ritardi: SNOWFLAKE SCHEMA! Si usa lo snowflake schema riportato in figura:! Alimentazione del DataMart: Estrazione statica Viene effettuata quando il DM deve essere popolato per la prima volta e consiste concettualmente in una fotografia dei dati operazionali. In altri termini è l alimentazione a partire da zero. 11 Estrazione Statica 1. Si devono definire delle interrogazioni sul DB operazionale (DBO) : " Una query per definire il contenuto della Fact Table " Una query per ciascuna Dimensional table 2. Si devono eseguire le query sul DBO ed immettere i risultati nel DM " Necessità di operare su due DB, DBO e DM non è possibile fare una istruzione SQL su due database INSERT INTO DM.RITARDI(RITARDO) SELECT RITARDO FROM DBO.VOLOGIORN " Per trasferire da DBO a DM devo usare Data Transformation Services.! Dove definire materialmente queste query? 1. Nel DBO, tramite delle viste; chi analizza i dati ha i permessi di leggere e quindi creare viste sul DBO, mentre non ha i permessi per creare tabelle e/o modificare le tabelle esistenti 2. Direttamente nel Data Transformation Services (DTS).! Verrà usato il seguente metodo: si creano le viste (almeno quelle più difficili, in genere quelle relative alla fact table) nel DBO e si usano nel DTS: in questo modo le operazioni da effettuare nel DTS saranno semplici 12

7 Ritardi: Estrazione statica Fact Table! Vista con lo stesso schema (attributi e chiave) della Fact Table! Salvo ed edito la view aggiungendo e calcolando NUMRITARDI CREATE VIEW dbo.vistaritardi AS Nel caso in cui RITARDO SELECT dbo.vologior.data, dbo.vologior.codvolo, è nullo viene conteggiato dbo.aeroporto.citta AS CITTA_ARRIVO, come RITARDO=0 ISNULL(RITARDO,0) AS RITARDO, NUMRITARDI = CASE WHEN RITARDO > 5 THEN 1 ELSE 0 END FROM dbo.vologior INNER JOIN dbo.volo ON dbo.vologior.codvolo = dbo.volo.codvolo INNER JOIN dbo.aeroporto ON dbo.volo.a = dbo.aeroporto.sigla 13 Ritardi: Estrazione statica Dimension Table! In uno snowflake schema le Dimension Table corrispondono generalmente a proiezioni su singole tabelle del DBO che possono essere eseguite direttamente nel DTS senza creare ulteriori viste " Ad esempio, per la dimensione VOLO, è inutile creare CREATE VIEW dbo.vistavolo AS SELECT CODVOLO, ORA_PARTENZA, COMPAGNIA, DA FROM dbo.volo questa query viene fatta direttamente nel DTS! Rispettare le key/foreign key dello schema " Ad esempio, nell alimentazione della dimensione CITTA, devo eliminare i duplicati SELECT DISTINCT CITTA,STATO FROM AEROPORTO per rispettare la key della relazione CITTA! Quando la Dimension Table è più complessa, come nei casi di - Dimension Table derivante dal join di più tabelle (come normalmente avviene in uno star schema ) - Dimension Table con attributi corrispondenti ad intervalli di valori è consigliabile usare una o più viste per la sua alimentazione, ed eventualmente anche delle tabelle temporanee! 14

8 ALIMENTAZIONE del DM: uso di pacchetti DTS 1. Si svuota il contenuto del DM: L unico vincolo da rispettare è quello dell integrità referenziale: quando si svuota la tabella A (DELETE FROM A), devono essere già state svuotate tutte le tabelle referenziate da A (quindi si deve iniziare con la fact table ) 2. Si copiano le dimensional table: l unico vincolo da rispettare è quello dell integrità referenziale: quando si copia la tabella A, devono essere già state copiate tutte le tabelle alle quali A si riferisce tramite una FK 3. Si copia il contenuto della vista nella fact table! Ognuna delle precedenti operazioni è un pacchetto DTS! Quale strumento usare per definire tali pacchetti? " Per la copia è più semplice creare il pacchetto con Importa Dati : infatti devo solo copiare nel DM il contenuto di una vista o di una tabella del DBO " Per svuotare è necessario usare l editor per pacchetti DTS! Dopo aver creato e provato i pacchetti (package) per i singoli passi, si può creare un unico package che li include tutti, eseguendoli nell ordine stabilito " In uno star schema si possono copiare tutte le dimension table in un solo passo 15 Ritardi: Alimentazione del Data Mart - svuoto il DM! Si crea un pacchetto DTS tramite editor " Per prima cosa si inserisce la connessione al DM 16

9 Ritardi: Alimentazione del Data Mart - svuoto il DM! Si crea un pacchetto DTS tramite editor " e quindi si scrive l istruzione SQL (si noti che occorre cancellare rispettando l ordine delle FK) 17 Ritardi: Alimentazione del Data Mart - Dimension Table CITTA! Nel DB operazionale la città e lo stato sono specificati in AEROPORTO " Prendo i dati dal DB Biglietti e precisamente dalla tabella AEROPORTO. " Si effettua un importa dati basato sulla query select distinct CITTA,STATO from AEROPORTO 18

10 Ritardi: Alimentazione del Data Mart - Dimension Table CITTA 19 Ritardi: Alimentazione del Data Mart - Dimension Table CITTA 20

11 Ritardi: Alimentazione del Data Mart - Dimension Table CITTA 21 Ritardi: Alimentazione del Data Mart! Si salva il pacchetto per alimentare Citta! Si crea un pacchetto per alimentare AEROPORTO nel DM " Si effettua un importa dati basato sulla query select SIGLA, CITTA from AEROPORTO " Non serve il distinct perchè SIGLA è chiave " Si può fare anche senza la query, importando direttamente la tabella! Nello stesso modo si crea un pacchetto per alimentare VOLO nel DM! Si crea un pacchetto per alimentare RITARDI nel DM prendendolo dalla vista creata in precedenza 22

12 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo! Si crea un pacchetto DTS complessivo di tutti I pacchetti creati finora, in cui viene imposto l ordine di esecuzione " Ogni pacchetto viene inserito tramite Attività Esegui Pacchetto che viene collegata al pacchetto creato in precedenza 23 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo " si inserisce il pacchetto per copiare i dati da Città 24

13 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo " E quindi si crea il flusso di lavoro tra I due pacchetti: 25 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo " Alle varie Attività Esegui Pacchetto si può dare un nome (usando le proprietà) 26

14 Analysis Services : Editor del Cubo! Il sistema OLAP di Analysis Services, così come un qualsiasi altro sistema OLAP, ha concetti e strumenti propri per definire uno schema multidimensionale (un cubo), concetti e strumento più o meno sofisticati e spesso proprietari (cioè propri del particolare sistema OLAP e differenti da sistema a sistema)! Ad esempio in Analysis Services lo strumento (automatico) per definire le dimensioni consente di scegliere se usare uno schema a stella oppure a fiocco di neve o altro, quale attributo considerare come chiave in un certo livello e così via. # Noi non useremo tutti i concetti e strumenti propri, specifici di Analysis Services (avendo già fatto le nostre scelte nella progettazione concettuale e logica) # Useremo di Analysis Services solo quei concetti/strumenti che ci consentono di 1. Definire gli operatori di aggregazione per le misure 2. Definire Misure Derivate e Calcolate 3. Visualizzare i dati del fatto in modo multidimensionale, effettuando operazioni di roll-up e drill-down 27 Cubo corrispondente ad uno Schema di Fatto! Input: 1. Schema di Fatto 2. Schema Logico! Primo passo: Si inserisce nel cubo la fact table! Secondo passo : si costruiscono le dimensioni! Terzo passo : si definiscono le misure # Conviene procedere in modo incrementale: definita una o più dimensione, si inseriscono una o più misure, si salva e si elabora il cubo, si visualizzano i dati, si verifica il risultato. E quindi si procede con le altre dimensioni e misure. 28

15 Editor del Cubo: costruzione del cubo! Input : schema di Fatto dei Ritardi con lo schema logico di pag. 10! Primo passo: Si aggiunge la fact table! Secondo passo : si costruiscono le dimensioni 29 Editor del Cubo: definizione delle dimensioni! In un cubo di Analysis Services le dimensioni sono costituite da livelli che formano una successione lineare (un nodo può avere al massimo un figlio) quindi per ogni gerarchia dello schema di fatto occorre definire nel cubo tante dimensioni quanti sono i cammini di aggregazione della gerarchia! Gerarchia della dimensione CODVOLO: corrisponde a due cammini di aggregazione e quindi viene realizzata nel cubo di Analysis Services attraverso due dimensioni:! Dimensione Volo_Compagnia con due livelli CodVolo $ Compagnia! Dimensione Volo_Partenza con quattro livelli CodVolo $ AeroPorto $ Citta $ Stato 30

16 Editor del Cubo: definizione delle dimensioni! Dimensione CITTA_ARRIVO! Tale dimensione corrisponde ad un solo cammino di aggregazione e quindi viene realizzata nel cubo attraverso una sola dimensione:! Dimensione CITTA_ARRIVO con due livelli Citta $ Stato 31 Editor del Cubo: definizione delle dimensioni! Dopo aver individuato le dimensioni si può costruire il cubo e le relative dimensioni! Nel seguito vengono descritti in dettaglio i passi per costruire un cubo con le relative dimensioni! Durante la costruzione del cubo e delle sue dimensioni è importante aver presente lo schema logico del Data Mart, in quanto i dati vengono appunto presi da tale schema 32

17 Editor del Cubo: costruzione delle dimensioni! Dimensione Volo_Compagnia con due livelli CodVolo $ Compagnia 1. Si aggiunge la Dimensional Table che contiene tale dimensione 2. Si verifica che il collegamento tra la Dimensional Table e la Fact Table realizzato in automatico sulla base della Foreign Key sia in effetti corretto 3. Si seleziona l ultimo livello della dimensione, ovvero Compagnia e si genera la dimensione 4. Si aggiunge alla dimensione il livello CodVolo 5. Si assegna il nome alla dimensione (il nome di default è quello dell attributo selezionato al punto 3.) # Ricordarsi che il primo attributo ad essere selezionato è quello dell ultimo livello! 33 Editor del Cubo: costruzione delle dimensioni! Dimensione Volo_Partenza con quattro livelli CodVolo $ AeroPorto $ Citta $ Stato 1. Si aggiungono le Dimensional Table che contengono tale dimensione non occorre inserire nuovamente la table VOLO in quanto VOLO_PARTENZA deriva dalla stessa dimensione iniziale CodVolo 2. Si verifica che sia corretto il collegamento realizzato in automatico sulla base delle Foreign Key 3. Si seleziona l attributo Stato (ultimo livello) e si genera la Dimensione 4. Si aggiungono alla dimensione i livelli Citta, Sigla e CodVolo 5. Si assegna il nome alla dimensione # Si noti che i livelli vengono aggiunti partendo dall ultimo ed arrivando al primo! 34

18 Editor del Cubo: costruzione delle dimensioni! Dimensione CITTA_ARRIVO con due livelli Citta $ Statto " Occorre inserire nuovamente la table CITTA in quanto CITTA_ARRIVO deriva da una dimensione iniziale differente da CodVolo per la quale era stata già inserita CITTA # Il problema di dover inserire più volte la stessa dimensional table si pone solo nel caso di Dimensional table condivisa da più gerarchie (e quindi solo nel caso di Snow-flake schema) 35 Ritardi: Definizione del Cubo Ritardi in Analysis Services Si noti che per la tabella CITTA utilizzata nella definizione della dimensione CITTA_ARRIVO è stato dato l alias per non confonderla con la tabella CITTA nell altra dimensione. Per ogni misura è definito il suo Data Type ed il suo formato di visualizzazione Display Format! Si noti che la misura Count (che verrà usata per definire il membro calcolato RITARDO) è aggregata tramite Count quindi calcola il numero di valori di un attributo, che corrisponde al numero di tuple della Fact Table Ritardi e quindi rappresenta il numero di voli 36

19 Dimensioni: livello (ALL) e membro ALL! Dimensione CITTA_ARRIVO con due livelli : Citta $ Statto CITTA STATO (ALL) MARSIGLIA FRANCIA ALL PARIGI FRANCIA ALL LONDRA INGHIL ALL livelli membri! Nella visualizzazione della dimensione, il livello (ALL) è chiamato (Totale) ed il membro ALL è totale CITTA_ARRIVO! Nelle proprietà della dimensione si può eliminare il livello (ALL) (All level = No) e cambiare il nome del membro ALL: 37 Dimensioni: livello (ALL) e membro ALL in MDX! Consideriamo la seguente interrogazione MDX, che restituisce il complessivo dei ritardi per tutti i voli con città di arrivo in FRANCIA SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[STATO].[FRANCIA])! Con ([CITTA_ARRIVO].[STATO].[FRANCIA]) individuo un evento secondario corrispondente ad un pattern secondario {STATO} : Questo quindi equivale a raggruppare su STATO e selezionare FRANCIA CITTA STATO (ALL) MARSIGLIA FRANCIA ALL PARIGI FRANCIA ALL LONDRA INGHIL ALL......! Nello stesso modo, per il complessivo dei ritardi per tutte le città di arrivo, si deve utilizzare il membro ALL SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[(Totale)].[Totale CITTA_ARRIVO])! In questo modo si raggruppa rispetto al livello (ALL) e si seleziona il membro ALL, pertanto si considerano tutte le città di arrivo 38

20 Dimensioni: livello (ALL) e membro ALL in MDX! I membri di una dimensione sono ordinati:!" #$%&'()*+##,-,..+/0 1" 2.,3*+, 4" 5,.6+78+, 9" :,.+7+ ;" +37<+8 =" 803>.,?" A Questo è l ordine con il quale i membri vengono illustrati in un asse, ad esempio nella query: SELECT [CITTA_ARRIVO].Members ON COLUMNS FROM RITARDI! In base all interpretazione di default di MDX, se una dimensione non è utilizzata nella specifica della clausola where, essa si considera limitata al suo primo membro. Quindi la seguente query equivale a SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[(Totale)].[Totale CITTA_ARRIVO]) 39 Dimensioni: livello (ALL) e membro ALL in MDX! Dimensione CITTA_ARRIVO senza il livello (ALL) CITTA STATO MARSIGLIA FRANCIA PARIGI FRANCIA LONDRA INGHIL......! Adesso il primo membro della dimensione è [CITTA_ARRIVO].[FRANCIA], quindi In base all interpretazione di default, la query SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI equivale a SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[FRANCIA]) 40

21 Ritardi: Osservazione sulla misure calcolate! Nella realizzazione del cubo in Analysis Services occorrerà definire la misura RITARDO come misura calcolata in quanto è aggregata tramite AVG; si usano a tale scopo RITARDO_BASE e COUNT:! Per verificare la correttezza di RITARDO, calcoliamo tale misura direttamente sugli eventi primari nel DM, utilizzando SQL: select CITTA_ARRIVO, AVG(cast(RITARDO as decimal)) as ritardo from Ritardi group by CITTA_ARRIVO select STATO, AVG(cast(RITARDO as decimal)) as ritardo from Ritardi INNER JOIN CITTA ON CITTA_ARRIVO=CITTA group by STATO Se RITARDO è un integer, nel calcolo di AVG di deve trasformare in real: viene usato il casting a decimal (oppure float) 41 Ritardi: Osservazione su CODVOLO! CITTA_ARRIVO! Nella visualizzazione del pattern secondario {CODVOLO,CITTA_ARRIVO} viene evidenziato l effetto della dipendenza tra dimensioni CODVOLO! CITTA_ARRIVO: Per il CODVOLO=V1 si ha una sola città di arrivo (ROMA)! Come verifica consideriamo un pattern secondario senza CODVOLO: {STATO_PARTENZA,CITTA_ARRIVO} 42

22 Ritardi: Esempi di interrogazioni MDX 1. Calcolare ogni misura per le compagnie AIRFRANCE e ALITALIA in ottobre e novembre del 1998 :! Nota: Usare {Measures.MEMBERS, Measures.RITARDO}, in quanto l operatore MEMBERS non include la Misura (membro) Calcolata RITARDO. 2. Calcolare il ritardo, raggruppando i dati su un asse per compagnia (tutte le compagnie), per mese (ottobre e novembre del 1998) e per città di arrivo (tutte le città di arrivo): Ci sono stati dei voli dell AIRFRANCE a novembre con arrivo a Parigi, ma sempre con ritardo =0. Non ci sono stati dei voli dell ALITALIA a novembre con arrivo a Parigi, e quindi la cella non c è. Visualizzazione Alternativa: si mettono le città di arrivo sulle colonne e Measures.RITARDO nella WHERE: 43 Ritardi: Esempi di interrogazioni MDX 3. Data la misura RAPPORTO, definita (con WITH MEMBER) come rapporto tra numero di voli in ritardo (NumRitardi) e numero di voli complessivi (Count) MEMBER MEASURES.[RAPPORTO] AS '[Measures].[Numritardi] / [Measures].[Count] Per fare un rapporto tra reali una delle due misure deve avere un Display Format con le cifre decimali (non è sufficiente che sia il Data Type sia un real) : quindi (vedi pag. 13) viene cambiato il Display Format di NumRitardi. Il casting in MDX richiede la definizione di una funzione in VisualBAsic o altro Consideriamo il complessivo Novembre + Dicembre definendo il membro MEMBER DATA.[NOVEMBREDICEMBRE] AS '[Data].[novembre] +[Data].[dicembre] # È la stessa situazione considerata nel cubo delle vendite: per calcolare il complessivo si deve definire una misura derivata! mese Marzo Aprile città RE Frutta tipo 44

23 Ritardi: Esempi di interrogazioni MDX Come usiamo MEMBER DATA.[NOVEMBREDICEMBRE]? WITH MEMBER DATA.[NOVEMBREDICEMBRE] AS '[Data].[novembre] +[Data].[dicembre]' SELECT {[CITTA_ARRIVO].[FRANCIA], [CITTA_ARRIVO].[ITALIA]} ON COLUMNS, {DATA.[NOVEMBREDICEMBRE] } ON ROWS FROM RITARDI WITH MEMBER DATA.[NOVEMBREDICEMBRE] AS '[Data].[novembre] +[Data].[dicembre]' SELECT {[CITTA_ARRIVO].[FRANCIA], [CITTA_ARRIVO].[ITALIA]} ON COLUMNS, {DATA.[NOVEMBREDICEMBRE], [Data].[novembre], [Data].[dicembre] } ON ROWS FROM RITARDI WITH MEMBER DATA.[OTTOBREDICEMBRE] AS '[Data].[ottobre] +[Data].[dicembre]' SELECT {[CITTA_ARRIVO].[FRANCIA], [CITTA_ARRIVO].[ITALIA]} ON COLUMNS, {DATA.[OTTOBREDICEMBRE], [Data].[ottobre], [Data].[dicembre], [Data].[ottobre].[15] } ON ROWS FROM RITARDI NB: Si usa ottobre al posto di novembre perchè per ottobre ci sono più date e si può quindi verificare la risposta se tra i membri c è sia OTTOBREDICEMBRE, che ottobre, che una data di ottobre 45 Ritardi: Esempi di interrogazioni MDX Per visualizzare RAPPORTO rispetto a NOVEMBREDICEMBE:! Prima la somma e poi il rapporto: DATA.[NOVEMBREDICEMBRE] avrà SOLVE_ORDER = 0 e MEASURES.[RAPPORTO] avrà SOLVE_ORDER = 1! Invertendo i valori di SOLVE_ORDER! Verificare i valori di default di SOLVE_ORDER: WITH MEMBER MEASURES.[RAPPORTO] AS '[Measures].[Numritardi] / [Measures].[Count]' MEMBER DATA.[NOVEMBREDICEMBRE] AS '[Data].[novembre] +[Data].[dicembre]' SELECT { [Measures].[Numritardi], [Measures].[Count], MEASURES.[RAPPORTO] } ON COLUMNS, { [Data].[novembre], [Data].[dicembre],DATA.[NOVEMBREDICEMBRE] } ON ROWS FROM RITARDI Alla prima misura definita (MEASURES.[RAPPORTO] ) viene assegnato un SOLVE_ORDER più alto rispetto alla seconda (MEASURES.[RAPPORTO]). 46

24 Esercizio proposto! Nell esempio, l analisi è stata fatta a livello di volo giornaliero! Per fare un esempio di schema temporale, consideriamo un analisi a minor livello di dettaglio, senza considerare il volo, ovvero DIMENSIONI = {DATA, COMPAGNIA, AEROPORTO_PARTENZA, CITTA_ARRIVO} % Misura RITARDO calcolato come media (glossario delle misure) RITARDO = AVG(VOLOGIORN.RITARDO) Un evento primario è inteso a misurare il ritardo medio dei voli per una data, di una compagnia, in un aeroporto di partenza e per una città di arrivo % Operatore di aggregazione per RITARDO : AVG 47 Altri operatori di aggregazione! Oltre agli operatori di aggregazione standard (sum, count, min, max, avg) se ne possono definire altri particolari e più complessi! Esempio: Misura NUM_VOLI_IN_RITARDO per analizzare il numero di voli che sono stati almeno una volta in ritardo, ovvero tali per cui esiste almeno un evento primario con NUMRITARDI=1 " È facile verificare che occorre contare negli eventi primari con NUMRITARDI=1 il CODVOLO in modo distinto: where NUMRITARDI=1 count(distinct CODVOLO)! Tutti gli operatori di aggregazione (standard e complessi) devono essere definiti nel sistema OLAP " È buona norma comunque verificarne il risultato anche in relazione attraverso SQL, ovvero verificare il calcolo in SQL sugli eventi primari " Gli eventi primari sono disponibili in forma relazionale nello schema logico del DM, ovvero dopo la progettazione logica e dopo aver alimentato i dati : quindi la verifica deve essere fatta attraverso SQL nel DM alimentato. 48

25 Altri operatori di aggregazione : NUM_VOLI_IN_RITARDO! Esempio: Misura NUM_VOLI_IN_RITARDO where NUMRITARDI=1 count(distinct CODVOLO)! Calcolo in SQL SELECT VOLO.COMPAGNIA, count(distinct RITARDI.CODVOLO ) as NUM_VOLI_IN_RITARDO FROM RITARDI INNER JOIN VOLO ON RITARDI.CODVOLO = VOLO.CODVOLO where RITARDI.NUM_RITARDI = 1 group by VOLO.COMPAGNIA! Riportiamo anche NUM_RITARDI SELECT VOLO.COMPAGNIA, count(distinct RITARDI.CODVOLO) as NUM_VOLI_IN_RITARDO, SUM(NUM_RITARDI) as NUM_RITARDI FROM RITARDI INNER JOIN VOLO ON RITARDI.CODVOLO = VOLO.CODVOLO where RITARDI.NUM_RITARDI = 1 group by VOLO.COMPAGNIA 49 Altri operatori di aggregazione : NUM_VOLI_IN_RITARDO! Verifichiamo anche altri pattern {COMPAGNIA, STATO_ARRIVO} {COMPAGNIA, STATO_PARTENZA, STATO_ARRIVO} {COMPAGNIA, STATO_ARRIVO, MESE}! Nell ultimo pattern si nota che se si aggrega rispetto alla dimensione data, i valori delle due misure coincidono, in quanto in una data si può avere una sola volta un volo e quindi il count distinct è uguale a count normale 50

26 Altri operatori di aggregazione : NUM_VOLI_IN_RITARDO! Riportiamo l SQL per l ultimo pattern SELECT COMPAGNIA, STATO as STATO_ARRIVO, DATEPART(month,DATA) AS MESE, count(distinct RITARDI.CODVOLO ) as NUM_VOLI_IN_RITARDO, SUM(NUM_RITARDI) as NUM_RITARDI FROM RITARDI INNER JOIN CITTA ON CITTA_ARRIVO = CITTA INNER JOIN VOLO ON RITARDI.CODVOLO = VOLO.CODVOLO where NUM_RITARDI = 1 group by COMPAGNIA, STATO, DATEPART(month,DATA)! Si noti l uso della funzione DATEPART per estrarre da una data il mese e quindi raggruppare rispetto al mese 51