INTRODUZIONE AL DATA WAREHOUSING

IL PROBLEMA
In genere: genere: abbondanza di dati DB4 DB1 DB2

DB3

ma anche abbondanza di ridondanza ed inconsistenza che non permette di utilizzare i dati in modo utile a fini decisionali
2

TIPICHE RICHIESTE A CUI SPESSO DIFFICILE DARE UNA RISPOSTA

Qual il volume delle vendite per regione e categorie di prodotto durante lultimo anno? Come si correlano i prezzi delle azioni delle societ produttrici di hardware con i profitti trimestrali degli ultimi 10 anni? Quali sono stati i volumi di vendita dello scorso anno per regione e categoria di prodotto? In che modo i dividendi di aziende di hardware sono correlatiai porfitti trimestrali negli ultimi 10 anni? Quali ordini dovremmo soddisfare per massimizzare le entrate?

Possibili applicazioni
telecomunicazioni contesti banking universit gestione dei rischi assicurazioni analisi finanziaria programmi di marketing beni di consumo salute analisi statistica produzione integrazione DB clienti integrazione relazioni clienti problematiche analisi temporale
4

SISTEMI INFORMATICI: UNA CLASSIFICAZIONE

Tr

s cti

r c ssi g syst
r tivi

s:

r i r c ssi

D cisi

rt syst

s:

f rt t i t gr ti, i s rt i r c ssi ir zi li Ric i r zi i r vist ri ri i v lg s ss gr iq tit i ti, c st rici i v lg ti r v i ti v ri f ti r tiv , c

ggr g ti st r

IN SINTESI ...

sistemi di supporto alle decisioni (DSS)

dati

conoscenza utile allazienda

DSS: Tecnologia che supporta la dirigenza aziendale nel prendere decisioni tattico-strategiche in modo migliore e pi veloce
6

Perch i sistemi tradizionali non sono sufficienti?

no dati storici sistemi eterogenei basse prestazioni DBMS non adeguati al supporto decisionale problemi di sicurezza

PI FORMALMENTE ...

Sistemi tradizionali
On-Line

Transaction Processing (OLTP)

Sistemi di data warehousing

On-Line

Analytical Processing (OLAP)

Profondamente diversi

IN DETTAGLIO ...
OLTP
funzione progettazione frequenza dati sorgente uso accesso flessibilit accesso # record acceduti tipo utenti # utenti tipo DB performance dimensione DB gestione giornaliera orientata alle applicazioni gironaliera recenti, dettagliati

OLAP
supporto alle decisioni orientata al soggetto

sporadica storici, riassuntivi, multidimensionali singola DB DB multiple ripetitivo ad hoc read/write read uso di programmi generatori di query precompilati decine migliaia operatori manager migliaia centinaia singola multiple, eterogenee alta bassa 100 MB - GB 100 GB - TB

EVOLUZIONE DEI DSS

Anni 60: rapporti batch

difficile trovare ed analizzare i dati costo, ogni richiesta richiede un nuovo programma non integrato con strumenti di automazione dufficio strumenti di interrogazione, fogli elettronici, interfacce grafiche accesso ai dati operazionali

Anni 70: SS basato su terminale

Anni 80: strumento dautomazione dufficio

Anni 90: data warehousing, con strumenti integrati OLAP

10

SISTEMI DI DATA WAREHOUSING

Il ata Warehousing si pu definire come il processo di integrazione di basi di dati indipendenti in un singolo repository (il data warehouse) dal uale gli utenti finali possano facilmente ed efficientemente eseguire uery, generare report ed effettuare analisi

11

I SISTEMI DI DATA WAREHOUSING

Client Query & Analysis Client

Metadata

Warehouse

Integration

Source

Source

Source

12

IL DATA WAREHOUSE
Coll zione i ti c e soddisf le seg enti roprieta`: usata per il supporto alle decisioni orientata ai soggetti integrata: livello aziendale e non diparti entale correlata alla variabile tempo: ampio orizzonte temporale con dati tipicamente aggregati: per effettuare stime fuori linea: dati aggiornati periodicamente

13

IL DATA WAREHOUSE

Orientata ai soggetti: considera i dati di interesse ai soggetti dellorganizzazione e non uelli rilevanti ai processi organizzativi
basi data

di dati operazionali dipartimentali:

produzione, marketing

vendita,

warehouse: prodotti, clienti, fornitori

14

IL DATA WAREHOUSE
Integrata: i dati provengono da tutte le sorgenti informative il data warehouse rappresenta i dati in modo univoco, riconciliando le eterogeneita` delle diverse rappresentazioni:

nomi struttura codifica rappresentazione multipla

15

IL DATA WAREHOUSE
Correlata alla variabile tempo: presenza di dati storici per eseguire confronti, previsioni e per individuare tendenze Le basi di dati operazionali mantengono il valore corrente delle informazioni Lorizzonte temporale di interesse dellordine dei pochi mesi Nel data warehouse di interesse levoluzione storica delle informazioni Lorizzonte temporale di interesse dellordine degli anni

16

IL DATA WAREHOUSE

