Sistemi Informativi Aziendali Umberto Nanni Cos’è il Data ...unina.stidue.net/Sistemi Informativi/Altri Appunti/Business... · Sistemi Informativi Aziendali AA 2009-2010 Prof

Università “La Sapienza” di Roma

Sistemi Informativi AziendaliAA 2009-2010

Prof. Umberto Nanni

Introduzione al Data Warehousing per Sistemi Informativi Aziendali

2

Sistemi Informativi Aziendali Umberto Nanni

Università “La Sapienza” – Roma, Fac. Ingegneria

Cos’è il Data Warehousing

Collezione di metodi, tecnologie e strumenti

di ausilio al “lavoratore della conoscenza”

(manager, gestore, analista) per condurre

analisi dei dati finalizzate all’attuazione di

processi decisionali e/o a migliorare la

gestione del patrimonio informativo.

3



Cos’è un Data Warehouse

• Un Datawarehouse è una collezione di dati

• integrati (anche oltre l’orizzonte

dell’organizzazione)

• consistenti (nonostante l’origine eterogenea)

• focalizzati su un’area di interesse

• articolati su un orizzonte temporale significativo

• permanenti (non volatili, storicizzati)

4



Finalità del Data Warehouse

L’analisi dei dati in un Data Warehouse

consente di

• prendere decisioni

• individuare ed interpretare fenomeni

• fare previsioni sul futuro

• controllare un sistema complesso

5



Valore e quantitàdi informazione

valore

quantità

informazionestrategica

fontiinformative

primarie

rapporti

informazioniselezionate

BD

$$$$

concorrenti

marketing

prezzi

venditelogistica

6



Ruolo del DW nell’organizzazione

obiettivi risultati

sistemadirezionale

sistemaoperativo

sistemi ETL

datiesterni

sistemidi servizio

sistemiERP

internet /extranet

repo

rtis

tica

OLA

P

data

min

ing

Datawarehouse

Datamart-1 Datamart-2 Datamart-3

KPIKPI DSSDSS MKTMKT HRHRCRMCRM …

sistemadirezionale

sistema operativo

7



OLTP & OLAP

OLTP - On-Line Transaction Processing• transazioni, recovery, consistenza (scrittura e/o

lettura)• brevi, frequenti, elevato livello di concorrenza• intervento su piccole quantità di dati• dati accurati aggiornati all’istanteOLAP - On-Line Analitical Processing• operazioni di sola lettura• poche operazioni, basso livello di concorrenza• intervento su grandissime quantità di dati• dati articolati nel tempo ma essenzialmente

statici

8



Separazione tra DataBase operazionalee Data Warehouse

• carico computazionale completamente differente• accorgimenti differenti:

– DB: delicata sincronizzazione delle attività– DW: dati statici (aggiornamenti occasionali)

• integrazione con attività aziendale:– DB operazionale: integrazione– DW: descrizione, storicizzazione

• dati di interesse– DB: minimale– DW: massimale

9



Alcuni ambienti per il Data Warehouse

• Oracle 10g

• IBM DB2-UDB

• Microsoft SQL-Server

• Sybase IQ

• Microstrategy

• Teradata (NCR)

• Netezza – Cognos

• Business Objects (parte di SAP, Ottobre 2007)

10



Architettura per il Datawarehouse:aspetti in gioco

• separazione OLTP, OLAP

• scalabilità

• estendibilità

• sicurezza

• amministrabilità

11



Scelta architettura per il Datawarehouse

• determinata da scelte progettuali

• condizionata da / condiziona scelta del prodotto

• condiziona costo / rende possibile alternative ed integrazioni future (quantitative e/o qualitative)

• condiziona costo del trattamento dati

• condiziona effettiva PERMANENZA dati

12



Data Mart

Collezione di dati focalizzata su particolare profilo di utente o su particolare obiettivo di analisi

Alternative:

1.Data Mart dipendente: il DM è sottoinsieme e/o aggregazione di dati presenti nel DW primario

→ DM estratto da DW

2.Data Mart indipendente: il DM è sottoinsieme e/o aggregazione di dati presenti nel DB operazionale

