Biglietti: schema E/R
1
Biglietti: albero degli attributi
2
Biglietti: albero degli attributi
3
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)
4
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à”.
5
Progettazione logica


Riportando le dimensioni
degeneri nella fact table e
traducendo la gerarchia
condivisa in una sola
dimension table, si ottiene
questo star schema :
Se per la gerarchia condivisa si effettua uno snowflake sul primo
attributo condiviso (la SIGLA) si ottiene questo schema :
6
Alimentazione del Data Mart

Si considera il seguente schema relazionale del DB operazionale DB_BIGLIETTI

Si considera solo 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. l’alimentazione a partire da zero
7
Alimentazione del Data Mart

Per semplificare il processo di alimentazione, consideriamo dapprima
come schema del Data Mart DM_BIGLIETTI il secondo schema di pagina
6, ma senza l’introduzione di chiavi surrogate (infatti le chiavi surrogate
devono essere create e gestite durante l’alimentazione), ovvero si
utilizzano le chiavi del DB operazionale DB_BIGLIETTI:

Nel seguito vengono dapprima individuate le espressioni SQL utili ad
alimentare il DM, poi tali espressioni verranno utilizzate per creare un
pacchetto DTS

La generazione delle dimension table VOLO e AEROPORTO è semplice,
in quanto corrisponde a copiare le istanze delle rispettive relazioni nel
DB_BIGLIETTI. Siccome VOLO si riferisce tramite FK ad AEROPORTO
occorre copiare prima AEROPORTO.
8
Alimentazione del Data Mart

Essendo la fact table BIGLIETTI con granularità temporale, le sue istanze
(gli eventi primari) verranno determinate tramite un raggruppamento sulle
dimensioni

Per alimentare la fact table occorre effettuare delle interrogazioni sul DB
operazionale (DB_BIGLIETTI) e riportarne il risultato nel DM
(DM_BIGLIETTI). Normalmente una query SQL può essere riferita solo ad
un DataBase, allora procediamo in questo modo
1. Nel DB operazionale si crea la query che calcola le istanze della fact
table e si memorizza tale query in una vista (VIEW_BIGLIETTI)
2. Si copia il contenuto della vista VIEW_BIGLIETTI nella table fact
BIGLIETTI del DM

Per semplicità, effettuiamo prima il calcolo senza la dimensione CHECK_IN,
che ricordiamo essere una dimensione con valore boolean (1 = biglietto con
check_in, 0 = bigletto senza check_in).
9
Alimentazione del Data Mart


La view VIEW_BIGLIETTI deve contenere il join tra BIGLIETTI, CHECK_IN
(per prendere NUMCOLLI) e CLIENTE (per prendere ANNONASC) ed il
raggruppamento su DATA, CODVOLO, ANNONASC
Conviene fare il join graficamente (vedi figura) quindi salvare la view, riaprirla
e scrivere a mano il raggruppamento
10
Alimentazione del Data Mart

Si deve considerare se è sufficiente fare l’INNER JOIN oppure si deve fare un
OUTER JOIN …

Tra BIGLIETTO e CLIENTE è sufficiente l’INNER JOIN in quanto tutti i biglietti
hanno un cliente (questo si vede dall’E/R ma si deve verificare in pratica sul
relazionale, controllando che il campo CLIENTE in BIGLIETTI sia not null )

Tra BIGLIETTO e CHECK_IN è necessario fare un outer join per includere
anche i biglietti che non hanno corrispondente in CHECK_IN …
11
Alimentazione del Data Mart


Aprendo la view, aggiungo il GROUP BY e le misure:
La somma di un insieme di valori con almeno un NULL è teoricamente NULL: per
avere 0 invece che NULL mettiamo allora SUM(ISNULL(NUMCOLLI,0)).
In SQL SERVER il NULL nella somma è considerato per default 0, quindi si può non
inserire ISNULL.
12
Alimentazione del Data Mart


Cosa avviene se un valore di un attributo di ragruppamento è NULL?
Supponiamo che ANNONASC possa essere NULL, sia a causa di BIGLIETTI
senza un CLIENTE specificato, sia perchè il cliente ha un ANNONASC nullo.