Dati aggregati: nellattivita` di analisi dei dati per il supporto alle decisioni:
non

interessa chi ma uanti

non

interessa un dato ma la somma, la media, il minimo, il massimo di un insieme di dati

17

IL DATA WAREHOUSE

Fuori linea:
base

di dati operazionale: i dati venono acceduti, inseriti, modificati, cancellati pochi record alla volta data warehouse:
operazioni

di accesso e interrogazione diurne operazioni di caricamento e aggiornamento notturne

che riguardano milioni di record

18

IL DATA WAREHOUSE

Un DW rappresenta spesso lunione di pi data mart Data mart: restrizione data warehouse ad un singolo processo o ad un gruppo di processi aziendali (es. Marketing)

DW
Data mart #1 Data DW mart #2 Data mart #3

19

... UNA BASE DI DATI SEPARATA ...

Per tanti motivi

non esiste ununica base di dati operazionale che contiene tutti i dati di interesse la base di dati deve essere integrata non tecnicamente possibile fare lintegrazione in linea i dati di interesse sarebbero comun ue diversi

devono

essere mantenuti dati storici devono essere mantenuti dati aggregati

lanalisi dei dati richiede per i dati organizzazioni speciali e metodi di accesso specifici degrado generale delle prestazioni senza la separazione

20

ARCHITETTURA DI RIFERIMENTO
21

CARATTERISTICHE ARCHITETTURALI IRRINUNCIABILI Separazione: lelaborazione analitica e uella transazionale devono essere il pi possibile separate Scalabilit: larchitettura hw e sw deve essere facilmente ridimensionabile Estendibilit: deve essere possibile accogliere nuove applicazioni e tecnologie Sicurezza: il controllo sugli accessi essenziale (dati strategici) Amministabilit: lattivit di amministrazione non deve essere troppo complessa
22

Architettura di riferimento (a due livelli)

acquisizione memorizzazione accesso
Back room
catalogo dei metadati

Front room

dw

23

Architettura ad un livello
acquisizione middleware
Back room
catalogo dei metadati
Dw virtuale

accesso

Front room

24

ARCHITETTURA A TRE LIVELLI

Back room
catalogo dei metadati

acquisizione memorizzazione accesso

Front room

dw

Dati riconciliati
25

SISTEMI SORGENTE
Ogni sorgente di informazioni aziendali Spesso rappresentate da dati operazionali: insieme di record la cui funzione uella di catturare le transazioni del sistema organizzativo tipico accesso OLTP uso di production keys (non vengono usate nel DW)

26

DATI RICONCILIATI

Integrazione dati sorgente

simile

ad integrazione schemi relazionali

isiedono su data staging area

Area

di memorizzazione i dati sorgente vengono trasformati tecnologia relazionale ma anche flat files

27

DATA WAREHOUSE

Risiede su Presentation Server

Componente

che permette la memorizzazione e la gestione del data warehouse, secondo un approccio dimensionale

Pu essere basato su:

tecnologia

relazionale (ROLAP) tecnologia multidimensionale (MOLAP)

28

END-USER DATA ACCESS TOOLS

Client del DW, di facile utilizzo tools per interrogare, analizzare e presentare linformazione contenuta del DW a supporto di un particolare bisogno aziendale invio specifiche richieste al presentation server in formato SQL

29

I METADATI
= dati sui dati Link tra i DB operazionali e il DW ogni passo eseguito durante la costruzione del DW genera metadati che possono poi essere utilizzati dalle fasi successive

Esempi: schema, data in cui un dato stato creato, uale tool lha creato, storia delle trasformazioni di un dato nel tempo, statistiche, dimensione tabelle, ecc. ecc.

30

DUE RITMI DIVERSI ...

Uso bimodale:
16-22

ore al giorno usati per attivit di interrogazione

funzionalit

front room

2-8

ore al giorno per caricamento, indicizzazione, controllo ualit e pubblicazione

funzionalit

back room

31

SERVIZI PRINCIPALI BACK ROOM

Processo ETL: Extraction,Transformation, Loading Extraction

Estrazione dei dati dalle sorgenti informative operazionali Opzioni: tutti i dati / solo dati modificati (incrementale) Pulizia, per migliorare la ualit dei dati Trasformazione di formato, da formato sorgente a uello del DW Correlazione con oggetti provenienti da altre sorgenti Caricamento (refresh o update) con aggiunta di informazioni temporali e generazione di dati aggregati

Transformation

Loading

32

SERVIZI PRINCIPALI BACK ROOM

Il ruolo degli strumenti ETL uello di alimentare una sorgente dati singola, dettagliata, esauriente e di alta ualit che possa a sua volta alimentare il DW in caso di architettura a tre livelli uesti strumenti alimentano il livello dei dati riconciliati la riconciliazione avviene uando il DW viene popolato la prima volta e periodicamente uando il DW viene aggiornato
33

SERVIZI PRINCIPALI FRONT ROOM

Supporto di tool di accesso: tool che permettono allutente di accedere in modo intuitivo ed altamente espressivo ai dati contenuti nel DW:
capacit

di effettuare confronti presentazione dati avanzata risposte alla domanda: perche?

34

TOOL DI ACCESSO

Ad hoc

permettono allutente di specificare le proprie uery attraverso interfaccie user-friendly

tools per la generazione di reportistica

applicazioni avanzate

applicazioni che permettono di applicare operazioni molto sofisticate al DW

previsione DATA MINING ...

35

TOOL DI ACCESSO
DBMS Presentazione
Aggregate navigator

Traduzione in SQL

ODBC, JDBC
36

PROGETTAZIONE DI UN DATA WAREHOUSE

37

FATTORI DI RISCHIO

Tipiche ragioni di fallimento dei progetti di data warehousing: Rischi legati alla gestione del progetto
necessit

di condivisione di informazione tra i reparti definizione dellambito e delle finalit del sistema

Rischi legati alle tecnologie (rapida evoluzione) Rischi legati ai dati e alla progettazione

ualit dei dati e del progetto realizzato di trasformare la cultura aziendale, inerzia organizzativa

Rischi legati allorganizzazione

difficolt

38

METODOLOGIE DI PROGETTAZIONE

Approccio top-down

+ visione globale dellobiettivo + DW consistente e ben integrato costi onerosi e lunghi tempi di realizzazione (rischio di scoraggiare la direzione) complessit dellanalisi e riconciliazione contemporanea di tutte le sorgenti impossibilit di prevedere a priori nel dettaglio le esigenze delle diverse aree aziendali impossibilit di prevedere la consegna a breve termine di un prototipo
39

METODOLOGIE DI PROGETTAZIONE

Approccio bottom-up
il DW viene costruito in modo incrementale assemblando iterativamente pi data mart rischio: determina una visione parziale del dominio di interesse il primo data mart da prototipare deve essere uello che gioca il ruolo pi strategico per lazienda e deve ricoprire un ruolo centrale per lintero DW

40

BUSINESS DIMENSIONAL LIFECYCLE [KIMBALL]

Pianificazione Definizione dei requisiti
Progetto dellarchitettura Selezione e installazione prodotti

Modellazione dimensionale Progettazione fisica Progetto dellalimentazione

Specifica applicazioni Sviluppo applicazioni

Tecnologia

Dati

Applicazioni

Attuazione Manutenzione
41

LA PROGETTAZIONE DI UN DATA MART

Analisi e riconciliazione delle fonti dati

input: schema delle sorgenti output: schema riconciliato input: schema riconciliato output: fatti, carico di lavoro preliminare input: schema riconciliato, fatti, carico di lavoro preliminare ouput: schemi di fatto input: schemi di fatto, carico di lavoro preliminare ouput: carico di lavoro, schemi di fatto validati
42

Analisi dei re uisiti

Progettazione concettuale

Raffinamento del carico di lavoro, validazione dello schema concettuale

LA PROGETTAZIONE DI UN DATA MART

Progettazione logica
input:

lavoro output: schema logico del data mart

schema di fatto, modello logico target, carico di

Progettazione dellalimentazione
input:

schemi delle sorgenti, schema riconciliato, schema logico del data mart output: procedure di alimentazione

Progettazione fisica
input:

schema logico del data mart, DBMS target, carico di lavoro output: schema fisico del data mart
43

LA PROGETTAZIONE DI UN DATA MART

Aspetto chiave:
basare la modellazione dei data mart sugli schemi operazionali uno schema concettuale di massima per il data mart pu essere derivato dal livello dei dati riconciliati per uesto motivo la fase di analisi e riconciliazione delle fonti avviene prima della fase di analisi dei re uisiti utente

se ueste due fasi sono invertite

lo schema viene ricavato dalle specifiche utente e solo a posteriori si verifica che le informazioni richieste siano effettivamente disponibili nei database operazionali rischio di minare la fiducia del cliente verso il progettista

44

ANALISI E RICONCILIAZIONE DELLE FONTI DATI

Schemi sorgenti operazionali Analisi e riconciliazione Schema riconciliato, Mapping sorgenti operazionali Progettazione del cleaning Campioni dei dati Progettazione della trasformazione Procedure per strumenti ETL

Metadati

Schema riconciliato, Mapping sorgenti operazionali

Strumenti ETL
45

ANALISI E RICONCILIAZIONE DELLE FONTI DATI

Sorgente 1
Schema logico (locale)

Sorgente 2
Schema logico (locale)

Ricognizione e normalizzazione
Schema concettuale (locale) riconciliato Schema concettuale (globale) riconciliato

Ricognizione e normalizzazione Integrazione degli schemi

Schema concettuale (locale) riconciliato

Schema concettuale (globale) riconciliato

Metadati

Definizione corrispondenza Schema logico (globale) riconciliato con le sorgenti

e corrispondenza

46

ANALISI E RICONCILIAZIONE DELLE FONTI DATI

Ricognizione: Esame approfondito degli schemi locali mirato alla piena comprensione del dominio applicativo normalizzazione: correzione degli schemi locali per modellare in modo pi accurato il dominio applicativo (Fasi da svolgere anche se sorgente dati unica) integrazione: v. uanto detto su integrazione di schemi concettuali definizione delle corrispondenze: il risultato finale lo schema riconciliato in cui sono risolti i conflitti e linsieme delle corrispondenze tra gli elementi degli schemi sorgenti e uelli dello schema riconciliato

47

LE FASI DELLA PROGETTAZIONE DI UN DATA MART

Progettazione concettuale:
fornisce

una rappresentazione formale del contenuto informativo del data mart indipendente dal sistema che verr utilizzato per la sua implementazione

progettazione logica:
lo

schema concettuale viene tradotto nel modello dei dati del sistema prescelto in cui vengono scelte le caratteristiche legate allo schema fisico del DW (indici, partizionamento)
non

progettazione fisica:
fase

la vediamo
48

LE FASI DELLA PROGETTAZIONE DI UN DATA MART

Requisiti utente Schema riconciliato PROGETTAZIONE Carico di lavoro CONCETTUALE valori dei dati modello logico Schema di fatto PROGETTAZIONE Carico di lavoro LOGICA volume dei dati DBMS Schema PROGETTAZIONE logico FISICA Schema fisico

49

PROGETTAZIONE CONCETTUALE DI UN DATA WAREHOUSE

50

ANALISI MULTIDIMENSIONALE

Lanalisi richiede normalmente dimensioni multiple:

uanti items ho venduto per regione per mese per tipo di cliente? Tempo Prodotto Cliente Area geografica Dipartimento/settore

Dimensioni normalmente utilizzate per lanalisi:

Progettazione concettuale
OLTP
modello entit-relazione si cerca di eliminare il pi possibile la ridondanza
maggiore efficienza delle operazioni di aggiornamento

schema simmetrico ci possono essere molti modi per connettere (mediante unoperazione di join) due tabelle la rappresentazione dipende dalla struttura dei dati
52

Progettazione concettuale
OLAP

Un data warehouse si basa su un modello dei dati multidimensionale che rappresenta i dati sotto forma di data cube Un data cube permette di modellare e creare viste dei dati rispetto a molteplici dimensioni Modello dati multidimensionale Detto Star Schema Implementabile su un DB relazionale Consente volumi di dati molto grandi

volumi

dellordine di 100 gbytes forniscono tempi di risposta sotto i 10 sec

53

Progettazione concettuale
OLAP
magazzino

Processo: vendite in una catena di supermercati

tempo

C A feb apr mag set B 1 9 10 42 vino 15 7 2 25 12 3 23 11

prodotto

acqua coca cola

54

PROGETTAZIONE CONCETTUALE Il manager regionale esamina Il manager finanziario esamina

la vendita dei prodotti in tutti i periodi relativamente ai propri mercati la vendita dei prodotti in tutti i mercati relativamente al periodo corrente e quello precedente

magazzino tempo prodotto

Il manager di prodotto esamina la vendita di un prodotto in tutti i periodo e in tutti i mercati Il manager strategico si concentra su una categoria di prodotti, unarea regionale e un orizzonte temporale medio
55

PROGETTAZIONE CONCETTUALE
OLAP

Ogni parametro puo` essere organizzato in una gerarchia che ne rappresenta i possibili livelli di aggregazione:
negozio,

