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 Si costruisce l’albero degli attributi basato sull’entità VOLOGIORN (tale entità ha come chiave {DATA,CODVOLO}) Si modifica l’albero aggiungendo la dipendenza CITTA  STATO Si modifica l’albero eliminando A-SIGLA

Ritardi: Progettazione dello Schema di Fatto 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. 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 drill-down) 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)

Ritardi: Progettazione dello Schema di Fatto Si definisce la misura RITARDO e si suppone che essa sia aggregata rispetto a tutte le dimensioni tramite media: RITARDO (AVG) 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

Ritardi: Progettazione dello Schema di Fatto 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 (non occorre raggruppare rispetto alle dimensioni)

Ritardi: Progettazione dello Schema di Fatto 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 > 5 then NUMRITARDI = 1 else NUMRITARDI = 0 NUMRITARDI è una misura derivata che verrà aggregata tramite somma. 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

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 …).

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 In questa prima soluzione, 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)

DataMart 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; Inoltre aggiungere l’attributo NUMRITARDI per la nuova misura) Alimentazione del DataMart: Estrazione statica L’estrazione statica che 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

Estrazione Statica Si devono definire delle interrogazioni sul DB operazionale: Una query per definire il contenuto della Fact Table Una query per ciascuna Dimensional table Si devono eseguire le query sul DB operazionale (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? Nel DB Operazionale, tramite delle viste; chi deve analizzare i dati ha i permessi di leggere e quindi creare delle viste sul DB operazionale, mentre non ha I permessi per creare tabelle e/o modificare le tabelle esistenti 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

è nullo viene conteggiato Ritardi: Estrazione statica Fact Table Essendo un DM transazionale, è semplice, non si deve raggruppare; unica nota: per CITTA_ARRIVO devo fare un join con AEROPORTO). Salvo ed edito la view aggiungendo e calcolando NUMRITARDI CREATE VIEW dbo.VistaRitardi AS SELECT dbo.VOLOGIOR.DATA, dbo.VOLOGIOR.CODVOLO, dbo.AEROPORTO.CITTA AS CITTA_ARRIVO, 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 Nel caso in cui RITARDO è nullo viene conteggiato come RITARDO=0

Ritardi: Estrazione statica Le Dimensional table sono in questo caso semplici interrogazioni su una singola tabella del DBO: è inutile creare una vista del tipo CREATE VIEW dbo.VistaVista AS SELECT CODVOLO, ORA_PARTENZA, COMPAGNIA, DA FROM dbo.VOLO questa “query” viene fatta direttamente nel DTS In altri casi è consigliabile creare una vista (anche in più passaggi, cioè usando piu’ viste) come nel caso della dimensione FASCIA_ETA CREATE VIEW CLIENTE_ETA AS select CF, year(getdate()) - ANNONASC AS ETA from CLIENTE CREATE VIEW FASCIA_ETA AS SELECT CF, FASCIAETA = CASE WHEN (ETA >0 AND ETA <= 10) THEN 'BIMBO' WHEN (ETA >10 AND ETA < 18) THEN 'RAGAZZO' WHEN (ETA >=18 AND ETA <= 50) THEN 'ADULTO' ELSE 'VECCHIO' END FROM CLIENTE_ETA

ALIMENTAZIONE del Data Mart: creazione di pacchetti DTS Si svuota il contenuto del DM: per testare le procedure di estrazione statica 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 …) 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 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 è conveniente (è più semplice) creare tale pacchetto tramite “Importa Dati” applicato al DM, infatti devo semplicemente copiare nel DM il contenuto di una vista o di una tabella del DO 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

Si crea un pacchetto DTS tramite editor Ritardi: Alimentazione del Data Mart - svuoto il DM Si crea un pacchetto DTS tramite editor Per prima cosa si inserisce la connessione al DM …

Si crea un pacchetto DTS tramite editor 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)

Nel DB operazionale la città e lo stato sono specificati in AEROPORTO 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

Ritardi: Alimentazione del Data Mart - Dimension Table CITTA

Ritardi: Alimentazione del Data Mart - Dimension Table CITTA