In questi casi conviene codificare il valore NULL con un opportuno valore, ad esempio 0;
In questo modo tale valore non crea problemi quando utilizzato come valore di chiave.
Nella view si sostituisce dbo.CLIENTE.ANNONASC con
ISNULL(dbo.CLIENTE.ANNONASC, 0) AS ANNONASC.

A questo punto la creazione della view (VIEW1) per alimentare la fact table senza la
dimensione CHECK_IN è terminata.
Nel seguito discuteremo come introdurre tale dimensione
13
Alimentazione del Data Mart



La dimensione CHECK_IN è particolare in quanto non corrisponde ad un attributo dello
schema del DB operazionale, ma deve essere calcolato:
1 = biglietto con check_in,
0 = bigletto senza check_in.
In base alla discussione già fatta sul left join, possiamo calcolare tale valore effettuando
il left join; questo calcolo, riportato nelle slide seguenti, risulta essere complesso, in
quanto richiede la definizione di più viste.
Una soluzione più semplice è quella di aggiungere l’attributo alla tabella BIGLIETTO e
di calcolarlo tramite UPDATE sulla tabella. In pratica tale soluzione corrisponde alla
traduzione del subset CHECK_IN con il “collasso verso l’alto”, dove CHECK_IN è
l’attributo selettore
UPDATE BIGLIETTO
SET CHECK_IN = 0
WHERE NUMBIGLIETTO NOT IN (SELECT NUMBIGLIETTO FROM [CHECK-IN])
UPDATE BIGLIETTO
SET CHECK_IN = 1
WHERE NUMBIGLIETTO IN (SELECT NUMBIGLIETTO FROM [CHECK-IN])
14
Alimentazione del Data Mart




Avendo a disposizione l’attributo CHECK_IN, l’alimentazione della fact table con tale
dimensione è molto semplice, basta aggiungerlo agli attributi di raggruppamento
La vista (VIEW_BIGLIETTI) per alimentare la fact table è quindi:
Ora il contenuto della vista può essere copiato nella table fact BIGLIETTI del DM.
Conclusioni

Normalmente, il calcolo è un raggruppamento sulle dimensioni

Considerazioni sui join tra tabelle: LEFT JOIN

Considerazioni sui valori nulli: ISNULL
15
Alimentazione del Data Mart: creazione di pacchetti DTS
1.
2.
3.
Si svuota il contenuto del DM: è utile per testare le procedure di estrazione
statica
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 definisce un pacchetto DTS per ogni passo. Siccome in ogni passo si
devono semplicemente copiare delle tabelle è conveniente (è più
semplice) creare tale pacchetto tramite “Importa Dati”

In uno star schema si possono copiare tutte le dimension table in un solo
passo
Si copia il contenuto della vista nella fact table

Ai passi generali riportati si possono aggiungere altre operazioni che dipendono dal
contesto; ad esempio le istruzioni di update di pagina 14.

Dopo aver creato e provato i pacchetti (package) per i singoli passi, si puo creare un
unico package che li include tutti, eseguendoli nell’ordine stabilito
16
Analysis Services: definizione del CUBO Biglietti


Nel seguito viene utilizzato Analysis Services per analizzare i dati del DM dei
Biglietti, discutendo alcuni punti caratteristici
Dimensione ParteDa : quando
viene salvato il cubo, vengono
contati i membri di ciascun livello;
se il numero di CodVolo risulta
inferiore a quello del livello padre
Sigla (messaggio in basso) occorre
rifare il conteggio in modo da
contare le sigle effettivamente
presenti
17
CUBO : gerarchia condivisa

Dimensione ArrivaA : non si può usare (come in figura) la stessa tabella
AEROPORTO definendo un altro join tra VOLO e AEROPORTO sulla base
dell’attributo A : è come se venissero considerati solo i voli che partono ed
arrivano allo stesso aeroporto (la figura piccola riporta la visualizzazione)!
18
CUBO : gerarchia condivisa

Dimensione ArrivaA : si deve inserire una nuova “copia” di AEROPORTO

AEROPORTO usato in ParteDA si rinomina in AeroportoDa (cambia alias)

Si inserisce ancora la tabella AEROPORTO

Si procede con la definizione di ArrivaA

