DWH PROG Logica

Corso di Sistemi Informativi
Progettazione DW
Reverse Engineering di schemi relazionali
14 Novembre 2022
Prof. S. Castano Sistemi Informativi - AA. 2022/23 1
Reverse engineering di schemi relazionali

• Procedimento per ricavare dallo schema relazionale lo schema ER
corrispondente
• Procedimento inverso della Progettazione logico-relazionale
(forward engineering): dato uno schema ER definire lo schema
relazionale corrispondente
• Per rendere efficace il processo di reverse engineering si deve
partire da
– Uno schema relazionale il più possibile completo (con indicazione di
chiavi primarie, chiavi esterne, valori nulli);
– Uno schema relazionale normalizzato.
1
Reverse engineering di schemi relazionali
• Il Reverse engineering di schemi relazionali si basa sull'applicazione
in senso inverso delle regole di ristrutturazione e traduzione
utilizzate nel forward engineering.
• Nel seguito utilizzeremo la seguente notazione sintetica per

denotare una chiave esterna (foreing key)
K1:R per denotare K1 foreign key REFERENCES R (K)
Reverse engineering: entità

Uno schema di relazione senza chiavi esterne R(K, W) è tradotto in
un’entità R con
- K={a1, a2, …, at} identificatore di R
- W={a(t+1), …, am} attributi descrittivi di R
Persona(CF, Nome, Indirizzo, Età)
CF
Nome Persona
Età
Indirizzo
•Si applica a tutte le relazioni dello schema senza chiavi esterne

Prof. S. Castano Sistemi Informativi - AA. 2022/23 »4
2
Reverse engineering: associazioni
• Per la traduzione di schemi di relazione contenenti una o
più chiavi esterne, occorre ricordare che in ER ci sono:
– Diverse tipologie di associazione (binaria, N-aria)
– Reverse
Vincoli di integrità (cardinalità): : entità e gerarchie
engineering
• cardinalità massime (‘1:1’, ‘1:N’, ‘N:M’)
!  Si inizia considerando le relazioni senza STUDENTE(MATR, ETA)
• cardinalità
chiavi esterne, minime (partecipazione opzionale/obbligatoria)
che corrispondono
sicuramente a entità nello schema E/R
!  Uno schema relazionale con

R(K, A, ...)
R1(K1:R, B, ...)
corrisponde in E/R ad un subset R1 is-a R
%  Notazione sintetica per una foreing key

K1:R indica FK: K1 REFERENCES R
!  Il caso di R1(K1:R, B, ...), R2(K2:R, C, ...) corrisponde
ad una gerarchia di generalizzazione su R con entità figlie R1, R2, !
!  Le proprietà di copertura della gerarchia non possono essere
ricavate automaticamente in quanto non presenti nello schema
relazionale: occorre riferirsi ad altre informazioni, analizzare
l'istanza del database, presenza di trigger, ..!
5 43
Reverse engineering:
Reverse engineeringassociazioni
: associazioni
!  Dato uno schema relazionale con
R(K,...) 
Dato unoR1(K1,
schema ...relazionale
KR:R, ...) con
–!  R(K,…)
Se KR non è chiave,
allora la...
– R1(K1, FKKR:R,
traduce
...) (0,Y)
una associazione uno-a-molti
Si traduce in èun’associazione
!  Se KR A tra R e R1,dicon
not null allora la partecipazione R1 èmax-card(R1,A)=1
obbligatoria : X=1
!  Se KR è chiave in R1, allora l'associazione A è uno-a-uno : N=1
• Come scegliere X:
– Se KR è NOT NULL  X=1 (partecipazione obbligatoria)
– ! Altrimenti
Se KR èX=0 (partecipazione
una opzionale)
parte della chiave di R1:
• Come scegliere Y:
R1(K1,KR, ...) 
– Se KR è UNIQUE (chiave) in R1  Y=1 (A è uno-a-uno)
la FK traduce un identificatore esterno
– altrimenti Y=N (A è uno-a-molti ) 44
3
R(K,...) 
R1(K1, ... KR:R, ...) 
!  Se KR non è chiave,
allora la FK traduce
una associazione uno-a-molti
!  Se KR è not null allora la partecipazione di R1 è obbligatoria : X=1

!  Se KR è chiave in R1, allora l'associazione A è uno-a-uno : N=1
Dato uno schema relazionale con
!  Se KR è una parte della chiave di R1:
– R(K,…)
– R1(K1,KR:R, ...)
R1(K1,KR, ...) 
la FK traduce un identificatore esterno