→ DW=Ui(DMi), ossia il DM è parte del DW

3.soluzione ibrida, combinando le precedenti

13



Architettura DW: 1 Livello

• esiste solo il DB operazionale• DW virtuale (non rispetta separazione OLTP-OLAP)• dati coincidenti con DB operazionale• difficile integrazione con altre sorgenti

sorgentisorgenti warehousewarehouse analisianalisi

dati - livello 1dati - livello 1 middleware

(copia di) BDoperazionale

sorgentiesterne

14



Architettura DW: 2 Livelli – DM dipendenti

• fonti dati integrate con sorgenti esterne• esecuzione su piattaforma software dedicata• ETL: Extraction, Transformation, Loading• materializzazione del DW• realizzazione e materializzatione di Data Mart

operBD

extBD

sorgentisorgenti warehousewarehouse analisianalisialimentazionealimentazione

DW

DataMart

DataMart

ETL

dati - livello 1dati - livello 1 dati - livello 2dati - livello 2

15



Architettura DW: 2 Livelli – DM indipendenti

• vengono materializzati i soli Data Mart

• non esiste un DW primario materializzato

• DW = unione dei DM

operBD

extBD


DataMart

DataMart

ETL

dati - livello 1dati - livello 1 dati - livello 2dati - livello 2

16



Architettura DW: 3 Livelli

• viene introdotto il livello dei dati riconciliati (operationaldata store)

• separazione in due fasi delle attività ETL:1. estrazione/trasformazione2. caricamento

operBD

extBD


DWDataMart

DataMart

ET(L)

datiriconciliati

caricamento

dati - livello 1dati - livello 1 dati - livello 2dati - livello 2 dati - livello 3dati - livello 3

17



Metadati

• metadati interni• riguardano l’amministratore del DW (es.: sorgenti,

trasformazioni, schemi, utenti, etc.)• metadati esterni• di interesse degli utenti (es.: unità di misura, le possibili

aggregazioni)

• STANDARD• CWM - Common Warehouse Model (OMG), definito

mediante:– UML (Unified Modeling Language)– XML (eXtensible Markup Language)– XMI (XML Metadata Interchange)

18



ETL: Extraction, Transformation, Loading

• estrazione

• pulitura - validazione - filtraggio

• trasformazione

• caricamento

Dati Operazionali, Dati Esterni

Dati Riconciliati

Data Warehouse

19



Estrazione

• iniziale:– finalizzata alla creazione del DW

• successiva:– statica (integrale rispetto alle sorgenti)– incrementale

• log• timestamp

20



Pulitura

• intervento a livello di VALORI:• duplicati• inconsistenze

– violazione dominio– violazione dipendenze funzionali

• valori nulli• uso improprio campi• ortografia• abbreviazioni (non omogenee)

21



Trasformazione

• intervento a livello di FORMATI:

• disallineamento formati

• overloading campi

• codifiche non omogenee

22



Caricamento (Loading)

• Refresh:caricamento ex-novo dell’intero DW

• Update:modifiche intervenute

23



Modello multidimensionale

dato nel DB aziendale(rappresentazione dell’evento)

vendita diuno scopettone

fatto nel DW aziendale(misura

in uno spazion-dimensionale )

N vendite di articolo Xpresso il negozio Y

il giorno Z

vendita didetersivo per piatti

evento nella realtàU. Nanni, di anni 28,

acquistauno scopettone

Pippo, di anni 32,acquista

brillantante

Pluto, di anni 77,acquista

dentifricio

Paperino, di anni 16,acquista

lucido da scarpe

U. Nanni, di anni 28,acquista

detersivo per piattiprogetto DB

selezione dei soliaspetti di interesse

operativo

progetto DWaggregazione di

interesse analitico

24



Eventi e Fatti

• EVENTO (nella realtà) e FATTO (di interesse) sono termini il cui significato èdeterminato dalla granularità (livello di dettaglio) della rappresentazione multidimensionale del Data Warehouse

Esempio di FATTO:il giorno 02/05/2004 a Romasono stati venduti278 scopettonicon un incasso di 745 Euro

