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
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
Tr
s cti
r c ssi g syst
r tivi
s:
r i r c ssi
D cisi
rt syst
s:
ggr g ti st r
IN SINTESI ...
dati
DSS: Tecnologia che supporta la dirigenza aziendale nel prendere decisioni tattico-strategiche in modo migliore e pi veloce
6
PI FORMALMENTE ...
Sistemi tradizionali
On-Line
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
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
10
11
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
vendita,
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:
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
non
17
IL DATA WAREHOUSE
Fuori linea:
base
di dati operazionale: i dati venono acceduti, inseriti, modificati, cancellati pochi record alla volta data warehouse:
operazioni
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
devono
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
Front room
dw
23
Architettura ad un livello
acquisizione middleware
Back room
catalogo dei metadati
Dw virtuale
accesso
Front room
24
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
di memorizzazione i dati sorgente vengono trasformati tecnologia relazionale ma anche flat files
27
DATA WAREHOUSE
che permette la memorizzazione e la gestione del data warehouse, secondo un approccio dimensionale
28
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
Uso bimodale:
16-22
front room
2-8
back room
31
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
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
Supporto di tool di accesso: tool che permettono allutente di accedere in modo intuitivo ed altamente espressivo ai dati contenuti nel DW:
capacit
34
TOOL DI ACCESSO
Ad hoc
35
TOOL DI ACCESSO
DBMS Presentazione
Aggregate navigator
Traduzione in SQL
ODBC, JDBC
36
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
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
Tecnologia
Dati
Applicazioni
Attuazione Manutenzione
41
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
Progettazione concettuale
Progettazione logica
input:
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
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
44
Metadati
Strumenti ETL
45
Sorgente 2
Schema logico (locale)
Ricognizione e normalizzazione
Schema concettuale (locale) riconciliato Schema concettuale (globale) riconciliato
Metadati
46
47
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
49
ANALISI MULTIDIMENSIONALE
uanti items ho venduto per regione per mese per tipo di cliente? Tempo Prodotto Cliente Area geografica Dipartimento/settore
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
Progettazione concettuale
OLAP
magazzino
prodotto
54
PROGETTAZIONE CONCETTUALE
OLAP
Ogni parametro puo` essere organizzato in una gerarchia che ne rappresenta i possibili livelli di aggregazione:
negozio,
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
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
di fatto
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:
61
DIMENSIONI: ESEMPI
dimensioni: tempo, prodotti, magazzino dimensioni: tempo, prodotti, clienti, spedizioni dimensioni: tempo, facolt, tipologia studenti dimensioni: clienti, venditori, concorrenti, automobili, concessionarie
Attivit: ordini
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
63
LE DIMENSIONI
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
(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
misure: n. prodotti venduti, incassi, costi, ... misure: n. spedizioni, n. clienti, importi, ... misure: n. studenti,
Incasso, unit vendute: sono additive in uanto si possono aggregare sommando rispetto ad ogni dimensione:
somma
69
si
supponga che
clienti
numero di clienti che hanno comprato carne o pesce un ualun ue numero tra 30 e 50
70
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
Le misure non additive sono misure che non possono essere sommate Esempi:
misure:
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
prodotto
74
FATTI ANOMALI
fatti anomali
in uesto caso i fatti rappresentano semplicemente una relazione molti-a-molti, senza aggiungere alcuna nuova informazione Esempi:
dimensioni: corsi, professori, studenti, tempo dimensioni: ospedali, dottori, diagnosi, tempo, pazienti, assistenti, procedure
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
customer
id 53 81 111
c it y
r e gio n
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
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
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
84
importante considerare:
85
fatti
vengono
nuovi
campi
vengono
86
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
Unit Incasso
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
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
con lo stesso nome in fatti diversi hanno la stessa granularita` e le stesse unita` di misura
stesso
91
COSTELLAZIONE DI FATTI
Schema risultante:
costellazione
di fatti
92
DBMS informativo:
relazionale
94
DBMS RELAZIONALI
Tecnologia consolidata molto efficienti su dati di dettaglio estesi in modo da permettere la materializzazione degli aggregati
(Oracle
9i)
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
prodotto
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
97
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
Business Objects
98
Performance
Query: MOLAP Caricamento: 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
100
architettura a un livello:
ogni
101
PROGETTAZIONE LOGICA
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
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
105
ESEMPIO DI INSTANZA
product prodId p1 p2 name price bolt 10 nut 5
store storeId c1 c2 c3
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
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
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
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
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
115
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
Gli utenti finali e i tool di accesso devono generare codice differente in relazione che esistano o meno le tabelle agrgegate
discontinuit
delle applicazioni
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
Oltre a creare una relazione per ogni tabella, possibile rappresentare esplicitamente le gerarchie, utilizzando il concetto di DIMENSIONE
nuovo
119
DIMENSIONI IN ORACLE 9I
Oggetti che permettono di descrivere gerarchie esistenti allinterno delle tabelle vengono utilizzate per:
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
Caricamento:
Immediate:
(default)
Deferred:
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
utilizzata dallaggregate navigator in fase di riscrittura delle uery Disable: non utilizzata dallaggregate navigator in fase di riscrittura delle uery
127
128
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
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
Mercati
Quantit
Prodotti
Periodi di tempo
Vendite
134
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
Esempio:
determinare i 10 prodotti piu` venduti ad una certa data e in un certo magazzino, ordinati per vendite
138
Roll-up Product
Year
Year
Dipartimento
Panificio Panificio Cibo surgelato Cibo surgelato
Marca
Barilla Agnesi Findus Orogel
140
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
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
{PId, MId,TId}
In genere:
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
{}
144
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
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
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
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)
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
p1 p1 p2
155