in cui KR è una parte della chiave primaria di R1, allora si traduce44in
• un’associazione A tra R e R1
• identificatore esterno tramite A per R1
• min-card(R1,A)=1
• max-card(R1,A)=1
Dato uno schema relazionale con

R (K1:R1,..., Kn:Rn, ...)
in cui ci sono n foreign key Ki, ciascuna facente riferimento a una
relazione Ri, la regola di traduzione-standard è in una associazione n-
aria A
Reverse engineering : associazioni
!  In generale, una relazione R con n foreign key RKi riferite ad n
•Se la chiave diRiRindividua
relazioni è l'insieme di tutte len-aria
un'associazione foreign
tra lekey:
Ri
(regola di traduzione-standard )
R (K1:R1,K2:R2, K3:R3)
R (RK1:R1,..., RKn:Rn, ...)
!  Se la chiave di R è l'insieme di tutte le foreign key:

R (RK1,..., RKn, ...) 
Allora max-card(Ri,A)=N
  per ogni Ri, i=1..3
allora tutte le entità hanno cardinalità max N.
!  Se la chiave di R è un
sottoinsieme delle foreign key
R (RK1,RK2,RK3, ...) 
Prof. S. Castano
  Sistemi Informativi - AA. 2022/23 »8
allora l'associazione n-aria deve
essere reificata
8  
45
4
Reverse engineering : esempio
!  In generale, una relazione R con n foreign key RKi riferite ad n
relazioni Ri individua un'associazione n-aria tra le Ri
Reverse
(regola di traduzione-standard ) engineering: associazioni
R (RK1:R1,..., RKn:Rn, ...)
• Se la chiave di R è un sottoinsieme delle foreign key
!  R (K1:R1,K2:R2,K3:R3)
Se la chiave di R è l'insieme di tutte le foreign key:
R (RK1,..., RKn, ...) 
allora l’entità R3 ha cardinalità max 1 e l'associazione n-aria A deve
 
allora tutte le entità hanno essere reificata
cardinalità max N.
!  Se la chiave di R è un
sottoinsieme delle foreign key
R (RK1,RK2,RK3, ...) 
 
allora l'associazione n-aria deve
essere reificata
 