25



Cubo multidimensionale

05/0

5/20

04

scopettoniRoma

numero: 278totale: € 745

dentifricioscopettonidetersivi piatti

brillantanti

13/1

1/20

02

06/1

1/20

02

07/1

1/20

02

08/1

1/20

02

11/1

1/20

02

12/1

1/20

02

05/1

1/20

02

Foggia

Firenze

L’Aquila

Roma

Torino

Venezia

Palermo

26



Dimensioni

dentifricioscopettonidetersivi piatti

brillantanti

Foggia

Firenze

L’Aquila

Roma

Torino

Venezia

Palermo

13/1

1/20

02

06/1

1/20

02

07/1

1/20

02

08/1

1/20

02

11/1

1/20

02

12/1

1/20

02

05/1

1/20

02

← tempo →

←luogo

→←

mer

ce →

27



dimensioni(o attributi di classificazione)

misure(o variabili, o metriche, o indicatori, …)

Schema relazionale per il cubo multidimensionale

TABELLA(dimens-1, …, dimens-k, misura-1, …, misura-h)

Esempio:VENDITE(prodotto, città, data, numVendite, incasso)

CHIAVE IDENTIFICATIVA

Dipendenza Funzionale: dimensioni → misure

Nell’esempio: prodotto, città, data → numVendite, incasso

28



Gerarchia dimensionale

Ad ogni dimensione viene associata una gerarchia che ne raggruppa i valori a diverso livello di aggregazione (anche in modo ortogonale). Ciascun nodo della gerarchia è detto

ATTRIBUTO (DIMENSIONALE)

Esempio di gerarchia (dimensione temporale):giorno

settimanamese

quadrimestre trimestre

anno

Valgono le DIPENDENZE FUNZIONALI:giorno → settimanagiorno → mesemese → trimestremese → quadrimestretrimestre → annoquadrimestre → anno

ALL

29



Accesso al Data Warehouse

Reportistica• esigenze predefinite (ev., parametrizzate)• estrazione automatica di informazioniOLAP• esigenze di analisi non identificabili a priori• esplorazione interattiva dei dati, alla ricerca di

informazioni di interesseData Mining• esigenze di analisi non identificabili a priori• esplorazione (semi) automatica dei dati

30



Reportistica

Rapporti/Report di struttura e forma predefinita• interrogazione

– tipicamente basata su restrizioni e/o aggregazioni• presentazione

– intercalata con testo– dati in forma tabellare e/o grafica– personalizzata con variabili d’ambiente (data, utente, …)

• generazione– richiesta esplicita dell’utente– periodica– in base a condizioni predefinite

• distribuzione– preview/stampa, e-mail, web, …

31



OLAP

• modalità di attuazione:

– costruzione di una sessione di analisi,

articolata in una serie di passi, ciascuno

dipendente dai risultati ottenuti in

precedenza

• utenti tipici:

– esperti del dominio, non necessariamente

esperti informatici

32



OLAP: cubo di esempio

scopettonidetersivi piatti

brillantanti

Firenze

L’Aquila

Roma

Torino

Palermo

06/1

1/20

02

07/1

1/20

02

08/1

1/20

02

11/1

1/20

02

12/1

1/20

02

05/1

1/20

02

33



OLAP – Operazioni basenel modello multidimensionale

RESTRIZIONE (limitazione puramente quantitativa)• selezione su specifici valori di attributi dimensionali• nel caso si imponga l’uguaglianza con un singolo valore,

l’operatore prende il nome di SLICING (scompare una dimensione)

AGGREGAZIONE (aumento del livello di astrazione)• considerata 1 dimensione, raggruppare un attributo

dimensionale ad un livello di maggiore granularità• se, al limite, si aggrega al massimo livello (il più

generico, costituito da un singolo valore), scompare una dimensione

34



OLAP: Operatore Roll-Up

Aggregazione lungo una dimensione→ uso di un operatore aggregativo su valori di misura

Esempi:a. vendite di ciascun prodotto per città e per meseb. vendite giornaliere per città (totale su tutti i prodotti)c. vendite giornaliere per prodotto (Nord/Centro/Sud)

