Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
Queste dispense sono state estratte dalle dispense originali delProf. Stefano Rizzi, disponibili in http://www-db.deis.unibo.it/~srizzi/)
e sono state tratte dal libro di testo [Data Warehouse - teoria epratica della Progettazione, Autori: Matteo Golfarelli, Stefano Rizzi,Editore: McGraw-Hill]
Esse quindi costituiscono anche un’indicazione degli argomenti dellibro di testo svolti durante il corso.
Progettazione del
Data Warehouse
2
Approccio top-down
! Analizza i bisogni globali dell’intera azienda e pianifica losviluppo del DW per poi progettarlo e realizzarlo nella suainterezza" Promette ottimi risultati poiché si basa su una visione globale
dell’obiettivo e garantisce in linea di principio di produrre un DWconsistente e ben integrato
# Il preventivo di costi onerosi a fronte di lunghi tempi di realizzazionescoraggia la direzione dall’intraprendere il progetto
# Affrontare contemporaneamente l’analisi e la riconciliazione di tuttele sorgenti di interesse è estremamente complesso
# Riuscire a prevedere a priori nel dettaglio le esigenze delle diversearee aziendali impegnate è pressoché impossibile, e il processo dianalisi rischia di subire una paralisi
# Il fatto di non prevedere la consegna a breve termine di unprototipo non permette agli utenti di verificare l’utilità del progetto ene fa scemare l’interesse e la fiducia
3
Approccio bottom-up
! Il DW viene costruito in modo incrementale,assemblando iterativamente più data mart, ciascunodei quali incentrato su un insieme di fatti collegati auno specifico settore aziendale e di interesse per unacerta categoria di utenti" Determina risultati concreti in tempi brevi
" Non richiede elevati investimenti finanziari
" Permette di studiare solo le problematiche relative al datamart in oggetto
" Fornisce alla dirigenza aziendale un riscontro immediatosull’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)
$ Aspetti architetturali (non trattati al momento …)• Un DM è un differente database rispetto al DW
• Un DM può essere alimentato dal DW , o viceversa
$ Finchè consideriamo un DW costituito da un singolo DM, idue termini sono sinonimi
DM1
Source 1
DM2
DM3
Source 2
DM4
DM5
Source 3
DATA MART:
un sottoinsieme o un’aggregazione deidati presenti nel DW primario, contenentel’insieme delle informazioni rilevanti peruna particolare area del business, unaparticolare divisione dell’azienda, una
particolare categoria di soggetti.
5
Il primo data mart da
prototipare...
$ deve essere quelloche gioca il ruolo piùstrategico perl’azienda
$ deve ricoprire unruolo centrale e diriferimento perl’intero DW
$ si deve appoggiaresu fonti dati giàdisponibili econsistenti
DM1
Source 1
DM2
DM3
Source 2
DM4
DM5
Source 3
6
La progettazione del
data martAnalisi e riconcilia-
zione delle sorgenti
Analisi dei
requisiti
Progettazione
concettuale
Raffinamento del
carico di lavoro
Progettazione
logica
Progettazione
dell’alimentazione
utente finale
progettista
amministratore db
Progettazione
fisica
7
La progettazione del
data mart
schema di fatto
PROGETTAZIONECONCETTUALE
requisiti utente
schema logico
PROGETTAZIONELOGICA
carico di lavorovolume dati
modello logico
schema fisico
PROGETTAZIONEFISICA
carico di lavoro
volume dati
DBMS
schemi
delle
sorgenti
operazionali
schema riconciliato
RICONCILIAZIONE
schema riconciliato
PROGETTAZIONEDELL!ALIMENTAZIONE
schema dell!alimentazione
Analisi e riconciliazione delle
sorgenti operazionali
Rispetto alle dispense originali, la parte di integrazione dipiù sorgenti operazionali è stata eliminata in quanto verràtrattata più ampiamente nella parte del corso relativa allaIntegrazione delle Informazioni
È rimasta solo la parte sull’analisi di una singola sorgente.
9
Progettazione del livello
riconciliato
$ La fase di integrazione è incentrata sulla componente intensionale dellesorgenti operazionali, ossia riguarda la consistenza degli schemi che ledescrivono
$ Pulizia e trasformazione dei dati operano a livello estensionale, ossiacoinvolgono direttamente i dati veri e propri
Meta-dati
Progettazione
del cleaning
Progettazione
della
trasformazioneSchema riconciliato,
Mapping sorgentioperazionali
Schemi sorgentioperazionali Campioni
dei dati
Schema riconciliato,Mapping sorgentioperazionali
Procedure perstrumenti ETL
Strumenti ETL
Analisi e
riconciliazione
10
Analisi e riconciliazione
delle sorgenti operazionaliSorgente I
Ricognizione e
normalizzazione
Schema logico
(locale)
Sorgente II
Ricognizione e
normalizzazione
Schema logico(locale)
Definizione
corrispondenza
con le sorgenti
Meta-dati
Schema logico
(globale) riconciliato
e corrispondenza
Schema
concettuale
(globale) riconciliato Schema concettuale
(globale) riconciliato
Schema concettuale
(locale) trasformato
Integrazione
degli schemi
Schema concettuale
(locale) trasformato
11
Ricognizione e
normalizzazione! Il progettista, confrontandosi con gli esperti del
dominio applicativo, acquisisce un’approfonditaconoscenza delle sorgenti operazionali attraverso:$ ricognizione, che consiste in un esame approfondito degli
schemi locali mirato alla piena comprensione del dominioapplicativo;
$ normalizzazione, il cui obiettivo è correggere gli schemilocali al fine di modellare in modo più accurato il dominioapplicativo
! Ricognizione e normalizzazione devono esseresvolte anche qualora sia presente una sola sorgentedati; qualora esistano più sorgenti, l’operazione dovràessere ripetuta per ogni singolo schema
12
Ricognizione e
normalizzazione
PRODOTTOcodiceProdnomeProd
descrizioneProd
codiceCategorianomeCategoria
descrizioneCategoria
appartienea
(1,1)
(1,n)
PRODOTTOcodice
nome
descrizione
CATEGORIA
codice
nome
descrizione
Analisi dei requisiti
Versione semplificata rispetto alle dispense originali
14
Obiettivi
! La fase di analisi dei requisiti ha l’obiettivo diraccogliere le esigenze di utilizzo del data martespresse dai suoi utenti finali
! Essa ha un’importanza strategica poiché influenza ledecisioni 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 delsistema.
15
Fonti
! La “fonte” principale da cui attingere irequisiti sono i futuri utenti del data mart(business users)$ La differenza nel linguaggio usato da progettisti e
utenti, e la percezione spesso distorta che questiultimi hanno del processo di warehousing,rendono il dialogo difficile e a volte infruttuoso
! Per gli aspetti più tecnici, saranno gliamministratori del sistema informativo e/o iresponsabili del CED a fungere dariferimento per il progettista$ In questo caso, i requisiti che dovranno essere
catturati riguardano principalmente vincoli di varianatura imposti sul sistema di data warehousing
16
I fatti
! I fatti sono i concetti su cui gli utenti finali del datamart baseranno il processo decisionale; ogni fattodescrive una categoria di eventi che si verificano inazienda$ Fissare le dimensioni di un fatto è importante poiché
significa determinarne la granularità, ovvero il più fine livellodi dettaglio a cui i dati saranno rappresentati. La scelta dellagranularità di un fatto nasce da un delicato compromesso tradue esigenze contrapposte: quella di raggiungere un’elevataflessibilità 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 dovrannocoprire
17
I fattiData mart Fatti
approvvigionamenti acquisti, inventario di magazzino, distribuzione
produzione confezionamento, inventario, consegna, manifattura
gestione domanda vendite, fatturazione, ordini, spedizioni, reclami
marketing promozioni, fidelizzazione, campagne pubblicitarie
bancario conti correnti, bonifici, prestiti ipotecari, mutui
investimenti acquisto titoli, transazioni di borsa
servizi carte di credito, domiciliazioni bo llette
scheda di ric overo ricoveri, dimissioni, interventi chirurgici, diagnosi
pronto soccorso accessi, esami, dimissioni
medicina di b ase scelte, revoche, prescrizioni
merci domanda, offerta, trasporti
passeggeri domanda, offerta, trasporti
manutenzione interventi
traffico traffico in rete, chiamate
CRM fidelizzazione, reclami, servizi
gestione domanda biglietteria, noleggi auto, soggiorni
CRM frequent-flyers, reclami
logistica trasporti, scorte, movimentazione
risorse umane assunzioni, dimissioni, promozioni, incentivi
budgeting budget commerciale, budget di marketing
infrastrutture acquisti, opere
commerciale/
manufatturiero
finanziario
sanitario
trasporti
telecomunicazioni
turismo
gestionale
18
Glossario dei requisiti
Fatto Possibili dimensioni Possibili misure Storicità
inventariodi magazzino
prodotto, data,magazzino
quantità in magazzino 1 anno
venditeprodotto, data,negozio
quantità venduta,importo, sconto
5 anni
linee d!ordineprodotto, data,fornitore
quantità ordinata,importo, sconto
3 anni
Progettazione concettuale
Versione identica alle dispense originali.
Alcuni concetti (eventi, aggregazione, …) sono già stati trattatinell’introduzione al modello multidimensionale; i relativi lucidi sonoqui ripetuti solo per completezza.
20
Quale formalismo?
! Mentre è universalmente riconosciuto che unDW si appoggia sul modellomultidimensionale, non c’è accordo sullametodologia di progetto concettuale.
! Il modello Entity/Relationship è molto diffusonelle imprese come formalismo per ladocumentazione dei sistemi informativirelazionali, ma non può essere usato permodellare il DW.
21
Il Dimensional Fact Model
! Il DFM è un modello concettuale grafico per data mart, pensatoper:$ supportare efficacemente il progetto concettuale;
$ creare un ambiente su cui formulare in modo intuitivo leinterrogazioni dell’utente;
$ permettere il dialogo tra progettista e utente finale per raffinare lespecifiche dei requisiti;
$ creare una piattaforma stabile da cui partire per il progetto logico(indipendentemente dal modello logico target);
$ restituire una documentazione a posteriori espressiva e nonambigua.
! La rappresentazione concettuale generata dal DFM consiste inun insieme di schemi di fatto. Gli elementi di base modellatidagli schemi di fatto sono i fatti, le misure, le dimensioni e legerarchie
22
Il DFM: costrutti di base
! Un fatto è un concetto di interesse per il processo decisionale;tipicamente modella un insieme di eventi che accadono nell’impresa(ad esempio: vendite, spedizioni, acquisti, ...). È essenziale che un fattoabbia aspetti dinamici, ovvero evolva nel tempo
! Una misura è una proprietà numerica di un fatto e ne descrive unaspetto quantitativo di interesse per l’analisi (ad esempio, ogni venditaè misurata dal suo incasso)
! Una dimensione è una proprietà con dominio finito di un fatto e nedescrive una coordinata di analisi (dimensioni tipiche per il fatto venditesono prodotto, negozio, data)
negoziodata
prodotto
VENDITA
quantità vendutaincassonum. clientiprezzo unitario
dimensione
misura
fatto
Un fatto esprime unaassociazionemolti-a-molti
tra le dimensioni
23
Il DFM: costrutti di base! Con il termine generale attributi dimensionali si intendono le dimensioni
e gli eventuali altri attributi, sempre a valori discreti, che le descrivono(per esempio, un prodotto è descritto dal suo tipo, dalla categoria cuiappartiene, dalla sua marca, dal reparto in cui è venduto)
! Una gerarchia è un albero direzionato i cui nodi sono attributidimensionali e i cui archi modellano associazioni molti-a-uno tra coppiedi attributi dimensionali. Essa racchiude una dimensione, posta allaradice dell’albero, e tutti gli attributi dimensionali che la descrivono
vacanza
giorno
stato
categoria
tipo
trimestre mese
negozio
città del negozio
regione
responsabile delle venditeannodistretto di vendita
data
gruppo di marketing
reparto
marca
città della marca
prodotto
settimana
VENDITA
quantità vendutaincassonum. clientiprezzo unitario
gerarchiaattributo
dimensionale
24
vacanzaresponsabile delle vendite
distretto di vendita
settimana
negozio
PRODOTTO
NEGOZIO DATA
qtàvenduta
incasso prezzounitario
num. clienti
data
prodottoMESE
mese
(1,n)
(1,1)
TRIMESTREtrimestre
(1,n)
(1,1)
ANNOanno
(1,n)
(1,1)
(1,n)
(1,1)
cittàCITTÀ
(1,n)
(1,1)
regioneREGIONE
(1,n)
(1,1)
statoSTATO
(1,n)
(1,1)
tipoTIPO
(1,n)
(1,1)
categoriaCATEGORIA
(1,n)
(1,1)
repartoREPARTO
MARCAmarca
(1,n)
(1,1)
CITTÀMARCA
cittàmarca
(1,n)
(1,1)
(0,n)
(0,n)
(0,n)vendita
RESP.VENDITE
(1,n)
(1,1)
DISTRETTOVENDITA
(1,n)
(1,1)
giorno
VACANZA
(1,n)
(1,1)
GIORNO
(1,n)
(1,1)
(1,n)
(1,1)
SETTIMANA
GRUPPOMARKETING
gruppomarketing
(1,n)
(1,1)
Il DFM: corrispondenza
con l’E/R
25
“Naming conventions”
! Tutti gli attributi dimensionali in ciascuno schema difatto devono avere nomi diversi
! Eventuali nomi uguali devono essere differenziatiqualificandoli con il nome di un attributo dimensionaleche li precede nella gerarchia$ Ad esempio, warehouse city è la città in cui si trova un
magazzino, mentre store city è la città in cui si trova unnegozio
! I nomi degli attributi non dovrebbero riferirsiesplicitamente al fatto a cui appartengono$ Ad esempio, si evitino shipped product e shipment date
! Attributi con lo stesso significato in schemi diversidevono avere lo stesso nome
26
Eventi e aggregazione
! Un evento primario è una particolare occorrenza di un fatto, individuatada una ennupla costituita da un valore per ciascuna dimensione. Aciascun evento primario è associato un valore per ciascuna misura
$ Con riferimento alle vendite, un possibile evento primario registra peresempio che, il 10/10/2001, nel negozio NonSoloPappa sono state vendute10 confezioni di detersivo Brillo per un incasso complessivo pari a 25 euro
! Dato un insieme di attributi dimensionali (pattern), ciascuna ennupla diloro valori individua un evento secondario che aggrega tutti gli eventiprimari corrispondenti. A ciascun evento secondario è associato unvalore per ciascuna misura, che riassume in sé tutti i valori della stessamisura negli eventi primari corrispondenti$ Pertanto, le gerarchie definiscono il modo in cui gli eventi primari possono
essere aggregati e selezionati significativamente per il processodecisionale; mentre la dimensione in cui una gerarchia ha radice nedefinisce la granularità più fine di aggregazione, agli altri attributidimensionali corrispondono granularità via via crescenti
27
Eventi e aggregazione
parte
data
negozio
mese
tipoparte
tipoparte
mese
cittànegozio
sparsità
operatori di
aggregazione
28
Il DFM: costrutti avanzati
! Un attributo descrittivocontiene informazioniaggiuntive su unattributo dimensionaledi una gerarchia, a cuiè connesso da unaassociazione -a-uno.Non viene usato perl’aggregazione poichéha valori continui e/opoiché deriva daun’associazione uno-a-uno
! Alcuni archi delloschema di fattopossono essereopzionali
vacanza
giorno
peso
dieta
stato
categoria
tipo
trimestre mese
negozio
città del negozio
regione
responsabile delle venditeannodistretto di vendita
data
gruppo di marketing
reparto
marca
città della marca
prodotto
settimana indirizzo
telefono
responsabile
capo reparto
VENDITA
quantità vendutaincassonum. clientiprezzo unitario (AVG)
attributo
descrittivo
arco opzionale
29
Il DFM: costrutti avanzati
vacanza
giorno
promozione
sconto
costo
data fine
data inizio
pubblicità
peso
dieta
stato
categoria
tipo
trimestre mese
negozio
città del negozio
regione
responsabile delle venditeannodistretto di vendita
data
gruppo di marketing
reparto
marca
città della marca
prodotto
settimana indirizzo
telefono
responsabile
capo reparto IVA
VENDITA
quantità vendutaincassonum. clientiprezzo unitario (AVG)
attributo
cross-dimensionale
dimensione
opzionale
non-additività
convergenza
30
Il DFM: costrutti avanzati
copertura di
arco opzionale
tipo prodottocodProd
codOrddata
data scadenzataglia
LINEA D'ORDINE
quantità
importo
P-E
cliente
31
Il DFM: costrutti avanzatigerarchia condivisa
ruolo
distretto del
numero chiamato
uso del num.
chiamato
distretto del
numero chiamante
anno
CHIAMATA
numerodata mesedurata
uso del num.
chiamante
ora
numero
chiamante
numero
chiamato
distrettoanno
CHIAMATA
numerodata mese
numero
telefonico durata
uso
orachiamante
chiamato
clienteordine
prodotto
anno
SPEDIZIONE
numero
data mese
costo
magazzino città regione stato
data dispedizione
32
Il DFM: costrutti avanzati
arco multiplo
autore anno
VENDITA
numerodata meselibro incasso
genere
categoria
fascia d'utenza
RICOVERO
reparto
costocodPaz
sesso
cognome
data
diagnosi
nome
città
anno nascita
categoria
fascia d'utenza
RICOVERO
reparto
costocodPaz
sesso
cognome
data
diagnosi
nome
città
anno nascita
gruppodi diagnosi
33
Additività! L’aggregazione richiede di definire un operatore adatto per
comporre i valori delle misure che caratterizzano gli eventiprimari in valori da abbinare a ciascun evento secondario
! Da questo punto di vista è possibile distinguere tre categorie dimisure:$ Misure di flusso: si riferiscono a un periodo, al cui termine vengono
valutate in modo cumulativo (il numero di prodotti venduti in ungiorno, l’incasso mensile, il numero di nati in un anno)
$ Misure di livello: vengono valutate in particolari istanti di tempo (ilnumero di prodotti in inventario, il numero di abitanti di una città)
$ Misure unitarie: vengono valutate in particolari istanti di tempo, masono espresse in termini relativi (il prezzo unitario di un prodotto, lapercentuale di sconto, il cambio di una valuta)
Gerarchie temporali Gerarchie non temporali
Misure di flusso SUM, AVG, MIN, MAX SUM, AVG, MIN, MAX
Misure di livello AVG, MIN, MAX SUM, AVG, MIN, MAX
Misure unitarie AVG, MIN, MAX AVG, MIN, MAX
34
Additività! Una misura è detta additiva su una dimensione se i
suoi valori possono essere aggregati lungo lacorrispondente gerarchia tramite l’operatore disomma, altrimenti è detta non-additiva. Una misuranon-additiva è non-aggregabile se nessun operatoredi aggregazione può essere usato su di essa
stato
INVENTARIO
livelloquantità ingresso
magazzino città
indirizzo
data
AVG, MIN
unità per pallet
prodotto
tipo
reparto
peso
confezionemarca
categoria
meseanno
35
Misure additiveanno 1999 2000
trim. I ’99 II ’99 III ’99 IV ’99 I ’00 II ’00III ’00IV ’00
categ oria tipo prodottoBrillo 100 90 95 90 80 70 90 85
Sbianco 20 30 20 10 25 30 35 20detersivo
Lucido 60 50 60 45 40 40 50 40Manipulite 15 20 25 30 15 15 20 10
puliziacasa
saponeScent 30 35 20 25 30 30 20 15
Latte F Slurp 90 90 85 75 60 80 85 60Latte U Slurp 60 80 85 60 70 70 75 65latticino
Yogurt Slurp 20 30 40 35 30 35 35 20Bevimi 20 10 25 30 35 30 20 10
alimentari
bibitaColissima 50 60 45 40 50 60 45 40
anno 1999 2000
trim. I’99 II’99 III’99 IV’99 I’00 II’00 III’00 IV’00
categoriapulizia casa 225 225 220 200 190 185 215 170alimentari 240 270 280 240 245 275 260 195
anno 1999 2000
categ oria tipodetersivo 670 605pulizia
casa sapone 200 155latticino 750 685
alimentaribibita 280 290anno 1999 2000
categoriapulizia casa 870 760alimentari 1030 975
36
Misure non-additive
anno 1999
trim. I’99 II’99 III’99 IV’99
categ oria tipo prodottoBrillo 2 2 2,2 2,5Sbianco 1,5 1,5 2 2,5detersivo
Lucido – 3 3 3Manipulite 1 1,2 1,5 1,5
puliziacasa
saponeScent 1,5 1,5 2 –
anno 1999
trim. I’99 II’99 III’99 IV’99
cat egoria tipodetersivo 1,75 2,17 2,40 2,67pulizia
casa sapone 1,25 1,35 1,75 1,50media: 1,50 1,76 2,08 2,09
anno 1999
trim. I’99 II’99 III’99 IV’99
categ oriapulizia casa 1,50 1,84 2,14 2,38
37
Schemi di fatto vuoti
! Uno schema di fatto si dice vuoto se non hamisure$ In questo caso, il fatto registra solo il verificarsi di
un eventoanno
semestre
FREQUENZAstudente
nazionalità
età
corso
facoltà
areaindirizzo
sesso
nome
professore
(COUNT)
38
Sovrapposizione di schemi
! Una query di drill-across mette in relazione misureappartenenti a fatti diversi
! La presenza di query di drill-across richiede didefinire quali misure e quali pattern di aggregazionepossano essere utilizzati quando si interrogano 2 opiù schemi di fatto. In uno schema sovrapposto:$ Le misure sono l’unione delle misure presenti nei vari
schemi
$ Le gerarchie includono solo gli attributi presenti in entrambele gerarchie
$ Il dominio di ogni attributo è l’intersezione del dominio deicorrispondenti attributi sugli schemi di origine
39
Sovrapposizione di schemi
stato
SPEDIZIONE
prodotto
quantità sped.costo sped.
categoria
tipo
trimestre
mesedestinazione città
indirizzo
anno
cliente
data
settimana
reparto
peso
confezione marca
dieta
capo reparto
contratto
termini
incentivo
magazzino
indirizzo
responsabile
modalità
indirizzoindennitàvettore
data ricezione
numero fattura
mese ord.
data ord.anno ord. ordine
stato
INVENTARIO
livelloquantità ingresso
magazzino città
indirizzo
data
AVG, MIN
unità per pallet
prodotto
tipo
reparto
peso
confezionemarca
categoria
meseanno
AVG, MIN
prodotto
categoria
tipo
reparto
peso
confezione marca
SPEDIZIONE
quantità sped.costo sped.livello inventarioquantità ingr. inventario
meseanno data
magazzino
indirizzo
INVENTARIO
40
Progettazione concettuale:
approcci! Basata sui requisiti
$ Il progettista deve essere in grado di enucleare, dalleinterviste condotte presso l’utente, un’indicazione precisacirca i fatti da rappresentare, le misure che li descrivono e legerarchie attraverso cui aggregarli utilmente. Il problema delcollegamento tra lo schema concettuale così determinato ele sorgenti operazionali viene affrontato in un secondotempo
! Basata sulle sorgenti$ È possibile definire lo schema concettuale in funzione della
struttura delle sorgenti, evitando il complesso compito distabilire il legame con esse a posteriori. Inoltre, è possibilederivare uno schema concettuale prototipale dagli schemioperazionali in modo pressoché automatico
41
Progettazione concettuale:
come! La progettazione concettuale viene effettuata a partire dalla
documentazione relativa al database riconciliato:$ Schemi E/R$ Schemi Relazionali$ Schemi XML$ ...................
! Passi di progettazione:! Definizione dei fatti" Per ogni fatto:
1. Costruzione di un albero degli attributi2. Editing dell’albero degli attributi3. Definizione delle dimensioni4. Definizione delle misure5. Creazione dello schema di fatto
42
L’esempio delle vendite
(da E/R)
TIPO
PRODOTTO
CATEGORIA
NEGOZIO
(1,1)(0,N)
(1,1) (1,N)
(1,1) (0,N) (1,1) (1,N)
(0,N)
data
quantità
prezzounitario
SCONTRINO(1,N)
tipo categoria
prodotto
responsabilevendite
num. scontrino
negozio città
di
di
in inpeso
dieta(0,1)
indirizzo
GRUPPOMARKETING
(1,1)
(1,N)
gruppomarketing
per
responsabile
REPARTO
(1,1)
(1,N)
reparto
per
capo reparto
telefono
REGIONE
(1,1)
(1,N)
regione
di
STATO
(1,1)
(1,N)
stato
di
MARCA
marca
(1,1)(1,N)
(1,1) (1,N)di
MAGAZZINO
(1,N)
(1,N)
damagazzino
num.distretto
(1,1) (1,N)in
(1,1)
(1,N)
di
indirizzo prodottain
dimensione
vendita
DISTRETTOVENDITA
CITTÀ
43
L’esempio delle vendite
(da schema logico)PRODOTTI (prodotto, peso, dimensione, dieta,
diMarca:MARCHE, diTipo:TIPI)
NEGOZI (negozio, indirizzo, telefono, respVendite,(numDistr, stato):DISTRETTI, inCittà:CITTÀ)
SCONTRINI (numScontrino, data, negozio:NEGOZI)
VENDITE (prodotto:PRODOTTI, numScontrino:SCONTRINI,quantità,prezzoUnitario)
MAGAZZINI (magazzino, indirizzo)
CITTÀ (città, regione:REGIONI)
REGIONI (regione, stato:STATI)
STATI (stato)
DISTRETTI (numDistr, stato:STATI)
PROD_IN_MAGAZZ (prodotto:PRODOTTI, magazzino:MAGAZZINI)
MARCHE (codMarca, prodottaIn:CITTÀ)
TIPI (tipo, gruppoMarketing:GRUPPIMARK,categoria:CATEGORIE)
GRUPPIMARK (gruppoMarketing, responsabile)
CATEGORIE (categoria, reparto:REPARTI)
REPARTI (reparto, capoReparto)
44
Definizione dei fatti
I fatti sono concetti di interesse primario per il processodecisionale; tipicamente, corrispondono a eventi che
accadono dinamicamente nel mondo aziendale
! Sullo schema E/R un fatto può corrispondere o a un’entità F o aun’associazione n-aria R tra le entità E1, E2..., En
! Sullo schema relazionale un fatto corrisponde a una relazione F
(1,1) (1,1)
E1 R
E3
E2
FE1 E2
E3
R1 R2
R3
(1,1)
reificazione
45
Definizione dei fatti
Le entità o relazioni che rappresentano archivifrequentemente modificati (come VENDITA) sono
buoni candidati per definire fatti; quelli cherappresentano archivi quasi-statici (come NEGOZIO
e CITTÀ) no
$ Nell’esempio delle vendite si sceglie come fattol’associazione VENDITA, corrispondente alla relazioneVENDITE.
! Ogni fatto identificato diviene la radice di un nuovoschema
PRODOTTO(1,1)(0,N)
quantità
prodotto
in
prezzounitario
SCONTRINO(1,N)
num. scontrino
in(1,1)
VENDITA
46
Costruzione dell’albero degli
attributi! L’albero degli attributi è un albero in cui:
$ ogni vertice corrisponde a un attributo - semplice ocomposto - dello schema sorgente;
$ la radice corrisponde all’identificatore (chiave primaria) di F;
$ per ogni vertice v, l’attributo corrispondente determinafunzionalmente tutti gli attributi corrispondenti ai discendentidi v
! L’albero degli attributi corrispondente a F può esserecostruito in modo automatico applicando unaprocedura che naviga ricorsivamente le dipendenzefunzionali espresse, nello schema sorgente, dagliidentificatori e dalle associazioni a-uno
47
Costruzione dell’albero degli
attributiroot=nuovoVertice(ident(F)); // ident(F) è l’identificatore di F
// la radice dell’albero è etichettata con l’identificatore dell’entitàscelta come fatto
traduci(F, root);
procedura traduci(E, v):
// E è l’entità corrente dello schema sorgente, v il vertice correntedell’albero
{ per ogni attributo a!E tale che a"ident(E)
aggiungiFiglio(v, nuovoVertice(a));
// aggiunge al vertice v un figlio a
per ogni entità G connessa a E da un’associazione R tale che max(E,R)=1{ per ogni attributo b!R
aggiungiFiglio(v, nuovoVertice(b));
// aggiunge al vertice v un figlio b
prossimo=nuovoVertice(ident(G));
// crea un nuovo vertice con il nome dell’identificatore di G ...
aggiungiFiglio(v, prossimo);
// ... lo aggiunge a v come figlio ...
traduci(G, prossimo);
// ... e innesca la ricorsione
}
}
48
TIPO
PRODOTTO
CATEGORIA
NEGOZIO
(1,1)(0,N)
(1,1) (1,N)
(1,1) (0,N) (1,1) (1,N)
(0,N)
data
quantità
prezzounitario
SCONTRINO(1,N)
tipo categoria
prodotto
responsabilevendite
num. scontrino
negozio città
di
di
in inpeso
dieta(0,1)
indirizzo
GRUPPOMARKETING
(1,1)
(1,N)
gruppomarketing
per
responsabile
REPARTO
(1,1)
(1,N)
reparto
per
capo reparto
telefono
REGIONE
(1,1)
(1,N)
regione
di
STATO
(1,1)
(1,N)
stato
di
MARCA
marca
(1,1)(1,N)
(1,1) (1,N)di
MAGAZZINO
(1,N)
(1,N)
damagazzino
num.distretto
(1,1) (1,N)in
(1,1)
(1,N)
di
indirizzo prodottain
dimensione
vendita
DISTRETTOVENDITA
CITTÀ
L’esempio delle vendite
49
L’esempio delle vendite
dimensione
stato
regione
prezzo unitario
quantità
data
negozio
resp. vendite
città stato
prodotto
marca
tipocategoria
indirizzo
dieta
città
pesoreparto
capo reparto
gruppo mark.responsabile
telefono
num. distretto+stato
regione
prodotto+num.scontrino
num.scontrino
num. distretto
50
Editing dell’albero
! In genere non tutti gli attributi dell’albero sonod’interesse per il data mart; quindi, l’albero puòessere manipolato per eliminare i livelli di dettaglionon necessari$ La potatura di un vertice v si effettua eliminando l’intero
sottoalbero con radice in v• Gli attributi eliminati non verranno inclusi nello schema di fatto,
quindi non potranno essere usati per aggregare i dati
$ L’innesto viene utilizzato quando, sebbene un verticeesprima un’informazione non interessante, è necessariomantenere nell’albero i suoi discendenti
• L’innesto del vertice v, con padre v', viene effettuato collegandotutti i figli di v direttamente a v' ed eliminando v; come risultatoverrà perduto il livello di aggregazione corrispondenteall’attributo v ma non i livelli corrispondenti ai suoi discendenti
51
b
c
a d
e
f
g
b
c
a
b
c
a
e
f
g
potatura di d
innesto di d
Editing dell’albero
! Quando un vertice opzionale viene innestato, tutti i suoi figliereditano il trattino di opzionalità$ Nel caso di potatura o innesto di un vertice opzionale v con padre v'
è possibile aggiungere a v' un nuovo figlio b corrispondente a unattributo booleano che esprima l’opzionalità
! Potare o innestare un figlio della radice che corrisponde, sulloschema sorgente, a un attributo incluso nell’identificatoredell’entità scelta come fatto significa rendere più grossolana lagranularità del fatto$ Se il vertice innestato ha più di un figlio, si può avere un aumento
del numero di dimensioni nello schema di fatto
52
dimensione
stato
regione
prezzo unitario
quantità
data
negozio
resp. vendite
città stato
prodotto
marca
tipocategoria
indirizzo
dieta
città
pesoreparto
capo reparto
gruppo mark.responsabile
telefono
num. distretto+stato
regione
prodotto+num.scontrino
num.scontrino
num. distretto
L’esempio delle vendite
53
L’esempio delle vendite
prezzo unitario
quantità
data
negozio
resp. vendite
città stato
prodotto
marca
tipocategoria
indirizzo
dieta
città
pesoreparto
capo reparto
gruppo mark.responsabile
telefono
num. distretto+stato
regione
prodotto+num.scontrino
54
Editing dell’albero! Nella pratica possono rendersi necessarie ulteriori
manipolazioni sull’albero degli attributi$ Può essere necessario modificarne radicalmente la struttura
sostituendo il padre di un certo nodo: ciò corrisponde adaggiungere o eliminare una dipendenza funzionale
$ In presenza di un’associazione uno-a-uno sono consigliabili duesoluzioni:
• quando il vertice v determinato dall’associazione uno-a-uno ha deidiscendenti di interesse lo si può eliminare dall’albero tramite innesto;
• quando v non ha discendenti di interesse lo si può rappresentare comeattributo descrittivo.
• in alcuni casi può convenire invertire i due nodi coinvolti
da b c da
b
c
elimina b!c
aggiungi b!c
codice
descrizione codice
descrizione descrizione
55
Definizione delle dimensioni
! Le dimensioni devono essere scelte nell’albero degliattributi tra i vertici figli della radice; possonocorrispondere ad attributi discreti o a intervalli divalori di attributi discreti o continui
! La loro scelta è cruciale per il progetto poichédefinisce la granularità degli eventi primari
! Il tempo dovrebbe sempre essere una dimensione:$ Se la sorgente è uno schema storico, il tempo è
rappresentato esplicitamente come un attributo; se apparenell’albero degli attributi come figlio di un vertice diversodalla radice, si può effettuare un innesto o eliminare unadipendenza funzionale al fine di farlo diventare un figliodiretto della radice e quindi una dimensione
$ Nelle sorgenti snapshot il tempo non viene rappresentatoesplicitamente; in questo caso il tempo viene tipicamenteaggiunto “manualmente” allo schema di fatto
56
L’esempio delle vendite
prezzo unitario
quantità
data
negozio
resp. vendite
città stato
prodotto
marca
tipocategoria
indirizzo
dieta
città
pesoreparto
capo reparto
gruppo mark.responsabile
telefono
num. distretto+stato
regione
prodotto+num.scontrino
57
Definizione delle misure
! Se tra le dimensioni compaiono tutti gli attributi checostituiscono un identificatore dell’entità fatto, allorale misure corrispondono ad attributi numerici chesiano figli della radice dell’albero
! In caso contrario le misure devono essere definiteapplicando, ad attributi numerici dell’albero, funzionidi aggregazione che operano su tutte le istanze di Fcorrispondenti a ciascun evento primario (in genere sitratta di somma/media/massimo/minimo diespressioni oppure del conteggio del numero diistanze di F)$ Un fatto può anche non avere misure$ Qualora la granularità del fatto sia differente da quella dello
schema sorgente, può essere utile definire più misure cheaggregano lo stesso attributo tramite operatori diversi
58
L’esempio delle vendite
prezzo unitario
quantità
data
negozio
resp. vendite
città stato
prodotto
marca
tipocategoria
indirizzo
dieta
città
pesoreparto
capo reparto
gruppo mark.responsabile
telefono
num. distretto+stato
regione
prodotto+num.scontrino
GLOSSARIO
quantità venduta = SUM(VENDITA.quantità)
incasso = SUM(VENDITA.quantità*VENDITA.prezzoUnitario)
prezzo unitario = AVG(VENDITA.prezzoUnitario)
num. clienti = COUNT(*)
59
Creazione dello schema di
fatto! L’albero degli attributi può ora essere tradotto in uno schema di
fatto che include le dimensioni e misure definite$ le gerarchie corrispondono ai sottoalberi dell’albero degli attributi
con radice nelle diverse dimensioni$ il nome del fatto corrisponde al nome dell’entità scelta come fatto$ È possibile potare e innestare l’albero per eliminare dettagli inutili$ È possibile aggiungere attributi dimensionali definendo opportuni
intervalli per attributi numerici (per es. sulla dimensione tempo)$ Gli attributi che non verranno usati per l’aggregazione possono
essere contrassegnati come descrittivi; tra questi compariranno ingenere anche gli attributi determinati da associazioni uno-a-uno eprivi di discendenti
$ Per quanto riguarda eventuali attributi alfanumerici figli della radicema non prescelti né come dimensioni né come misure:
• se la granularità degli eventi primari coincide con quella dell’entità F,essi possono essere rappresentati come attributi descrittivi associatidirettamente al fatto, di cui descriveranno ciascuna occorrenza
• se invece le due granularità sono differenti, essi devononecessariamente essere potati
60
L’esempio delle vendite
peso
dieta
stato
categoria
tipo
trimestre mese
negozio
città regione
responsabile delle venditeanno
distretto di vendita
data
gruppo di marketing
reparto
marcaprodotto
settimana indirizzo
telefono
responsabile
capo reparto
VENDITA
quantità vendutaincassonum. clientiprezzo unitario (AVG)
61
Creazione dello schema di
fatto! Eventuali attributi cross-dimensionali e archi multipli
possono essere evidenziati in questa fase$ Identificare queste tipologie di attributi a partire dallo schema
sorgente è complesso, poiché richiede di navigare anche leassociazioni a-molti, per cui si preferisce definirli a partiredai requisiti utente per rappresentarli solo successivamentesullo schema di fatto
• Un attributo cross-dimensionale corrisponde in genere a unattributo posto su un’associazione molti-a-molti R dello schemaE/R; i suoi padri nello schema di fatto corrisponderanno alloraagli identificatori delle entità coinvolte in R
• Un arco multiplo corrisponde a un’associazione a-molti R daun’entità E a un’entità G; nello schema di fatto, esso potràallora connettere l’identificatore di E o il fatto con un attributo diR o di G
62
Creazione dello schema di
fatto
IVA
(1,1) (0,N)di
stato
categoria
negozio
data
IVA
VENDITA
quantitàincasso
prodotto
NEGOZIO PRODOTTO
(0,N) (1,1)
negozio codVendita prodotto
effettua
quantitàdata
di
CATEGORIA
categoria
(1,1)
(1,N)
in
STATO
stato
(1,1)
(1,N)
VENDITA
incasso
(1,N) (1,N)vende
reparto
categoria
RICOVERO
costocodPaziente
data
diagnosi
(1,1) (0,N)diREPARTO PAZIENTE
(0,N) (1,1)
reparto codRicovero codPaziente
costodata
di
DIAGNOSI
diagnosi
(1,N)
(0,N)
RICOVEROin
(1,1) (1,N)di CATEGORIA
categoria
63
Creazione dello schema di
fatto! In questa fase devono anche essere identificate le
eventuali non-additività e non-aggregabilità presentinello schema, considerando tutte le accoppiatedimensione-misura
! Dato uno schema di fatto n-dimensionale, per ladimensione di e la misura mj, la domanda da porsisarà:
“Siano {val1..., valk} i valori assunti dalla misura mj nei keventi primari corrispondenti a k differenti valori presi daldominio della dimensione di e da un valore prefissato diciascuna delle altre n–1 dimensioni. Volendo caratterizzarecomplessivamente i k eventi con un unico valore di mj, qualioperatori di aggregazione ha senso utilizzare?”
64
Carico di lavoro e volume dati
! Informazioni utilizzate, sia nella progettazione logica sia nellaprogettazione fisica, per ottimizzare le prestazioni del sistema
! Carico di Lavoro : Informazioni sulle principali operazioni cheverranno effettuate sul sistema (il carico di lavoro di un sistemaOLAP è per sua natura estemporaneo)$ Reportistica standard$ Colloqui con gli utenti
! Volume Dati: informazioni necessarie a determinare/stimare ladimensione del data mart.$ Numero di valori distinti degli attributi nelle gerarchie$ Lunghezza degli attributi$ Numero di eventi di ogni fatto