La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

1 Biglietti e Ritardi: schema E/R. 2 Definire uno schema di fatto per analizzare i ritardi; in particolare lanalisi deve considerare laeroporto di partenza,

Presentazioni simili


Presentazione sul tema: "1 Biglietti e Ritardi: schema E/R. 2 Definire uno schema di fatto per analizzare i ritardi; in particolare lanalisi deve considerare laeroporto di partenza,"— Transcript della presentazione:

1 1 Biglietti e Ritardi: schema E/R

2 2 Definire uno schema di fatto per analizzare i ritardi; in particolare lanalisi deve considerare laeroporto di partenza, mentre per quello darrivo basta considerare solo la citta e lo stato 1. Si costruisce lalbero degli attributi basato sullentità VOLOGIORN (tale entità ha come chiave {DATA,CODVOLO}) 2. Si modifica lalbero aggiungendo la dipendenza CITTA STATO 3. Si modifica lalbero eliminando A-SIGLA Ritardi: Progettazione dello schema di Fatto

3 3 4. Si modifica lalbero 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 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 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 ununica CITTA_ARRIVO e quindi raggruppando su STATO_ARRIVO il valore delle misure non cambia (vedi pag. 14)

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

5 5 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 dellattributo RITARDO del DB operazionale (non occorre raggruppare rispetto alle dimensioni) Ritardi: Progettazione dello Schema di Fatto

6 6 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 lespressione 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

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

8 8 Ritardi: Progettazione dello schema di Fatto a partire dallo schema relazionale del DB operazionale Ovviamente lo schema logico relazionale è indispensabile nella fase di progettazione dellalimentazione, durante la quale si deve conoscere leffettiva 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

9 9 Ritardi - Progettazione Logica 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) In questa prima soluzione, per semplicità, non verranno introdotte chiavi surrogate.

10 10 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 lattributo NUMRITARDI per la nuova misura) Alimentazione del DataMart: Estrazione statica Lestrazione 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 è lalimentazione a partire da zero

11 11 Estrazione Statica 1. Si devono definire delle interrogazioni sul DB operazionale: Una query per definire il contenuto della Fact Table Una query per ciascuna Dimensional table 2. 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? 1. 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 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 12 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). 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 Salvo ed edito la view aggiungendo e calcolando NUMRITARDI Nel caso in cui RITARDO è nullo viene conteggiato come RITARDO=0

13 13 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

14 14 1. Si svuota il contenuto del DM: per testare le procedure di estrazione statica Lunico vincolo da rispettare è quello dellintegrità 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: lunico vincolo da rispettare è quello dellintegrità 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 ALIMENTAZIONE del Data Mart: creazione di 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 nellordine stabilito In uno star schema si possono copiare tutte le dimension table in un solo passo 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 leditor per pacchetti DTS

15 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 16 Ritardi: Alimentazione del Data Mart - svuoto il DM Si crea un pacchetto DTS tramite editor … e quindi si scrive listruzione SQL (si noti che occorre cancellare rispettando lordine delle FK)

17 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 18 Ritardi: Alimentazione del Data Mart - Dimension Table CITTA

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

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

21 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 22 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo Si crea un pacchetto DTS complessivo di tutti I pacchetti creati finora, in cui viene imposto lordine di esecuzione Ogni pacchetto viene inserito tramite Attività Esegui Pacchetto che viene collegata al pacchetto creato in precedenza

23 23 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo … si inserisce il pacchetto per copiare i dati da Città …

24 24 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo E quindi si crea il flusso di lavoro tra I due pacchetti:

25 25 Ritardi: Alimentazione del Data Mart - Pacchetto complessivo Alle varie Attività Esegui Pacchetto si può dare un nome (usando le proprietà)

26 26 Ritardi: Definizione del Cubo Ritardi in Analysis Service Si considera il DM con lo schema di pag. 10 (alla Fact Table è stato aggiunto lattributo NUMRITARDI) e si realizza il seguente cubo: Si noti che per la tabella CITTA utilizzata nella definizione della dimensione CITTA_ARRIVO è stato dato lalias per non confonderla con la tabella CITTA nellaltra 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

27 27 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 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

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

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

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

31 31 Editor del Cubo: definizione delle dimensioni Dimensione Volo_Compagnia con due livelli CodVolo Compagnia 1. Si aggiunge la Dimensional Table che contiene tale dimensione 2. Si verifica che sia corretto il collegamento realizzato in automatico sulla base della Foreign Key 3. Si seleziona lattributo Compagnia e si genera la Dimensione 4. Si aggiunge alla dimensione il livello CodVolo

32 32 Editor del Cubo: definizione 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 lattributo Stato (ultimo livello) e si genera la Dimensione 4. Si aggiungono alla dimensione i livelli Citta, Sigla e CodVolo

33 33 Editor del Cubo: definizione delle dimensioni 1. 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 Dimensione CITTA_ARRIVO con due livelli Citta Statto 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)

34 34 Dimensioni: livello (ALL) e membro ALL Dimensione CITTA_ARRIVO con due livelli : Citta Statto CITTASTATO(ALL) MARSIGLIAFRANCIAALL PARIGIFRANCIAALL LONDRAINGHILALL... … 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:

35 35 Dimensioni: livello (ALL) e membro ALL in MDX SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[STATO].[FRANCIA]) Consideriamo la seguente interrogazione MDX, che restituisce il complessivo dei ritardi per tutti i voli con città di arrivo in 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 CITTASTATO(ALL) MARSIGLIAFRANCIAALL PARIGIFRANCIAALL LONDRAINGHILALL... … SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[(Totale)].[Totale CITTA_ARRIVO]) Nello stesso modo, per il complessivo dei ritardi per tutte le città di arrivo, si deve utilizzare il membro ALL In questo modo si raggruppa rispetto al livello (ALL) e si seleziona il membro ALL, pertanto si considerano tutte le città di arrivo

36 36 Dimensioni: livello (ALL) e membro ALL in MDX SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI In base allinterpretazione 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 I membri di una dimensione sono ordinati: 1.Totale CITTA_ARRIVO 2.FRANCIA 3.MARSIGLIA 4.PARIGI 5.INGHIL 6.LONDRA 7.ITALIA 8.… Questo è lordine con il quale i membri vengono illustrati in un asse, ad esempio nella query: SELECT [CITTA_ARRIVO].Members ON COLUMNS FROM RITARDI SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[(Totale)].[Totale CITTA_ARRIVO])

37 37 Dimensioni: livello (ALL) e membro ALL in MDX Dimensione CITTA_ARRIVO senza il livello (ALL) CITTASTATO MARSIGLIAFRANCIA PARIGIFRANCIA LONDRAINGHIL... SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI Adesso il primo membro della dimensione è [CITTA_ARRIVO].[FRANCIA], quindi In base allinterpretazione di default, la query equivale a SELECT { [Measures].[Ritardo] } ON COLUMNS FROM RITARDI WHERE ([CITTA_ARRIVO].[FRANCIA])

38 38 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: select CITTA_ARRIVO, AVG(cast(RITARDO as decimal)) as ritardo from Ritardi group by CITTA_ARRIVO Per verificare la correttezza di RITARDO, calcoliamo tale misura direttamente sugli eventi primari nel DM, utilizzando SQL: 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)

39 39 Ritardi: Osservazione su CODVOLO CITTA_ARRIVO Nella visualizzazione del pattern secondario {CODVOLO,CITTA_ARRIVO} viene evidenziato leffetto della dipendenza tra dimensioni CODVOLO CITTA_ARRIVO: Come verifica consideriamo un pattern secondario senza CODVOLO: {STATO_PARTENZA,CITTA_ARRIVO} Per il CODVOLO=V1 si ha una sola città di arrivo (ROMA)

40 40 1. Calcolare ogni misura per le compagnie AIRFRANCE e ALITALIA in ottobre e novembre del 1998 : Ritardi: Esempi di interrogazioni MDX Nota: Usare {Measures.MEMBERS, Measures.RITARDO}, in quanto loperatore 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 dellAIRFRANCE a novembre con arrivo a Parigi, ma sempre con ritardo =0. Non ci sono stati dei voli dellALITALIA 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:

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

42 42 Come usiamo MEMBER DATA.[NOVEMBREDICEMBRE] ? Ritardi: Esempi di interrogazioni MDX 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 …

43 43 Per visualizzare RAPPORTO rispetto a NOVEMBREDICEMBE: Ritardi: Esempi di interrogazioni MDX Prima la somma e poi il rapporto: DATA.[NOVEMBREDICEMBRE] avrà SOLVE_ORDER = 0 e MEASURES.[RAPPORTO] avrà SOLVE_ORDER = 1 Verificare i valori di default di SOLVE_ORDER: Invertendo i valori 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]).

44 44 Parte Seconda: Analisi dei Biglietti Supponiamo di voler analizzare dello schema E/R iniziale anche i biglietti e quindi di considerare come Fatto lentità 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

45 45 Biglietti: albero degli attributi

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

47 47 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 dellalbero degli attributi (aggiunta di una dipendenza funzionale). Oppure può essere rilevata durante lanalisi del carico di lavoro, ad esempio, analizzando la possibilità di fare una interrogazione del tipo per ogni stato, confrontare gli incassi delle sue città.

48 48 Uso delle viste per definire misure e dimensioni Calcoliamo CHECKIN tramite una vista: lattributo CHECKIN dipende solo dalla chiave di BIGLIETTO quindi la vista conterrà solo la chiave e lattributo calcolato In questo caso conviene usare il LEFT JOIN come illustrato nellesempio 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

49 49 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

50 50 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

51 51 Uso delle viste per definire misure e dimensioni Verifica dei risultati

52 52 Biglietti - Progettazione Logica 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) 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 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) AEROP_ARRIVO:AEROPORTO,ORAPARTENZA DIMENSION TABLEs VOLO(CODVOLO,COMPAGNIA, AEROP_PART:AEROPORTO, AEROP_ARRIVO:AEROPORTO,ORAPARTENZA ) AEROPORTO(SIGLA, CITTA:CITTA) CITTA (CITTA,STATO)


Scaricare ppt "1 Biglietti e Ritardi: schema E/R. 2 Definire uno schema di fatto per analizzare i ritardi; in particolare lanalisi deve considerare laeroporto di partenza,"

Presentazioni simili


Annunci Google