citta`, provincia, regione giorno, mese, trimestre, anno

56

Progettazione concettuale
OLAP
Leliminazione della ridondanza non un obiettivo
non si devono eseguire operazioni di aggiornamento schemi denormalizzati

schemi asimmetrici un solo modo per connettere (mediante unoperazione di join) due tabelle
minore numero dijoin maggiore efficienza

la rappresentazione dipende dalla struttura dei dati

57

CONCETTI USATI PER DEFINIRE UN DATA CUBE

Fatto un tema di interesse per lorganizzazione (vendite, spedizioni, ac uisti) Misura una propriet di un fatto da analizzare (numero di unit vendute, prezzo unitario) Dimensione descrive una prospettiva lungo la uale unorganizzazione vuole mantenere i dati (prodotto, negozio, data)
58

PROGETTAZIONE CONCETTUALE

Utilizza modelli multidimensionali

schemi

di fatto

ogni schema di fatto mette in evidenza

le

dimensioni (spigoli del cubo) le misure (contenuto di ogni cubetto) Fatti e dimensioni collegati attraverso associazioni uno-a-molti lo schema complessivo rappresenta una relazione molti-a-molti
59

SCHEMI DI FATTO
fatto ora VENDITA Unit Incasso cliente dimensioni prodotto

negozio

misure
60

LE DIMENSIONI

Devono essere scelte solo le entit rilevanti per le analisi che si intendono effettuare Le dimensioni sono tipicamente caratterizzate da attributi:

testuali discreti dimensione di un prodotto

ma possono anche essere numeriche

esiste sempre una dimensione temporale

61

DIMENSIONI: ESEMPI

Attivit: vendita in una catena di supermercati

dimensioni: tempo, prodotti, magazzino dimensioni: tempo, prodotti, clienti, spedizioni dimensioni: tempo, facolt, tipologia studenti dimensioni: clienti, venditori, concorrenti, automobili, concessionarie

Attivit: ordini

Attivit: iscrizioni universitarie

Attivit : vendita automobili

62

LE DIMENSIONI

Problema: come si pu identificare se un attributo numerico un fatto o un attributo di una dimensione? Se una misura che varia continuamente nel tempo

fatto

analisi costo di un prodotto nel tempo

se una descrizione discreta di ualcosa che ragionevolmente costante

attributo di una dimensione

costo di un prodotto visto come informazione descrittiva

63

LE DIMENSIONI

Le dimensioni utilizzate sono spesso le stesse in vari contesti applicativi:

tempo collocazione geografica organizzazione clienti

il numero di attributi per ogni dimensione in genere molto elevato (anche nellordine del centinaio)

64

LA DIMENSIONE TEMPO

presente in ogni DW in uanto virtualmente ogni DW rappresenta una serie temporale Domanda: perch non campo di tipo DATE nella tabella dei fatti? Risposta: la dimensione tempo permette di descrivere il tempo in modi diversi da uelli che si possono desumere da un campo date in SQL (giorni lavorativi-vacanze, periodi fiscali, stagioni, ecc.)
65

LA DIMENSIONE TEMPO

Alcuni tipici attributi della dimensione tempo:

(pu essere un campo di tipo data in SQL) giorno-della-settimana n-giorno-nel-mese n-giorno-in-anno n-settimana-in-anno mese stagione periodo fiscale ...
tempo-k
66

I FATTI
I fatti hanno delle proporiet che sono dette misure Le propret dei fatti sono tipicamente:

numeriche additive
possono

essere aggregati rispetto agli attributi delle dimensioni, utilizzando loperazione di addizione

67

FATTI E MISURE: ESEMPI

Attivit (fatti): vendite in una catena di supermercati

misure: n. prodotti venduti, incassi, costi, ... misure: n. spedizioni, n. clienti, importi, ... misure: n. studenti,

Attivit (fatti): ordini

Attivit (fatti): iscrizioni universitarie

Attivit (fatti): chiamate gestite da compagnia telefonica

misure: costo, durata

68

ADDITIVIT DELLE MISURE

Incasso, unit vendute: sono additive in uanto si possono aggregare sommando rispetto ad ogni dimensione:
somma

incassi/unit su tempo somma incassi/unit su prodotti somma incassi/unit su dipartimenti

69

SEMIADDITIVIT DELLE MISURE

Numero clienti non una misura additiva:

n. clienti su tempo OK somma n. clienti su dipartimenti OK MA:
somma
somma

n. clienti su prodotto genera problemi

si

supponga che

clienti

che hanno comprato carne 20 clienti che hanno comprato pesce 30

il

numero di clienti che hanno comprato carne o pesce un ualun ue numero tra 30 e 50
70

SEMIADDITIVIT DELLE MISURE

Il numero clienti una misura semiadditiva, poich pu essere sommata solo rispetto ad alcune dimensioni Soluzione: cambiare la granularit del database, portandola a livello singola transazione

71

SEMIADDITIVIT DELLE MISURE

Tutte le misure che memorizzano una informazione statica, uali:

bilanci

finanziari misure di intensit (temperatura di una stanza)

sono semiadditive rispetto al tempo

ci che comun ue si pu fare calcolare la media su un certo periodo di tempo

72

NON ADDITTIVIT DELLE MISURE

Le misure non additive sono misure che non possono essere sommate Esempi:
misure:

costo unitario e uantit nel contesto di un

ordine dimensioni: clienti, spedizioni, tempo, i costi unitari non possono essere sommati se prima non sono moltiplicati per le rispettive uantit, uindi tali costi sono misure non additive

73

SCHEMI DI FATTO

VENDITA Unit Incasso NumClienti PrezzoUnitario (AVG)

prodotto

misure non additive

74

FATTI ANOMALI

In alcuni contesti applicativi, puo` capitare di avere fatti senza misure