Ritardi: Alimentazione del Data Mart - Dimension Table CITTA

Si salva il pacchetto per alimentare 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 in precedenza

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à …

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à)

Ritardi: Definizione del Cubo Ritardi in Analysis Service Si considera il DM con lo schema di pag. 10 (alla Fact Table è stato aggiunto l’attributo NUMRITARDI) e si realizza il seguente cubo: 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

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 dimensione dello schema di fatto occorre definire nel cubo tante dimensioni quanti sono i cammini di aggregazione Dimensione CODVOLO: Tale dimensione 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

Editor del Cubo: definizione delle dimensioni Diensione CITTA_ARRIVO Tale dimensione corrisponde ad un solo cammino di aggregazione e quindi viene realizzata nel cubo attraverso una sola dimensioni: Dimensione CITTA_ARRIVO con due livelli Citta  Statto

Editor del Cubo: definizione delle dimensioni Il cubo visualizza I dati del seguente DataMart

Editor del Cubo: definizione delle dimensioni Si aggiunge la fact table

Editor del Cubo: definizione delle dimensioni Dimensione Volo_Compagnia con due livelli CodVolo  Compagnia Si aggiunge la Dimensional Table che “contiene” tale dimensione Si verifica che sia corretto il collegamento realizzato in automatico sulla base della Foreign Key Si seleziona l’attributo Compagnia e si genera la Dimensione Si aggiunge alla dimensione il livello CodVolo

Editor del Cubo: definizione delle dimensioni Dimensione Volo_Partenza con quattro livelli CodVolo  AeroPorto  Citta  Stato 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 Si verifica che sia corretto il collegamento realizzato in automatico sulla base delle Foreign Key Si seleziona l’attributo Stato (ultimo livello) e si genera la Dimensione Si aggiungono alla dimensione i livelli Citta, Sigla e CodVolo

Editor del Cubo: definizione delle dimensioni Dimensione CITTA_ARRIVO con due livelli Citta  Statto Si aggiunge le Dimensional Table che “contiene” tale dimensione 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)

Dimensioni: livello (ALL) e membro ALL Dimensione CITTA_ARRIVO con due livelli : Citta  Statto livelli CITTA STATO (ALL) MARSIGLIA FRANCIA ALL PARIGI LONDRA INGHIL ... … 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:

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 LONDRA INGHIL ... … 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

Dimensioni: livello (ALL) e membro ALL in MDX I membri di una dimensione sono ordinati: Totale CITTA_ARRIVO FRANCIA MARSIGLIA PARIGI INGHIL LONDRA ITALIA … 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 SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI equivale a SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[(Totale)].[Totale CITTA_ARRIVO])

Dimensioni: livello (ALL) e membro ALL in MDX Dimensione CITTA_ARRIVO senza il livello (ALL) CITTA STATO MARSIGLIA FRANCIA PARIGI 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])

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)

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}

Ritardi: Esempi di interrogazioni MDX 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. 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:

Ritardi: Esempi di interrogazioni MDX 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]’ 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] tipo 42 58 mese città Marzo Frutta RE Aprile È la stessa situazione considerata nel cubo delle vendite: per calcolare il complessivo si deve definire una misura derivata!

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 …

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]).

Parte Seconda: Analisi dei Biglietti Supponiamo di voler analizzare dello schema E/R iniziale anche i biglietti e quindi di considerare come Fatto l’entità Biglietti Lo schema di Fatto Biglietti verrà implementato nello stesso DataMart che contiene già lo schema Ritardi; in questo modo I due schemi di fatto possono, condividere nello schema logico, alcune Dimensional table

Biglietti: albero degli attributi

BIGLIETTI: Dimensioni, Misure e Schema Dimensioni = {CodVolo, Data, Check-in,AnnoNascitaCliente} Tra le dimensioni non ho tutti gli attributi chiave di BIGLIETTO GLOSSARIO delle MISURE NUM. BIGLIETTI = COUNT(*) INCASSO = SUM(BIGLIETTO.tariffa) NUM. COLLI = SUM(BIGLIETTO.NumeroColli)