← giorno →

←città

→

←

prod

otto

→ ← mese →

←città

→

←

prod

otto

→

(a)(a)

35



OLAP: Operatori di aggregazione

DISTRIBUTIVI: calcolabili a partire da:1. aggregati parziali

– Esempi: SUM, MAX, MIN, …

ALGEBRICI: calcolabili a partire da:1. aggregati parziali

2. insieme finito di misure di supporto

– Esempi: AVG, deviazione standard, …

OLISTICI: calcolabili a partire da:1. dati originari

– Esempio: rango di una matrice

36



OLAP: Operatore Drill-Down

Disaggregazione lungo una dimensione→ comporta la disponibilità dei dati disaggregati

Esempi:a. passare dalle vendite di ciascun prodotto per città e per

mese alle vendite giornaliereb. passare dalle vendite mensili per città (totale su tutti i

prodotti) alle vendite giornaliere per città e per prodotto← giorno →

←città

→

←

prod

otto

→← mese →

←città

→

←

prod

otto

→

(a)(a)

37



OLAP: Cuboidi (dimensioni)

• dato un cubo di dati, è possibile effettuare diverse operazioni di roll-up che conducono alla scomparsa di una dimensione

• dato un cubo con k dimensioni, esistono 2k

possibili cuboidi

prodotto, data, città

tutti

prodotto data città

prodotto, data prodotto, città data, cittàdrill-down

roll-up

38



OLAP: Cuboidi (livelli aggregazione)

• dato un cubo di dati, è possibile effettuare diverse operazioni di roll-up che aumentano il livello di aggregazione (con o senza la scomparsa di una dimensione)

• dato un cubo con k dimensioni di n1, n2, …, nk livelli di aggregazione, esistono n1×n2 ×…×nk possibili cuboidi

articolo,giorno

{}

articolomarca,mese

giorno

articolo,mese marca,giorno

marca mese

drill-down

roll-up

39



scopettonidetersivi piatti

brillantanti

OLAP: Operatori Slice-and-Dice

Selezione (o, al limite, slicing)Esempi:passare dalle vendite mensili dei prodotti per città

a. alle vendite mensili dei prodotti per le sole città del centrob. alle vendite mensili per città di detersivi per piatti

detersivi piatti

Firenze

L’Aquila

Roma

Torino

Palermo

Set

t-02

Ott-

02

Ago

-02

(b)(b)

detersivi piatti

Firenze

L’Aquila

Roma

Torino

Palermo

Set

t-02

Ott-

02

Ago

-02

40



OLAP: Operatori di Pivoting

Rotazione delle dimensioni su una tabella bidimensionaleEsempio

passare da:passare da: vendite di (prodotti per mese) vendite di (prodotti per mese) perper (citt(cittàà))

a:a: vendite di (prodotti per cittvendite di (prodotti per cittàà) ) perper (mese)(mese)

RM FI AQ TO PAbrillantanti ago-02 34 23 12 56 65

set-02 56 45 23 44 67ott-02 76 34 34 55 45

detersivi piatti ago-02 57 46 35 79 88set-02 79 68 46 67 90ott-02 99 57 57 78 68

scopettoni ago-02 46 35 24 68 77set-02 68 57 35 56 79ott-02 88 46 46 67 57

ago-02 set-02 ott-02brillantanti RM 34 56 76

FI 23 45 34AQ 12 23 34TO 56 44 55PA 65 67 45

detersivi piatti RM 57 79 99FI 46 68 57AQ 35 46 57TO 79 67 78PA 88 90 68

scopettoni RM 46 68 88FI 35 57 46AQ 24 35 46TO 68 56 67PA 77 79 57

dueoperazioni

dueoperazioni

41



OLAP: Operatore Drill-Through

• accesso ai dati ad un livello di

aggregazione più basso di quello offerto

dal Data Warehouse

• accesso ai dati riconciliati (architettura a

tre livelli) o al DB operazionale

• costituisce un caso estremo di Drill-Down

42



OLAP: Operatori Drill-Across