fatti anomali

in uesto caso i fatti rappresentano semplicemente una relazione molti-a-molti, senza aggiungere alcuna nuova informazione Esempi:

Attivita` principale: corsi universitari

dimensioni: corsi, professori, studenti, tempo dimensioni: ospedali, dottori, diagnosi, tempo, pazienti, assistenti, procedure

attivita` principale: assegnazione cure negli ospedali

75

GERARCHIE
Ciascuna dimensione spesso organizzata in una gerarchia che rappresenta i possibili livelli di aggregazione per i dati ogni livello della gerarchia rappresenta una relazione molti-a-uno regione anno

provincia citt negozio

categoria marca prodotto

trimestre mese giorno

76

ESEMPIO DI DW CON GERARCHIE

sType store city region
s Ty pe t Id t1 t2 c it y Id s fo la s ize s m a ll la r ge po p 1M 5M lo c a t io n d o w n to w n s ubur bs r e gId n o r th s o uth

customer

id 53 81 111

name joe fred sally

address 10 main 12 main 80 willow

city sfo sfo la

c it y

r e gio n

r e gId nam e n o r th co ld r e gio n s o uth w a r m r e gio n

77

GERARCHIE
Gli attributi della gerarchia vengono associati alle dimensioni a cui si riferiscono e chiaramente indicati gli attributi della dimensione devono essere associati al livello della gerarchia a cui si riferiscono

