1 Biglietti e Ritardi: schema E/R. 2 Definire uno schema di fatto per analizzare i ritardi; in...

1

Biglietti e Ritardi: schema E/R

2

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 STATO3. Si modifica l’albero eliminando A-SIGLA

Ritardi: Progettazione dello schema di Fatto

3

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

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 ladipendenza funzionale CODVOLO CITTA_ARRIVOPertanto 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)

4

6. Si definisce la misura RITARDO e si suppone che essa sia aggregata rispetto a tutte le dimensioni tramite media: RITARDO (AVG)


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

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 (non occorre raggruppare rispetto alle dimensioni)


6

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

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

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

9

Ritardi - Progettazione Logica

STAR SCHEMA: FACT TABLE

RITARDI(CODVOLO:VOLO,DATA,CITTA_ARRIVO: CITTAARRIVO,RITARDO,NUMRITARDI)

DIMENSION TABLEsVOLO(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 TABLEsVOLO(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

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 staticaL’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

11

Estrazione Statica1. 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

1. Necessità di operare su due DB, DBO e DMnon è possibile fare una istruzione SQL su due database …INSERT INTO DM.RITARDI(RITARDO)SELECT RITARDO FROM DBO.VOLOGIORN

2. 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

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 ASSELECT dbo.VOLOGIOR.DATA, dbo.VOLOGIOR.CODVOLO, dbo.AEROPORTO.CITTA AS CITTA_ARRIVO,

ISNULL(RITARDO,0) AS RITARDO,NUMRITARDI = CASE

WHEN RITARDO > 5 THEN 1ELSE 0

ENDFROM 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

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 ASSELECT CODVOLO, ORA_PARTENZA, COMPAGNIA, DAFROM 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 ASselect CF, year(getdate()) - ANNONASC AS ETAfrom CLIENTE

CREATE VIEW FASCIA_ETA ASSELECT 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'

ENDFROM CLIENTE_ETA

14

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

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

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 nell’ordine 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 l’editor per pacchetti DTS

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

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 queryselect distinct CITTA,STATO from AEROPORTO

18


19


20


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

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


… si inserisce il pacchetto per copiare i dati da Città …

24


E quindi si crea il flusso di lavoro tra I due pacchetti:

25


Alle varie “Attività Esegui Pacchetto” si può dare un nome (usando le proprietà)

26

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

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

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:


29


Il cubo visualizza I dati del seguente DataMart

30


Si aggiunge la fact table

31


Dimensione Volo_Compagnia con due livelli CodVolo Compagnia

1. Si aggiunge la Dimensional Table che “contiene” tale dimensione2. Si verifica che sia corretto il collegamento realizzato in automatico sulla base

della Foreign Key3. Si seleziona l’attributo Compagnia e si genera la Dimensione4. Si aggiunge alla dimensione il livello CodVolo

32


Dimensione Volo_Partenza con quattro livelli CodVolo AeroPorto Citta Stato

1. Si aggiungono le Dimensional Table che “contengono” tale dimensionenon 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 Key3. Si seleziona l’attributo Stato (ultimo livello) e si genera la Dimensione4. Si aggiungono alla dimensione i livelli Citta, Sigla e CodVolo

33


1. Si aggiunge le Dimensional Table che “contiene” tale dimensioneoccorre 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

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:

35

Dimensioni: livello (ALL) e membro ALL in MDX

SELECT { [Measures].[Ritardo] } ON COLUMNSFROM 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

CITTA STATO (ALL)

MARSIGLIA FRANCIA ALL

PARIGI FRANCIA ALL

LONDRA INGHIL ALL

... ... …

SELECT { [Measures].[Ritardo] } ON COLUMNSFROM RITARDIWHERE ([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

Dimensioni: livello (ALL) e membro ALL in MDX

SELECT { [Measures].[Ritardo] } ON COLUMNSFROM 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

I membri di una dimensione sono ordinati:1. Totale CITTA_ARRIVO2. FRANCIA3. MARSIGLIA4. PARIGI5. INGHIL6. LONDRA7. ITALIA8. …

Questo è l’ordine con il quale i membri vengono illustrati in un asse, ad esempio nella query:

SELECT [CITTA_ARRIVO].Members ON COLUMNSFROM RITARDI

SELECT { [Measures].[Ritardo] } ON COLUMNSFROM RITARDI WHERE ([CITTA_ARRIVO].[(Totale)].[Totale CITTA_ARRIVO])

37

Dimensioni: livello (ALL) e membro ALL in MDX Dimensione CITTA_ARRIVO senza il livello (ALL)

CITTA STATO

MARSIGLIA FRANCIA

PARIGI FRANCIA

LONDRA INGHIL

... ...

SELECT { [Measures].[Ritardo] } ON COLUMNSFROM RITARDI

Adesso il primo membro della dimensione è [CITTA_ARRIVO].[FRANCIA], quindi In base all’interpretazione di default, la query

equivale aSELECT { [Measures].[Ritardo] } ON COLUMNSFROM RITARDIWHERE ([CITTA_ARRIVO].[FRANCIA])

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 Ritardigroup 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=CITTAgroup by STATO Se RITARDO è un integer, nel calcolo di

AVG di deve trasformare in real: viene usato il casting a decimal (oppure float)

39

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:

Come verifica consideriamo un pattern secondario senza CODVOLO: {STATO_PARTENZA,CITTA_ARRIVO}

Per ilCODVOLO=V1si ha una sola città di arrivo (ROMA)

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

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 membroMEMBER DATA.[NOVEMBREDICEMBRE] AS '[Data].[novembre] +[Data].[dicembre]


tipo42 58

mese

città

MarzoFrutta

RE

Aprile

È la stessa situazione considerata nel cubo delle vendite:

per calcolare il complessivo si deve definire una misura derivata!

42

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

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

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

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

45

Biglietti: albero degli attributi

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

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à”.

48

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 calcolatoIn questo caso conviene usare il LEFT JOIN come illustrato nell’esempio

SELECT Biglietti.K AS K,CHECKIN = CASE WHEN (CheckIn.K is null) THEN 0ELSE 1END

FROM Biglietti LEFT OUTER JOIN CheckIn ON Biglietti.K = CheckIn.K

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 ASSELECT BIGLIETTO.NUMBIGLIETTO AS NB_BIGLIETTO, CHECK_IN = CASE

WHEN ([CHECK-IN].NUMBIGLIETTO IS NULL) THEN 0ELSE 1

END,ISNULL( [CHECK-IN].NUMCOLLI,0) AS NUMCOLLIFROM BIGLIETTO LEFT OUTER JOIN [CHECK-IN] ON

BIGLIETTO.NUMBIGLIETTO = [CHECK-IN].NUMBIGLIETTO

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

Uso delle viste per definire misure e dimensioni Verifica dei risultati

52

Biglietti - Progettazione Logica

SNOWFLAKE SCHEMA di RITARDI: FACT TABLE

RITARDI(CODVOLO:VOLO,DATA,CITTAARRIVO:CITTA,RITARDO,NUMRITARDI)

DIMENSION TABLEsVOLO(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 TABLERITARDI(CODVOLO:VOLO,DATA,CHECK_IN,ANNONASCITACLIENTE,INCASSO,NUM_BIGLIETTI, NUM_COLLI)

DIMENSION TABLEsVOLO(CODVOLO,COMPAGNIA, AEROP_PART:AEROPORTO, AEROP_ARRIVO:AEROPORTO,ORAPARTENZA AEROP_ARRIVO:AEROPORTO,ORAPARTENZA )AEROPORTO(SIGLA, CITTA:CITTA)CITTA (CITTA,STATO)

1 Biglietti e Ritardi: schema E/R. 2 Definire uno schema di fatto per analizzare i ritardi; in...

Documents

Transcript of 1 Biglietti e Ritardi: schema E/R. 2 Definire uno schema di fatto per analizzare i ritardi; in...