Ritardi e Biglietti

Biglietti e Ritardi: schema E/R
1
Ritardi: Progettazione dello schema di Fatto

Definire uno schema di fatto per analizzare i ritardi; in particolare
l’analisi deve considerare l’aeroporto di partenza, mentre per quello
d’arrivo basta considerare solo la citta e lo stato
1.
2.
3.
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
2
Ritardi: Progettazione dello Schema di Fatto
4.
Si modifica l’albero eliminando CODVOLO per CITTA_ARRIVO, ovvero
riportando CITTA_ARRIVO come figlio diretto della radice; questa modifica
deriva dalla specifica di analizzare i ritardi direttamente rispetto alla città di
arrivo e quindi di far diventare CITTA_ARRIVO una dimensione.
5.
Scelta delle Dimensioni :
{DATA, CODVOLO, CITTA_ARRIVO}
quindi tra le dimensioni ho tutti gli
attributi chiave ovvero questo è uno
schema transazionale.
Si noti che tra le dimensioni esiste la
dipendenza funzionale
CODVOLO  CITTA_ARRIVO
Pertanto quando si visualizzerà il cubo
(ovvero, quando faremo dei roll-up e drilldown) se visualizzo il livello CODVOLO
(ovvero considero un pattern contenente
CODVOLO) i roll-up ed i drill-down lungo la
dimensione CITTA_ARRIVO non modificheranno il valore visualizzato delle misure:
infatti fissato il CODVOLO ho un’unica CITTA_ARRIVO e quindi raggruppando su
STATO_ARRIVO il valore delle misure non cambia (vedi pag. 14)
3
Ritardi: Progettazione dello Schema di Fatto
6.
7.
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
4
Ritardi: Progettazione dello Schema di Fatto
8.
Come ultimo passo devo definire il “glossario delle misure” ovvero
devo stabilire come calcolare il valore delle misure per gli eventi
primari; in questo caso lo schema è transazionale, quindi il valore
della misura RITARDO corrisponde direttamente al valore dell’attributo
RITARDO del DB operazionale (non occorre raggruppare rispetto alle
dimensioni)
5
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
6
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 …).
7
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
8
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)
9
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
10
Estrazione Statica
1.
Si devono definire delle interrogazioni sul DB operazionale:


2.

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?
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
11
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
Nel caso in cui RITARDO
SELECT dbo.VOLOGIOR.DATA, dbo.VOLOGIOR.CODVOLO,
è nullo viene conteggiato
dbo.AEROPORTO.CITTA AS CITTA_ARRIVO,
come RITARDO=0
ISNULL(RITARDO,0) AS RITARDO,
NUMRITARDI = CASE
WHEN RITARDO > 5 THEN 1
ELSE 0
END
FROM
dbo.VOLOGIOR INNER JOIN
dbo.VOLO ON dbo.VOLOGIOR.CODVOLO = dbo.VOLO.CODVOLO INNER JOIN
12
dbo.AEROPORTO ON dbo.VOLO.A = dbo.AEROPORTO.SIGLA
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
13
ALIMENTAZIONE del Data Mart: creazione di pacchetti DTS
1.
2.
3.



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
14
Ritardi: Alimentazione del Data Mart - svuoto il DM

Si crea un pacchetto DTS tramite editor

Per prima cosa si inserisce la connessione al DM …
15
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)
16
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
17
Ritardi: Alimentazione del Data Mart - Dimension Table CITTA
18
Ritardi: Alimentazione del Data Mart - Dimension Table CITTA
19
Ritardi: Alimentazione del Data Mart - Dimension Table CITTA
20
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
21
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
22
Ritardi: Alimentazione del Data Mart - Pacchetto complessivo

… si inserisce il pacchetto per copiare i dati da Città …
23
Ritardi: Alimentazione del Data Mart - Pacchetto complessivo

E quindi si crea il flusso di lavoro tra I due pacchetti:
24
Ritardi: Alimentazione del Data Mart - Pacchetto complessivo

Alle varie “Attività Esegui Pacchetto” si può dare un nome (usando le proprietà)
25
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
26
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
27
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
28
Editor del Cubo: definizione delle dimensioni

Il cubo visualizza I dati del seguente DataMart
29
Editor del Cubo: definizione delle dimensioni

Si aggiunge la fact table
30
Editor del Cubo: definizione delle dimensioni

1.
2.
3.
4.
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
31
Editor del Cubo: definizione delle dimensioni

1.
2.
3.
4.
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
32
Editor del Cubo: definizione delle dimensioni
Dimensione CITTA_ARRIVO con due livelli
Citta  Statto

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
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 Snowflake schema)
33
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
...
...
…

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:
livelli
membri
34
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
FRANCIA
ALL
LONDRA
INGHIL
ALL
...
...
…
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
35
Dimensioni: livello (ALL) e membro ALL in MDX

I membri di una dimensione sono ordinati:
1.
2.
3.
4.
5.
6.
7.
8.
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])
36
Dimensioni: livello (ALL) e membro ALL in MDX


Dimensione CITTA_ARRIVO senza il livello (ALL)
CITTA
STATO
MARSIGLIA
FRANCIA
PARIGI
FRANCIA
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])
37
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)
38
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}
39
Ritardi: Esempi di interrogazioni MDX
1.
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.
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:
40
Ritardi: Esempi di interrogazioni MDX
3.
Consideriamo la misura RAPPORTO, definita (tramite WITH MEMBER) come
rapporto tra numero di voli in ritardo (NumRitardi) e numero di voli complessivi
(Count)
MEMBER MEASURES.[RAPPORTO] AS '[Measures].[Numritardi] / [Measures].[Count]’
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]
città
È la stessa situazione considerata
nel cubo delle vendite:
per calcolare il complessivo si deve
definire una misura derivata!
42 58
mese
RE
tipo
Frutta
Marzo Aprile
41
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 …
42
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]).
43
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
44
Biglietti: albero degli attributi
45
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)
46
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à”.

47
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
48
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
49
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
50
Uso delle viste per definire misure e dimensioni

Verifica dei risultati
51
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)
52