• Correlare i dati provenienti da due o più cubi in base ai valori dimensionali, calcolando un’espressione in un nuovo cubo

Esempio:A partire da• vendite per prodotto, data, città• dipendenti per cittàcalcolare:• vendite medie per prodotto per dipendente

43



Data Mining

• nasce prima del Data Warehouse

• collezione di tecniche derivanti da Intelligenza Artificiale, Pattern Recognition, e tecniche statistiche di vario tipo (es.: algoritmi genetici, logiche fuzzy, sistemi esperti, reti neurali, etc.)

• obiettivi:– descrittivi: individuare schemi di comportamento,

rapporti di causa-effetto, classificare individui, etc.

– predittivi: predire andamenti, classificare individui in base al rischio, etc.

44



Alcune applicazioni del Data Mining

• Analisi dei dati e Supporto alle Decisioni• Analisi di mercato e marketing

– Target Marketing, Customer RelationshipManagement (CRM), Market Basket Analysis (MBA), segmentazione del mercato

• Analisi e gestione del rischio– previsioni di affidabilità, fidelizzazione di utenti,

controllo di qualità, …– individuazione di frodi e di pattern inusuali (outliers)

• Text Mining• Web Mining, ClickStream Analysis• Ingegneria genetica: ricerca sequenze in DNA

45



Data Mining: regole associative

SE “viene acquistato il prodotto birra” (X), ALLORA “viene acquistato anche il prodotto pannolino” (Y)

X → YSupporto (quale frazione di soggetti verifica la regola):

s = |X ∩ Y||all|

Confidenza (quale frazione di soggetti soddisfa la regola tra quelli in cui è applicabile):

c = |X ∩ Y||X|

Campi di applicazione: economico (market basket analysis), telecomunicazioni, medico, …

s(X→Y) = F(X∧∧∧∧Y)

c(X→Y) = F( Y | X )

46



Data Mining: clustering

• individuazione di similarità, cogliendo disomogeneità nella distribuzione per definire gruppi omogenei (apprendimento senza supervisione)

• ricerca gruppi (cluster) basata su– distribuzione della popolazione– una funzione di “distanza”

Esempio: ILM - Intervallo Libero da Malattia (a 5 anni)(collaborazione con Ist. Regina Elena di Roma)

47



Data Mining: alberi di decisione

determinare le cause di un fenomeno di interesse in ordine di importanza

– nodo interno: test di un attributo– diramazione: valore (o intervallo) di un attributo– foglia: assegna una classificazione (decisione finale)

studente ? credito ?si

età ?

<=30 30..40 >40

no si no si

sino altobasso

Esempio:il cliente acquisterà un computer ?

48



flat rate

con scatto alla rispostaTariffe:

Data Mining: serie temporali

• individuazione pattern ricorrenti / atipiciin sequenze temporali

• predizione caratteristiche

durata

cost

o

Esempio (Least Cost Routing): instradamento traffico telefonico su operatore a costo minimo(collaborazione con Between – azienda di consulenza)DOMANDA CHIAVE:data una telefonata in uscita da un numero interno X diretta verso un numero esterno Y, quanto durerà la telefonata ?

49



Data Mining: risultati “interessanti”

• Semplicità - Ad esempio:– lunghezza delle regole (associative)– taglia (albero di decisione)

• Certezza - Ad esempio:– confidenza (regole associative): c(X → Y) = #(X and Y) / #(X)– affidabilità della classificazione

• Utilità - Ad esempio:– supporto (regole associative): s(X → Y) = #(X and Y) / #(ALL)

• Novità - Ad esempio:– non nota in precedenza– sorprendente– sussunzione di altre regole (incluse come casi particolari)

esatto

errore

val.predetto

val.e

ffetti

vo

matrice di confusione

50



Progetto di Data Warehouse

• Definizione di obiettivi e pianificazione– fattibilità (confini, dimensione, sorgenti, …)– team– piano operativo

• Progetto dell’infrastruttura– alternative architetturali– alternative tecnologiche

• Progetto e sviluppo dei Data Mart– analisi con esperti del dominio

51



Ciclo di vita (Kimball, 1998)

pianificazione

definizione requisiti

