Sistemi Informativi Avanzati
Anno Accademico 2012/2013
Prof. Domenico Beneventano
Progettazione di un
Data Warehouse
Dai Capitoli 2,3 e 4 del libro
Data Warehouse - teoria e pratica della Progettazione
Autori: Matteo Golfarelli, Stefano Rizzi;
Editore: McGraw-Hill
Contenuto
!
Progettazione di un Data Warehouse
Nella prima parte verrà delineato il processo di
progettazione di un Data Warehouse,
evidenziando gli obiettivi del corso
!
Progetto di un DW da un DB relazionale
Nella seconda parte verranno evidenziati alcuni passi
preliminari nella progettazione di un Data Warehouse a
partire da un database relazionale
! Documentazione di schemi E/R
! Reverse engineering di schemi relazionali
Approccio top-down
!
Analizza i bisogni globali dell'intera azienda e pianifica lo
sviluppo del DW per poi progettarlo nella sua interezza
" Promette ottimi risultati poiché si basa su una visione globale dell'obiettivo
e garantisce in linea di principio di produrre un DW consistente e ben
integrato
# Il preventivo di costi onerosi a fronte di lunghi tempi di realizzazione
scoraggia la direzione dall'intraprendere il progetto
# Affrontare contemporaneamente l'analisi e la riconciliazione di tutte le
sorgenti di interesse è estremamente complesso
# Riuscire a prevedere a priori nel dettaglio le esigenze delle diverse aree
aziendali impegnate è pressoché impossibile, e il processo di analisi
rischia di subire una paralisi
# Il fatto di non prevedere la consegna a breve termine di un prototipo non
permette agli utenti di verificare l'utilità del progetto e ne fa scemare
l'interesse e la fiducia
3
Approccio bottom-up
!
Il DW viene costruito in modo incrementale, assemblando
iterativamente più data mart, ciascuno dei quali incentrato
su un insieme di fatti collegati a uno specifico settore
aziendale e di interesse per una certa categoria di utenti
" Determina risultati concreti in tempi brevi
" Non richiede elevati investimenti finanziari
" Permette di studiare solo le problematiche relative al data mart in
oggetto
" Fornisce alla dirigenza aziendale un riscontro immediato
sull'effettiva utilità del sistema in via di realizzazione
" Mantiene costantemente elevata l'attenzione sul progetto
# Determina una visione parziale del dominio di interesse
4
Data Mart (DM)
DATA MART:
un sottoinsieme o un'aggregazione dei dati
presenti nel DW primario, contenente
l'insieme delle informazioni rilevanti per
una particolare area del business, una
particolare divisione dell'azienda, una
particolare categoria di soggetti.
!
Il primo data mart da
prototipare...
DM4
DM2
$ deve essere quello che
gioca il ruolo più strategico
per l'azienda
$ deve ricoprire un ruolo
centrale e di riferimento
per l'intero DW
$ si deve appoggiare su
fonti dati già disponibili e
consistenti
DM1
DM3
DM5
Source 3
Source 1
Source 2
5
La progettazione del
data mart
amministratore db"
Analisi e riconcilia-!
zione delle sorgenti"
Analisi dei"
requisiti"
Progettazione "
concettuale"
progettista"
utente finale"
Raffinamento del"
carico di lavoro"
Progettazione"
logica"
Progettazione"
dell'alimentazione"
Progettazione"
fisica"
6
La progettazione del data mart
requisiti utente"
schema riconciliato"
PROGETTAZIONE"
CONCETTUALE"
schemi"
delle"
sorgenti
operazionali"
carico di lavoro"
volume dati"
modello logico"
schema di fatto"
RICONCILIAZIONE"
PROGETTAZIONE"
LOGICA"
schema riconciliato"
carico di lavoro"
volume dati"
DBMS"
schema logico"
PROGETTAZIONE"
FISICA"
PROGETTAZIONE"
DELL'ALIMENTAZIONE"
schema fisico"
schema dell'alimentazione"
7
Analisi e riconciliazione
delle sorgenti operazionali
!
In presenza di più
sorgenti operazionali,
questa fase ricade in
un problema più
generale di
Data Integration.
Sorgente I"
Sorgente II"
Schema logico
(locale)"
Schema logico
(locale)"
Ricognizione e
normalizzazione!
Ricognizione e
normalizzazione!
Schema concettuale
(locale) trasformato"
Schema concettuale
(locale) trasformato"
%
Schema
concettuale
(globale) riconciliato"
In queste slide
il problema viene
Meta-dati"
illustrato
intuitivamente tramite
un esempio.
Integrazione!
degli schemi!
Schema concettuale"
(globale) riconciliato"
Definizione corrispondenza!
con le sorgenti!
Schema logico"
(globale) riconciliato"
e corrispondenza"
8
Analisi e riconciliazione
delle sorgenti operazionali
Sorgente I"
PERSONA(NOMECOGNOME,
TELEFONO1,
TELEFONO2,
MAIL)
Sorgente II"
INDIVIDUO(NOME,
COGNOME,
TELEFONO,
Schema logico HOMEPAGE)
Schema logico
(locale)"
(locale)"
Ricognizione e
normalizzazione!
TELEFONO2(0,1)
TELEFONO1
Ricognizione e
normalizzazione!
NOMECOGNOME
PERSONA
Schema
concettuale
(globale) riconciliato"
MAIL
Integrazione!
degli schemi!
Schema concettuale"
(globale) riconciliato"
TELEFONO)
COGNOME
NOME
TELEFONO
NOMECOGNOME
Schema concettuale
(locale) trasformato"
Schema concettuale
(locale) trasformato"
Definizione corrispondenza!
con le sorgenti!
Meta-dati"
PERSONA
WEB
INDIVIDUO
Schema logico"
(globale) riconciliato"
e corrispondenza"
HOMEPAGE
PERSONA(NOMECOGNOME,WEB,
TELEFONO)
9
CORRISPONDENZE (MAPPING)
SCHEMA LOGICO
RICONCILIATO
SCHEMA LOGICO
SORGENTE 1
PERSONA
SCHEMA LOGICO
SORGENTE 2
INDIVIDUO
NOMECOGNOME NOMECOGNOME NOME+
COGNOME
TELEFONO
TELEFONO1
TELEFONO
WEB
MAIL
HOMEPAGE
Progettazione del livello riconciliato
Schemi sorgenti
operazionali"
Campioni dei dati"
Analisi e
riconciliazione"
Schema riconciliato,"
Mapping sorgenti
operazionali"
Progettazione
del cleaning!
Progettazione
della
trasformazione!
Procedure per
strumenti ETL"
Schema riconciliato,"
Mapping sorgenti
operazionali"
Strumenti ETL"
Meta-dati"
$ La fase di integrazione è incentrata sulla componente intensionale delle
sorgenti operazionali, ossia riguarda la consistenza degli schemi che le
descrivono
$ Pulizia e trasformazione dei dati operano a livello estensionale, ossia
coinvolgono direttamente i dati veri e propri
11
Ricognizione e normalizzazione
!
Il progettista, confrontandosi con gli esperti del dominio
applicativo, acquisisce un'approfondita conoscenza delle
sorgenti operazionali attraverso:
$ Ricognizione : esame approfondito degli schemi locali mirato
alla piena comprensione del dominio applicativo;
$ Normalizzazione: l'obiettivo è correggere gli schemi locali per
modellare in modo più accurato il dominio applicativo
Ricognizione e normalizzazione devono essere svolte
anche qualora sia presente una sola sorgente dati; qualora
esistano più sorgenti, l'operazione dovrà essere ripetuta
per ogni singolo schema
! Il punto di partenza, l'input del processo è costituito da:
!
1. Schema logico e istanza della sorgente
2. Eventuale schema concettuale equivalente allo schema logico
3. Eventuale documentazione della sorgente operazionale
12
Analisi e Riconciliazione: obiettivi
!
!
Fase importante, costituisce un input per tutta la progettazione
E' un problema più ampio di Data Integration in quanto le
sorgenti operazionali sono molteplici
%
Parte teorica/esercizi scritti, analisi e riconciliazione si
considerano già fatte: il punto di partenza è uno schema E/R
completo e il relativo schema logico relazionale
%
Parte pratica/tesina, l’analisi e riconciliazione delle sorgenti
deve essere condotta dallo studente
% Data Profiling : analisi delle sorgenti operazionali per
scoprire/rilevare proprietà e relazioni tra i dati e ottenerne
una rappresentazione concettuale (schema E/R)
Data Profiling: un esempio
!
!
Consideriamo una tabella PRODOTTO contenuta in un DB
relazionale oppure in un foglio Excel o in un file csv.
Riportiamo in ogni caso la tabella in un DB relazionale:
quindi consideriamo la relazione
PRODOTTO(CodProd,NomeProd,DescrizioneProd,
DescrizioneCategoria,NomeCategoria,
CodiceCategoria)
CodProd è stata supposta chiave in quanto codice progressivo.
%
%
Nelle slide che seguono viene data una intuizione di come
analizzare lo schema e l'istanza del DB per individuare vincoli di
integrità non dichiarati ma impliciti nei dati.
L’analisi viene condotta tramite semplici query SQL (si sfrutta
quindi il fatto che la relazione è stata riportata in un RDB)
14
Data Profiling: un esempio
& Analizzando alcune istanze si individuano proprietà ragionevoli
sulla base dei nomi degli attributi. Queste proprietà sono
espresse come vincoli di integrità (chiavi, foreign key,
dipendenze funzionali) sulle relazioni
A.
Chiavi: NomeProd è chiave alternativa?
SELECT NomeProd
FROM PRODOTTO
WHERE NomeProd IS NULL
B.
SELECT NomeProd
FROM PRODOTTO
GROUP BY NomeProd
HAVING count(*)> 1
Dipendenze funzionali: si analizzano le seguenti FD
1) CodiceCategoria ' NomeCategoria
2) CodiceCategoria ' DescrizioneCategoria
3) CodProdotto ' CodiceCategoria
4) CodiceCategoria ' CodProdotto
1) SELECT CodiceCategoria
FROM PRODOTTO
GROUP BY CodiceCategoria
HAVING count(DISTINCT NomeCategoria )> 1
15
Data Profiling: un esempio
!
Supponendo valide le prime tre DF si ottiene il seguente schema
logico:
CATEGORIA(Codice,Nome,Descrizione)
AK: Nome
PRODOTTO(Codice,NomeProd,Descriz,CodiceCategoria)
!
Si analizzano le relazioni tra tabelle individuando le foreign key;
nell’esempio CodiceCategoria è una foreign key riferita al
Codice tre CATEGORIA ?
Due possibilità per verificarlo
1. Si dichiara e verifica il vincolo nello schema relazionale
2. Si effettua un controllo preliminare in SQL per individuare le
tuple (oppure il loro numero) di PRODOTTO che
non soddisfano la foreign key:
SELECT * – oppure count(*)
FROM PRODOTTO
WHERE CodiceCategoria IS NOT NULL
AND CodiceCategoria NOT IN (SELECT CODICE
FROM PRODOTTO)
16
Data Profiling: un esempio
!
Supponendo valida la foreign key si ottiene il seguente schema
logico riconciliato e normalizzato:
CATEGORIA(Codice,Nome,Descrizione)
AK: Nome
PRODOTTO(Codice,NomeProd,Descriz,
CodiceCategoria:CATEGORIA)
!
In un'architettura a tre livelli, tale schema logico costituisce lo
schema riconciliato e riviene implementato in un nuovo RDB che
verrà alimentato con i dati del RDB iniziale.
!
E' semplice ricavare lo schema E/R
che può essere completato con altri
vincoli, sempre verificati sull'istanza (es.
una categoria ha almeno un prodotto)
%
Il procedimento generale per ricavare lo
schema E/R è in Reverse Engineering,
alla fine di queste slide.
"
PRODOTTO"
descrizione"
nome"
codice"
(1,1)"
appartiene
a"
(1,n)"
"
CATEGORIA"
descrizione"
nome"
codice" 17
Analisi e Riconciliazione: Riepilogo
!
Parte teorica/esercizi : fase già svolta, si parte da E/R+relazionale
TIPO
PRODOTTO
prodotto
quantità
(0,N)
in
(1,1)
prezzo
unitario
VENDITA
(1,1)
data
in
(1,N)
SCONTRINO
num. scontrino
PRODOTTO(PRODOTTO,TIPO)
SCONTRINO(NUMSCONTRINO,DATA)
VENDITA(PRODOTTO:PRODOTTO,NUMSCONTRINO:SCONTRINO
QUANTITA,PREZZOUNITARIO
!
Parte pratica/tesina: per considerare un caso reale, non ha
senso partire da un DBR con già lo schema E/R completo:
!
Fase di analisi e riconciliazione : esempi e strumenti in laboratorio.
Analisi dei requisiti
La fase di analisi dei requisiti ha l'obiettivo di raccogliere le
esigenze di utilizzo del data mart espresse dai suoi utenti
finali
! Essa ha un'importanza strategica poiché influenza le
decisioni da prendere riguardo:
$ lo schema concettuale dei dati
$ il progetto dell'alimentazione
$ le specifiche delle applicazioni per l'analisi dei dati
$ l'architettura del sistema
$ il piano di avviamento e formazione
$ le linee guida per la manutenzione e l'evoluzione del
sistema.
!
19
Fonti
!
La fonte principale da cui attingere i requisiti
sono i futuri utenti del data mart (business users)
$ La differenza nel linguaggio usato da progettisti e
utenti, e la percezione spesso distorta che questi ultimi
hanno del processo di warehousing, rendono il dialogo
difficile e a volte infruttuoso
!
Per gli aspetti più tecnici, saranno gli
amministratori del sistema informativo e/o i
responsabili del CED a fungere da riferimento
per il progettista
$ In questo caso, i requisiti che dovranno essere catturati
riguardano principalmente vincoli di varia natura
imposti sul sistema di data warehousing
20
I fatti
!
I fatti sono i concetti su cui gli utenti finali del data mart
baseranno il processo decisionale; ogni fatto descrive una
categoria di eventi che si verificano in azienda
$ Fissare le dimensioni di un fatto è importante poiché significa
determinarne la granularità, ovvero il più fine livello di
dettaglio a cui i dati saranno rappresentati. La scelta della
granularità di un fatto nasce da un delicato compromesso tra
due esigenze contrapposte: quella di raggiungere un'elevata
flessibilità d'utilizzo e quella di conseguire buone prestazioni
$ Per ogni fatto occorre definire l'intervallo di storicizzazione,
ovvero l'arco temporale che gli eventi memorizzati dovranno
coprire"
21
I fatti
commerciale/
manufatturiero
finanziario
sanitario
trasporti
telecomunicazioni
turismo
gestionale
Data mart
approvvigionamenti
produzione
gestione domanda
marketing
bancario
investimenti
Fatti
acquisti, inventario di magazzino, distribuzione
confezionamento, inventario, consegna, manifattura
vendite, fatturazione, ordini, spedizioni, reclami
promozioni, fidelizzazione, campagne pubblicitarie
conti correnti, bonifici, prestiti ipotecari, mutui
acquisto titoli, transazioni di borsa
servizi
scheda di ricovero
pronto soccorso
medicina di base
merci
passeggeri
manutenzione
carte di credito, domiciliazioni bollette
ricoveri, dimissioni, interventi chirurgici, diagnosi
accessi, esami, dimissioni
scelte, revoche, prescrizioni
domanda, offerta, trasporti
domanda, offerta, trasporti
interventi
traffico
CRM
gestione domanda
CRM
logistica
risorse umane
traffico in rete, chiamate
fidelizzazione, reclami, servizi
biglietteria, noleggi auto, soggiorni
frequent-flyers, reclami
trasporti, scorte, movimentazione
assunzioni, dimissioni, promozioni, incentivi
budgeting
infrastrutture
budget commerciale, budget di marketing
acquisti, opere
22
ESEMPIO : flessibilità vs prestazioni
!
Schema E/R delle vendite:
TIPO
prezzo
unitario
quantità
PRODOTTO
(0,N)
in
(1,1)
VENDITA
(1,1)
data
in
(1,N)
prodotto
SCONTRINO
num. scontrino
1. Dimensioni = { prodotto, num.scontrino } : massima granularità
" Flessibilità: analisi del numero clienti rispetto al tipo
# Prestazioni: il Data Mart ha volume paragonabile con il DBO
2. Dimensioni = { prodotto, data } : minore granularità
" Prestazioni: il Data Mart ha volume ridotto rispetto al DBO
# Flessibilità: analisi del numero clienti rispetto al tipo non più fattibili
23
ESEMPIO : vendite (DB Operazionale)
!
Scontrini:
Scontr12, del 02/02/02
Scontr13, del 02/02/02
ALIM_1, qty 10, prezzo 25
ALIM_2, qty 24, prezzo 13
ALIM_2, qty 20, prezzo 12
!
!
!
DB operazionale:
PRODOTTO
SCONTRINO
PRODOTTO
TIPO
NUMERO
DATA
ALIM_1
Alimentare
Scontr12
02/02/02
ALIM_2
Alimentare
Scontr13
02/02/02
VENDITA
PRODOTTO
N_SCONTRINO
QUANTITA
PREZZO_UNITARIO
ALIM_1
Scontr12
12
25
ALIM_2
Scontr12
13
12
ALIM_2
Scontr13
24
13
24
ESEMPIO : vendite (DATA MART)
!
Dimensioni = { prodotto, num.scontrino }
( granularità transazionale (massima granularità)
un evento primario nel Data Mart corrisponde ad una
sola istanza del fatto nel DB Operazionale
FATTO VENDITA (Misure = { quantità, numero_clienti })
ROLLUP
L'operatore di
aggregazione per
NUMERO_CLIENTI
è COUNT
DISTINCT di
N_SCONTRINO
PRODOTTO N_SCONTRINO QUANTITA NUMERO_CLIENTI
ALIM_1
Scontr12
12
1
ALIM_2
Scontr12
13
1
ALIM_2
Scontr13
24
1
TIPO
N_SCONTRINO
Alimentare
Scontr12
25
1
Alimentare
Scontr13
24
1
QUANTITA NUMERO_CLIENTI
TIPO
QUANTITA
NUMERO_CLIENTI
Alimentare
59
2
L'operatore di
aggregazione per
QUANTITA è SUM
25
ESEMPIO : vendite (DATA MART)
!
Dimensioni = { prodotto, data }
( granularità temporale
un evento primario nel Data Mart corrisponde a più istanze
del fatto nel DB Operazionale:
le misure del fatto devono essere calcolate tramite
funzioni di aggregazione sulle istanze del DB operazionale
quantità = SUM(VENDITA.QUANTITA)
numero_clienti =COUNT(DISTINCT VENDITA.NSCONTRINO)
FATTO VENDITA (Misure = { quantità, numero_clienti })
PRODOTTO
DATA
QUANTITA
NUMERO_CLIENTI
ALIM_1
02/02/02
25
1
ALIM_2
02/02/02
24
2
TIPO
DATA
QUANTITA
NUMERO_CLIENTI
Alimentare
02/02/02
59
???
ROLLUP
Non è più possibile
valutare il
NUMERO_CLIENTI
rispetto al TIPO!
26
Progettazione concettuale: un esempio
TIPO
PRODOTTO
quantità
(0,N)
in
(1,1)
prezzo
unitario
VENDITA
data
quantità
tipo
(1,1)
in
(1,N)
data
SCONTRINO
prodotto
prodotto
num. scontrino
!
Dimensioni = { Prodotto,
NumSContrino}
!
Schema di Fatto transazionale:
PRODOTTO
TIPO
VENDITA
QUANTITA
NUM_VENDITE
NUM_CLIENTI
prezzo-unitario
prodotto +
num.scontrino
num.scontrino
!
Dimensioni = { Prodotto, Data}
!
Schema di Fatto temporale :
NSC
PRODOTTO
VENDITA
QUANTITA
DATA
DATA
NUM_VENDITE
TIPO
NUM_CLIENTI
27
Un Esempio più completo
!
Esempio delle vendite con scontrino (nella tabella, per
semplicità, il tipo è sottinteso dal nome del prodotto)
VENDITA - DB OPERAZIONALE
TIPO
PRODOTTO
!
(1,N)
PREZZO
VENDITA
DATA
(1,N)
SCONTRINO
Misure
1. NUMERO_VENDITE = COUNT(*)
2. PREZZO_MEDIO = AVG (PREZZO)
3. NUMERO_CLIENTI = COUNT(DISTINCT SCONTRINO)
il numero clienti è valutato contando gli scontrini
4. NUMERO_PRODOTTI = COUNT(DISTINCT PRODOTTO)
per valutare quanti differenti prodotti vengono venduti
28
Esempio: Analisi dei dati - aggregazione
!
Le dimensioni di analisi
sono MESE e TIPO
!
Il report completo da
ottenere è il seguente:
VENDITA - DB OPERAZIONALE
REPORT : MESE-TIPO, tutte le misure, con i totali
Legenda
29
Esempio: il report in SQL-OLAP
!
Il report si può ottenere con i vari strumenti OLAP (cubo
multidimensionale, tabelle pivot, SQL-OLAP !)
DB OPERAZIONALE
!
In SQL-OLAP:
30
Esempio: Operatore COUNT(*)
ALIMENTAZIONE
DATA MART
NUMERO_VENDITE = COUNT(*)
FACT_TABLE
(DATA MART)
ANALISI DEI DATI
(AGGREGAZIONE)
%
NUMERO_VENDITE = SUM(NUMERO_VENDITE)
Per l operatore COUNT(*) è corretto calcolare il valore
aggregato a partire dai valori presenti nel Data Mart !
31
Esempio: Prezzo Medio tramite AVG
ALIMENTAZIONE
DATA MART
PREZZO_MEDIO= AVG(PREZZO)
FACT_TABLE
(DATA MART)
ANALISI DEI DATI
(AGGREGAZIONE)
NO!
(25+17.5)/2 = 21.25
%
PREZZO_MEDIO= AVG(PREZZO_MEDIO)
NO!
(10+25+17.5)/3 = 16.25
Per l operatore AVG non è corretto calcolare il valore aggregato
a partire dai valori presenti nel Data Mart!
32
Esempio: Prezzo Medio calcolato
NUMERO_VENDITE = COUNT(*)
PREZZO_SOMMA = SUM(PREZZO)
ALIMENTAZIONE
DATA MART
FACT_TABLE
(DATA MART)
ANALISI DEI DATI
(AGGREGAZIONE)
PREZZO_MEDIO =
OK!
OK!
(20+25+35)/(2+1+2) = 16.0
(25+35)/(1+2) = 20.0
%
PREZZO_SOMMA
---------------------NUMERO_VENDITE
PREZZO_MEDIO deve essere una misura calcolata da altre
misure componenti
33
Esempio: Operatore COUNT(DISTINCT )
ALIMENTAZIONE
DATA MART
NUM_CLIENTI= COUNT(DISTINCT SCONTRINO)
FACT_TABLE
(DATA MART)
ANALISI DEI DATI
(AGGREGAZIONE)
NUMERO_CLIENTI= SUM(NUMERO_CLIENTI)
NO !
1+1=2
OK !
1+2 = 3
%
NO !
1+1+2=4
Per l operatore COUNT(DISTINCT ) non è sempre corretto
calcolare il valore aggregato dai valori nel Data Mart :
NUMERO_CLIENTI è non aggregabile rispetto a TIPO!
34
Esempio: Operatore COUNT(DISTINCT )
ALIMENTAZIONE
DATA MART
NUMERO_PRODOTTI= COUNT(DISTINCT PRODOTTO)
FACT_TABLE
(DATA MART)
ANALISI DEI DATI
(AGGREGAZIONE)
NUMERO_PRODOTTI= SUM(NUMERO_PRODOTTI)
OK!
2+1=3
NO!
1+2 = 3
%
NO !
2+1+2=5
NUMERO_PRODOTTI è non aggregabile rispetto a MESE: non
è possibile calcolare i valori per TOTALE_MESE
35
Analisi dei Requisiti: obiettivi del corso
!
Fase importante, costituisce un altro input per la progettazione
%
Parte teorica/esercizi scritti, i requisiti costituiscono un input
del problema e verranno espressi indicando
1.
2.
3.
%
Il fatto da progettare (esempio: fatto VENDITA) con le relative
dimensioni del fatto (esempio: {DATA,PRODOTTO})
Le misure del fatto (esempio: {QUANTITA,PREZZO,
NUMERO_CLIENTI})
Le analisi da effettuare (query in SQL-OLAP)
Parte pratica/ tesina, l’analisi dei requisiti deve essere condotta
dallo studente individuando
1.
2.
3.
I fatti da progettare (normalmente due fatti)
Dimensioni e Misure
Analisi da effettuare (con strumenti OLAP)
Esempio di requisito
in un esercizio di progettazione
!
Dato il DBO con schema relazionale (vedi pagina 46)
effettuare la progettazione dello schema di fatto OPERAZIONE con
dimensioni : TIPO,BANCA,CLIENTE,DATA
(TIPO ha due valori : 'P' per i prelievi e 'V' per i versamenti)
e misure :
IMPORTOMEDIO: è l'importo medio dell'operazione
NUMEROTOTALE: è il numero totale di operazioni
% Lo schema del DBO può contenere anche
semplici dipendenze funzionali (FD):
CITTA(CITTA,REGIONE,STATO)
FD: REGIONE ' STATO
OPERAZIONE(… DATA, MESE, ANNO,IMPORTO)
FD: DATA ' MESE
FD: MESE ' ANNO
37
Risultato della progettazione concettuale
!
Schema di fatto con granularità temporale
CITTA
REGIONE
BANCA
STATO
OPERAZIONE
DATA
CLIENTE
NUMEROTOTALE
(C) IMPORTOMEDIO (AVG)
MESE
ANNO
TIPO
38
Progetto di un DW da un DB relazionale
!
La sorgente operazionale è un DB relazionale (RDB)
!
Oltre allo schema logico-relazionale, più o meno completo
con vincoli di integrità (chiavi, integrità referenziale, valori
nulli, !), la documentazione generalmente disponibile per
un RDB può comprendere
1.
2.
!
Uno schema E/R “equivalente” allo schema logico con
l’eventuale documentazione allegata
Altra documentazione generica sul RDB, quale le
specifiche e requisiti del RDB e Manuali d'uso
Se lo schema E/R del RDB non è disponibile esso viene
ricavato attraverso tecniche di Reverse engineering
Documentazione di schemi E/R
!
Uno schema E/R non è quasi mai sufficiente da solo a rappresentare
tutti gli aspetti e vincoli di un dominio applicativo, per varie ragioni:
1.
2.
in uno schema E/R compaiono solo i nomi dei vari concetti ma questo
può essere insufficiente per comprenderne il significato.
vari vincoli di integrità (proprietà dei dati rappresentati) non possono
essere espressi direttamente dai costrutti del modello E/R
!
Documentazione di schemi E-R: uno schema E/R è corredato con
una documentazione di supporto che faciliti l'interpretazione dello
schema stesso e a descrivere vincoli di integrità non esprimibili in E/R
!
Regole aziendali o business rules
$
$
$
Una descrizione di un concetto (entità,associazione attributo) dello
schema associazione del modello E-R (Dizionario dei dati)
Un Vincolo di integrità, sia esso la documentazione di un vincolo già
nello schema E/R o la descrizione di un vincolo non esprimibile in E/R
Una Derivazione ovvero un concetto che può essere ottenuto attraverso
un'inferenza o un calcolo da altri concetti dello schema (Dato Derivato)
40
Data Profiling di un DB relazionale
!
Analisi delle istanze del DB per scoprire vincoli di integrità non
noti ed impliciti nei dati. E’ importante in ogni caso:
1.
2.
DB con schema E/R e documentazione disponibile
Nella realtà spesso non tutte le business rules sono
documentate: ci sono vincoli di integrità non espressi nello
schema E/R e non documentati.
DB con schema E/R non disponibile
Lo schema relazionale di partenza per effettuare Reverse
Engineering non è quasi mai completo e normalizzato
$ Individuazione di chiavi, chiavi esterne, !
$ Individuazione di dipendenze funzionali e normalizzazione dello
schema
Oltre a questi vincoli di integrità “classici”, nel caso di progettazione
di un DW vengono analizzati vincoli particolari quali la convergenza
!
41
Reverse engineering di schemi relazionali
!
Dallo schema relazionale ottenere lo schema E/R equivalente
!
Procedimento inverso della Progettazione logico-relazionale:
dato uno schema E/R tradurlo in uno schema relazionale
!
!
!
Regole di semplificazione dello schema E/R per eliminare identificatori
esterni, gerarchie, !
Regole di traduzione logico-relazionale per tradurre uno schema E/R in
uno schema relazionale normalizzato
Il Reverse engineering di schemi relazionali in schemi E/R si
basa sull'applicazione in senso inverso di queste regole di
semplificazione e traduzione.
Per rendere efficace il processo si deve partire da
1. Uno schema relazionale completo con le indicazioni di chiavi e di
integrità referenziale (chiavi esterne), valori nulli, !
2. Uno schema relazionale normalizzato (infatti le regole di traduzione
logico-relazionale forniscono uno schema relazionale normalizzato)
42
Reverse engineering : entità e gerarchie
!
Si inizia considerando le relazioni senza
chiavi esterne, 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
%
!
STUDENTE(MATR, ETA)
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, ..!
43
Reverse engineering : associazioni
!
Dato uno schema relazionale con
!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
!
Se KR è una parte della chiave di R1:
R1(K1,KR, ...)
la FK traduce un identificatore esterno
44
Reverse engineering : associazioni
In generale, una relazione R con n foreign key RKi riferite ad n
relazioni Ri individua un'associazione n-aria tra le Ri
(regola di traduzione-standard )
!!
!
!
!R (RK1:R1,..., RKn:Rn, ...)
!
Se la chiave di R è l'insieme di tutte le foreign key:
R (RK1,..., RKn, ...)
!
allora tutte le entità hanno 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
Reverse engineering : esempio
!
Schema relazionale dato
CITTA(CITTA,REGIONE,STATO)
CLIENTE(CLIENTE,CITTA:CITTA)
BANKOMAT(BANKOMAT,CLIENTE:CLIENTE)
BANCA(BANCA,CITTA:CITTA)
FILIALE(FILIALE,BANCA:BANCA)
OPERAZIONE(NUMOP,BANKOMAT:BANKOMAT,
FILIALE:FILIALE,DATA,MESE,ANNO,IMPORTO)
VERSAMENTO([NUMOP,BANKOMAT]:OPERAZIONE,
ASSEGNO, ASSEGNODI:BANCA)
AK:ASSEGNO
!
Se non diversamente specificato
tutte le foreign key si suppongono not null
46
Reverse engineering : esempio
!
Schema E/R
corrispondente
BANCA
ASSEGNO
DI
(1,1)
REGIONE
IN
STATO
CITTA
(0,N)
(0,N)
(0,N)
(1,N)
CITTA
BANCA
(1,1)
DI
INDIRIZZO
VERSAMENTO
ASSEGNO
(1,1)
(1,1)
FILIALE
CLIENTE
ASSEGNO
FILIALE
(0,N)
(1,N)
CLIENTE
DA
DEL
IMPORTO
(1,1)
(1,1)
MESE
ANNO
DATA
OPERAZIONE
(1,1)
(1,N)
BANKOMAT
BANKOMAT
NUMOP
!
Le cardinalità minime delle entità con molteplicità maggiore di 1 (es:
BANCA nell'associazione ASSEGNO-DI) non sono nello schema
relazionale : occorre riferirsi ad altre informazioni, analizzare l'istanza
del database, presenza di trigger, ..!
47
Vincoli di integrità scoperti sui dati
!
Per definizione un vincolo di integrità deve essere valido
per tutte le istanze dello schema
!
Un vincolo di integrità scoperto sui dati vale ovviamente
solo per l'istanza corrente
!
!
Riportare un vincolo scoperto sui dati sullo schema
riconciliato deve essere una decisione del progettista!
Come comportarsi se un vincolo viene considerato valido
e riportato sullo schema riconciliato ma poi risulta non più
verificato da alcune istanze del RDB?
!
Le istanze che non verificano il vincolo possono essere
corrette oppure non riportate – in fase di alimentazione –
nel RDB conciliato.
48