78

SCHEMI DI FATTO
gerarchia anno trimestre mese cliente giorno ora negozio citt regione stato indirizzo modello VENDITA Unit Incasso prodotto professione et nome cognome indirizzo categoria descrizione colore
79

settimana

attributi descrittivi

AGGREGAZIONE

In alcune situazioni, non si hanno vincoli su tutte le dimensioni ma solo per alcune Esempio:

uale` il rapporto tra vendite effettuate nei weekend e vendite effettuate nei giorni lavorativi in ogni magazzino? Quale prodotto e` stato maggiormente venduto negli ultimi 3 mesi?

Lesecuzione di ueste interrogazioni e` molto costosa se viene effettuata sui dati di base

Idea: precalcolare aggregati

80

AGGREGAZIONE

Un aggregato e` un insieme di misure ottenute come sintesi di varie misure che caratterizzano i fatti di base una misura aggregata spesso associata a dimensioni aggregate utile considerare gli aggregati a livello concettuale per capire

se lo schema di base permette il calcolo degli aggregati rientra nellanalisi del carico di lavoro

81

AGGREGAZIONE

un aggregato viene utilizzato per due motivi:

efficienza impossibilita`

di rappresentare gli stessi dati al livello di dettaglio Esempio: costi di promozione possono essere espressi a livello categoria e non a livello di singolo prodotto

82

ESEMPIO
aggregati (livello 2)
Categoria per mese

aggregati (livello 1)

Categoria per prodotto per giorno Vendite mensili per prodotto per giorno

vendite
83

DUE PROBLEMI

Quali dati aggregare?

Come rappresentare i dati aggregati?

84

QUALI DATI AGGREGARE?

importante considerare:

tipiche richieste aziendali

distribuzione geografica, linee di prodotti, periodicit generazione reportistica per ogni dimensione, identificare gli attributi e le combinazioni di attributi che pu essere utile aggregare stimare la dimensione delle tabelle aggregate se la dimensione della tabella aggregata non riduce di molto la dimensione della tabella di partenza, forse non conviene aggregare aggregazioni non molto usate possono essere utili come punto di partenza per effettuare altre aggregazioni pi significative

distribuzione statistica dei dati

85

COME E DOVE MEMORIZZARE I DATI AGGREGATI?

Esistono due approcci di base:

nuovi

fatti

vengono

create nuove tabelle per i fatti e le dimensioni aggregate

nuovi

campi

vengono

aggiunti nuovi attributi nei fatti e nelle dimensioni

vediamo solo il primo approccio

86

NUOVE TABELLE DEI FATTI

Per ogni aggregato di interesse viene generato un nuovo fatto si generano nuove dimensioni derivate da uelle di base ma contenenti solo i dati di interesse per i fatti aggregati

87

ESEMPIO
anno trimestre mese cliente VENDITA ne ozio citt regione stato indirizzo
88

professione et nome cognome indirizzo categoria

Unit Incasso

COMPOSIZIONE DEGLI SCHEMI

Lo schema risultante da ogni processo aziendale pu essere visto come lo schema associato ad uno specifico data mart problema: combinare i fatti e le dimensioni contenuti negli schemi associati a ciascun processo, cioe contenuti in ciascun data mart
89

Composizione degli schemi

Gli schemi associati ai vari processi possono avere dimensioni a comune
Una singola dimensione puo` essere usata in relazione a diversi fatti

per potere passare dalle informazioni contenute in uno schema alle informazioni contenute in un altro (drill-across): le dimensioni con lo stesso nome devono avere lo stesso significato e contenere gli stessi attributi (o sottoinsiemi di attributi)
dimensioni conformate

Conseguenza: i vincoli su attributi delle dimensioni a comune devono restituire le stesse entit per ogni schema considerato
90

FATTI CONFORMATI

Anche le misure devono essere conformati

misure

con lo stesso nome in fatti diversi hanno la stessa granularita` e le stesse unita` di misura

stesso

periodo temporale stesso riferimento geografico

91

COSTELLAZIONE DI FATTI

Schema risultante:
costellazione

di fatti

92

PROGETTAZIONE LOGICA DI UN DATA WAREHOUSE

93

SCELTA SISTEMA DI GESTIONE DEI DATI

DBMS operazionale: in genere relazionale

DBMS informativo:
relazionale

(Oracle 8/8i, RedBrick- Informix,) multidimensionale (Oracle Express Server)

94

DBMS RELAZIONALI
Tecnologia consolidata molto efficienti su dati di dettaglio estesi in modo da permettere la materializzazione degli aggregati

(Oracle

9i)

performance scalabilit general-purposes

95

DBMS MULTIDIMENSIONALI p m m zz
1v 2 q 3 4 q 5 q f bb f bb p m mb A B A A

magazzino
C A feb B 1 9 10 42 vino 15 7 2 25 12 3 23 11

tempo

apr mag set

prodotto

acqua coca cola

96

DBMS MULTIDIMENSIONALI

Modello dei dati basato su hypercubi (vettori multidimensionali) precalcolo aggregazioni aumento prestazioni per le uery utente ma

sparsit (in genere meno del 20% delle celle contiene informazioni) no join no interfaccia SQL (API) --> no standard necessit sistema relazionale per dati dettaglio file molto grandi limitazioni a circa 10GB (problemi scalabilit) aggiunta capacit di navigare da un MDBMS ad un RDBMS

Per superare uesti problemi:

97

SISTEMI ROLAP & MOLAP

ROLAP:

sistema di data warehouse in grado di supportare le interrogazioni tipiche (roll-up, drill-down,) presentation server relazionale

Oracle 9i + Discoverer

MOLAP:

sistema di data warehouse in grado di supportare le interrogazioni tipiche (roll-up, drill-down,) presentation server multidimensionale

Express Server

DOLAP (Desktop OLAP):

i dati vengono recuperati da un DW relazionale o multidimensionale e copiati localmente

Business Objects

98

ROLAP & MOLAP

Performance
Query: MOLAP Caricamento: ROLAP

Analisi: MOLAP Dimensione DW: ROLAP

MOLAP: problema sparsit MOLAP: minor numero di dimensioni ammesse

Flessibilit nello schema: ROLAP

99

PROGETTAZIONE LOGICA

