Sei sulla pagina 1di 66

Data warehousing e OLAP

• Introduzione
– Il contesto, processi aziendali
• Decision Support Systems
• Sistemi di Data Warehousing
– Data mart
– Architettura
– Modellazione Concettuale
– Star Schema, Dimensioni, Livelli
• OLAP
• Progettazione di un Data Warehouse
– Analisi, Integrazione, Progettazione

1
Il Contesto

• Verso la fine degli anni ‘90 si è capita


l’importanza strategica, per il business,
dell’uso dei dati aziendali raccolti dai processi
operazionali (Business Intelligence)
• Il ritorno di investimento dato
dall’automatizzazione dei processi aziendali
non dava il risultato sperato.
• Occorreva sfruttare meglio i dati aziendali
globali accumulati

2
Il problema

In genere: DB1 DB2


 abbondanza di dati
DB4
DB3
ma anche
 abbondanza di ridondanza ed inconsistenza
che non permette di utilizzare i dati in modo utile
a fini decisionali

3
Tipiche richieste
• Qual è il volume delle vendite per regione e
categorie di prodotto durante l’ultimo 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 correlati ai profitti trimestrali negli ultimi 10
anni?
4
Possibili applicazioni

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

5
In sintesi ...

sistemi di supporto
alle decisioni (DSS)

conoscenza utile
dati all’azienda

DSS: Tecnologia che supporta la dirigenza


aziendale nel prendere decisioni tattico-
strategiche in modo migliore e più veloce

6
Processi Aziendali

Processi informativi aziendali:


Processi operativi
Operano su dati dipartimentali e dettagliati
Decisioni strutturate e basate su regole definite
Processi gestionali
Operano su dati settoriali e parzialmente aggregati
Decisioni semistrutturate, basate su regole note ma
con intervento umano creativo
Processi direzionali
Operano su dati integrati e aggregati
Decisioni non strutturate, non cis ono regole, il tutto
è basato su capacità umane

7
Processi Aziendali - Una Banca

Processi Operativi:
Gestione di un movimento su Conto Corrente
bancario presso uno sportello
Processi Gestionali
Concessione di un fido
Revisione delle condizioni su conto corrente
Processi Direzionali
Verifica dell’andamento di servizi su carte di
credito
Lancio di una campagna promozionale
Accordi commerciali
8
Processi Aziendali - Compagnia
Telefonica
Processi Operativi:
Stipula dei contratti
Instradamento delle telefonate
Dati contabili telefonate(scatti, durata, tariffa…)
Processi Gestionali
Stipula di contratti speciali
Installazione infrastrutture
Processi Direzionali
Scelta dei parametri che fissano il costo delle
telefonate
Definizione di contratti diversificati
Pianificazione potenziamento infrastrutture
9
Informatizzazione dei sistemi
informativi aziendali

Un sistema aziendale può essere tanto più


informatizzato quanto più le sue decisioni
sono strutturate.
Un processo altamente strutturato può essere
facilmente informatizzato, mentro un processo
non strutturato può essere solo parzialmente
supportato da inziative di informatizzazione

10
Sistemi Informativi

Tipologie di sistemi informativi:


Transaction Processing System:
dipartimentali, per sistemi strutturati
Management Information System: settoriali,
anche per processi gestionali
Decision Support System: fortemente
integrati, di supporto alle decisioni

11
Perché i sistemi tradizionali non
sono sufficienti?

• Non gestiscono dati storici


• Sono sistemi eterogenei
• Basse prestazioni
• DBMS non adeguati al supporto decisionale
• Problemi di sicurezza

12
Più formalmente…

• Sistemi tradizionali
– On-Line Transaction Processing (OLTP)

• Sistemi di data warehousing


– On-Line Analytical Processing (OLAP)

⇒ Profondamente diversi

13
Sistemi di Supporto alle
Decisioni
I DSS sono i sistemi che supportano la dirigenza nel
predere decisoni tattico-strategiche, nel modo
migliore e velocemente.
Tipiche operazioni:
3. Quali sono stati i volumi di vendita dello scorso
anno per una certa categoria di prodotto?
4. Quali ordini dovremmo soddisfare per
massimizzare le entrate?