BIGLIETTI: Modifica dello schema di fatto Si aggiunge allo schema di fatto la dipendenza CITTA  STATO Tale dipendenza non era inizialmente espressa nello schema E/R e si può rilevare ed aggiungere allo schema E/R durante la fase di ricognizione dei dati. Oppure può essere rilevata ed aggiunta dal progettista durante la costruzione dell’albero degli attributi (aggiunta di una dipendenza funzionale). Oppure può essere rilevata durante l’analisi del carico di lavoro, ad esempio, analizzando la possibilità di fare una interrogazione del tipo “per ogni stato, confrontare gli incassi delle sue città”.

Uso delle viste per definire misure e dimensioni Calcoliamo CHECKIN tramite una vista: l’attributo CHECKIN dipende solo dalla chiave di BIGLIETTO quindi la vista conterrà solo la chiave e l’attributo calcolato In questo caso conviene usare il LEFT JOIN come illustrato nell’esempio SELECT Biglietti.K AS K, CHECKIN = CASE WHEN (CheckIn.K is null) THEN 0 ELSE 1 END FROM Biglietti LEFT OUTER JOIN CheckIn ON Biglietti.K = CheckIn.K

Uso delle viste per definire misure e dimensioni Conviene aggiungere alla vista anche il calcolo del NUMCOLLI in quanto anche tale valore dipende solo dalla chiave di BIGLIETTO: CREATE VIEW VISTACHECKIN AS SELECT BIGLIETTO.NUMBIGLIETTO AS NB_BIGLIETTO, CHECK_IN = CASE WHEN ([CHECK-IN].NUMBIGLIETTO IS NULL) THEN 0 ELSE 1 END, ISNULL( [CHECK-IN].NUMCOLLI,0) AS NUMCOLLI FROM BIGLIETTO LEFT OUTER JOIN [CHECK-IN] ON BIGLIETTO.NUMBIGLIETTO = [CHECK-IN].NUMBIGLIETTO

Uso delle viste per definire misure e dimensioni Definizione di una unica vista per alimentare la Fact table CREATE VIEW dbo.VIEW1 AS SELECT dbo.BIGLIETTO.DATA, dbo.VISTACHECKIN.CHECK_IN, dbo.FASCIAETA.FASCIAETA, count(*) as NUMBIGLIETTI, SUM(dbo.VISTACHECKIN.NUMCOLLI) as NUMCOLLI, SUM(dbo.BIGLIETTO.TARIFFA) AS INCASSO FROM dbo.BIGLIETTO INNER JOIN dbo.FASCIAETA ON dbo.BIGLIETTO.CLIENTE = dbo.FASCIAETA.CF INNER JOIN dbo.VISTACHECKIN ON dbo.BIGLIETTO.NUMBIGLIETTO = dbo.VISTACHECKIN.NB_BIGLIETTO group by dbo.BIGLIETTO.DATA, dbo.VISTACHECKIN.CHECK_IN, dbo.FASCIAETA.FASCIAETA

Uso delle viste per definire misure e dimensioni Verifica dei risultati

Biglietti - Progettazione Logica Un DataMart può contenere più schemi di fatto e quindi, nella progettazione logica relazionale, uno schema relazionale di DataMart può contenere più Fact Table relative ai vari schemi di fatto e i vari schemi logici possono condividere alcune dimensional table SNOWFLAKE SCHEMA di RITARDI: 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) Per realizzare lo SNOWFLAKE SCHEMA di BIGLIETTI, oltre ad inserire la FACT TABLE, si modificano le Dimensional Table già presenti: FACT TABLE RITARDI(CODVOLO:VOLO,DATA,CHECK_IN,ANNONASCITACLIENTE,INCASSO,NUM_BIGLIETTI, NUM_COLLI) DIMENSION TABLEs VOLO(CODVOLO,COMPAGNIA, AEROP_PART:AEROPORTO, AEROP_ARRIVO:AEROPORTO,ORAPARTENZA ) AEROPORTO(SIGLA, CITTA:CITTA) CITTA (CITTA,STATO)