Durante uesta fase, lo schema concettuale del DW viene tradotto in uno schema logico, implementabile sullo strumento scelto Il modello logico deve essere il pi possibile vicino al modello concettuale, anche se alcune variazioni possono essere rese necessarie dal particolare tool prescelto

supponiamo che il sistema prescelto sia ROLAP

100

IMPATTO DELLARCHITETTURA SULLO SCHEMA LOGICO

Architettura a due livelli:

ogni

tabella = una relazione tabella = una vista

architettura a un livello:
ogni

nel seguito ipotizziamo architettura a due-tre livelli

101

PROGETTAZIONE LOGICA

Modelli logici per data mart in ROLAP:

modello

a stella modello snowflake

102

MODELLO A STELLA
Si interpretano fatti e dimensioni come entit del modello entit-relazione si mappa lo schema entit-relazione in uno schema relazionale

fatti e dimensioni diventano tabelle a cui si aggiunge una chiave artificiale le tabelle delle dimensioni contengono tutti gli attributi per tutti i livelli della gerarchia poich le associazioni sono tutte uno-a-molti, si modellano con chiavi esterne

103

CHIAVI

Le chiavi aggiunte devono essere chiavi artificiali (numeriche, progressive)

non

sono le chiavi semantiche eventualmente utilizzate nella base di dati operazionale

si ottimizzano le operazioni di join le chiavi semantiche possono essere comun ue presenti come attributi comuni

104

ESEMPIO DI SCHEMA
Tempo Codice orario Ora Giorno Settimana Mese Trimestre Anno Luogo Codice luogo Negozio Indirizzo Codice Citt Citt Codice Regione Regione Codice Stato Stato Prodotto Codice prodotto Descrizione Colore Modello Codice categoria Categoria

Vendite Codice orario Codice luogo Codice prodotto Codice cliente Unit Incasso

Cliente Codice cliente Nome Cognome Indirizzo Et Codice professione Professione

105

ESEMPIO DI INSTANZA
product prodId p1 p2 name price bolt 10 nut 5

store storeId c1 c2 c3

city nyc sfo la

sale oderId date o100 1/7/97 o102 2/7/97 105 3/8/97

custId 53 53 111

prodId p1 p2 p1

storeId c1 c1 c3

qty 1 2 5

amt 12 11 50

customer

custId 53 81 111

name joe fred sally

address 10 main 12 main 80 willow

city sfo sfo la

106

Osservazioni sulla normalizzazione dello schema

La tabella dei fatti completamente normalizzata le tabelle delle dimensioni possono non essere normalizzate, ma:
la dimensione delle tabelle delle dimensioni in genere irrilevante rispetto alla dimensione della tabella dei fatti quindi, ogni sforzo per normalizzare queste tabelle ai fini del DW una perdita di tempo lo spazio guadagnato in genere meno dell1% dello spazio richiesto dallo schema complessivo

la normalizzazione delle tabelle delle dimensioni pu ridurre la capacit di browsing (navigazione) dello schema (si veda oltre)
107

SCHEMI SNOWFLAKE

In presenza di gerarchie, una dimensione pu essere facilmente normalizzata introducendo una nuova relazione per ogni livello della

schema snowflake
Mo ello Co ice mo ello Mo ello co ice categoria

Pro otto Co ice pro otto Descrizione Colore Co Mo ello

Categoria Co ice categoria categoria

108

SCHEMI SNOWFLAKE

Uno schema snowflake rende meno efficienti le operazioni di ricerca, anche se la tabella e` grande (+ join) e` conveniente utilizzare uno schema snowflake solo se uesto approccio aumenta la leggibilita` dello schema e le prestazioni globali

109

SCHEMI AGGREGATI

Approccio A
lo

schema logico aggregato viene creato utilizzando le stesse regole utilizzate per lo schema di base
lo

schema di base e gli schemi aggregati dovranno essere alimentati dalle procedure ETL si aumenta il carico di lavoro della back room non si altera il carico di lavoro del presentation server

110

SCHEMI AGGREGATI

Approccio B
lo

schema aggregato viene creato in modo virtuale, come insieme di viste, eventualmente materializzate
solo

lo schema di base deve essere alimentato si aumenta il carico di lavoro del presentation server non si altera il carico di lavoro della back room (si semplificano le procedure di alimentazione)

111

ESEMPIO

Fatti: unit, incasso Dimensioni: prodotti, tempo si vogliono analizzare unit e incasso per categoria di prodotto

CREATE VIEW vendite_per_cat(categoria,tempo_k,unit_cat,incasso_cat) AS SELECT categoria, tempo_k, SUM(unit),SUM(incasso) FROM Vendite,prodotti WHERE vendite.prodotto_k = prodotti.prodotto_k GROUP BY categoria, tempo_k

112

VANTAGGI E SVANTAGGI NELLUSO DEGLI AGGREGATI

Svantaggi:

Luso degli aggregati aumenta di molto la dimensione del DB (anche del 300%!) usare aggregazione nel caso in cui ogni aggregato sintetizza almeno 10-20 record di base

Vantaggi:
Miglioramento delle prestazioni possono essere utilizzati in modo trasparente allutente

113

INFLUENZA AGGREGATI SUL CODICE SQL

Se gli aggregati sono presenti, per poterli utilizzare bisogna ovviamente scrivere codice SQL opportuno partendo da una uery sulle tabelle di base, le tabelle aggregate possono essere utilizzate sostituendole alle corrispondenti tabelle di base
114

ESEMPIO QUERY DI BASE

SELECT categoria, SUM(unit_cat) FROM vendite, prodotti, tempo WHERE vendite.prodotto-k = prodotti.prodotto-k AND vendite.tempo-k = tempo.tempo-k AND tempo.giorno = 1 Gennaio, 1996 GROUP BY categoria

115

ESEMPIO QUERY AGGREGATA

SELECT categoria, unit_cat FROM vendite-per-cat, tempo WHERE vendite-aggreg-per-cat.tempo-k = tempo.tempo-k AND tempo.giorno = 1 Gennaio, 1996

116

INFLUENZA SUL CODICE SQL

Gli utenti finali e i tool di accesso devono generare codice differente in relazione che esistano o meno le tabelle agrgegate
discontinuit

delle applicazioni

Soluzione: aggregate navigator

117

AGGREGATE NAVIGATOR

Livello software il cui obiettivo uello di intercettare le richieste SQL e tradurle utilizzando nel modo migliore le tabelle aggregate

si scelgono le pi piccole

le richieste SQL si assumono utilizzare le tabelle di base si rende trasparente luso degli aggregati allutente finale

118

PROGETTAZIONE LOGICA IN ORACLE 9I

Oltre a creare una relazione per ogni tabella, possibile rappresentare esplicitamente le gerarchie, utilizzando il concetto di DIMENSIONE
nuovo

oggetto della base di dati

possibilit di materializzare le uery

119

DIMENSIONI IN ORACLE 9I
Oggetti che permettono di descrivere gerarchie esistenti allinterno delle tabelle vengono utilizzate per:

riscrivere le uery suggerire la creazione di view materializzate

non contengono nuovi dati ma specificano:

gli attributi coinvolti nelle gerarchie (livelli) le gerarchie (anche >= 1 per una stessa tabella) dipendenze funzionali tra livelli ed altri attributi delle tabelle sottostanti

120

DIMENSIONI IN ORACLE 8I
CREATE DIMENSION <nome> LEVEL <nome_l1> IS <nome tabella>.<attr> LEVEL <nome_l2> IS <nome tabella>.<attr> HIERARCHY <nome gerarchia> ( <nome_livello> CHILD OF <nome_livello> CHILD OF ) ATTRIBUTE <nome livello> DETERMINES <nome<tabella>.<attr> ...

121

ESEMPIO

VENDITA

prodotto Unit categoria Incasso NumClienti descrizione PrezzoUnitario (AVG) colore modello Prodotti Prodotto_k Prodotto Modello Colore Descrizione Categoria

122

DIMENSIONI IN ORACLE 8I
CREATE DIMENSION Prodotti_D LEVEL prod_l IS Prodotti.prodotto LEVEL categ_l IS Prodotti. categoria HIERARCHY Prodotti_H ( prod_l CHILD OF categ_l) ATTRIBUTE prod_l DETERMINES descrizione ATTRIBUTE prod_l DETERMINES modello ATTRIBUTE prod_l DETERMINES colore;

123

VIEW MATERIALIZZATE

Materializzo la vista, cioe` la calcolo una sola volta, la memorizzo e la uso durante lesecuzione delle uery Necessit di specificare:

Politiche di caricamento Politiche di aggiornamento (refresh) Utilizzo/non utilizzo da parte dellaggregate navigator

124

VIEW MATERIALIZZATE IN ORACLE 9I

Caricamento:
Immediate:

allatto della definizione

(default)
Deferred:

popolata alla successiva operazione di refresh (che deve essere completo)

125

VIEW MATERIALIZZATE IN ORACLE 9I

Refresh:

Come:
Fast: incrementale (molte restrizioni) Complete: totale Force: incrementale uando possibile, totale altrimenti

Quando:
On Commit: fast refresh al commit delle transazioni sulle tabelle di definizione della view (solo per join view e singletable view) On Demand: invocando specifiche procedure Start with <date> Next <date expression> .

126

VIEW MATERIALIZZATE IN ORACLE 9I

Query Rewrite:
Enable:

utilizzata dallaggregate navigator in fase di riscrittura delle uery Disable: non utilizzata dallaggregate navigator in fase di riscrittura delle uery

127

VIEW MATERIALIZZATE IN ORACLE 9I

CREATE MATERIALIZED VIEW nome BUILD <tipo caricamento> REFRESH <tipo refresh> [ENABLE QUERY REWRITE] AS <sotto uery di definizione> DROP MATERIALIZED VIEW nome ALTER MATERIALIZED VIEW ...

128

VIEW MATERIALIZZATE IN ORACLE 9I

CREATE MATERIALIZED VIEW vendite_cat BUILD immediate REFRESH complete on commit ENABLE QUERY REWRITE AS SELECT categoria, tempo_k, SUM(unit),SUM(incasso) FROM Vendite,prodotti WHERE vendite.prodotto_k = prodotti.prodotto_k GROUP BY categoria, tempo_k
129

INTERROGAZIONE DI UN DATA WAREHOUSE

130

TIPOLOGIE
Reportistica On-Line Analytical Processing Data mining

131

REPORTISTICA

Approccio orientato ad utenti che hanno necessit di accedere a intervalli di tempo predefiniti a informazioni strutturate in modo pressoch invariabile di uesti rapporti nota a priori la forma un rapporto definito da uninterrogazione e da una presentazione linterrogazione comporta in genere la selezione e laggregazione di dati multidimensionali la presentazione pu essere in forma tabellare o grafica la reportistica non nata con il DW, ma ha ac uisito con il DW benefici in termini di affidabilit e tempestivit dei risultati

132

OLAP: ON-LINE ANALYTICAL PROCESSING

Una visione multidimensionale, logica, dei dati Analisi interattiva dei dati Modellazione analitica: derivazione delle proporzioni, delle varianze, etc Aggregazioni per ogni sottoinsieme delle dimensioni Previsione, trend analysis, e statistical analysis Calcola e visualizza i dati in 2D o 3D crosstabs, charts, e grafi, con semplici operazioni di rotazione degli assi

133

OLAP SU DATA CUBES

Mercati

Quantit

Prodotti

Periodi di tempo

Vendite
134

PROGETTAZIONE CONCETTUALE Il manager regionale esamina Il manager finanziario esamina

la vendita dei prodotti in tutti i periodi relativamente ai propri mercati la vendita dei prodotti in tutti i mercati relativamente al periodo corrente e quello precedente

magazzino tempo prodotto

Il manager di prodotto esamina la vendita di un prodotto in tutti i periodo e in tutti i mercati Il manager strategico si concentra su una categoria di prodotti, unarea regionale e un orizzonte temporale medio
135

I NUOVI TIPI DI QUERY

Dipendono dai tool di accesso influenzano limplementazione delle uery Operazioni di base:

drill-down/roll-up pivoting slicing dicing top-n

136

OPERAZIONI TIPICHE

Roll up: riassumi i dati, salendo nella gerarchia dei concetti per una dimensione o attraverso una riduzione di una dimensione
il volume totale di vendite per categoria di prodotto e per regione per anno si rimuove per esempio la dimensione tempo

Roll down or drill down: passa da un livello di dettaglio basso ad un livello di dettaglio alto, scendendo nella gerarchia o introducendo una nuova dimensione.

per un particolare prodotto, trova le vendite dettagliate per ogni venditore e per ogni data

137

OPERAZIONI TIPICHE (CONT.)