Ci si basa sui dati accumulati da OLTP.

14
In dettaglio ...
OLTP OLAP
funzione gestione supporto alle
giornaliera decisioni
progettazione orientata alle orientata al soggetto
applicazioni
frequenza giornaliera sporadica
dati recenti, dettagliati
storici, riassuntivi,
multidimensionali
sorgente singola DB DB multiple
uso ripetitivo ad hoc
accesso read/write read
flessibilità accesso uso di programmi generatori di query
precompilati

# record acceduti decine migliaia


tipo utenti operatori manager
# utenti migliaia centinaia
tipo DB singola multiple, eterogenee
performance alta bassa
dimensione DB 100 MB - GB 100 GB - TB 15
Sistemi di Supporto alle
Decisioni
In generale i DSS si usano per:
• Customer Retention
– Identificare pattern che portano il cliente alla
“defezione”
• Customer Service
– Servizi di recommendation del prodotto
• Marketing
– Targeting delle promozioni
• Risk Assessment, Fraud Detection
– Trovare pattern sospetti

16
Evoluzione dei DSS

• Anni ‘60: rapporti batch


– difficile trovare ed analizzare i dati
– costo, ogni richiesta richiede un nuovo programma
• Anni ‘70: DSS basato su terminale
– non integrato con strumenti di automazione d’ufficio
• Anni ‘80: strumento d’automazione d’ufficio
– strumenti di interrogazione, fogli elettronici, interfacce
grafiche
– accesso ai dati operazionali
• Anni ‘90: data warehousing, con strumenti integrati
OLAP

17
I sistemi di data warehousing

Il Data Warehousing si può definire come il


processo di integrazione di basi di dati
indipendenti in un singolo repository (il data
warehouse) dal quale gli utenti finali possano
facilmente ed efficientemente eseguire query,
generare report ed effettuare analisi

18
Data Marts

• Data warehouse dipartimentale


• sistema specializzato che mette insieme i dati
necessari ad un dipartimento
• implementato creando views specifiche alle
applicazioni
• sottoinsiemi materializzati di views dipartimentali
che focalizzano su soggetti determinati.
• Possono utilizzare differenti metafore di
rappresentazione

19
Il data warehouse

Collezione di dati che soddisfa le seguenti proprietà:


• usata per il supporto alle decisioni
• orientata ai soggetti
• integrata: livello aziendale e non dipartimentale
• correlata alla variabile tempo: ampio orizzonte
temporale
• con dati tipicamente aggregati, per effettuare stime
• fuori linea: dati aggiornati periodicamente

20
Il data warehouse

Orientata ai soggetti: considera i dati di


interesse ai soggetti dell’organizzazione e
non quelli rilevanti ai processi organizzativi

– basi di dati operazionali dipartimentali:


• vendita, produzione, marketing
– data warehouse: prodotti, clienti, fornitori

21
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

22
Il data warehouse

Correlata alla variabile tempo: presenza di


dati storici per eseguire confronti,
previsioni e per individuare tendenze

– basi di dati operazionali: finestra temporale di


pochi mesi
– data warehouse: finestra temporale dell’ordine
di anni

23
Il data warehouse

Dati aggregati: nell’attività di analisi dei dati per


il supporto alle decisioni:

– non interessa “chi” ma “quanti”

– non interessa un dato ma la somma, la


media, il minimo, il massimo di un insieme
di dati

24
Il data warehouse

Fuori linea:
– base di dati operazionale: i dati vengono 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

25
Architettura
OLAP
Server

Analysis
other
Query
source Serve
Extract Reports
s Transform Data
Load
Data mining
Operational
Refresh
Warehouse
DBs

Tools
Data Marts
26
Popolare un data warehouse

• Estrazione dei dati dalle sorgenti informative


• Trasformazione e pulizia dei dati,
trasformazione di formato e correlazione con
oggetti provenienti da altre sorgenti
• Caricamento aggiunta di informazioni
temporali e generazione di dati aggregati
• Refresh - modalità incrementale

27
System Design