manutenzione

realizzazione

gest

ione

pro

getto

tecn

olog

ia

appl

icaz

ioni

dati

modellazionedimensionale

progettofisico

progetto esviluppo

alimentazione

specificaapplicazioni

sviluppoapplicazioni

progettoarchitettura

selezione einstallazione

prodotti

52



Flussi dati & Evoluzione progettuale

DW

Flussodati

Logica diprogettazione

53



Fasi di progetto di un Data Mart

1. Analisi e riconciliazione delle fonti datischemi delle sorgenti → schema riconciliato

2. Analisi dei requisitischema riconciliato → fatti, carico lavoro

3. Progetto Concettualeschema riconciliato, fatti, carico lavoro → schemi di fatto

4. Progetto Logicoschemi di fatto, carico lavoro → schema logico Data Mart

5. Progetto dell’Alimentazioneschemi delle sorgenti, schema riconciliato, schema logico Data Mart→ procedure alimentazione

6. Progetto Fisicoschema logico Data Mart, carico lavoro, DBMS → schema fisico DM

entità-relazione

schemi di fatto

star-schema, snowflakes

54



Riconciliazione delle fonti dati

Integrazione di schemi:

• a un passo

• a scala

• bilanciato

• iterativo

55



Fatti – il punto della situazione

FATTO: categoria di eventi che si verificano nella realtà di interesse dell’organizzazione.

Per ciascun fatto:– dimensioni: coordinate di analisi/classificazione– misure: proprietà di un fatto, aspetti quantitativi

• gerarchia dimensionale: per ciascuna dimensione• granularità di informazione: compromesso(*) tra

quantità di informazione ed efficienza

(*) Per compiti specifici esistono, in ogni caso:– il DB operazionale / riconciliato– il drill-through

56



Progetto Concettuale

• Il modello ER non sembra adeguato (anche se resta un fondamentale supporto nella fase di progetto logico)

• Non esiste un consenso unanime sul modello da adottare

• Diverse proposte in letteratura:– Multidimensional Entity-Relationship Model– DFM - Dimensional Fact Model– ……

57



Schema ER del DB operazionale

VOCE_Vcontiene

posizione

(1,n) (1,1)

ARTICOLO

riferita

(0,n)

NEGOZIO

articolo

incasso

FATTURA_Vimportonumero

quantita

(1,1)

DATA

emessa

(1,1)

(1,n)

CITTA

situato

(0,n)

presso

(1,1)

p_iva

(0,n)

(1,1)

citta

data

negozio

codice

58



Schema logico del DB operazionale

VOCE_Vcontiene

posizione

(1,n) (1,1)

ARTICOLO

riferita

(0,n)

NEGOZIO

articolo

incasso

FATTURA_Vimportonumero

quantita

(1,1)

DATA

emessa

(1,1)

(1,n)

CITTA

situato

(0,n)

presso

(1,1)

p_iva

(0,n)

(1,1)

citta

data

negozio

codice

59



Schema logico DB operazionale - revisione

VENDITA

voce_vendita

ARTICOLO

riferita

(0,n)

NEGOZIO

articolo

incasso

quantita

(1,1)

DATA

emessa

(1,1)

(1,n)

CITTA

situato

(0,n)

presso

(1,1)

(0,n)

(1,1)

citta

data

negozio

ACCORPAMENTO: si ipotizza che non interessi il raggruppamento delle vendite in fatture (ossia la Market Basket Analysis) e pertanto collassano le entità FATTURA e VOCE

denormalizzazione

ELIMINAZIONE DI ATTRIBUTI:vengono tolti dallo schema gli attributi che non interessano

60



Schema di fatto (preliminare)

VENDITA

quantitàincasso

data(TEMPO)

negozio(SPAZIO)

articolo(MERCE)

FATTO

DIMENSIONI

MISURE

61



dettagli suspecifiche di utente

Gerarchie dimensionali

data

settimanamese

trimestre

anno gerarchiaTEMPO

articolocittà_marcamarca

sottogeneregenere

gerarchiaMERCE

gerarchiaSPAZIO

cittanegozio

responsabile

