Progettazione del Approccio top-down - UniNa STiDuEunina.stidue.net/Basi di Dati...

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


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


vacanza

giorno

promozione

sconto

costo

data fine

data inizio

pubblicità

peso

dieta

stato

categoria

tipo

trimestre mese

negozio

città del negozio

regione


data

gruppo di marketing

reparto

marca

città della marca

prodotto

settimana indirizzo

telefono

responsabile

capo reparto IVA

VENDITA


attributo

cross-dimensionale

dimensione

opzionale

non-additività

convergenza

30


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


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


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


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


(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À


49


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


telefono


regione


num.scontrino

num. distretto


53


prezzo unitario

quantità

data

negozio

resp. vendite

città stato

prodotto

marca

tipocategoria

indirizzo

dieta

città

pesoreparto

capo reparto


telefono


regione


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


prezzo unitario

quantità

data

negozio

resp. vendite

città stato

prodotto

marca

tipocategoria

indirizzo

dieta

città

pesoreparto

capo reparto


telefono


regione


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


prezzo unitario

quantità

data

negozio

resp. vendite

città stato

prodotto

marca

tipocategoria

indirizzo

dieta

città

pesoreparto

capo reparto


telefono


regione


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


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


61


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


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


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

Progettazione del Approccio top-down - UniNa STiDuEunina.stidue.net/Basi di Dati...

Documents

Transcript of Progettazione del Approccio top-down - UniNa STiDuEunina.stidue.net/Basi di Dati...