Post on 01-May-2015
transcript
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)
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
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)
Ritardi: Progettazione dello Schema di Fatto
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
Ritardi: Alimentazione del Data Mart - Dimension Table CITTA
19
Ritardi: Alimentazione del Data Mart - Dimension Table CITTA
20
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
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
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
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:
Editor del Cubo: definizione delle dimensioni
29
Editor del Cubo: definizione delle dimensioni
Il cubo visualizza I dati del seguente DataMart
30
Editor del Cubo: definizione delle dimensioni
Si aggiunge la fact table
31
Editor del Cubo: definizione delle dimensioni
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
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 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
Editor del Cubo: definizione delle dimensioni
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]
Ritardi: Esempi di interrogazioni MDX
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] ?
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 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:
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
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)