distretto

regionezona

62



Schema di fattoDFM (Dimensional Fact Model)

settimanamese

trimestre

anno

città_marcamarca

sottogeneregenere

VENDITA

quantitàincasso

data

articolonegozio

città

responsabile

distretto

regionezona

63



Schema di Fatto (esempio)

settimanamese

trimestre

anno

VENDITA

quantitàincasso

data

articolonegozio

città

responsabile

distretto

regionezona

città_marcamarca

sottogenere genere

ALL

ALL

ALL

Es: vendite mensiliper città e per marca

64



(1,1)

(1,1)

Schema ER

VENDITA

ARTICOLO

riferita

(0,n)

NEGOZIO

articolo

incasso

quantita

(1,1)

appartiene

(1,1)

(1,1)

CITTA situato(0,n)

presso(1,1)(0,n) (1,1)

citta negozio

(1,1) (1,1)DATA

emessa

(1,n)data

MESE

mese(1,1)(1,n)

TRIMESTRE

trimestre

(1,n)ANNO

anno

(1,n)

(1,n)REGIONE

regione

(1,1)

(1,n)ZONA zona

RESPONSABILE(0,n)

(1,1)

responsabile

DISTRETTO

(0,n)(1,1)

distretto

(0,n)GENERE

genere

SOTTOGENERE

sottogenere

(1,1) (0,n)

(1,1)(0,n)CITTA_MARCA

citta_marca

MARCA

marca

(1,1) (0,n)

(1,n)SETTIMANA

settimana

65



Gerarchie condivise e ruoli

settimana

anno

trimestre

mese

città_marcamarca

sottogeneregenere

VENDITA

quantitàincasso

data

articolonegozio

città

responsabile

distretto

regionezona

città_negozio

può essere interessante valutare la distribuzione territoriale dei marchi di successo

66



Archi multipli (relazioni n:n)

settimana

anno

trimestre

mese

città_marca

marca

sottogeneregenere

VENDITA

quantitàincasso

data

articolonegozio

città

responsabile

distretto

regionezona

città_negozio

un negozio può avere (avuto) più responsabili

67



Attributi cross-dimensionali

settimana

anno

trimestre

mese

città_marca

marca

sottogeneregenere

VENDITA

quantitàincasso

data

articolo

negozio

città

responsabile

distretto

regionezona

città_negoziopuò esistere una percentuale di provvigione può dipendere dalla marca e dal negozio

perc_provvigione

68



(1,1)

(1,1)

Schema ER (rivisto)

VOCE_V

ARTICOLO

riferita

(0,n)

NEGOZIO

articolo

incasso

quantita

(1,1)

appartiene

(1,1)

(1,1)

CITTA situato(0,n)

presso(1,1)(0,n) (1,1)

citta negozio

(1,1) (1,1)DATA

emessa

(1,n)data

MESE

mese(1,1)(1,n)

TRIMESTRE

trimestre

(1,n)ANNO

anno

(1,n)SETTIMANA

settimana

(1,1)

(1,n)

(1,n)REGIONE

regione

(1,1)

(1,n)ZONA zona

RESPONSABILE(0,n)

(1,n)

responsabile

DISTRETTO(0,n)

(0,n)distretto

(0,n)GENERE

genere

SOTTOGENERE

sottogenere

(1,1) (0,n)

(1,1)

(0,n)

MARCA

marca

ha_sede(1,1) (0,n)

PROVVIGIONE

percent

(1,1)(0,n)

(1,1)

69



Manipolazione delle gerarchie

cittànegozio

responsabile

distretto

regionezona

cittanegozio

responsabile

distretto

zona

innesto

città negozio

responsabile

distretto

potatura

70



Alternative di rappresentazione per DW: *OLAP

ROLAP - Relational On-Line Analitical Processingdati su DBMS relazionaleaccesso indicizzato

MOLAP - Multidimensional On-Line AnaliticalProcessingdati su strutture multidimensionaliaccesso calcolato

HOLAP - Hybrid On-Line Analitical Processingdati su strutture di entrambe le tipologieintrodotta da Oracle (Express Server, 2002)

