Biglietti e Ritardi: schema E/R

Biglietti e Ritardi: schema E/R Ritardi: Progettazione dello schema di Fatto! Definire uno schema di fatto per analizzare i ritardi; in particolare l analisi deve considerare l aeroporto di partenza, mentre per quello d arrivo basta considerare solo la citta e lo stato 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 1 2 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. Ritardi: Progettazione dello Schema di Fatto 6. Si definisce la misura RITARDO e si suppone che essa sia aggregata rispetto a tutte le dimensioni tramite media: RITARDO (AVG) 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. 14) 7. 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 3 4

Ritardi: Progettazione dello Schema di Fatto 8. Come ultimo passo devo definire il glossario delle misure ovvero devo stabilire come calcolare il valore delle misure per gli eventi primari; in questo caso lo schema è transazionale, quindi il valore della misura RITARDO corrisponde direttamente al valore dell attributo RITARDO del DB operazionale e non occorre raggruppare rispetto alle dimensioni Ritardi: Progettazione dello schema di Fatto a partire dallo schema relazionale del DB operazionale! Oltre allo schema E/R normalmente è disponibile anche lo schema logico (relazionale) del DB operazionale! Si suppone che i due schemi siano equivalenti (ovvero che questo sia lo schema relazionale ottenuto da un corretto progetto logico ).! ERRATA/CORRIGE Nella versione originale delle dispense la misura RITARDO e definita raggruppando sulle dimensioni : {DATA, CODVOLO, CITTA_ARRIVO} Questo è sbagliato, anche se il risultato non cambia: siccome DATA,CODVOLO è una chiave, in un gruppo del GROUP BY ci può essere al massimo una tupla e quindi il raggruppamento non ha effetto e la funzione aggregata (AVG,MIN, MAX) restituisce il singolo valore della misura RITARDO 5 6 Ritardi: Progettazione dello schema di Fatto a partire dallo schema relazionale del DB operazionale! Ovviamente lo schema logico relazionale è indispensabile nella fase di progettazione dell alimentazione, durante la quale si deve conoscere l effettiva struttura del DB dal quale verranno prelevati i dati! Conviene effettuare la progettazione concettuale del Datawarehouse (gli schemi di fatto) a partire dallo schema relazionale? " Con uno schema E/R è più semplice la progettazione, essendo in esso evidenziate le associazioni e le relative cardinalità " A volte lo schema E/R non è disponibile ed occorre ricavarlo dallo schema logico secondo un procedimento di reverse engineering " In presenza dello schema relazionale si può utilizzare lo strumento Wand Ritardi - Progettazione Logica! STAR SCHEMA: " FACT TABLE RITARDI(CODVOLO:VOLO,DATA,CITTA_ARRIVO: CITTAARRIVO,RITARDO,) " 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) " DIMENSION TABLEs VOLO(CODVOLO,COMPAGNIA, AEROP_PART:AEROPORTO) AEROPORTO(SIGLA, CITTA_PART:CITTA) CITTA (CITTA,STATO) 7 8

Ritardi: SNOWFLAKE SCHEMA! Si usa lo snowflake schema riportato in figura (rispetto a quello della pagina precedente sono semplicemente cambiati i nomi di alcuni attributi) Ritardi: misure derivate! Supponiamo di voler analizzare anche il numero dei voli giornalieri che hanno subito un ritardo! Allo Schema di Fatto si aggiunge una misura (NUMRITARDI) a valore booleano calcolata come if RITARDO <> 0 then INRITARDO = 1 else INRITARDO = 0 NUMRITARDI è una misura derivata che verrà aggregata tramite somma. 9! A che punto del progetto si introduce la misura NUMRITARDI? " Sicuramente conviene indicarla durante la progettazione concettuale, e pertanto indicarla nello schema di fatto. Quindi si decide in che punto implementarla. Prescindendo da problemi di efficienza, " Se l espressione che definisce la misura è (facilmente) implementabile in Analysis Services, si può introdurla nella realizzazione dei cubi " altrimenti conviene introdurla già nella progettazione logica in modo da poterla calcolare (in SQL) e quindi memorizzare nella Fact Table 10 Ritardi: misure derivate! Modifichiamo la Fact Table Ritardi aggiungendo NUMRITARDI. Ritardi: Alimentazione del Data Mart - Fact Table! Alimentazione della fact table: definiamo una view (nel DB dei Biglietti) che contiene questi attributi (nota che per CITTA_ARRIVO devo fare un join con AEROPORTO).! Come calcolare la misura NUMRITARDI in SQL? 1. Si aggiunge alla tabella VOLOGIOR e si calcola tramite update (vedi dispense su Esempio Biglietti pagina 14); questa soluzione mi costringe a modificare lo schema del DB operazionale e ovviamente non sempre è possibile 2. Si definisce tramite una vista nel DB Operazionale, o meglio, si introduce nella vista che definisce l alimentazione del DM 3. Si definisce durante l alimentazione del DataMart utilizzando il trasferimento dati basato su una opportuna query.! Verrà utilizzato il secondo metodo, perchè facilmente implementabile grazie all istruzione CASE di SQL (vedi esempio delle telefonate) 11! 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 ISNULL(RITARDO,0) <> 0 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 12

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: 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)! 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! Come verifica consideriamo un pattern secondario senza CODVOLO: {STATO_PARTENZA,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) 13 14 Ritardi: Esempi di interrogazioni MDX 1. Calcolare ogni misura per le compagnie AIRFRANCE e ALITALIA in ottobre e novembre del 1998 : Ritardi: Esempi di interrogazioni MDX 3. Consideriamo la misura RAPPORTO, definita (tramite 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]! 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 è. Consideriamo il complessivo Novembre + dicembre MEMBER DATA.[NOVEMBREDICEMBRE] AS '[Data].[novembre] +[Data].[dicembre]'! 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 Visualizzazione Alternativa: si mettono le città di arrivo sulle colonne e Measures.RITARDO nella WHERE: 15! Verificare I valori di default di SOLVE_ORDER 16

Alimentazione del Data Mart: creazione di pacchetti DTS 1. Si svuota il contenuto del DM: è utile per testare le procedure di estrazione statica 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 " Si definisce un pacchetto DTS per ogni passo. Siccome in ogni passo si devono semplicemente copiare delle tabelle è conveniente (è più semplice) creare tale pacchetto tramite Importa Dati " In uno star schema si possono copiare tutte le dimension table in un solo passo 3. Si copia il contenuto della vista nella fact table Ritardi: Alimentazione del Data Mart - svuoto il DM! Si crea un pacchetto DTS tramite editor " Per prima cosa si inserisce la connessione al DM! 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 17 18 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) 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 19 20

Ritardi: Alimentazione del Data Mart - Dimension Table CITTA Ritardi: Alimentazione del Data Mart - Dimension Table CITTA 21 22 Ritardi: Alimentazione del Data Mart - Dimension Table CITTA 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 a pagina 5 23 24

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 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo " si inserisce il pacchetto per copiare i dati da Città 25 26 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo " E quindi si crea il flusso di lavoro tra I due pacchetti: Ritardi: Alimentazione del Data Mart - Pacchetto complessivo " Alle varie Attività Esegui Pacchetto si può dare un nome (usando le proprietà) 27 28