• Capacita` di pianificazione nel definire l’architettura


• Integrazione di servers e clients
• Disegno degli schemi e delle viste del data warehouse
• Disegno dell’organizzazione fisica del warehouse: metodi
di accesso, di caricamento, di partizionamento
• Metodi di connessione
• Disegno e implementazione degli script per l’estrazione, il
caricamento e il refresh dei dati
• Definizione dei metadati e popolamento della repository
• Disegno e implementazione delle applicazioni-utente

28
Tecnologie coinvolte
• conceptual data modeling
– disegno dello schema del warehouse
• integrazione di dati da fonti eterogenee
– monitoraggio e integrazione
• estensione di tecniche relazionali
• distributed and parallel processing
– warehouse & OLAP server

29
Modellazione concettuale di
un data warehouse
Dimensioni e misure
– Star schema: Un singolo oggetto (fact table) in mezzo
connessa ad un numero di oggetti (dimension tables)
– Snowflake schema: Un raffinamento dello star schema
in cui la gerarchia dimensionale è rappresentata
esplicitamente (normalizzando le tabelle delle
dimensioni)
– Fact constellations: fact tables multiple condividono
dimension tables.

30
Star Schema

• Un fatto è un evento di interesse per l’impresa


(vendite, spedizioni, acquisti)
• Le misure sono attributi che descrivono
quantitativamente il fatto da diversi punti di vista (num
di unità vendute, prezzo unitario)
• Una dimensione determina la granularità minima di
rappresentazione dei fatti (il prodotto,il negozio, la
data)
• Una gerarchia determina come le istanze di un fatto
possono essere aggregate e selezionate - descrive
una dimensione

31
Dimensioni

• Devono essere scelte sono le entità rilevanti


per l’analisi
• Tipicamente sono caratterizzate da attributi
testuali o discreti
• La dimensione temporale esiste sempre
Esempio:
•vendite in una catena di supermercati
–Dimensioni: tempo, prodotti, magazzino
•Iscrizioni universitarie
–Dimensioni: tempo, facoltà, tipologia studenti
32
Dimensioni

Come si identifica se un attributo numerico è un


fatto o una dimensione?
Se è una misura che varia continuamente nel
tempo è un fatto
analisi costo di un prodotto nel tempo
Se è una discrizione discreta di qualcosa che e’
ragionevolmente costante è un attributo di
una dimensione
costo di un prodotto come informazione descrittiva

33
Dimensioni

• Tipicamente le dimensioni sono:


– Tempo
– Collocazione geografica
– Organizzazione
– Clienti
• Il numero di attributi per ogni dimensione è in
genere molto elevato (centinaio)

34
Fatti

• I fatti sono tipicamente numerici addittivi


• Es. vendita in una catena di supermercati i
fatti possono essere
– N. prodotti venduti
– Incassi
– Costi
– …..

35
Addittività dei fatti

• Se i dati si possono aggregare sommando rispetto ad


ogni dimensione, sono detti addittivi (incassi totali)
• Se si possono aggregare sommando su alcune
dimensioni, ma non si possono aggregare
sommando su altre sono detti semiaddittivi (es. le
misure statiche come bilanci finanziari sono
semiaddittive rispetto al tempo)
• Se i fatti non si possono sommare sono detti non
addittivi (es. costi unitari non si possono aggregare
se prima non si moltiplicano per la unita’ vendute)

36
Gerarchie ed aggregati

• L’idea delle gerarchie é di aggregare


automaticamente i dati di interesse quando ci si
focalizza su un livello
Se ci concentriamo su “Mese” i fatti rappresentano i
totali delle vendite per ogni mese
• Possiamo concentrarci su diversi livelli della
gerarchia in dimensioni diverse
le vendite mensili per regione di ogni prodotto
• Gerarchia Tipica:
– Comune, Provincia, Regione,Stato, Continente

37
Esempio di Star Schema

Date Chiavi Esterne Product


Date ProductNo
Sales Fact Table ProdName
Month
Year Date ProdDesc
Category
Product QOH
Store Store
StoreID Cust
City Customer CustId
State unit_sales CustName
Country CustCity
Region dollar_sales
CustCountry
Yen_sales
Measurements La Fact Table è
normalizzata 38
Esempio di Snowflake
Schema
Year Product
Year Month
Date ProductNo
Month Sales Fact Table ProdName
Year Date ProdDesc
Date
Month Category
Product QOH
Store Store
Cust
City StoreID Customer
City CustId
City
State unit_sales CustName
State
CustCity
State dollar_sales
CustCountry
Country Country Yen_sales
Country
Region Measurements
39
Star Schema vs Snowflake
Schema
• Uno schema snowflake fattorizza di più e
quindi rende meno efficienti le operazioni di
ricerca (+ operazioni join)
• In genere si usa solo quando aumenta la
leggibilità dello schema e le prestazioni
globali

40
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 intersezione di ogni dimensione.
• Previsione, trend analysis, e statistical analysis.
• Calcola e visualizza i dati in 2D o 3D crosstabs, charts, e
grafi, with semplici operazioni di pivoting degli assi

41
OLAP: Data Cubes
All Products
Product
Milk Bread Orange … ... sum
January 96, Pisa.
Store Pisa
Roma Jan 96
Firenze
sum Feb 96
… ... Time
sum

Ogni dimensione contiene una gerarchia di valori


una cella del cubo contiene valori aggregati
(count, sum, max, etc.)
42
OLAP: esempi
Il manager regionale esamina Il manager finanziario esamina la vendita
la vendita dei prodotti dei prodotti in tutti i mercati relativamente
in tutti i periodi relativamente al periodo corrente e quello precedente
ai propri mercati

magazzino

tempo

prodotto

Il manager strategico si concentra su


Il manager di prodotto esamina
una categoria di prodotti,
la vendita di un prodotto
un’area regionale e un orizzonte
in tutti i periodo e in tutti i mercati
temporale medio
43
Operazioni tipiche
• Roll up: riassumi i dati
– il volume totale di vendite per categoria di
prodotto e per regione
• Roll down, drill down, drill through: passa da un
livello di dettaglio basso ad un livello di dettaglio
alto
– per un particolare prodotto, trova le vendite
dettagliate per ogni venditore e per ogni data
• Slice and dice: select & project
– Vendite delle bevande nel West negli ultimi 6
mesi
• Pivot: riorganizza il cubo
44
Operazioni tipiche: Pivot
Al All
Pivot l
Al All All
l
Pivot Drill-Down
Time
Al
l Product
Pivot
Time Drill-Down
Sto Product
re

Drill-Down
Time

45
Operazioni tipiche: Roll-Up
Re Product
gio
n

Roll-up
Year

Sto Product
r e
Drill-Down
Roll-up
Year

Sto Product
re

Drill-Down
Month
46
Operazioni tipiche: Slice and
Dice
Sto Product
re

Slice

Month
Sto Product
re

Month

47
ROLAP & MOLAP

ROLAP (Relational OLAP):


– utilizza le funzionalità di un’engine relazionale
• Tecnologia consolidata
• molto efficienti su dati di dettaglio
• estesi in modo da permettere la materializzazione degli aggregati
• performance
• scalabilità
• general-purposes
– fornisce ulteriori servizi OLAP services
• tools di disegno per schemi DSS
• permette di utilizzare performance analysis tools
– SQL strumento principale
– Queries difficili da formulare e possono essere time-
consuming
48
ROLAP & MOLAP
MOLAP (Multidimensional OLAP):
• Il modello di memorizzazione è un vettore
multidimensionale
• Queries multidimensionali si mappano sul server in
modo immediato
• Ma:
– Dati sparsi difficili da gestire
– Memoria sottoutilizzata
– … no join
– … no interfaccia SQL (API)
– … necessità sistema relazionale per dati dettaglio
– … file molto grandi
– … limitazioni a circa 10GB (problemi scalabilità)
49
DBMS multidimensionali

vendite prodotto mese magazzino

1 vino febbraio A magazzino


2 acqua febbraio B C
3 coca cola aprile A
B
4 acqua maggio A A
5 acqua settembre C
… … … ... feb
1 15 12
apr 9 7 3
tempo
mag 10 2 23
set 42 25 11
vino acqua coca cola
prodotto
50
ROLAP & MOLAP

• Performance
– Query: MOLAP
– Caricamento: ROLAP
• Analisi: MOLAP
• Dimensione DW: ROLAP
– MOLAP: problema sparsità
• Flessibilità nello schema: ROLAP
– MOLAP: minor numero di dimensioni ammesse

51
Metodologie di Progetto

La progettazione di un data warehouse è


diversa dalla progettazione di una base di
dati operazionale, infatti i dati da
memorizzare hanno caratteristiche diverse, si
è vincolati alle basi di dati esistenti.

52
Progettazione del Data
Warehouse

Attività principali:
– Requisiti utenti (interviste….)
– Analisi delle sorgenti informative esistenti
– Integrazione
– Progettazione concettuale, logica e fisica

53
Progettazione del Data
Warehouse
Analisi
Selezione delle sorgenti informative
Traduzione in un modello concettuale comune
Analisi delle sorgenti informative

Integrazione
Integrazione di schemi concettuali

Progettazione
Progettazione Concettuale
Progettazione Logica
Progettazione Fisica 54
Dati in ingresso

• Requisiti aziendali di analisi


• Descrizione delle basi di dati
• Descrizione di altre sorgenti informative (dati
ISTAT etc)

55
Fase di Analisi

• Selezione delle sorgenti informative


• Traduzione in un modello concettuale di
riferimento (integrazione tra schemi)
• Analisi delle sorgenti informative
(identificazione dei fatti, misure e dimensioni)

56
La fase di Integrazione

• E’ l’attività di fusione dei dati rappresentati in


più sorgenti in un’unica base dati globale.
• Lo scopo principale è l’identificazione di tutte
le porzioni delle sorgenti informative che si
riferiscono allo stesso aspetto e unificare la
loro rappresentazione
• Identificazione analisi e risoluzione di conflitti

57
La Fase di Progettazione

• La semplice integrazione non descrive tutti i


dati di interesse
• Progettazione:
– Concettuale - individuare concetti dimensionali
necessari per l’analisi
– Logica - identificare il miglior compromesso tra la
necessità di aggregare i dati e di normalizzarli
– Fisica - individuare la distribuzione dei dati e
relative strutture di accesso

58
Modelli dei Dati

• Le sorgenti informative possono essere varie: legacy,


relazionale, object-oriented, semistrutturato,
rappresentazione concettuale
• Per l’analisi e l’integrazione si fa riferimento al
modello Entità - Relazioni
• Per la progettazione si usa il modello logico per basi
di dati multidimensionali (MD)
• Per la realizzazione si fa riferimento al modello
relazionale (ROLAP) e ad un modello
multidimensionale generico (MOLAP)

59
Reverse Engineering

• Attività di comprensione concettuale di uno


schema di dati - da relazionale a concettuale
• Uno schema ER è più espressivo di uno
schema relazionale, ci vuole conoscenza di
dominio per recuperare la conoscenza persa
nella progettazione logica
• Il reverse engineering di schemi relazionali
viene fatto in modo semiautomatico da
strumenti CASE

60
Integrazione di sorgenti
informative
• E’ necessario risolvere i conflitti che nascono
dall’integrazione degli schemi. Sono dovuti
alla diversa rappresentazione
dell’informazione.
• Esempio: Nome e Cognome:
– “Mario”, “Rossi”
– “Mario Rossi”
– “Rossi Mario”
– “Rossi, M.”

61
Progettazione del DW e schemi
MD
• Introduzione di elementi dimensionali nella
base di dati integrata
• Identificazione di fatti, misure e dimensioni
• Ristrutturazione dello schema concettuale
– Rappresentazione dei fatti tramite entità
– Individuazione di nuove dimensioni
– Raffinamento dei livelli per ogni dimensione
• Grafo dimensionale
• Progettazione logica e fisica

62
Schema integrato ER

63
Grafo di derivazione di uno
schema dimensionale

64
La traduzione

• La dimensioni corrispondono agli ipernodi del


grafo
• Livelli e descrizioni corrispondono ai nodi
• Le funzioni di roll-up corrispondono agli archi
del grafo
• Le tabelle dei fatti sono derivabili dai nodi
fatto

65
Star Schema

66