71



• soluzioni dedicate• componente modulare

Architettura ROLAP

DW(DB relazionale)

R-DBMS(+)

metadati

middleware

OLAPclientSQL

(+)

72



Modello Logico MOLAP

• mancanza di uno standard affermato sia per le strutture dati che per i linguaggi di accesso

• gestione della “sparsità” dei dati (frazione popolata del cubo multidimensionale)– elementi significativi individuati in base ad offset

(collezione degli indici degli elementi non nulli)

– partizionamento in cubi più piccoli a densità quasi uniforme (densi o molto sparsi)

– strutture dati ad hoc (es.: kd-trees)

73



Modello logico (ROLAP): STAR-SCHEMA

• una DIMENSION TABLE per ciascuna dimensione:– chiave primaria (solitamente una chiave surrogata)– un insieme di attributi che descrivono i valori per tutti i

livelli di aggregazione

• una singola FACT TABLE:– chiave primaria: una foreign-key per ciascuna delle

dimension tables– un attributo per ciascuna misura

• Completa DENORMALIZZAZIONE (a parte la fact table)

74



Esempio di STAR-SCHEMA

articolosottogeneregeneremarcacittà_marcaregionezona

ID_ARTICOLO

articolo

quantitàincasso

ID_ARTICOLOID_DATAID_ NEGOZIO

vendite

negoziodistrettoresponsabilecittàregionezona

ID_NEGOZIO

negozio

datasettimanamesetrimestreanno

ID_DATAdatafact table

dimension tables

75



Modello logico (ROLAP): SNOWFLAKE

• A partire dallo STAR-SCHEMA, si opera una NORMALIZZAZIONE (parziale) delle dimensiontables, ottenendo:

• per ciascuna dimensione, la singola dimensiontable primaria nello Star-Schema può essere decomposta dando luogo ad una collezione di dimension table secondarie

• una singola fact table:– chiave primaria: una foreign-key per ciascuna delle

dimensioni (e per ciascuna dimension table primaria)– un attributo per ciascuna misura

76



Esempio di schema SNOWFLAKE

quantitàincasso

ID_ARTICOLOID_DATAID_NEGOZIO

venditedatasettimanamesetrimestreanno

ID_DATAdata

cittàregionezona

ID_CITTA

città

articolosottogeneregenere

ID_ARTICOLO

articolo

ID_MARCA

negoziodistrettoresponsabile

ID_NEGOZIO

negozio

ID_CITTA

marca

ID_MARCA

marchi

ID_CITTA

dimension table secondarie

dimension table primarie

77



Progetto Fisico e VISTE

• Il principale problema operativo in un Data Warehouse èquello delle prestazioni

• Per contro, la ridondanza non costituisce un grave problema, a causa della essenziale staticità del DW

• Per conseguire migliori prestazioni, si opera una parziale materializzazione delle viste sulla Fact Table

• La contropartite legate alla materializzazione di viste sono:

– spazio aggiuntivo (dati completamente ridondanti)

– tempo di calcolo al momento del refresh del DW

78



Reticolo delle Viste

VENDITE

quantitàincassoprezzo_unit

articologiorno

mesemarca

articolo,giorno

{}

articolomarca,mese

giorno

articolo,mesemarca,giorno

marca mese

79



viste materializzate (una ipotesi)

viste candidate

Ottimizzazione del calcolo basata sulle viste materializzate

VENDITE

quantitàincassoprezzo_unit

articologiorno

mesemarca

FATTORI DI COSTO:• tempo di calcolo• spazio• tempo di refresh

query ricorrenti

data warehouse

articolo,giorno

{}

articolomarca,mese

giorno

articolo,mesemarca,giorno

marca mese

80



Bibliografia

M. Golfarelli, S. Rizzi.Data WarehouseTeoria e Pratica della Progettazione (2a ed.)

McGraw-Hill, 2006.

Documents

Sistemi Informativi Aziendali Umberto Nanni Cos’è il Data ...unina.stidue.net/Sistemi Informativi/Altri Appunti/Business... · Sistemi Informativi Aziendali AA 2009-2010 Prof