Un altro esempio di cubo con gerarchia condivisa è in
http://dbgroup.unimo.it/SIA/EsempioTelefonate/Telefonate.html

Completare il cubo definendo le altre dimensioni e le misure. Introdurre la
misura CostoMedioBiglietto (CMB), calcolata come INCASSO/NUM_BIG.
Implementazione in Analysis Services
1.
2.
3.
Si definisce la misura derivata CMB_Base
Si definisce la misura di supporto Conteggio, aggregata con COUNT
Si definisce CMB calcolata come CMB_Base/Conteggio
19
CUBI VIRTUALI






Un cubo virtuale è una combinazione di più cubi all'interno di un cubo
logico e può essere paragonato a una vista di un database relazionale
Un cubo virtuale consente di visualizzare contemporaneamente i dati di
cubi diversi rendendo disponibili funzionalità di analisi più avanzate
Come per una vista, un cubo virtuale non è “materializzato” (memorizzato)
quindi non richiede ulteriore spazio di archiviazione fisico
Un cubo virtuale può anche essere basato su un singolo cubo per esporre
solo subset selezionati delle misure e delle dimensioni
Un cubo virtuale offre un'utile funzione di protezione grazie alla possibilità
di limitare l'accesso di alcuni utenti durante la visualizzazione dei cubi
sottostanti
Un cubo può essere riferito ad una sola fact table: il cubo virtuale è quindi
indispensabile per confrontare i dati relativi a due o più fact table
20
CUBI VIRTUALI

Normalmente un cubo virtuale è definito come combinazione di due o
più cubi che condividono alcune dimensioni.

D’altra parte non c’è alcuna limitazione nella definizione di un cubo
virtuale: si può definire un cubo virtuale come combinazione di due
cubi con insiemi di dimensioni differenti o, al limite, che non
condividono alcuna dimensione:
In corrispondenza di membri di dimensioni differenti, non esisterà
alcun evento nel cubo virtuale. Più precisamente
 Sia CV un cubo virtuale ottenuto come unione di C1 e C2
 Sia D1 (D2) una dimensione di C1 (C2) non presente in C2 (C1)
 Allora le celle non vuote (ovvero gli eventi esistenti) sono solo in
corrispondenza di
• (D1.All, D2.x), con x membro di D2
• (D1.y, D2.All), con y membro di D1
21
CUBI VIRTUALI : Esempio

Definiamo un Cubo Virtuale come composizione di
 Cubo dei Biglietti (CB) - cubo definito in precedenza
 Cubo dei Ritardi (CR) - nuovo cubo per analizzare I ritardi

Dimensioni Condivise
 È una dimensione che viene definita indipendntemente dal cubo e che può essere
condivisa (cioè usata) in più cubi
 Facilita la definizione dei cubi e risparmia spazio (si memorizza solo una volta)
 È un concetto analogo a quello di gerarchia condivisa

Nel nostro esempio definiamo le seguenti dimensioni condivise relative a CB
 ArrivaA, ParteDa, OraDiPartenza, Compagnia
 Le altre dimensioni (es. ANNONASCITA) sono degeneri: non serve che siano
condivise

Problema della gerarchia condivisa nel Cubo dei Biglietti:
 Quando si usano le due dimensioni ParteDa e ArrivaA esiste lo stesso problema
già discusso in precedenza
 La soluzione al problema è la stessa: si modifica il nome (cambia alias) della
tabella AEROPORTO; essendo una dimensione condivisa, si deve usare l’editor
delle Dimensioni
22
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
Si modifica l’albero aggiungendo la dipendenza CITTA  STATO
Si modifica l’albero eliminando A-SIGLA
23
Ritardi: Progettazione dello Schema di Fatto

Progettazione Schema di Fatto
4.
5.

Si modifica l’albero eliminando CODVOLO per CITTA_ARRIVO,
Si definisce lo Schema di Fatto selezionando come misura RITARDO
(ovviamente definita come media ed aggregata tramite media) e come
dimensioni: DATA CODVOLO e CITTA_ARRIVO
Si considera CITTA, STATO come gerarchia condivisa : per semplicità non
viene indicata sul disegno
24
Ritardi: Progettazione logica