Slice and dice: select & project

di Slice esegue una selezione su una dimensione del cubo. Loperazione di Dice definisce un sottocubo eseguendo una selezione su due o pi dimensioni Vendite delle bevande nel West negli ultimi 6 mesi
Loperazione

Pivot (rotate): riorienta il cubo Top-n:

Esempio:

determinare i 10 prodotti piu` venduti ad una certa data e in un certo magazzino, ordinati per vendite
138

OPERAZIONI TIPICHE: ROLL-UP

Product

Roll-up Product

Year

Drill-Down Roll-up Product Drill-Down Month

139

Year

OPERAZIONI TIPICHE: DRILL-DOWN E ROLL-UP

Dipartimento down Panificio
Cibo surgelato Lit. 12100000 Lit. 23000000 5088 15000

Incassi Unit vendute up

Dipartimento
Panificio Panificio Cibo surgelato Cibo surgelato

Marca
Barilla Agnesi Findus Orogel

Incassi Unit vendute

6000000 6100000 15000000 8000000 2600 2488 6500 8500

140

OPERAZIONI TIPICHE: SLICE AND DICE

Product Slice Month Product

Month

141

DATA MINING

Attivit orientata a scoprire informazioni nascoste nei dati le tecniche di data mining sono utilizzate da anni in applicazioni scientifiche specialistiche (ricerca geologica, medica, astronomica, metereologica, ) con il DW il data mining viene trasportato dallanalisi scientifica allanalisi commerciale (ricerche di mercato, segmentazione di mercato, analisi delle abitudini di ac uisto, ) permette di analizzare automaticamente grosse uantit di dati tipologie di pattern estraibili con regole di data mining: regole associative, clustering, alberi di decisione, serie temporali

142

IMPATTO SUL CODICE SQL

Tipiche uery OLAP richiedono molte aggregazioni

GE MI Totale 81 107 35 223 144 145 110 388

1995 SELECT SUM (vendite) FROM vendite S, Tempo T, Magazzini M 1996 WHERE S.TId = T.TId AND S.Mid = M.Mid 1997 GROUP BY T.anno, M.citta`

63 38 75

Totale 176 SELECT SUM (vendite) FROM vendite S, Magazzini M WHERE S.MId = M.MId GROUP BY M.citta`

SELECT SUM (vendite) FROM vendite S, Tempo T WHERE S.TId = T.TId GROUP BY T.anno
143

IMPATTO SUL CODICE SQL

{PId, MId,TId}

In genere:

{PId, MId} {PId}

{PId, TId} {MId}

{MId, TId} {TId}

fatti con k dimensioni 2k uery SQL aggregate

Nuovo operatore SQL CUBE per calcolare tutte le possibili aggregazioni rispetto ad un insieme di attributi
CUBE Pid, Mid, Tid BY SUM Vendite e uivalente ad un insieme di uery:
SELECT SUM (vendite) FROM vendite S GROUP BY grouping list

Presente in molti DBMS

{}

144

IMPATTO SUL CODICE SQL

Necessita` di determinare i primi n elementi rispetto ad un certo ordinamento Esempio: determinare i 10 prodotti piu` venduti in un certo magazzino, ordinati per entita` delle vendit Presente in molti DBMS

145

OPERATORI AGGREGATI IN ORACLE 9I

SQL viene esteso con nuovi operatori di aggregazione. Tra i vari operatori:
ROLLUP CUBE RANK/TOP-N

146

ROLL-UP

SELECT .
GROUP BY ROLLUP (elenco colonne)

calcola laggregato standard rispetto allelenco di colonne specificato calcola subtotali di livello pi alto, riducendo ad uno ad uno le colonne da aggregare, procedendo da destra a sinistra nella lista

147

ROLL-UP Esempio:
SELECT citt, mese, prodotto, SUM(vendite) FROM Vendite v, Magazzini m, Tempo t, Prodotti p WHERE m.Magazzino_k = v.Magazzino_k AND p.Prodotto_k = v.Prodotto_k AND t.Tempo_k = v.Tempo_k GROUP BY ROLLUP(citt,mese,prodotto)

148

ROLL-UP Citt
geno a geno a geno a geno a geno a geno a geno a ilano ilano ilano ilano ilano ilano ilano

Mese a o a o a o uglio luglio luglio arzo arzo arzo luglio luglio luglio

Prodotto Vendite 0 0 0 0 0 0 770 0 7 0 00 0 0

149

CUBE

SELECT .
GROUP BY CUBE (elenco colonne)

calcola laggregato standard rispetto allelenco di colonne specificato e rispetto ad ogni sottoinsieme dellelenco specificato

150

CUBE Esempio:
SELECT citt, mese, prodotto, SUM(vendite) FROM Vendite v, Magazzini m, Tempo t, Prodotti p WHERE m.Magazzino_k = v.Magazzino_k AND p.Prodotto_k = v.Prodotto_k AND t.Tempo_k = v.Tempo_k GROUP BY CUBE(citt,mese,prodotto)

151

CUBE

Citt geno a geno a geno a geno a geno a geno a geno a geno a geno a milano milano milano milano milano

Mese marzo marzo marzo luglio luglio luglio

Prodotto Vendite 0 0 0 0 0 0 340 440 770 430 143 73 340 100

152

p1 p2 marzo marzo marzo luglio luglio p1 p2 p1 p2

TOP-N

SELECT A1,,An FROM (SELECT B1,,Bm, RANK() OVER(ORDER BY Ai ASC, ORDER BY Aj DESC) AS rank FROM WHERE ... GROUP BY A1,,An)

WHERE rank <= N;

permette di ordinare i risultati e restituire solo i primi N rispetto allordinamento prescelto

153

TOP-N

Esempio: SELECT citt, mese, prodotto, sum_vendite FROM (SELECT citt,mese,prodotto, SUM(vendite) AS sum_vendite, RANK() OVER (ORDER by SUM(vendite) DESC) AS rank FROM Vendite v, Magazzini m, Tempo t, Prodotti p WHERE m.Magazzino_k = v.Magazzino_k AND p.Prodotto_k = v.Prodotto_k AND t.Tempo_k = v.Tempo_k GROUP BY (citt,mese,prodotto)) WHERE rank <= 3;

154

TOP-N
Citt Mese Prodotto Vendite

milano milano geno a

mar o luglio mar o

p1 p1 p2

430 340 320

155