45
9
!  Schema relazionale dato
CITTA(CITTA,REGIONE,STATO)
Reverse engineering: entità e gerarchie
CLIENTE(CLIENTE,CITTA:CITTA)
BANKOMAT(BANKOMAT,CLIENTE:CLIENTE)
Reverse engineering : entità e gerarchie
BANCA(BANCA,CITTA:CITTA)
Uno schema relazionale con
FILIALE(FILIALE,BANCA:BANCA)
– R(K,
Si inizia considerando le relazioni
!  OPERAZIONE(NUMOP,BANKOMAT:BANKOMAT, A)
senza STUDENTE(MATR, ETA)
chiavi esterne,FILIALE:FILIALE,DATA,MESE,ANNO,IMPORTO)
che corrispondono
– R1(K:R, B)
sicuramente a entità nello schema E/R in ER con una gerarchia di generalizzazione (sottoinsieme)
VERSAMENTO([NUMOP,BANKOMAT]:OPERAZIONE,
viene tradotto
ASSEGNO, ASSEGNODI:BANCA)
R1 is-a R
!  UnoAK:ASSEGNO
schema relazionale con
R(K, A, ...)
R1(K1:R, B, ...)
corrisponde in E/R ad un subset R1 is-a R
!  Se non diversamente specificato
tutte le foreign key si suppongono not null
%  Notazione sintetica per una foreing key
K1:R indica FK: K1 REFERENCES R
46
!  Il caso di R1(K1:R, B,•Il...),caso diR2(K2:R,
R1(K1:R,C, B, ...) corrispondeC, ...) corrisponde ad una gerarchia
...) e R2(K2:R,
ad una gerarchia di generalizzazione su R con su
di generalizzazione entità figlie entità
R con R1, R2,figlie
! R1, R2
!  Le proprietà di copertura della gerarchia non possono essere
ricavate automaticamente in quanto non presenti nello schema
relazionale: occorre riferirsi ad altre informazioni, analizzare
Prof. S. Castano
l'istanza del database, presenza di trigger, ..! Sistemi Informativi - AA. 2022/23 10
10 43
5
Schema relazionale
CITTA’(Città,Regione, Stato)
CLIENTE(Cliente,Città:città)
BANKOMAT(Bankomat, Cliente:cliente)
BANCA(Banca, Città:città)
FILIALE(Filiale,Banca:banca)
OPERAZIONE(NumOp, Bankomat:bankomat, Filiale:filiale,Data,Mese,Anno,Importo)
VERSAMENTO ([NumOp,Bankomat]:operazione,Assegno, Banca:banca)
•Tutte le foreign key sono NOT NULL
11
Schema
Reverse ER
engineering : esempio REGIONE STATO
!  Schema E/R ASSEGNO (0,N)

BANCA (1,1) IN (0,N) CITTA
corrispondente DI
(1,N)
CITTA
(0,N)
BANCA
DI INDIRIZZO
(1,1)
VERSAMENTO (1,1) (1,1)

ASSEGNO
FILIALE CLIENTE
ASSEGNO
(0,N) (1,N)
FILIALE CLIENTE
DA DEL
IMPORTO
(1,1) (1,1)
MESE
ANNO OPERAZIONE (1,1) (1,N) BANKOMAT
DATA
BANKOMAT
NUMOP
!  Le cardinalità
• Per leminime delle entità
cardinalità con molteplicità
non direttamente maggiore
ricavabili dallodischema
1 (es: relazionale (es.,
BANCA nell'associazione ASSEGNO-DI) non sono nello schema
BANCA nell'associazione ASSEGNO-DI) occorre riferirsi ad altre
relazionale : occorre riferirsi ad altre informazioni, analizzare l'istanza
informazioni,
del database, presenza analizzare l'istanza del database, etc.
di trigger, ..!
47
• In assenza di informazioni, la cardinalità di default è (0,N)
12
Vincoli di integrità scoperti sui dati

!  Per definizione un vincolo di integrità deve essere valido
per tutte le istanze dello schema 6
Corso di Sistemi Informativi
Progettazione logica di DW/DM

Modellazione ROLAP
14 Novembre 2022
13
Modelli logici per DW

• La struttura multidimensionale dei dati può essere
realizzata utilizzando modelli logici diversi :
– MOLAP (Multidimensional On-Line Analytical
Processing): i dati sono organizzati utilizzando
strutture intrinsecamente multidimensionali (es. vettori
multidimensionali).
– ROLAP (Relational On-Line Analytical Processing): i
dati multidimensionali sono organizzati secondo il
modello relazionale.
14
7
Sistemi MOLAP
• I dati sono memorizzati direttamente in un formato

multidimensionale (es., vettori multidimensionali)
• Pone il problema della sparsità: in media solo il 20%
delle celle dei cubi contiene effettivamente
informazioni, mentre le restanti celle corrispondono a
fatti non accaduti
• Diffusione limitata dovuta alla mancanza di strutture
dati standard; i diversi produttori di software
utilizzano strutture proprietarie che li rendono
difficilmente sostituibili e accessibili mediante
strumenti di terze parti.
15
Sistemi ROLAP
• Sistemi basati sul modello relazionale, molto diffusi.

• ROLAP è giustificato dall’enorme lavoro svolto in
letteratura sul modello relazionale, dalla ampia
esperienza aziendale sull’utilizzo e l’amministrazione di
basi di dati relazionali e dall’elevato livello di prestazioni e
flessibilità raggiunto dai DBMS relazionali
• Problema delle prestazioni (costose operazioni di join tra
tabelle di elevate dimensioni)  denormalizzazione.
• La modellazione multidimensionale su sistemi relazionali
è basata sul cosiddetto schema a stella (star schema) e
sulle sue varianti.
16
8
ROLAP: schema a stella
• Uno schema a stella (star schema) è composto da:
– Un insieme di relazioni DT1…, DTn, chiamate
dimension table, ciascuna corrispondente a una
dimensione. Ogni DTi è caratterizzata da una chiave
primaria (tipicamente surrogata) di e da un insieme di
attributi che descrivono le dimensioni di analisi ai
diversi livelli di aggregazione.
– Una relazione FT, chiamata fact table, che importa le
chiavi di tutte le dimension table. La chiave primaria di
FT è data dall ’ insieme delle chiavi esterne dalle
dimension table, d1…, dn; FT contiene inoltre un
attributo per ogni misura.
17
Esempio
Data
Dimension ID_data
Table Data
Mese
Trimestre Negozio
Anno ID_Negozio ID_Negozio
ID_data Negozio
Prodotto ID_Prodotto Città
Quantità Regione
ID_Prodotto
Incasso Rappresentante
Prodotto
Tipo Dimension
Categoria Fact Table Table
Marca
Dimension
Table
18
9
Schema a stella
• Le dimension table sono denormalizzate, ovvero

non sono in 3NF a causa della presenza di
dipendenze funzionali transitive
 È sufficiente un join per recuperare tutti i dati
relativi a una dimensione
 La denormalizzazione introduce una forte
ridondanza nei dati (es., la categoria di un
prodotto viene ripetuta per ogni prodotto di quel
tipo)
• Non si hanno problemi di sparsità in quanto nella fact
table vengono memorizzate soltanto le combinazioni
di chiavi per cui esiste informazione (i.e., tuple
corrispondenti a punti dello spazio multi-dimensionale
corrispondenti a eventi accaduti)
19
Esempio di istanza
ID_Negozio Negozio Città Regione Rappresentante

1 N1 RM Lazio R1 Dimension
2 N2 RM Lazio R1
3 N3 MI Lombardia R2
Table
… … … … …
ID_Negozio ID_data ID_Prodotto Quantità Incasso

1 1 1 1 1,0
2 1 2 1 1,50 Fact Table
3 2 3 3 3,0
… … … … …
Dimension
Table
ID_data Data Mese Anno ID_Prodotto Prodotto Tipo Categoria Marca
1 2/9/2001 9/2001 2001 1 LatteSlurp latticino Alimentari Slurp
2 3/10/2001 10/2001 2001 2 LatteGnam latticino Alimentari Gnam
3 5/10/2001 10/2001 2001 3 YogurtSlurp latticino Alimentari Slurp
... ... ... ... … … … … …
20
10
Interrogazioni OLAP su schemi a stella
Settimana
ID_Settimana
Settimana Negozio
Mese ID_Negozio
ID_Negozio
Negozio
Prodotto ID_Settimana
Città
ID_Prodotto
ID_Prodotto Stato
Quantità
Prodotto Rappresentante
Incasso
Tipo
Categoria
Fornitore
Query: Totale della quantità venduta per i diversi tipi di

prodotto, in ogni mese e città ma solo per i prodotti
alimentari
21
Query OLAP in SQL
Predicato di join:
collegamento tra fact
SELECT N.Città, S.Mese, P.Tipo,
table e dimension table
SUM(Quantità)
FROM Settimana AS S, Negozio AS N,
Prodotto AS P, Vendite AS V
WHERE V.ID_Settimana=S.ID_Settimana and
V.ID_Negozio=N.ID_Negozio and
V.ID_Prodotto=P.ID_Prodotto
and P.Categoria = ‘Alimentari’
GROUP BY N.Città, S.Mese, P.Tipo
Predicato di
selezione
Estrazione di
fatti rilevanti
22
11
ROLAP: schema a fiocco di neve
• Lo schema a fiocco di neve (snowflake schema) riduce il
livello di denormalizzazione delle dimension table DTi
degli schemi a stella.
• Uno schema snowflake è ottenibile da uno schema a
stella decomponendo una o più dimension table DTi in più
tabelle DTi,k in modo da eliminare alcune dip. funzionali
transitive in esse presenti. Ogni dimension table DTi,k è
caratterizzata da:
– una chiave primaria (tipicamente surrogata) di,k
– il sottoinsieme degli attributi di DTi che dipendono funzionalmente
da di,k.
– zero o più chiavi esterne che fanno riferimento a altre DTi,k
necessarie a garantire la ricostruibilità del contenuto informativo di
DTi.
• Denominiamo primarie le dimension table le cui chiavi
sono importate nella fact table, secondarie le rimanenti.
23
Esempio di snowflaking
Data
ID_data
Dimension table
Data
Mese primaria
Trimestre
Anno
Negozio
Dimension table ID_Negozio ID_Negozio
primaria Prodotto ID_data Negozio
ID_Prodotti ID_Prodotto
Prodotto Quantità ID_Città
ID_Tipo Incasso Città
Marca ID_Città
Tipo Città
ID_Tipo Regione
Tipo
Dimension table
Categoria
secondaria
Dimension table
secondaria
24
12
Esempio di istanza
ID_Tipo Tipo Categoria ID_Prodotto Prodotto Tipo Marca

1 latticino alimentari 1 LatteSlurp 1 Slurp
2 … … 2 LatteGnam 1 Gnam
3 YogurtSlurp 1 Slurp
… … … …
ID_data Data Mese Anno

1 2/92001 9/2001 2001
2 3/10/2001 10/2001 2001 ID_Negozio ID_data ID_Prodotto Quantità Incasso
3 5/10/2001 10/2001 2001 1 1 1 1 1,0
... ... ... ... 2 1 2 1 1,50
3 2 3 3 3,0
… … … … …
ID_Negozio Negozio Città

1 N1 1 ID_Città Città Regione
2 N2 1 1 RM Lazio
3 N3 2 2 MI Lombardia
… … …
25
Normalizzazione con lo snowflake schema

• Le specifiche caratteristiche degli schemi a stella richiedono particolare
attenzione affinché nella nuova dimension table secondaria sia spostato
il corretto insieme di attributi
• La presenza di più dipendenze funzionali transitive in cascata fa sì che,
affinché la decomposizione sia efficace, tutti gli attributi che dipendono
(transitivamente e non) dall’attributo che ha determinato lo snowflaking
siano posti nella nuova relazione
Negozio
ID_Negozio ® Negozio
Negozio ID_Negozio
ID_Negozio ID_Negozio ® Negozio Negozio ® ID_Città
Negozio
Negozio Negozio ® Città ID_Città Negozio ® Rappresentante
Città Rappresentante
Città ® Regione
Regione Città
Stato Regione ® Stato
ID_Città ID_Città ® Città
Rappresentante Negozio ® Rappresentante Città
Città ® Regione
Regione
Stato Regione ® Stato
26
13
Schema a fiocco di neve
• Lo spazio richiesto per la memorizzazione dei dati si

riduce grazie alla normalizzazione
• È necessario inserire nuove chiavi surrogate che
permettano di determinare le corrispondenze tra
dimension table primarie e secondarie
• L’esecuzione di interrogazioni che coinvolgono solo gli
attributi contenuti nella fact table e nelle dimension table
primarie è avvantaggiata (le dimensioni delle tabelle
coinvolte è inferiore)
• Il tempo di esecuzione delle interrogazioni che
coinvolgono attributi delle dimension table secondarie
aumenta (maggior nr. di join)
27
Query OLAP in SQL su schema snowflake
ID_Settimana
Settimana
Mese Negozio
ID_Negozio
ID_Negozio
Negozio
Prodotto ID_Settimana
ID_Città
ID_Prodotti ID_Prodotto
Prodotto Quantità Rappresentante
ID_Tipo Incasso
Città
Fornitore ID_Città
Tipo Città
Stato Ulteriori predicati di join:
ID_Tipo
Tipo collegamento tra dim.
select N.Città, S.Mese, P.Tipo, SUM(Quantità)
Categoria table primaria e dim. table
from Settimana AS S, Negozio AS N, Città, Prodotto AS
P, Tipo, Vendite AS V secondaria
where V.ID_Settimana=S.ID_Settimana AND
V.ID_Negozio = N.ID_Negozio AND
N.ID_Città = Città.ID_Città AND
V.ID_Prodotto = P.ID_Prodotto AND
P.ID_Tipo= Tipo.ID_Tipo AND
P.Categoria = ‘Alimentari’
group by N.Città, S.Mese, P.Tipo;
28
14
Progettazione logica
• Insieme dei passi che, a partire dallo schema
concettuale DFM, permettono di derivare lo schema
logico (relazionale) del DW
INPUT OUTPUT
Schema concettuale Progetto
Carico di lavoro logico Schema logico
Volume dei dati
Vincoli di sistema
 È basata su principi diversi e spesso in contrasto con

quelli utilizzati nei sistemi operazionali (es., ridondanza
dei dati; denormalizzazione delle relazioni).
29
Le principali operazioni da svolgere durante progettazione

logica sono:
1. Scelta dello schema logico da utilizzare (es. star/snowflake

schema)
2. Traduzione degli schemi concettuali
3. Scelta delle viste da materializzare
30
15
Traduzione DFM  star schema
 Regola di base
Creare una fact table contenente tutte le misure
collegate con il fatto e, per ogni gerarchia, creare una
dimension table che ne contiene tutti gli attributi.
31
Esempio
Categoria
Fornitore Tipo
Prodotto
Rappresentante
Mese VENDITE
Quantità Negozio Città Stato
Settimana
Guadagno
Settimana
ID_Settimana
Settimana Negozio
Mese ID_Negozio ID_Negozio
ID_Settimana Negozio
Prodotto Città
ID_Prodotto ID_Prodotto
Quantità Stato
Prodotto Rappresentante
Tipo Guadagno
Categoria
Fornitore
32
16
Attributi descrittivi
• Contiene informazioni non utilizzabili per effettuare
aggregazioni ma che si ritiene comunque utile
mantenere.
– Se collegato a un attributo dimensionale, va incluso nella
dimension table che contiene l’attributo.
– Se collegato direttamente al fatto deve essere incluso nella fact
table.
33
Gerarchie condivise
• Se le due gerarchie contengono esattamente gli stessi attributi sarà
sufficiente importare due volte la chiave della medesima dimension
table
uso
chiamante ora
CHIAMATA
distretto numero numero

chiamato durata data mese anno
telefonico
uso del num.

chiamante
Chiamate
distretto del ID_Chiamante
CHIAMATA
ora Numero Utente
numero chiamante numero
ID_chiamato
chiamante numero ID_utente
distretto del ID_Data
durata data mese anno
distretto
numero chiamato numero Count
uso del num. chiamato uso
chiamato
34
17
Star vs. Snowflake
Esistono pareri contrastanti sull’utilità dello snowflaking

– Contrasta con la filosofia del data warehousing
– Rappresenta un inutile “abbellimento” dello schema
Può essere utile

• Quando il rapporto tra le cardinalità della dimension table
primaria e secondaria è elevato, poiché determina un forte
risparmio di spazio
• Quando una porzione di una gerarchia è comune a più
dimensioni
35
Gerarchie condivise
Se le due gerarchie condividono solo una parte degli attributi è
necessario decidere se:
• Introdurre ulteriore ridondanza nello schema duplicando le
gerarchie e replicando i campi comuni.
• Eseguire uno snowflake sul primo attributo condiviso introducendo
una terza tabella comune a entrambe le dimension table.
36
18
Esempio
magazzino città regione stato
SPEDIZIONE
ordine
numero cliente
prodotto costo
data di
spedizione data mese anno
Magazzino
ID_Magazzino Città
Spedizioni Magazzino
ID_Magazzino ID_Città
ID_Città Città
ID_Data
Ordine Stato
ID_Ordine
ID_Prodotto ID_Ordine
Quantità Ordine
Incasso Cliente
ID_Città
La dimension table secondaria Città è comune e utilizzata per Magazzino e Ordine
37
Il carico di lavoro
• Il carico di lavoro è sostanzialmente l’insieme delle interrogazioni

utente che il sistema deve eseguire
• Interrogazioni di un sistema OLAP sono per natura estemporanee
 carico di lavoro dinamico
• È necessario identificare in fase di progettazione un carico di
lavoro di riferimento
– Reportistica standard
– Colloqui con gli utenti
• Le interrogazioni OLAP sono facilmente caratterizzabili
– Pattern di aggregazione
– Misure richieste
– Clausole di selezione
38
19
Dinamicità del carico di lavoro
• Il carico di lavoro preliminare non è di per sé sufficiente a

ottimizzare le prestazioni del sistema
– L’interesse degli utenti cambia nel tempo
– Il numero di interrogazioni aumenta al crescere della confidenza
degli utenti con il sistema
• Per ottimizzare la struttura logica del data mart è necessaria
una fase di tuning attuabile solo dopo che il sistema è stato
messo in funzione
• Il carico di lavoro reale può essere desunto dal log delle
interrogazioni sottoposte al sistema
39
Il volume dati
• Consiste nelle informazioni necessarie a determinare/stimare la

dimensione del datamart
– Cardinalità di un pattern: numero atteso di eventi per quel pattern
– Cardinalità dei domini degli attributi dimensionali
• Deve essere calcolato a partire dalla cardinalità del pattern

primario considerando la quantità di dati necessari a coprire
l’intervallo temporale deciso per il data mart (es., 3-5 anni).
• Normalmente il numero di eventi accaduti è di gran lunga

inferiore a quelli possibili (sparsità)
– ROLAP: memorizza solo gli eventi accaduti
40
20
Le principali operazioni da svolgere durante progettazione

logica sono:
1. Scelta dello schema logico da utilizzare (es. star/snowflake

schema)
2. Traduzione degli schemi concettuali
3. Scelta delle viste da materializzare
41
Viste
• L’analisi dei dati al massimo livello di dettaglio è spesso troppo

complessa e non interessante per gli utenti che richiedono dati di
sintesi
• L’aggregazione rappresenta il principale strumento per ottenere
informazioni di sintesi
• L’elevato costo computazionale connesso con l’aggregazione
induce a pre-calcolare i dati di sintesi maggiormente utilizzati
Con il termine vista si denotano le fact table

contenenti dati aggregati
42
21
Viste
• Le viste possono essere identificate in base al livello
(pattern) di aggregazione che le caratterizza
Viste primarie: corrispondono al pattern di aggregazione primario

(l’insieme delle dimensioni)
Viste secondarie: corrispondono ai pattern di aggregazione
secondari (aggregati)
Si può ottenere un significativo aumento delle

prestazioni pre-calcolando i dati aggregati
(viste secondarie) di uso più comune.
Prof. S. Castano Sistemi Informativi

43 - AA. 2022/23 43
43
Esempio
v1 = {prodotto, data, negozio}
v2 = {tipo, data, città}
v4 = {tipo, mese, regione} v3 = {categoria, mese, città}
v5 = {trimestre, regione}
• vi  vj indica che i dati di vj possono essere calcolati aggregando

quelli di vi
• Una interrogazione che richieda i dati di vendita aggregati per (tipo
prodotto, data e città del negozio) risulterà meno costosa
se eseguita sulla vista v2 piuttosto che sulla vista v1
• Una vista v sul pattern p non serve solo per le interrogazioni con
pattern di aggregazione p ma anche per tutte quelle che richiedono i
dati a pattern p' più aggregati di p (p £ p')
44
22
Aggregazioni parziali
• Il calcolo di valori aggregati a partire da dati pre-

aggregati (in viste materializzate) può determinare
errori se non si considerano con attenzione le
caratteristiche degli operatori utilizzati per
l’aggregazione delle misure (e.g., problemi con
misure non-additive)
45
Esempio
data  quadrimestre  anno
Calcolo del livello di inventario per anno
Data Quadrimestre Livello di

inventario
Vista primaria
1/1/2002 I ’02 100
10/2/2002 I ‘02 200
31/3/2002 I ‘02 60
5/6/2002 II ‘02 85
18/7/2002 II ‘02 125
31/12/2002 III ‘02 110
AVG
Quadrimestre Livello di Vista secondaria

inventario
I ‘02 120
II ‘02 105
III ‘02 110
Prof. 1999
S.46
Castano AVG 113,33
Sistemi Informativi - AA. 2022/23 46
46
23
Esempio
data  quadrimestre  anno
Calcolo del livello di inventario per anno
Data Quadrimestre Livello di
inventario
1/1/2002 I ’02 100 Anno Livello di
10/2/2002 I ‘02 200 inventario
AVG
31/3/2002 I ‘02 60
2002 113,33
5/6/2002 II ‘02 85
18/7/2002 II ‘02 125
?
31/12/2002 III ‘02 110
AVG
Quadrimestre Livello di Anno Livello di

inventario inventario
AVG
I ‘02 120
II ‘02 105 2002 111,66
III ‘02 110
La soluzione corretta è sempre quella che si ottiene

aggregando i dati direttamente dalla vista primaria
Prof. 1999
S.47
Castano AVG 113,33
Sistemi Informativi - AA. 2022/23 47
47
• Affinchè i dati pre-aggregati possano essere utilizzati per il calcolo di
dati ulteriormente aggregati, può essere necessario memorizzare
anche nuove misure necessarie per il corretto calcolo in dipendenza
dal tipo di operatore aggregato utilizzato
• Gli operatori di aggregazione che possono essere così classificati:
– Distributivi: permettono di calcolare dati aggregati a partire
direttamente da dati parzialmente aggregati (es. somma, massimo,
minimo)
– Algebrici: richiedono un numero finito di informazioni aggiuntive
(misure di supporto) per calcolare dati aggregati a partire da dati
parzialmente aggregati (es. AVG– richiede il numero dei dati
elementari –count- che hanno contribuito a formare un singolo
dato parzialmente aggregato)
– Olistici: non permettono di calcolare dati aggregati a partire da dati
parzialmente aggregati utilizzando un numero finito di informazioni
aggiuntive (es., mediana)
Prof. S. Castano Sistemi Informativi

48 - AA. 2022/23 48
48
24
Misure di supporto: necessarie in presenza di operatori di
aggregazione algebrici
Quadrimestre Livello di Count Liv. inventario

* Count
inventario
I ‘02 120 3 360
II ‘02 105 2 210
III ‘02 110 1 110
AVG 113,33
Valore aggregato corretto
Prof. S.49
Castano Sistemi Informativi - AA. 2022/23 49
49
25

DWH PROG Logica

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

DWH PROG Logica

Caricato da

Copyright:

Formati disponibili

Corso di Sistemi Informativi

Prof. S. Castano Sistemi Informativi - AA. 2022/23 1

Reverse engineering di schemi relazionali

Prof. S. Castano Sistemi Informativi - AA. 2022/23 2

• Nel seguito utilizzeremo la seguente notazione sintetica per

Prof. S. Castano Sistemi Informativi - AA. 2022/23 3

Reverse engineering: entità

Persona(CF, Nome, Indirizzo, Età)

•Si applica a tutte le relazioni dello schema senza chiavi esterne

! Uno schema relazionale con

% Notazione sintetica per una foreing key

Prof. S. Castano Sistemi Informativi - AA. 2022/23 »6

! Se KR è not null allora la partecipazione di R1 è obbligatoria : X=1

la FK traduce un identificatore esterno

Prof. S. Castano Sistemi Informativi - AA. 2022/23 »7

Reverse engineering: associazioni

Dato uno schema relazionale con

! Se la chiave di R è l'insieme di tutte le foreign key:

Prof. S. Castano Sistemi Informativi - AA. 2022/23 »9

•Tutte le foreign key sono NOT NULL

Prof. S. Castano Sistemi Informativi - AA. 2022/23 11

! Schema E/R ASSEGNO (0,N)

VERSAMENTO (1,1) (1,1)

Vincoli di integrità scoperti sui dati

Progettazione logica di DW/DM

Prof. S. Castano Sistemi Informativi - AA. 2022/23 13

Modelli logici per DW

Prof. S. Castano Sistemi Informativi - AA. 2022/23 14

• I dati sono memorizzati direttamente in un formato

Prof. S. Castano Sistemi Informativi - AA. 2022/23 15

• Sistemi basati sul modello relazionale, molto diffusi.

Prof. S. Castano Sistemi Informativi - AA. 2022/23 16

Prof. S. Castano Sistemi Informativi - AA. 2022/23 17

Prof. S. Castano Sistemi Informativi - AA. 2022/23 18

• Le dimension table sono denormalizzate, ovvero

Prof. S. Castano Sistemi Informativi - AA. 2022/23 19

ID_Negozio Negozio Città Regione Rappresentante

ID_Negozio ID_data ID_Prodotto Quantità Incasso

Prof. S. Castano Sistemi Informativi - AA. 2022/23 20

Query: Totale della quantità venduta per i diversi tipi di

Prof. S. Castano Sistemi Informativi - AA. 2022/23 21

Query OLAP in SQL

Prof. S. Castano Sistemi Informativi - AA. 2022/23 23

Prof. S. Castano Sistemi Informativi - AA. 2022/23 24

ID_Tipo Tipo Categoria ID_Prodotto Prodotto Tipo Marca

ID_data Data Mese Anno

ID_Negozio Negozio Città

Normalizzazione con lo snowflake schema

Prof. S. Castano Sistemi Informativi - AA. 2022/23 26

• Lo spazio richiesto per la memorizzazione dei dati si

Prof. S. Castano Sistemi Informativi - AA. 2022/23 27

Query OLAP in SQL su schema snowflake

Prof. S. Castano Sistemi Informativi - AA. 2022/23 »28

 È basata su principi diversi e spesso in contrasto con

Prof. S. Castano Sistemi Informativi - AA. 2022/23 29

Le principali operazioni da svolgere durante progettazione

1. Scelta dello schema logico da utilizzare (es. star/snowflake

Prof. S. Castano Sistemi Informativi - AA. 2022/23 30

Prof. S. Castano Sistemi Informativi - AA. 2022/23 31

Prof. S. Castano Sistemi Informativi - AA. 2022/23 32

Prof. S. Castano Sistemi Informativi - AA. 2022/23 33

distretto numero numero

uso del num.

!  Uno schema relazionale con

%  Notazione sintetica per una foreing key

!  Se KR è not null allora la partecipazione di R1 è obbligatoria : X=1

!  Se la chiave di R è l'insieme di tutte le foreign key:

!  Schema E/R ASSEGNO (0,N)