Se è già stato realizzato lo Schema logico di pag. 8, si possono riusare
le dimension table già introdotte, cioè VOLO e AEROPORTO
D’altra parte se si progetta lo schema logico da zero, per entrambi gli
schemi di fatto, è possibile usare in AEROPORTO il riferimento a CITTA:
Nel seguito useremo il primo schema + lo schema di pagina 8 (altrimenti
dobbiamo variare gli oggetti (cubi) realizzati finora
25
Ritardi: Alimentazione del Data Mart - Fact Table

Alimentazione della fact table: raggruppo su DATA,CODVOLO e CITTA_ARRIVO;
definiamo una view (nel DB dei Biglietti) che contiene questi attributi (si noti che per
CITTA_ARRIVO devo fare un join con AEROPORTO). Considero dei join interni.

Salvo ed edito la view aggiungendogli il raggruppamento e calcolando RITARDO:
CREATE VIEW dbo.VistaRitardi AS
SELECT dbo.VOLOGIOR.DATA, dbo.VOLOGIOR.CODVOLO,
dbo.AEROPORTO.CITTA AS CITTA_ARRIVO, AVG(RITARDO) AS RITARDO
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
GROUP BY dbo.VOLOGIOR.DATA, dbo.VOLOGIOR.CODVOLO, dbo.AEROPORTO.CITTA
26
Ritardi: Alimentazione del Data Mart - Dimension Table CITTA



Se nel DM ho AEROPORTO

Prendo i dati direttamente da tale tabella e li inserisco in citta:
insert into CITTA
select distinct CITTA,STATO from AEROPORTO

Si noti il distinct: in CITTA l’attributo CITTA è chiave
Se nel DM non ho AEROPORTO

Prendo i dati dal DB Biglietti e precisamente dalla tabella AEROPORTO.

Quindi si effettua un “importa dati” basato sulla query
select distinct CITTA,STATO from AEROPORTO
Dopo aver alimentato CITTA si può alimentare RITARDI con un semplice
“importa dati” per prendere la view Ritardi nel DB Biglietti ed inserirlo nella
tabella RITARDI del DM
27
Cubo dei Ritardi

Definizione delle dimensioni





Data: come dimensione temporale
ParteDA: si riutilizza la dimensione condivisa già definita in precedenza
Compagnia: si riutilizza la dimensione condivisa già definita in precedenza
CittaArrivo: nuova dimensione basata sulla tabella CITTA
Definizione della misura RITARDO aggregata tramite AVG
1.
2.
3.
Si definisce RITARDOBASE basata su Ritardo ed aggregata tramite SUM
Si definisce la misura di supporto Conteggio, aggregata con COUNT
Si definisce Ritardo calcolato come RITARDOBASE /Conteggio
28
Cubo Virtuale

Quando si definisce un Cubo Virtuale si possono combinare solo le misure
non i membri calcolati; quindi RITARDO deve essere ricalcolato nel cubo
virtuale e pertanto le misure RitardoBase e Conteggio devono essere
riportate nel cubo virtuale

Se nel cubo virtuale si
sceglie DATA di BIGLIETTI:
non si visualizza Ritardo!

Allora definiamo DATA come Dimensione Condivisa; dovendo
selezionare la tabella dalla quale prenderla, si sceglie RITARDI: infatti in
RITARDI ho tutti i voli giornalieri e quindi tutte le date che mi interessano
Prima di modificare una dimensione all’interno del cubo, accertarsi che
questa dimensione non sia usata da un cubo virtuale; in caso positivo,
cancellare prima il cubo virtuale

29
Proprietà dei membri e dimensioni virtuali

Gli attributi descrittivi collegati ad attributi dimensionali si
possono modellare usando “Proprietà membro”
 Nell’esempio, un possibile attributo descrittivo è il nome
inglese dell’insegnamento.

Una dimensione virtuale è una dimensione rispetto alla quale
non vengono calcolati e materializzati dati aggregati
 Logicamente, non c’è nessuna differenza tra dimensioni
“ordinarie” e dimensioni virtuali

Una dimensione virtuale viene definita rispetto ad una
proprietà di un membro di una dimensione “ordinaria”
30