Datawarehouse

L'ambiente del Data Warehouse
Lo scenario attuale nelle aziende di medie e grandi dimensioni rappresentato da un buon livello
di "meccanizzazione" delle attivit di routine della gestione aziendale (ciclo passivo: acquisti,
contabilit fornitori, pianificazione e controllo delle forniture; ciclo attivo: fatturazione, gestione
del credito, contabilit clienti). Questo, se ha portato uno sgravio nel lavoro quotidiano degli
impiegati, di fatto non ha rappresentato un reale vantaggio competitivo per l'azienda, la quale
deve sempre essere in grado di analizzare dinamicamente il mercato per capirne i meccanismi e
prevederne gli andamenti.
Sempre di pi quindi i manager, nella loro attivit decisionale, hanno necessit di accedere in
maniera tempestiva a informazioni di sintesi e di analisi dei dati prodotti dai sistemi gestionali.
La conseguenza immediata di ci il bisogno di far ricorso al personale del centro di calcolo che
in questo modo viene gravato da compiti che non riguardano direttamente la gestione del sistema
informativo.
Da qualche anno il mercato informatico ha recepito questa esigenza sviluppando delle soluzioni
dedicate ai decision maker aziendali per le loro attivit di carattere strategico: questi sistemi
vengono detti Decision Support System. Tali sistemi devono essere in grado di fornire in tempo
reale informazioni, rapporti e consentire analisi di varia natura (What If Analisys, On Line
Analitical Processing, Data Mining).
La What If Analisys permette previsioni basate su ipotesi sui dati futuri: ad esempio possiamo
prevedere cosa succede alla vendita dei coperchi se applichiamo uno sconto del 5% alle pentole
smaltate. L'On Line Analitical Processing mette a disposizione del manager un ambiente di dati
multidimensionale, nel quale pu eseguire ricerche aggregando i dati in suo possesso: possibile
ad esempio ottenere informazioni sulle vendite di prodotti alimentari avvenute in Veneto
nell'ultimo mese coinvolgendo le dimensioni del tempo, luogo e prodotti. Il Data Mining applica
tecniche di intelligenza artificiale agli archivi aziendali alla ricerca di quei dati che non sono
visibili in un primo istante perch immersi in una quantit enorme di dati simili.
Gli obiettivi che si prefiggono i DSS sono:
fornire un ambiente integrato nel quale sia possibile ottenere dati trasversali a tutte le
funzioni aziendali (produzione, amministrazione, finanza e controllo, marketing e
vendite),
ridurre il tempo di risposta alle query comunque complesse,
ottenere semplicit d'uso che produce l'indipendenza dei manager nell'uso dei dati,
mantenere la segretezza delle indagini dei manager.
L'infrastruttura dei DSS il Data Warehouse. L'idea del data warehouse letteralmente quella
di creare un ``magazzino di dati'' nel quale vengono registrati dati provenienti da molte fonti
correlate e/o non correlate tra di loro. Tale magazzino deve essere fisicamente indipendente dagli
altri archivi del sistema, perch l'attivit tipicamente molto pesante di interrogazione di un DSS
non deve inficiare le prestazioni generali del sistema informativo gestionale; inoltre deve
aggiornarsi solo nei momenti in cui le risorse di sistema sono meno utilizzate e deve essere
interrogabile ``liberamente''.
Interrogazione libera significa che non esiste uno schema predefinito di domande che possibile
istanziare ma l'utente che di volta in volta costruisce dinamicamente la propria interrogazione
con un'attivit di analisi. A differenza di quanto avviene invece nelle applicazioni tipiche dei
Data Base dove, escludendo interrogazioni ad-hoc scritte direttamente nei linguaggi dei DBMS
(Data Base Management System) dai DBA (Data Base Administrator), i moduli di inserimento
ed estrazione dei dati sono gi predefiniti (inserimento o stampa di un ordine cliente, di una
fattura, stampa di un report sugli ordini dell'ultimo mese, ecc.).
Se ci poniamo in una situazione reale di un manager che deve prendere una decisione vediamo
subito che la sua un'attivit di analisi, che innanzitutto cerca di trovare conferma ad un'ipotesi
che il suo fiuto imprenditoriale o la sua esperienza del mercato in cui opera gli ha suggerito.
Quindi evidente che per decidere dovr porre non una, ma un certo numero di interrogazioni ed
ottenere non una, ma un certo numero di risposte. Questo comporterebbe un lavoro eccessivo del
DBMS limitando di fatto il personale impiegatizio nello svolgimento delle proprie funzioni.
Bisogna riconoscere che il data warehouse non rappresenta una rivoluzione totale rispetto al
passato, ma sicuramente consente di ottimizzare la disponibilit di informazioni.
Definizione di Data Warehouse

La definizione di data warehouse fornitaci da W. H. Inmon, uno degli ideatori di questa
metodologia, la seguente[4]:
`ìl data warehouse una collezione di dati:
orientata al soggetto,
integrata,
non volatile,
dipendente dal tempo''.
Nei tradizionali database spesso ci troviamo davanti ad una struttura dati orientata ad ottimizzare
le operazioni che giornalmente pi volte sono necessarie nella gestione di un'azienda:
l'inserimento di un nuovo ordine o di una fattura, la registrazione dell'uscita di un prodotto, il
carico e scarico dei magazzini, ecc. Tali sistemi, proprio perch pensati per questo scopo, sono
detti operazionali oppure OLTP (On Line Transaction Processing). A differenza di questi un data
warehouse orientato ai soggetti che determinano le scelte dei manager, quali ad esempio: i
clienti, i fornitori, le vendite e gli acquisti. Il data warehouse permette di raggruppare e
confrontare i soggetti tra loro.
La pi importante delle caratteristiche di un data warehouse l'integrazione. Essa nasce dalla
necessit di dare coerenza ai dati provenienti da diverse applicazioni progettate per scopi diversi.
Poich i manager per poter prendere le loro decisioni abbisognano di ogni possibile fonte di dati
interna o esterna all'azienda, il problema da affrontare quello di rendere questi dati accessibili
ed omogenei in un unico ambiente, ma questo pone delle difficolt come quelle che si possono
vedere in fig. 1.1
Figure 1.1: Esempio di integrazione dei dati
Possono esistere quattro fonti di dati dove il sesso di un cliente stato memorizzato in modo
diverso: allora nel data warehouse bisogna decidere quale forma vogliamo tenere come valida e
di conseguenza bisogna codificare i dati provenienti dalle altre tre applicazioni prima di inserirli
nel data warehouse. Ovviamente le parti di codice che si occupano di trasformare i dati saranno
diverse per ciascuna sorgente.
Una situazione simile alla precedente si ha quando ad esempio applicazioni diverse misurano una
grandezza con unit di misura diverse: allora bisogna trasformare le misure incompatibili in una
che abbiamo scelto e definito come standard. Pi applicazioni possono contenere la descrizione
di un articolo ed in questo caso occorre decidere quale sia la descrizione pi completa da
memorizzare o se memorizzarle tutte in una sola. In applicazioni diverse gli attributi che si
riferiscono ad uno stesso argomento (come un codice articolo) possono essere stati definiti in
modo diverso, quindi bisogna scegliere il tipo pi adatto alla memorizzazione nel data
warehouse. Questi sono solo alcuni esempi dei problemi che si riscontrano nell'integrazione dei
dati.
La terza caratteristica che deve avere un data warehouse la non-volatilit, ossia i dati in esso
contenuti non devono poter essere cambiati dall'utente, questo perch il data warehouse viene
usato per fare indagini e non per inserire o modificare operazioni. Non nel data warehouse che
si va a modificare l'indirizzo di un cliente, anche perch in tal caso si perderebbe ogni
riferimento storico al fatto che il cliente ha cambiato indirizzo. I dati vengono caricati
solitamente in massa ed in modalit batch e successivamente acceduti dagli end-user.
L'ultima caratteristica importante di un data warehouse la dipendenza dal tempo. A differenza
dei database dove le operazioni direttamente accessibili, di solito, sono quelle degli ultimi 60-90
giorni, in un data warehouse l'intervallo temporale si allarga fino ad arrivare a coprire un arco di
5-10 anni. In ambiente operazionale il database contiene il ``valore corrente'' (ad esempio
l'indirizzo odierno di un fornitore) e questo dato pu essere modificato solo perdendo ogni
riferimento al dato precedente, mentre in un data warehouse i dati possono essere visti come
delle sofisticate foto istantanee (snapshot) fatte in determinati momenti, perci tengono conto
anche della storia dei soggetti. La struttura chiave di un sistema operazionale pu o meno
contenere degli elementi di tempo (anno, mese, data, ora , ... ), mentre quella di un data
warehouse deve sempre contenere qualche elemento di tempo.
Un data warehouse non solo un insieme di dati strutturati, ma piuttosto un sistema composto
anche da applicazioni che servono ad estrarre, analizzare e presentare i dati.
I dati presenti in un data warehouse devono essere consistenti. Questo significa che se due
persone interrogano l'archivio in momenti diversi per conoscere le vendite avvenute nel mese di
gennaio devono ottenere lo stesso risultato; inoltre se i dati di un determinato periodo per
qualche motivo non sono stati caricati completamente, l'utente che li richiede deve essere
avvisato che i dati che sta analizzando sono incompleti. Da ci si vede come risulti utile la figura
del responsabile della qualit dei dati pubblicati nel data warehouse che rende disponibili le
informazioni solo quando hanno sufficienti requisiti di analisi.
La struttura di un Data Warehouse

La figura 1.2 riporta un esempio della struttura tipica di un data warehouse. Essa si compone di
diversi livelli di dettaglio (detti anche summarization level).
Figure 1.2: Esempio di summarization dei dati
Partendo dal basso vediamo per primo un archivio di dati dettagliati dove sono registrati soggetti
che si riferiscono ad un tempo lontano; generalmente questi dati sono salvati su nastri, perch ,
essendo richiesti solo di rado, si considera accettabile un tempo di accesso pi elevato. Poi
troviamo i dati attuali ad un elevato livello di dettaglio: essi tengono conto di un periodo
relativamente breve. Quindi ci sono i dati ``leggermente riassunti'', ossia se ci si riferisce ad
esempio alle vendite anzich la quantit di prodotto venduta in un giorno, in questo archivio
potremo trovare la somma di ci che stato venduto in una settimana; a questo livello viene
trattato un periodo abbastanza lungo. Infine all'ultimo livello troviamo dei dati `àltamente
riassunti'', simili ai precedenti ma relativi a periodi di aggregazione e latenza pi lunghi. Ogni
livello di dettaglio viene ricavato a partire dal livello corrente. Una volta che i dati sono
`ìnvecchiati'' passano automaticamente agli altri livelli di dettaglio.
L'orientazione al soggetto
I soggetti vengono rappresentati a livello logico nel data warehouse con una serie di tabelle
collegate tra loro tramite relazioni.
I soggetti sono il fulcro delle operazioni di ricerca e confronto eseguite dagli utenti del data
warehouse. Essi vengono scelti in base al tipo di organizzazione aziendale ed al tipo di data
warehouse che si intende progettare. Alcuni esempi di soggetti sono i seguenti:
clienti,
vendite,
prodotti,
polizze,
reclami.
Come abbiamo appena notato relativamente ad un soggetto possono esserci pi tabelle

contenenti dati di epoche diverse a diversi livelli di aggregazione.
Siamo in presenza di un'organizzazione continua dei dati quando i dati di un livello di dettaglio
di un soggetto sono suddivisi su pi tabelle sulla base del tempo: ciascuna tabella contiene i dati
relativi ad un periodo diverso contiguo a quello di un'altra tabella.
Granularit
Per granularit si intende il livello di dettaglio dei dati salvati nel data warehouse. Pi alto il
livello di dettaglio e pi bassa la granularit e viceversa.
Essa il pi importante aspetto progettuale di cui bisogna tener conto, perch direttamente
legata al volume di dati salvato e, di conseguenza, alle prestazioni del sistema e alla necessit di
risorse hardware. Ovviamente bisogna scegliere il giusto livello di granularit per evitare di
memorizzare dettagli che non verranno mai presi in considerazione o non registrarne altri di
essenziali.
Spesso la soluzione sta nello scegliere pi livelli di granularit come mostrato in fig. 1.2. Questo
significa registrare fisicamente dati di dettaglio diverso in tabelle diverse. Così possibile
passare da una visione sintetica delle informazioni, ottenuta accedendo in un primo momento ai
dati altamente riassunti, ad una visione dettagliata, presa dalle tabelle a pi bassa granularit ,
ottimizzando così il numero di accessi ai supporti magnetici e l'uso del DBMS. Questo processo
detto Drill Down.
Partizionamento
Si ha un partizionamento dei dati quando quelli contenuti in una stessa struttura logica vengono
divisi in pi di una unit fisica ed inoltre un dato appartiene ad una ed una sola partizione.
Nel data warehouse la questione non se partizionare i dati, ma come partizionarli. Una volta
scelto il giusto livello di granularit occorrer scegliere come partizionare i dati in modo che
ciascuna unit fisica di dati possa essere manipolata indipendentemente dalle altre.
Lo sviluppatore deve scegliere se partizionare i dati a livello di sistema o di applicazione. La
partizione a livello di sistema una funzione del DBMS e del sistema operativo, mentre quella a
livello di applicazione contenuta nel codice della stessa applicazione e perci direttamente
controllata dallo sviluppatore. In questa seconda soluzione il DBMS non sa di alcuna relazione
esistente tra i dati partizionati a livello di applicazione.
Data la flessibilit che deve avere un data warehouse, acquista significato partizionare i dati a
livello di applicazione. La ragione pi importante che ci porta a questa scelta che per anni
diversi possono esserci diverse definizioni di un soggetto perch ad esempio nel frattempo le
esigenze degli utenti sono cambiate. Se il partizionamento venisse fatto a livello di sistema, il
DBMS esigerebbe una definizione di soggetto che rimanga inalterata nel tempo. Un cambio
verrebbe interpretato dal sistema come l'introduzione di un nuovo soggetto indipendente dal
precedente e quindi non riconducibile al primo nel caso di query che coinvolgano periodi a
cavallo tra le due definizioni.
Il partizionamento porta con s alcuni vantaggi: maggior facilit di creare indici, ristrutturare,
riorganizzare, recuperare i dati e monitorare le operazioni degli utenti.
Multidimensional DBMS e Data Warehouse

Per spiegare cosa sia un Multidimensional DBMS bene introdurre brevemente lo Star
Schema a cui dedicato un capitolo nel seguito.
Supponiamo di avere una catena di negozi di vendita al dettaglio della quale vogliamo gestire le
vendite e le condizioni d'indagine siano dettate dal tempo, i negozi, i prodotti e le promozioni.
Ogni giorno vengono registrate le vendite di ciascun prodotto. La struttura che immagazzina i
dati pu essere uno star schema come quello di fig. 1.3, dove la tabella VENDITE contiene
pochissimi attributi ma moltissime righe (una per ogni prodotto venduto ogni giorno in ciascun
negozio in qualsiasi condizione promozionale) e viene chiamata fact table; mentre le tabelle
Tempo, Negozi, Prodotti e Promozioni hanno moltissimi attributi, ma bassa cardinalit (al
confronto della fact table) e vengono chiamate dimension table.
Figure 1.3: Esempio base di Star Schema.
La fact table legata alle dimension table tramite delle chiavi esterne e l'insieme degli attributi
che sono chiavi esterne costituisce la chiave primaria della fact table.
Il nome dimension table si giustifica dal fatto che possiamo pensare ad una riga della fact table
come ad un elemento di un ipercubo le cui coordinate spaziali sono individuate dai singoli
elementi delle dimension table: un elemento per ciascuna dimension table. Possiamo pensare ad
esempio alla vendita di ``caramelle al limone'' del 23 dicembre 1998 nel negozio di Napoli sotto
la promozione ``Babbo Natale'': questo un elemento della fact table individuato da quattro
elementi dimensionali che sono la data, il prodotto, il negozio e la promozione. Nella fact table
relativamente a questo elemento saranno salvati per esempio la quantit venduta, il ricavo
ottenuto ed il numero di clienti che hanno effettuato questo acquisto.
Dopo questa breve introduzione possiamo dire che il Multidimensional DBMS un DBMS che
ottimizzato per l'uso di strutture simili a questa. Esso mette a disposizione dell'utente una
struttura che molto flessibile, soprattutto nell'analisi e la riorganizzazione dei dati nel passare
da un livello di dettaglio ad un altro anche creati ad-hoc al volo.
Spesso si dice che possibile applicare ad un ipercubo la tecnica dello slice and dice ossia
letteralmente dell'`àffettare e tagliare a dadini'' l'ipercubo, intendendo con questo che possibile
visualizzare parti della fact table selezionandole in base a qualsiasi range di valori di una o pi
dimensioni. Ad esempio possibile vedere quale sia stata la vendita di latticini nei negozi di
Milano, Roma e Napoli la seconda settimana di agosto del 1998 indipendentemente dalla
promozione presente in ciascun negozio in quel periodo; questo implica che i dati vengano
raggruppati e che vengano creati alcuni totali sommando i risultati di ciascun record appartenente
ai gruppi, il tutto nel giro di qualche secondo al massimo.
Esistono sostanzialmente due modi di pensare al data warehouse: uno secondo il quale
possibile basare tutto l'archivio su un Multidimensional DBMS ed un altro dove il data
warehouse fornisce il supporto dettagliato dal quale caricare i dati che alimentano il
Multidimensional DBMS. Noi ci atterremo al secondo. In questo modo possibile caricare il
MDBMS con dei dati leggermente riassunti e creare qualsivoglia livello di granularit in modo
molto efficiente; poi eventualmente i dati così ottenuti possono essere salvati nel data
warehouse.
In media un MDBMS contiene dati relativi agli ultimi 12 - 15 mesi mentre un data warehouse
allarga i suoi orizzonti a 5 - 10 anni. Ovviamente deve essere possibile navigare da un sistema
all'altro in modo indolore, ossia cominciare ad esempio una ricerca nel MDBMS e poi fare un
drill down nel data warehouse o fare l'operazione inversa, il tutto in modo trasparente per l'enduser.
Vi sono alcuni rischi nel realizzare un data warehouse utilizzando solo un MDBMS. Riferendoci
alla fig. 1.4 si pu vedere che, alimentando direttamente le strutture multidimensionali dalle
applicazioni legacy, il codice pu diventare ridondante perch le vendite possono richiedere
alcuni dati dall'applicazione A comuni al marketing e alla produzione: questo significa che
l'estrazione dei dati dai sistemi legacy pu avvenire pi volte, consumando di conseguenza pi
risorse. Il sistema risultante non completamente integrato perch ogni dipartimento ha la
propria interpretazione dei dati provenienti dall'ambiente operazionale. Il lavoro di progettazione
e manutenzione del data warehouse risulta complicato dalla dimensione e ridondanza del codice.
Figure 1.4: Relazioni tra le applicazione in ambiente legacy e pi strutture multidimensionali.
Data Warehouse e tecnologia
Per avere successo un data warehouse deve permettere un accesso ai dati intuitivo, facile e
praticamente immediato: per soddisfare queste propriet necessario che l'ambiente possieda
alcune caratteristiche tecnologiche che stanno prendendo piede in questi ultimi anni.
Innanzi tutto deve essere possibile indicizzare i dati in svariate maniere usando:
indici bit map,
indici a multilivello,
STARindexTM, ottimizzati per le strutture a star schema.
Deve inoltre essere possibile usare pi di un tipo di indice nella stessa query.
In linea di principio un bit map index viene costruito a partire da due o pi indici di una tabella,
ciascuno dei quali si riferisce ad un solo attributo. Quando viene istanziata una query, viene
posto a 1 un bit per ciascun indice su quelle righe dell'indice che soddisfano le condizioni della
query: in questo modo, se una query deve soddisfare delle condizioni poste su due o pi attributi,
le righe di risultato possono essere calcolate con l'ausilio di semplici operazioni logiche sulle
sequenze di bit ottenute dalla scansione parallela degli indici.
Come nei database anche nei data warehouse esistono gli indici a multilivello: essi sono degli
indici basati su due o pi attibuti di una tabella; ad esempio un indice di una tabella ordini clienti
pu essere fatto sul cognome, nome e numero d'ordine.
Gli STARindexTM vengono costruiti su una o pi chiavi esterne della fact table e contengono
informazioni che collegano i valori delle righe delle dimension table alle righe della fact table
che contengono i valori di quelle dimensioni. Lo scopo principale di uno STARindexTM quello
di ottimizzare il processo di join delle dimension table attraverso la fact table, evitando il
prodotto cartesiano delle dimension table che contiene valori privi di significato o non
interessanti. A differenza di un indice a multilivello che mette in relazione pi attributi di una
sola tabella, lo STARindexTM collega gli attributi della fact table a quelli delle dimension table.
L'ambiente di data warehouse deve essere in grado di tenere tutti o almeno parte degli indici
nella memoria principale per ridurre al minimo il numero di accessi ai dischi che, come vedremo,
sono il maggior fattore di rallentamento ai tempi di risposta ad una query. Deve supportare la
ricerca basata solo sugli indici, ossia, quando possibile, rispondere alle query usando solo gli
indici senza accedere alle tabelle.
Un data warehouse deve essere in grado di gestire l'immagazzinamento dei dati e la lettura in
modo parallelo su pi dispositivi: questo permette di abbassare in modo drastico i tempi di
accesso ai dati.
Le tabelle che ricevono meno accessi possono essere fisicamente salvate su supporti hardware
meno costosi ma pi lenti (nastri magnetici ad esempio); il DBMS che gestisce il data
warehouse che si occupa di ricercare ed estrarre i dati richiesti da supporti fisici anche se questi
sono di diversa natura.
Il linguaggio usato dal DBMS del data warehouse deve essere molto ricco e supportare
caratteristiche come:
accesso ad insiemi di record in una sola volta,
accesso ai singoli record,
uso di uno o pi indici per risolvere una query,
istruzioni specifiche per ottenere semplici informazioni statistiche e di analisi,
interfaccia SQL (Standard Query Language),
essere in grado di inserire, modificare e cancellare dati.
L'ambiente deve essere in grado di funzionare tanto in modalit interattiva che batch.
Poich il fulcro del calcolo dei tempi di accesso ai dati il numero di operazioni di I/O
(Input/Output) ai dispositivi di immagazzinamento e non l'uso delle CPU (Central Processing
Unit), la compattazione dei dati pu risultare molto utile. Il fattore che pi favorisce l'uso di
questa tecnica la permanenza dei dati ossia questi ultimi, una volta salvati, non vengono
modificati se non in casi eccezionali e solo dal Data Warehouse Administrator. L'overhead delle
CPU dovuto alla scompattazione piccolo se confrontato con i tempi necessari ad accedere ai
dispositivi.
Un data warehouse deve essere in grado di supportare dati a lunghezza variabile (i cosiddetti
blob data); la loro gestione favorita sempre dal fatto che i dati sono stabili una volta salvati.
Il Data Warehouse distribuito

La maggior parte delle organizzazioni mantiene un data warehouse centralizzato. Esiste cio un
server che contiene tutti i dati ed un DBMS che li gestisce: a questo server sono connessi molti
client su ognuno dei quali girano le applicazioni di reporting ed analisi. Le ragioni di questa
scelta tecnologica si possono riassumere così :
il data warehouse risulta integrato in ogni ambiente dell'organizzazione;
il volume di dati che contiene giustifica l'uso di un sistema centralizzato;
anche se i dati fossero integrati ma distribuiti in vari siti, potrebbe risultare piuttosto
difficile accedervi.
Il volume di dati che viene scambiato tra il DBMS e le applicazioni tale da favorire le reti
locali; sebbene in teoria sia possibile avere un client in Africa ed il server in Europa, i dati
scambiati tra le due macchine per un semplice report sono tali da poter impiegare parecchi
minuti prima di giungere a destinazione, malgrado siano stati ottenuti in pochissimi secondi:
questo causa di notevole frustrazione da parte dell'utente.
Ci sono casi per in cui pu risultare necessario costruire un data warehouse distribuito.
Figure 1.5: Esempio Data Warehouse distribuito
La fig. 1.5 mostra come possa esistere una realt nella quale insistono pi siti, ciascuno con un
suo ambiente operazionale, ed un data warehouse locale indipendente da tutti gli altri nel
funzionamento e nella struttura. Ciascun data warehouse locale viene alimentato da un ambiente
operazionale locale e quest'ultimo a sua volta alimenta anche un data warehouse globale che
contiene dati riguardanti tutti i settori dell'organizzazione. Con questa struttura non possibile
interrogare il data warehouse del sito C dal sito A. I dati contenuti nel data warehouse globale
non sono contenuti in nessun data warehouse locale e sono comuni a tutta l'organizzazione.
Poich la struttura del data warehouse globale definita centralmente, mentre la mappatura dei
dati che lo alimentano locale, possibile che dopo lo start up del progetto si verifichino
problemi di gestione del team di progetto, dal momento che i vari gruppi di lavoro che lo
compongono sono dislocati fisicamente in aree diverse. altrettanto possibile che con l'andare
del tempo il feedback agli sviluppatori locali porter alla stabilit dell'intero complesso.
In alcuni casi una copia limitata del data warehouse globale pu risiedere a livello locale per le
operazioni pi frequenti, in questi casi per bisogna fare molta attenzione all'allineamento dei
dati.
A differenza di un data warehouse centralizzato dove i dati dettagliati sono contenuti nel server
ed i dati di sintesi eventualmente stanno a livello locale nei client, in un data warehouse
distribuito la situazione si pu ribaltare: i dati dettagliati sono contenuti nei data warehouse locali
mentre quelli riassunti stanno nell'archivio globale, che centralizzato.
Un vantaggio di avere un data warehouse distribuito che le risorse hardware e software costano
meno perch si possono usare macchine e programmi meno complessi; se in un futuro ci si
avvicina ai limiti di capacit delle macchine si pu semplicemente aggiungere un nuovo server.
Occorre per tener presente che, ogni volta che si aggiunge un server, malgrado la capacit di
calcolo aumenti, contemporaneamente aumenta anche il traffico di rete e la difficolt di reperire i
dati di una query perch questi possono essere distribuiti su pi macchine. Perci , sebbene
l'intuito ci porti a pensare che l'aggiunta di un server aumenti le capacit del sistema e, di
conseguenza riduca i tempi di risposta, di fatto il sistema pu risultare pi lento.
Applicazioni del Data Warehouse

Un data warehouse nasce soprattutto come base di dati sulla quale fare ricerche e calcoli che
coinvolgono grandi quantit di dati. Come dicevamo prima, i tipi di ricerca che si possono fare
non sono predeterminati, ma l'utente che di volta in volta sceglie cosa cercare: perci occorre
mettere a sua disposizione una struttura semplice che gli permetta di muoversi tra i dati e
strumenti potenti che lo aiutino nelle analisi.
Per quanto riguarda la ricerca dei dati, i livelli di summarization permettono operazioni come il
Drill down ed il Drill up, mentre per le analisi su grandi quantitativi di dati troviamo l'OLAP
(On Line Analytical Processing) ed il Data Mining.
Operazioni di ricerca
Drill down
Drill up
On-Line Analytical Processing
Fast Analysis of Shared Multidimensional Information
Capire il concetto di multidimensionalit
Data Mining
Ambiente del Data Mining
Inductive learning
Machine learning
Modelli di Data Mining
Modello di verifica
Modello di scoperta
Funzioni del Data Mining
Classificazione
Associazioni
Modelli temporali
Raggruppamento e segmentazione
Operazioni di ricerca
Un data warehouse deve mettere a disposizione dell'end-user potenti strumenti di reporting che
gli consentano di cercare e confrontare i dati che sono disponibili nell'azienda. Questi strumenti
devono consentire le operazioni di drill down e drill up.
Drill down
Drill up
Drill down
L'operazione di drill down permette di partire da dati cumulativi altamente riassunti e scendere
nei dettagli passo per passo, attraversando vari livelli di summarization del data warehouse.
Un esempio pu rendere pi chiaro questo concetto. Supponiamo di avere un'azienda di latticini
e fare una ricerca che metta a confronto le vendite di yogurt di questo mese rispetto a quello
scorso, allora potremmo ottenere un report come quello di tab. 2.1.
Table 2.1: Dati altamente riassunti.

Prodotto
Regione
Questo mese
Confronto
Yogurt
Nord
110
12%
Yogurt
Centro
179
-3%
Yogurt
Sud
55
5%
Questi dati evidenziano una perdita nelle vendite nelle regioni centrali, a questo punto possiamo
cercare i motivi di queste perdite e scendere pi in dettaglio nella nostra ricerca aggiungendo il
nome degli agenti che distribuiscono i prodotti nelle varie zone. Il risultato pu essere quello di
tab. 2.2.
Table 2.2: Dati pi dettagliati dopo una singola operazione di drill down.
Prodotto
Regione
Agente
Questo mese
Confronto
Yogurt
Nord
Neri
52
21%
Yogurt
Nord
Bianchi
28
5%
Yogurt
Nord
Verdi
30
6%
Yogurt
Centro
Rossi
93
4%
Yogurt
Centro
Galli
75
5%
Yogurt
Centro
Pietri
11
-15%
Yogurt
Sud
Stani
25
5%
Yogurt
Sud
Gralli
30
6%
Gi a questo livello di dettaglio le eventuali decisioni di chi sta facendo le ricerche sono pi
chiare.
Pi precisamente si dice che si in presenza di un drill down quando l'interrogazione di un
utente passa da un livello alto di summarization ad uno pi basso attraversando tabelle diverse.
Drill up
Come si pu intuire questa l'operazione opposta alla precedente dove si passa da un livello
molto dettagliato ad una visione globale attraversando i livelli di summarization.
On-Line Analytical Processing

L'OLAP mira a fornire ai suoi utenti le caratteristiche di analisi che si trovano in un foglio
elettronico unitamente all'affidabilit di un database. OLAP permette una vista dei dati che va
oltre le due o tre dimensioni offerte dai fogli elettronici. Diversamente dai fogli elettronici i dati
possono essere condivisi tra molti utenti senza dover duplicare i file. In molti casi gli utenti
possono aggiungere o modificare i dati sotto il controllo del sistema senza comunque rischiare di
sovrascrivere l'informazione originale.
Le applicazioni OLAP sono caratterizzate dalla flessibilit con la quale gli utenti possono
ottenere varie viste dei dati o i report che essi vogliono per realizzare nuove analisi ad-hoc, per
eseguire calcoli complessi su larga scala e per ricercare dinamicamente eccezioni nei dati
contenuti nei database di grosse dimensioni.
Poich l'OLAP si rivolge soprattutto all'utente finale, deve presentare un'interfaccia semplice:
quella comunemente usata molto simile a quella dei fogli elettronici. D'altro canto gli strumenti
OLAP devono avere una buona integrazione con i sistemi che forniscono loro i dati. Alcuni
OLAP usano i loro database multidimensionali, altri si integrano con i database relazionali ed
altri ancora sono una forma ibrida che tiene alcuni dati in database multidimensionali ed accede
ad altri direttamente sugli archivi relazionali.

Queste cinque parole sono considerate una nuova definizione di OLAP. Pi in dettaglio
significano:
Fast: il sistema deve riuscire a rispondere alle interrogazioni in media in cinque secondi;
alle domande pi facili deve dare dei risultati in un secondo mentre a pochissime deve
rispondere in pi di 20 secondi.
Analysis: il sistema deve riuscire a fare analisi statistiche e di mercato in modo

abbastanza semplice per l'utente finale. Come minimo il sistema OLAP deve fornire la
possibilit di eseguire nuovi calcoli ad-hoc come parte di un'analisi, di restituire report
sui dati in ogni modo desiderato dall'utente senza che quest'ultimo debba inserire delle
linee di codice.
Shared: il sistema deve fornire tutti i requisiti di sicurezza affinch ognuno possa
accedere ai dati e, se possibile avere un accesso ai dati in scrittura da parte di pi utenti,
deve essere in grado di gestire la concorrenza.
Multidimensional: il requisito pi importante, l'essenza delle applicazioni OLAP. I

sistemi OLAP devono fornire una vista concettuale multidimensionale dei dati.
Information: tutto ci di cui necessita il sistema dovunque e comunque sia

immagazzinato, proveniente dai dati dettagliati o aggregati.
Le tecnologie per ottenere il FASMI includono architetture client-server, analisi di serie storiche,
orientazione agli oggetti, calcolo parallelo, modi proprietari ottimizzati di immagazzinamento
dati e multi-threading.

Il modello multidimensionale organizza i dati in termini delle dimensioni di mercato attuali
dell'azienda. Per esempio le vendite possono essere classificate per prodotto, cliente, periodo
storico, localizzazione, valore e quantit venduta. L'intersezione di tutte le dimensioni produce
una cella come nei fogli elettronici a due dimensioni. Sebbene questo tipo di dati possa essere
certamente immagazzinato in un database relazionale, l'SQL non il modo naturale di estrarre
informazione da una struttura multidimensionale.
Localizzare una cella in un database multidimensionale facile per l'utente e per il calcolatore
perch si conosce la posizione e non occorre ricorrere ad un indice, infatti le dimensioni ed i loro
range sono noti, ci che ignoto il dato contenuto nella cella, ma questo occupa uno spazio ed
una posizione ben definiti in memoria. questo il motivo che rende i database multidimensionali
pi facili da usare e aumenta notevolmente la resa nel manipolare dati multidimensionali in
confronto a quella che si ha con i database relazionali. Il prezzo da pagare la sparsity ossia la
presenza di moltissime celle con contenuto nullo. Ci accade per esempio perch in ciascun
periodo ogni cliente compera una piccola porzione dei prodotti disponibili (se non addirittura
niente). Nei modelli multidimensionali con molte dimensioni, la maggioranza delle celle non
conterr alcun dato. Perci il prezzo della velocit la memoria e viceversa.
Come nei fogli elettronici, ciascuna cella pu essere calcolata da formule che richiamano altre
celle. Nelle applicazioni di grandi dimensioni bisogna bilanciare bene l'uso delle risorse, perch
la maggior parte delle celle vengono calcolate a partiree da altre, quindi bisogna scegliere un
compromesso tra un calcolo in modalit batch, che salva i risultati in apposite tabelle (spreco di
spazio), ed un calcolo in tempo reale, che fornisce i risultati al volo (spreco di tempo e CPU). Il
vantaggio che si ottiene dalla prima soluzione la disponibilit di informazione derivata
accessibile in tempi brevissimi perch non deve essere calcolata on line ad ogni richiesta.
Gli utenti finali devono avere la possibilit di fare le analisi desiderate e navigare in tutte le
dimensioni dell'applicazione senza restrizioni sulle funzionalit di calcolo o di report e con
piccoli effetti sul rendimento del sistema.
Data Mining
Il termine Data Mining, che letteralmente significa `èstrarre dati'', citato in letteratura anche
come Knowledge Discovery in Databases (scoperta della ``conoscenza'' dai dati contenuti nei
database). Le definizioni di che cosa esattamente significhi anche qui si sprecano a seconda di
ci che ciascun produttore di software ci vuole vendere; di seguito ne sono riportate alcune:
Data Mining l'estrazione non banale di informazione potenzialmente utile, implicita e
sconosciuta in precedenza dai dati. Questo comporta un certo numero di approcci
tecnologici quali il raggruppamento (clustering), aggregazione dei dati, imparare regole
di classificazione, trovare reti di dipendenza, analizzare i cambiamenti, scovare
anomalie.
Williain J Frawley, Gregory Piatetsky-Shapiro e Christopher J Matheus.
Data Mining la ricerca di relazioni e modelli globali che esistono nei database
voluminosi ma sono nascosti nella vastit del numero di dati, come si verifica tra i dati
dei pazienti e le loro diagnosi mediche. Queste relazioni rappresentano una preziosa
conoscenza sul database e gli oggetti che esso contiene e se il database uno specchio
fedele della realt in esso registrata.
Marcel Holshemier & Arno Siebes (1994).
Data Mining significa `ùsare una variet di tecniche per identificare pepite di
informazione o conoscenza che permettono di prendere decisioni dal corpo dei dati ed
estrarre queste pepite in modo tale che possano essere poste in uso in aree quali il
supporto alle decisioni, la previsione e la stima. I dati spesso sono cos voluminosi che
non se ne pu fare un uso diretto ed l'informazione nascosta quella utile''.
Clementine User Guide, a data mining toolkit.
importante notare che nel data mining il computer che si occupa di trovare modelli dei dati,
identificandone regole e caratteristiche che li legano. Il processo di analisi parte da un insieme
limitato di dati e, usando una certa metodologia, cerca di sviluppare una rappresentazione
ottimale della struttura dei dati; durante questa fase il processo acquisisce conoscenza. Una volta
che tale conoscenza stata acquisita, questa pu essere estesa ad un insieme pi vasto di dati
basandosi sull'assunzione che il largo insieme di dati ha una struttura simile a quello pi
semplice.
Le fasi che portano dall'insieme dei dati grezzo all'estrazione della conoscenza possono essere
riassunte in cinque punti secondo Usama Fayyad & Evangelos Simoudis:
Selezione: selezione o segmentazione dei dati secondo alcuni criteri;
Preprocessing: ``pulizia'' dei dati da certe informazioni ritenute inutili e che possono
rallentare le future interrogazioni. In questa fase, inoltre, i dati possono essere trasformati
per evitare eventuali inconsistenze dovute al fatto che dati simili possono provenire da
sorgenti diverse e quindi con metadati leggermente diversi (ad esempio in un database il
sesso di una persona pu essere salvato come 'm' o 'f' ed in un altro come 0 o l);
Trasformazione: i dati non sono semplicemente trasferiti da un archivio ad uno nuovo,

ma sono trasformati in modo tale che sia possibile anche aggiungere informazione a
questi, come per esempio informazioni demografiche comunemente usate nella ricerca di
mercato. Quindi i dati vengono resi `ùsabili e navigabili'';
Data Mining: questo stadio si occupa di estrarre dei modelli dai dati. Un modello pu
essere definito come: dato un insieme di fatti (i dati) F, un linguaggio L ed alcune misure
di certezza C, un modello una dichiarazione S nel linguaggio L che descrive le relazioni
che esistono tra i dati di un sottoinsieme G di F con una certezza c tale che S sia pi
semplice in qualche modo della enumerazione dei fatti contenuti in G.
Interpretazione e valutazione: i modelli identificati dal sistema vengono interpretati

cosicch la conoscenza che se ne acquisisce pu essere di supporto alle decisioni, quali
ad esempio la previsione e classificazione dei compiti, il riassunto dei contenuti di un
database o la spiegazione dei fenomeni osservati.
Inductive learning
Machine learning
Modello di verifica
Modello di scoperta
Classificazione
Associazioni
Modelli temporali

Il data mining ha attratto attorno a s molti nuovi campi della Computer Science, tra questi
spiccano l'inductive learning e il machine learning.
Inductive learning
Machine learning
Inductive learning
L'inductive learning un processo che permette di costruire modelli di dati a partire dai dati
ricavati da un database. Oggetti con caratteristiche simili vengono raggruppati in classi e regole
attraverso le quali possibile prevedere a quale classe apparterr un nuovo oggetto. Il database
sul quale viene applicato questo processo un ambiente dinamico e di conseguenza il modello
d'induzione deve essere adattativo, deve cio essere in grado di imparare. Le strategie usate per
ottenere l'inductive learning sono sostanzialmente due:
supervised learning: il computer impara dagli esempi dove un insegnante aiuta il
sistema a costruire un modello definendo le classi e fornendo degli esempi. Il sistema

quindi deve trovare una descrizione per ciascuna classe, cio le propriet comuni presenti
negli esempi. Fatto questo il sistema si dedica agli oggetti che non ha ancora visto e
applica a questi le regole dedotte al passo precedente.
unsupervised learning: questo il modo di imparare attraverso l'osservazione e la

deduzione. Dapprima al data mining vengono forniti degli oggetti che sono solo
d'esempio, ma non si d nessuna definizione di classi: in questo modo il sistema deve
occuparsi di riconoscere le classi e dare le regole che le formano. Il risultato di questo
primo passo viene poi applicato al resto dell'archivio in esame.
Machine learning
Machine learning inteso come l'automazione del processo di apprendimento, dove
l'apprendimento il tentativo di ricavare regole dall'osservazione degli stati e delle transizioni di
stato dell'ambiente di impiego del software. Questo campo molto vasto e comprende anche
l'apprendimento dagli esempi, il rinforzo dell'apprendimento, l'apprendimento con insegnante,
ecc.
Un algoritmo d'apprendimento prende un dato da un insieme e l'informazione che a questo
connessa e d in uscita un concetto che rappresenta il risultato dell'apprendimento. Anche il
Machine learning prende spunto dagli esempi precedenti per creare delle generalizzazioni da
applicare ai nuovi casi.
Vediamo ora quali sono le differenze tra il data mining ed il machine learning:
lo scopo del data mining quello di scovare conoscenza in un insieme di dati, mentre
quello del machine learning quello di migliorare la resa di un qualche processo. Ne
segue che addestrare una rete neurale per bilanciare un palo fa parte del machine
learning, ma non del data mining.
il data mining si occupa di insiemi di dati molto voluminosi, mentre il machine learning
solitamente si limita a piccoli insiemi di dati, di conseguenza l'efficienza e la potenza di
calcolo sono pi importanti per il data mining.
il machine learning un vasto campo che non comprende solo l'apprendimento dagli
esempi, ma tutti i tipi di algoritmi di apprendimento.

IBM una delle pochissime grandi aziende informatiche che ha cominciato a scommettere nel
data mining ed ha identificato due modelli largamente usati nello sviluppo di applicativi: quello
di verifica e quello di scoperta.
Modello di verifica
Modello di scoperta
Modello di verifica
Il modello di verifica prende dall'utente un'ipotesi e ne verifica la validit nei dati. L'enfasi
posta sull'utente che genera le ipotesi. Il problema di questo modello il fatto che nessuna nuova
informazione viene creata, piuttosto tutte le interrogazioni daranno come risultato dei record che
confermano o negano le ipotesi poste. Il processo di ricerca iterativo: perci l'output viene via
via revisionato con un nuovo insieme di interrogazioni o ipotesi che raffinano la ricerca e l'intero
processo viene ripetuto.
Modello di scoperta
Qui l'enfasi posta sul sistema che in maniera automatica scopre importanti informazioni
nascoste nei dati. I dati vengono passati al setaccio alla ricerca di similitudini, tendenze e
generalizzazioni senza l'intervento o la guida dell'utente. Il data mining mira a rivelare molti fatti
che riguardano i dati nel tempo pi breve possibile.

I metodi usati dal data mining per estrarre la conoscenza sono descritti nelle seguenti sotto
sezioni.
Classificazione
Associazioni
Modelli temporali
Classificazione
Durante l'apprendimento delle regole di classificazione l'utente fornisce al sistema le condizioni
sui dati che definiscono ogni classe; il data mine quindi costruisce per ciascuna di queste una
descrizione che poi applica ai dati non ancora analizzati per dedurne la classe di appartenenza.
Una volta definite alcune classi il sistema in grado di dedurre le regole che governano la
classificazione e usando queste trova una descrizione per ogni classe. Una regola definita
corretta se la sua descrizione comprende tutti gli esempi dati dall'utente che appartengono ad una
classe ed esclude tutti quelli che non vi appartengono.
Una regola generalmente si presenta composta di due parti: una parte destra (RHS: Right Hand
Side) ed una parte sinistra (LHS: Left Hand Side); se vera la parte sinistra allora lo anche la
parte destra. Le regole si suddividono in tre categorie: regole esatte che non permettono
eccezioni; regole forti che permettono alcune eccezioni, ma queste ultime hanno un dato limite;
regole probabilistiche che mettono in relazione la probabilit condizionata P(RHS|LHS) con la
probabilit P(RHS).
Associazioni
Dati un certo numero di propriet ed un insieme di record, ognuno dei quali soddisfa alcune delle
propriet imposte, una funzione di associazione un'operazione che restituisce le affinit che
esistono tra le propriet selezionate. Le affinit possono essere espresse attraverso delle regole
quali: `ìl 72% dei record che soddisfano le propriet A, B e C soddisfano anche D ed E''. In
questo caso la percentuale risultante detta fattore di confidenza della regola.
Modelli temporali
In questo caso si analizzano i record inseriti in un certo arco di tempo per identificarne ad
esempio le tendenze. Per esempio si pu vedere quali siano gli acquisti che generalmente
precedono quello di un forno a microonde (dove l'identit dell'acquirente sia conosciuta) oppure
quali siano le richieste di indennizzo ad un'assicurazione con lo scopo di individuare sequenze di
esami medici che portano a migliori procedure di terapia o scovare possibili frodi da parte dei
clienti.
Raggruppamento e segmentazione sono processi di creazione di una partizione di tutti i membri
di ciascun insieme secondo una certa metrica. Un gruppo un insieme di oggetti che in qualche
modo sono simili tra loro. Spesso gli oggetti sono suddivisi in gruppi che possono anche essere
mutuamente esclusivi.
La chiave di lettura di questa metodologia quella di tradurre qualche misura di similitudine
intuitiva in una misura quantitativa. Quando viene usata la tecnologia unsupervised learning il
sistema deve automaticamente suddividere gli oggetti in classi, cio deve scoprire i sottoinsiemi
dagli esempi e trovare una descrizione che soddisfi ciascuno di questi sottoinsiemi.
La progettazione del Data Warehouse
Progetto di un Data Warehouse
Data Warehouse e modelli di dati
Entity Relationship Model
Data Item Set
Physical Data Model
Normalizzazione e denormalizzazione
Snapshot
Caricamento dei dati dal sistema operazionale
Integrazione dei dati
Problemi riscontrabili nell'integrazione dei dati
I metadati
La granularit in un Data Warehouse
Star Schema
Fact Table
Factless fact table
Dimension Table
Slowly changing dimension
Minidimension Table
Drill Across
Progetto di un Data Warehouse

Nel progetto di un'applicazione software generalmente si parte da un'analisi dei requisiti
dettagliata, costruita assieme al cliente, per passare poi alla fase di sviluppo. Questo richiede di
avere le idee chiare fin dall'inizio di ci che si vuole ottenere. Spesso invece nello sviluppo di un
data warehouse n i programmatori n gli end-user hanno chiaro quali siano gli usi finali
dell'applicazione, tanti sono i modi di impiego che pu avere.
La filosofia del progetto di un data warehouse riassunta nello slogan ``think big start small'',
ossia pensare a grandi progetti partendo con piccole realizzazioni. La strategia tipicamente usata
quella di partire dalle applicazioni operazionali gi esistenti ed integrarne i dati per un solo
soggetto d'indagine. Su questo soggetto alcuni utenti cominciano a lavorare e interrogare
l'archivio. In questo modo si crea curiosit sui possibili utilizzi del data warehouse. Una volta
che partito l'utilizzo allora nascono alcune esigenze da tradurre in applicazioni e la voglia di
estendere l'uso del data warehouse ad altri soggetti che di conseguenza portano all'espansione
dell'utenza e delle esigenze. Quando quasi tutti i soggetti sono stati individuati nasce l'esigenza di
specializzare il data warehouse per alcuni dipartimenti dell'azienda. Vengono cos creati i Data
Warehouse Dipartimentali, conosciuti anche come Data Mart, specializzati per l'uso in un solo
settore dell'azienda che pu essere ad esempio l'area marketing o l'area logistica. In questo modo,
solo quando tutti gli utenti possibili hanno messo mani sul data warehouse, si a conoscenza di
quali siano i requisiti dell'intera applicazione.
Un'altra strategia applicata quella di partire dai data mart, quindi con progetti pi piccoli
indipendenti, per poi arrivare alla loro integrazione in un data warehouse.
Entrambe le strategie richiedono tempi di sviluppo molto lunghi e collaborazioni molto strette tra
utenti e sviluppatori. Mediamente per lo sviluppo di un intero progetto di data warehouse si parla
di tempi che si prolungano per circa due anni. Ovviamente i primi livelli di sviluppo devono
essere molto rapidi, magari un po' rozzi ma devono permettere di creare un valido mezzo di
comunicazione tra utente e sviluppatore. Visti i tempi di sviluppo pare ovvia la filosofia
accennata prima dato che nessuna azienda sarebbe disposta ad enormi investimenti per lunghi
periodi senza avere la possibilit di vedere qualche risultato prima del completamento del
progetto.
Siccome gran parte della complessit di un progetto di data warehouse sta nel fatto che nessuno
ha ben chiaro all'inizio quali siano i requisiti che si vogliono ottenere dalle applicazioni che
usano i dati in esso contenuti, non possibile applicare le classiche tecniche di progettazione topdown o utilizzare dei CASE che facilitano il lavoro del progettista. Esistono strumenti di
sviluppo ma sono limitati a compiti ben precisi: la creazione delle tabelle, l'integrazione dei dati,
la preparazione di maschere e cos via.
Il progetto di un data warehouse richiede necessariamente l'impiego di un team di sviluppatori e
di conseguenza l'utilizzo di tecniche di software engeneering per facilitare il lavoro di squadra e
la successiva manutenzione del software creato.
Data Item Set
Physical Data Model
Snapshot
Caricamento dei dati dal sistema operazionale
I metadati

I modelli di dati usati per il progetto di un data warehouse non differiscono di molto da quelli
usati per un Data Base. Esistono tre livelli di modellazione:
di alto livello dove lo strumento usato l'Entity Relationship;
di medio livello dove si usano il DIS (Data Item Set) e lo Star Schema;
di basso livello chiamato anche modello fisico.
Data Item Set
Physical Data Model

La spiegazione di come si costruisce uno schema E-R si pu trovare in letteratura in molte fonti,
una delle quali riportata in bibliografia[3].
L'E-R viene usato per definire assieme agli end-user quali siano le entit che devono entrare a far
parte del data warehouse. Si definiscono vari schemi E-R per i vari settori dell'azienda a seconda
dei punti di vista di ciascuno degli end-user attraverso interviste e riunioni collettive. Quindi si
uniscono gli schemi ottenuti per ricavarne una descrizione complessiva dell'organizzazione che
soddisfi gli scopi supposti del data warehouse.
Una volta individuate le entit pi importanti del progetto, una piccola stima sulle istanze
riveler quali saranno le pi numerose, che verranno progettate usando una struttura a Star
schema, mentre per le altre entit si potr usare il DIS.
Data Item Set

Il DIS viene usato per identificare gli attributi dei dati e le relazioni che tra questi intercorrono.
A partire dallo schema E-R si va a particolareggiare ciascuna entit per definirne meglio gli
attributi e le associazioni con le altre entit. Esistono quattro costrutti che appartengono al data
item set:
gruppo primario di dati,
gruppo secondario di dati,
connettore,
``tipo di'' dati.
Per ciascuna entit individuata viene definito uno ed un solo gruppo primario di dati ed esso
contiene quegli attributi dell'entit che esistono una ed una sola volta per ciascuna istanza
dell'entit. Come tutti i gruppi di dati anche quello primario contiene attributi e chiavi.
Un gruppo secondario di dati contiene quegli attributi dell'entit che possono essere multipli per
ciascuna istanza di un'entit; ad esempio gli indirizzi che fanno capo ad un conto corrente
possono essere pi d'uno come in fig. 3.1. Un gruppo secondario legato a quello primario da
una linea verso il basso che parte dal gruppo primario e termina su quello secondario.
Figure 3.1: Le associazioni nello schema E-R si ritrovano nei connettori dello schema DIS. Il
gruppo primario nr. conto connesso al gruppo primario cliente.
Un connettore mette in relazione i dati provenienti da un gruppo primario e/o secondario a quelli
di un altro. In particolare un'associazione nello schema E-R si traduce in uno o due connettori
nel DIS, a seconda del tipo di associazione, come mostrato in fig. 3.1.
Il tipo di associazione E-R rappresentato in figura prevede a livello di DIS una coppia di
connettori, ma per brevit ne rappresentato in figura solo uno. Infatti come ad un numero di
conto possono essere associati pi clienti di una banca vero anche il viceversa, cio che un
cliente pu avere pi conti correnti presso la stessa banca. La convenzione usata per distinguere
un connettore la sottolineatura di una chiave esterna.
Il quarto costrutto serve a distinguere ci che definiamo super tipo da ci che un suo sotto tipo;
riferendoci ad esempio ad un conto corrente vogliamo distinguere quello che un conto per un
prestito da quello di un libretto di risparmio come in fig. 3.2. La convenzione usata per
distinguere i due tipi di dati una linea principale orizzontale che separa il super tipo a sinistra
dai suoi sotto tipi a destra. La fig. 3.2 la rappresentazione completa di un'entit CONTO
CORRENTE di uno schema E-R in uno schema DIS.
Figure 3.2: Esempio di DIS applicato all'entit CONTO
Una situazione interessante si presenta quando esistono due ``tipo di'' raggruppamenti come in
fig. 3.3. Un criterio di suddivisione dato dal ``tipo di'' operazione e l'altro dal ``tipo di''
sportello. In totale risultano quattro raggruppamenti delle operazioni di sportello: deposito
automatico, ritiro automatico, deposito dal cassiere e ritiro dal cassiere.
Figure 3.3: Esempio di DIS applicato alle attivit bancarie svolte allo sportello del cassiere ed a
quello automatico.
Physical Data Model

Il livello fisico nasce dall'estensione del livello medio aggiungendo le necessarie chiavi e le
caratteristiche fisiche al modello. Le caratteristiche fisiche del modello dei dati dipendono in
gran parte dal DBMS che intendiamo usare. Una volta sviluppato esso sar rappresentato da una
serie di tabelle.
In questo modello bisogna anche tener conto delle performance che vogliamo ottenere e di
conseguenza decidere il livello di granularit dei dati ed il loro partizionamento. Le
considerazioni si fanno soprattutto tenendo conto dell'uso delle risorse di I/O. L'obiettivo da
perseguire quello di ottenere il maggior numero di record ad ogni operazione di I/O; ossia di
trasferire in memoria un gruppo di record che ha un'alta probabilit di essere quello richiesto
dall'end-user in modo tale da ridurre il pi possibile il numero di I/O.
Il fatto che inoltre l'end-user non possa modificare i dati del data warehouse libera lo
sviluppatore da alcuni fattori di cui altrimenti dovrebbe tener conto, come ad esempio la
concorrenza che si potrebbe instaurare in un processo di scrittura o la scelta da parte dell'utente
di dove andare a salvare dei dati.
Il modello E-R ed il DIS per portano a tabelle altamente normalizzate il che va molto bene in un
ambiente operazionale dove le query coinvolgono poche tuple, ma in un data warehouse spesso
la normalizzazione porta a tempi di risposta insostenibili dovuti ai numerosi accessi ai dischi del
sistema. Quello che occorre cercare un compromesso tra la dimensione del data warehouse e le
prestazioni del sistema.
Una tecnica per ridurre il numero di I/O quella di registrare in un'unica riga vettori di dati.
Nelle ricerche dove il tempo una chiave importante capita spesso che vi siano sequenze di dati
che vengono richieste in successione (ad esempio le vendite giorno per giorno di una determinata
settimana), se i dati sono disponibili in una sola riga sufficiente una sola operazione di I/O per
ottenere tutte le informazioni che si vogliono.
Vediamo dall'esempio di fig. 3.4 come la denormalizzazione possa aiutare le operazioni di
lettura. Supponiamo che la descrizione di una parte di un prodotto sia registrata in una tabella:
ogni volta che il magazzino, le vendite o il ciclo produzione richiedono la descrizione della parte
devono fare due accessi (parte A della figura), mentre, se introduciamo ridondanza nei dati, i vari
reparti necessitano di un solo accesso alle risorse per ottenere la stessa informazione (parte B).
Figure 3.4: I dati normalizzati richiedono un I/O per la modifica e due per la lettura (A), mentre
la cosa si ribalta per i dati denormalizzati (B).
Come si pu notare dalla fig. 3.4 l'operazione di modifica risulta pi lenta e complessa, ma
questa viene fatta solo in casi eccezionali in modalit batch e per questo motivo il progettista pu
considerare valida la scelta della denormalizzazione.
Ovviamente avere dati ridondanti nel data warehouse porta ad uno spreco di risorse per quanto
riguarda le dimensioni dei file e questo il prezzo da pagare per ottenere migliori prestazioni nei
tempi di risposta all'end-user.
Snapshot
Sono un elemento chiave presente in ogni progetto di data warehouse. Si tratta di tabelle formate
sostanzialmente da quattro tipi di elementi:
elementi chiave: sono quelli che distinguono una tupla della tabella;
elementi di tempo: sempre presenti in uno snapshot;
elementi primari: i dati che portano l'informazione;
elementi secondari: opzionali, ma che aggiungono informazione e stabiliscono una

relazione con gli elementi primari.
L'aggiornamento di uno snapshot avviene in seguito al verificarsi di un evento sia esso

predeterminato nel tempo o no. Ad esempio, considerando il caso della vendita al dettaglio, uno
snapshot pu essere l'insieme delle vendite avvenute in un giorno diviso per prodotti: l'evento
determinato dall'ora di chiusura del negozio, l'elemento di tempo nella data che stiamo
considerando, elementi chiave possono essere l'insieme costituito da codice del prodotto e il
tempo, elementi primari il numero di prodotti venduti e il reddito proveniente da questa vendita,
infine elemento secondario pu essere un'informazione occasionale che si ottiene al momento
della vendita come la conoscenza della quantit di prodotto ancora presente in magazzino.
Uno snapshot pu aggiornarsi anche in seguito ad eventi non predeterminati nel tempo: ad
esempio in un magazzino pu avvenire quando un impiegato inserisce i dati relativi ad una
spedizione nell'ambiente operazionale.
Una volta che in uno snapshot sono stati inseriti anche elementi secondari, si viene a creare una
relazione di fatto tra i dati secondari ed i dati primari, ma non viceversa data l'opzionalit dei
secondari.
Caricamento dei dati dal sistema

operazionale
Esistono sostanzialmente tre tipi di operazioni per popolare un data warehouse a partire dai dati
dell'ambiente operazionale:
caricamento di dati d'archivio,
caricamento dei dati attualmente contenuti nell'ambiente operazionale
caricamento dei cambiamenti avvenuti nell'ambiente operazionale dall'ultimo refresh dei

dati avvenuto nel data warehouse.
Le prime due operazioni vengono fatte una volta per tutte e perci non rappresentano una grossa
difficolt n nell'uso delle risorse n nella scrittura del codice. La terza operazione invece
quella dove si devono maggiormente concentrare gli sforzi dello sviluppatore. Esistono cinque
tecniche usate per limitare la quantit di dati manipolata durante l'aggiornamento della
popolazione del data warehouse.
La prima tecnica utilizzabile laddove l'applicazione dell'ambiente operazionale inserisce in
ogni suo record un elemento di tempo; l'aggiornamento del data warehouse avviene in base alla
precedente data di aggiornamento: in pratica viene eseguita una scansione dell'archivio
operazionale alla ricerca dei record che hanno data successiva al precedente aggiornamento.
Una seconda tecnica si basa su un principio differenziale dove viene costruito un ``delta file''
contenente solo i dati che sono stati modificati dall'applicazione a partire dall'ultimo
aggiornamento. Questa tecnica molto efficiente, ma non tutte le applicazioni permettono di
usarla.
La terza tecnica consiste nell'osservazione dei file di log per determinare quali siano le modifiche
avvenute. Questa tecnica per presenta delle difficolt. In primo luogo perch le applicazioni
proteggono i file di log per poter essere usati in caso di necessit di recupero dei dati. In secondo
luogo perch il formato interno dei file di log scritto per la specifica applicazione e scrivere un
driver di filtro dal file di log al data warehouse pu risultare difficoltoso. In terzo luogo perch il
file di log in genere contiene molte informazioni in pi rispetto a quelle strettamente necessarie
all'operazione di popolamento del data warehouse.
La quarta tecnica consiste nel modificare il codice delle applicazione dell'ambiente operazionale,
ma non praticamente mai usata.
L'ultima tecnica, usata solo come ultima risorsa, quella di creare ad ogni aggiornamento
un'`ìstantanea'' del database e quindi confrontare in modo seriale l'immagine ``precedente'' con
quella `àttuale'' per determinare i record da inserire nel data warehouse. Questa tecnica per
ingombrante, complessa ed occupa una smisurata quantit di risorse.
Altra cosa che bisogna considerare il fatto che i dati contenuti nel data warehouse non possono
essere modificati, perci i dati modificati provenienti dall'ambiente operazionale devono essere
inseriti come nuovi record nel data warehouse a cui vengono aggiunti degli attributi di tempo per
distinguerli da quelli sullo stesso argomento precedentemente salvati.

Nel seguito sono riportati alcuni dei problemi che sorgono quando si vuole passare da un
ambiente operazionale tipicamente legacy ad un ambiente decisionale montato generalmente su
di un DBMS che pu essere relazionale.
Il DBMS relazionale sembra essere quello di maggior successo nello sviluppo di un data
warehouse; alcuni dei motivi che portano alla scelta di un relazionale sono la stabilit provata da
questi sistemi e la certezza che nelle future applicazioni saranno supportati da driver che
permetteranno abbastanza facilmente la migrazione verso i nuovi ambienti, cose che i sistemi
legacy per ora hanno difficilmente permesso.
L'estrazione dei dati dall'ambiente operazionale implica un cambio di tecnologia per

andare verso il data warehouse: spesso si tratta di spostare i dati verso DBMS diversi.
Come visto in precedenza difficile selezionare i dati che vogliamo di volta in volta
caricare.
Le chiavi di identificazione dei record dell'ambiente operazionale devono essere

ristrutturate per rientrare nella struttura del data warehouse. Spesso si tratta solamente di
aggiungere un elemento di tempo, ma l'operazione pu essere anche pi complessa.
I dati stessi devono essere ristrutturati (vedi fig. 1.1).
Alcuni dati devono essere eliminati al momento dell'aggiornamento del data warehouse.
Spesso non ha senso caricare il data warehouse con tutti i dati dell'ambiente operazionale.
Possono esistere pi fonti di dati per un solo elemento del data warehouse, bisogna allora
aggiungere della logica al processo di aggiornamento che di volta in volta scelga la fonte
pi opportuna.
Devono essere prodotti dati a vari livelli di aggregazione.
Sotto certe condizioni devono essere aggiunti dei valori di default ai dati estratti.
Sono necessarie conversioni spesso non banali dei dati per passare da un ambiente legacy
ad un data warehouse.
Dato il volume di dati che viene coinvolto nelle operazioni di aggiornamento, spesso
occorre far ricorso a speciali opzioni di progetto come il calcolo parallelo e la lettura
parallela dei dati da risorse diverse.
Nelle varie fasi dello sviluppo di un data warehouse le specifiche di aggiornamento

possono cambiare pi volte: di conseguenza pu esserci del software che viene creato ma
non documentato e questo pu creare problemi di sviluppo e manutenzione.
Gli scopi e le strutture del data warehouse sono diversi da quelli dell'ambiente
operazionale che lo alimenta.
I metadati
In un ambiente di data warehouse i metadati giocano un ruolo di primo piano, essi sono utili sia
allo sviluppatore che all'end-user/analista. Allo sviluppatore servono come prima
documentazione della struttura del data warehouse e dei processi di trasformazione che
subiscono i dati, all'analista servono a capire come sono stati ottenuti i dati salvati nel data
warehouse e quindi a formulare in modo pi preciso le sue interrogazioni.
Tipicamente i metadati tengono conto di:
struttura dei dati,
sorgente dei dati,
trasformazioni che i dati subiscono nel passaggio tra i due ambienti,
modello dei dati,
routine utilizzate per accedere ai dati,
cambiamenti subiti dalle strutture, le sorgenti, le routine ed il modello dei dati.
Tutte queste informazioni se accessibili a tutti i tipi di utenza in modo esplicito aiutano sia nelle
ricerche ed analisi dei dati in archivio che nello sviluppo delle applicazioni.

Come stato accennato prima necessario fare una stima delle occorrenze di ciascuna entit nel
progetto di un data warehouse. Questo sia per sapere di quali risorse si necessita sia per scoprire i
tempi di risposta e vedere se sono compatibili con le aspettative dell'end-user. In particolare
bisogna vedere se necessario riassumere alcuni dati e in quale modo farlo per riuscire a
soddisfare il compromesso tra la necessit informativa dell'end-user e l'occupazione di risorse. A
tal proposito bene pensare ad un data warehouse come ad un magazzino: ciascun dato occupa
del posto, quindi costa, perci i dati inutili vanno gettati o compattati.
Al massimo livello di dettaglio un rivenditore al dettaglio pu disporre di ciascuna vendita
avvenuta in funzione delle voci di tutti gli scontrini che sono stati emessi in tutte le casse (POS:
Point Of Sail). Un livello di summarization in questo caso l'aggregazione dei dati dei POS nella
quantit di ciascun prodotto venduta ogni giorno; un livello ancora pi alto di granularit lo
otteniamo nelle vendite settimanali e cos via. In questo modo si possono ottenere varie tabelle
interrogabili separatamente per raggiungere tempi di risposta ottimali.
La questione pi importante da risolvere nel progetto del data warehouse quanti e quali livelli
di granularit deve supportare la struttura. Bisogna tener conto del tipo di informazione che si
cerca pi spesso, delle istanze delle entit e delle risorse a nostra disposizione. In nostro aiuto
pu venire la fig. 3.5 dove si nota come al crescere delle istanze opportuno creare pi livelli di
granularit.
Figure 3.5: Soglie oltre le quali occorre attuare un progetto a pi livelli di granularit a seconda
delle occorrenze stimate nell'arco di un anno e di 5 anni.
Ovviamente a partire da un solo livello di granularit possibile ottenere on-line tutti gli altri,
ma questa operazione spreca moltissime risorse, perci pu essere usato un solo livello di
granularit laddove il numero di occorrenze di un'entit limitato. Bisogna poi tener conto
dell'arco di tempo che si vuole tenere on-line nel data warehouse, perch pi lungo e pi
probabile che sia necessario usare pi livelli di granularit.
interessante far notare che il livello di granularit dipende dal numero dei record e non dalla
loro dimensione: infatti, indipendentemente da quanto spazio un singolo record occupa, il
numero di accessi agli indici ed alle tabelle lo stesso; solo se i record sono eccezionalmente
grandi si potranno avere pi accessi alle risorse I/O per ottenerne uno.
Per determinare quale sia il giusto livello di granularit da applicare ad un progetto si mettono a
disposizione dell'utente finale i dati con un'applicazione di prova e tramite monitoraggi ed
interviste si stabilisce quale sia il livello di dettaglio da implementare.
Star Schema
Il nome star schema viene dalla vaga somiglianza che un diagramma a molte dimensioni ha con
il classico disegno di una stella come si pu vedere dalla fig. 4.1.
Lo schema composto da una tabella centrale detta fact table unita a molte altre tabelle dette
dimension table. La fact table l'unica ad avere join multiple con altre tabelle, mentre le
dimension table sono unite alla sola fact table.
Figure 4.1: Esempio di semplice Star Schema
Fact Table
Factless fact table
Dimension Table
Minidimension Table
Drill Across
Fact Table
La fact table il luogo ove vengono registrate le cosiddette misure di mercato, ossia gli elementi
d'indagine che variano in continuazione nell'entit che stiamo considerando. Esempi di misure di
mercato sono: il prezzo unitario di un prodotto, la quantit venduta, il costo del prodotto, ecc.
La chiave primaria di una fact table composta da tutte le chiavi esterne che la legano alle
dimension table. Se ne deduce che ogni record della fact table individuato dai record delle
dimension table: uno per ogni tabella dimensionale. Pensando allo star schema come ad un
grafico multidimensionale, ciascun record della fact table si trova in un punto le cui coordinate,
finite e discrete, sono determinate da un elemento preso da ciascuna dimensione. Un record della
fact table allora contiene le sue coordinate e le misure di mercato riferite a quel punto.
Ciascun attributo della fact table chiamato fatto. I fatti si suddividono in: additivi, semiadditivi
e non additivi. I primi godono della propriet di poter essere sommati lungo qualsiasi
dimensione, ossia comunque si aggreghino i record della fact table il contenuto di quell'attributo
pu essere sommato ottenendo un risultato utile e significativo: ad esempio, considerando la fig.
4.1, il reddito proveniente dalle vendite (dollar_sales) additivo, perch lungo qualsiasi
dimensione possiamo fare dei raggruppamenti ed ottenere il reddito totale delle vendite di quel
gruppo. I fatti semiadditivi invece sono additivi solo lungo alcune dimensioni e quelli non
additivi ovviamente non sono additivi lungo alcuna dimensione.
La fact table risulta essere fortemente normalizzata, perch contiene solamente la chiave
primaria e i pochi attributi che variano nel tempo che costituiscono i fatti salienti delle indagini.
Di solito una fact table viene aggiornata giornalmente: per questa ragione, se l'arco di tempo che
contiene di qualche anno, il numero dei suoi record pu raggiungere e superare qualche
milione. Bisogna allora porre particolare attenzione nella progettazione di questa tabella,
soprattutto nella scelta del tipo di campi che vogliamo salvare e degli indici che permetteranno
l'accesso selezionato. Si prediligono i campi di dimensione ridotta e gli indici di tipo bit map.
Factless fact table
Factless fact table

Le factless fact table sono fact table che non registrano alcun fatto, ma sono usate unicamente
per mettere in relazione tra loro gli elementi di dimensioni diverse. In fig. 4.2 riportato un
esempio in cui viene rappresentata la presenza ai corsi universitari. Usando questo schema
possibile stabilire la presenza media ad un corso, quanti corsi frequenta uno studente, quali corsi
tiene un docente, ecc.
Figure 4.2: Esempio di factless fact table.
Ciascun record della tabella registra l'esistenza di una relazione tra gli elementi delle dimension
table presi da ciascuna dimensione, ossia l'esistenza di un determinato punto dell'iperspazio di
riferimento. Ad esempio un record potrebbe registrare la presenza dello studente Tizio alla
lezione tenuta dal prof. Caio il 23 marzo del '99. Non tutti i punti dell'iperspazio di fig. 4.2
corrispondono infatti ad un evento reale, altrimenti ciascuno studente dovrebbe essere
contemporaneamente presente ad ogni corso o ugualmente ciascun docente dovrebbe insegnare
in tutti i corsi ogni giorno.
Da questo tipo di tabelle spesso vengono ricavate quelle che sono chiamate coverage table, che
sono tabelle di copertura di tutti gli elementi che soddisfano determinate propriet . Ad esempio
pu accadere che un prodotto dell'esempio di fig. 4.1 sia in promozione, ma non venga venduto.
La fact table di fig. 4.1 non tiene traccia di questo prodotto e del fatto che sia in promozione: se
invece aggiungiamo al nostro progetto una factless fact table ricavata da quella di fig. 4.1,
possiamo determinare tutti i prodotti in promozione in una assegnata settimana in un determinato
negozio e, mettendoli a confronto con quelli che sono stati venduti, possiamo ricavare quelli che
sono rimasti invenduti. Allora possiamo vedere che l'uso combinato di fact table e factless fact
table porta ad un allargamento degli orizzonti d'indagine.
Dimension Table
Le dimension table contengono le descrizioni delle dimensioni di mercato. Per esempio
possiamo trovare in una dimension table la completa definizione di un prodotto con tutti i suoi
attributi. I migliori attributi sono quelli testuali che possono essere usati come sorgente di
restrizioni nelle query degli utenti o come intestazioni degli insiemi di risposta agli end-user.
La chiave primaria di una dimension table composta da un solo attributo (a differenza di quella
di una fact table che composita) che si ripete come chiave esterna nella fact table.
Non possibile mettere direttamente in relazione tra loro due dimension table e spesso non ha
neanche senso cercare di connettere due dimensioni perch riguardano argomenti completamente
diversi; la loro unione acquista significato solo attraverso il verificarsi di un fatto.
Spesso non chiaro se un attributo deve appartenere ad una dimensione o essere considerato
come fatto e, per decidere da quale parte dello star schema debba andare, bisogna vedere se
questo attributo varia ``rapidamente'' nel tempo, nel qual caso un fatto. Un esempio tipico il
prezzo di un prodotto che, sebbene sembri costante per lunghi periodi, quasi sempre
considerato un fatto.
In una ricerca che coinvolge uno star schema importante che prima vengano scandite le
dimension table per determinare quali elementi soddisfino le caratteristiche selezionate e poi la
fact table per ricavare i risultati cercati. Il DBMS deve essere forzato a lavorare in questo modo
per evitare di accedere alla tabella pi numerosa finch non si sono determinate le condizioni di
selezione dei record.
Le dimension table sono denormalizzate perch sono quelle che subiscono pi accessi in lettura
e, come abbiamo visto prima, sebbene i dati siano ridondanti, risultano molto pi rapidi i tempi
di risposta; inoltre il risparmio di spazio che si ottiene dalla loro normalizzazione mediamente
inferiore all'uno per cento, data la differenza di dimensione dei file che contengono la fact table
rispetto a quelli che contengono le dimension table.
Minidimension Table

I valori di alcuni attributi dei record appartenenti ad una dimension table cambiano nel tempo, se
il cambiamento rapido pu essere ritenuto un fatto e quindi salvato nella fact table, ma se non
lo , siamo in presenza di una slowly changing dimension.
Ci sono tre soluzioni possibili in questi casi:
si sovrascrivono i vecchi valori perdendo ogni riferimento storico dei cambiamenti subiti
dall'elemento;
si crea un nuovo record nella dimension table al momento del cambiamento sul quale
vengono riportati i valori mutati e quelli stabili;
si creano degli attributi nella dimension table che tengono conto dei valori correnti e dei
valori passati.
Il primo metodo quello che sicuramente permette di ottenere file pi ridotti, ma non permette di
fare alcuna indagine storica sui cambiamenti subiti dall'elemento.
Il secondo il pi completo, perch permette di navigare avanti ed indietro nella storia
dell'elemento, ma quello che porta ad uno spreco maggiore di spazio. Per mantenere i
riferimenti tra le descrizioni di un elemento sufficiente aggiungere una o pi cifre di ``versione''
alla chiave della dimension table: in questo modo le descrizioni di un elemento avranno tutte una
base comune di codice e delle cifre diverse di versione. interessante notare che non occorre
aggiungere attributi di tempo alla tabella delle dimensioni per tener conto di quando un elemento
cambiato, perch questa tecnica porta inevitabilmente ad una partizione della fact table nella
quale tutti i record precedenti alla data di cambiamento di stato saranno riferiti alla versione
precedente dell'elemento, mentre tutti i record correnti saranno legati alla versione corrente.
Così attraverso la fact table possiamo risalire alla storia degli elementi.
Il terzo metodo tiene conto di un solo cambiamento. Nelle dimension tablevengono aggiunti gli
attributi che conterranno i valori precedenti dell'elemento e quelli con le date dell'effettivo
cambiamento. Così , se una dimension table del cliente registra il suo stato civile, conterr un
attributo stato_civile_originale, uno stato_civile_corrente ed uno data_cambio_stato_civile.
ovvio che in questo modo possiamo risalire solo all'ultimo cambiamento subito dall'elemento. Se
la tabella molto popolata e pochi elementi cambiano, questa ristrutturazione porta ad uno
spreco di spazio notevole dato che anche i record che non vengono cambiati possederanno i
nuovi attributi, che in questi ultimi record saranno ovviamente nulli.
Minidimension Table
Nelle dimensioni che contengono molti elementi spesso torna utile il raggruppamento di questi
attraverso caratteristiche che sono loro comuni. Se ad esempio abbiamo una tabella clienti come
in fig. 4.3, i loro dati demografici possono essere usati come base per le indagini di mercato:
infatti spesso pi interessante sapere cosa comperano le donne nubili piuttosto di cosa ha
comperato Anna Bianchi.
I tipi di raggruppamenti possibili possono essere raccolti in tabelle che prendono il nome di
minidimension table. Una minidimension table connessa alla fact table ed alla dimension table
attraverso una chiave esterna (minidimension key) come in fig. 4.3. Per facilitare l'accesso alla
fact table pu essere costruito un indice che include la minidimension key: questo permette di
evitare di selezionare prima gli elementi della dimensione che appartengono al gruppo scelto per
poi fare una ricerca nella fact table.
Figure 4.3: Esempio di uso delle Minidimension Table.
Le minidimension possono tornare utili nelle slowly changing dimension perch spesso sono loro
che contengono gli attributi che possono variare nel tempo, così sufficiente cambiare la
minidimension key del record della dimensione per salvare il cambiamento di stato dell'elemento
ed associarlo al nuovo gruppo di appartenenza. In questo modo non si aggiungono nuovi record
alla dimension table ed allo stesso tempo possibile risalire alla storia dell'elemento facendo
ricorso ai record nella fact table che contengono la chiave dell'elemento in esame e guardando
come la minidimension key variata nel tempo, perch , come nel caso dell'aggiunta di un record
con la nuova versione, la fact table viene ad essere partizionata dai valori della minidimension
key.
Drill Across
Se in un data warehouse sono presenti due o pi entit sviluppate con l'ausilio dello star schema
e queste condividono due o pi dimensioni possibile eseguire l'operazione di drill across. Essa
consiste nella possibilit di produrre report che uniscono le due entit attraverso le fact table
definendo ovviamente per entrambe le tabelle gli stessi valori di selezione nelle dimensioni
comuni.
Lo Yield Management per una catena di hotel
Esperienza di data warehouse
Lo Yield Management
La base di dati di partenza
Lo schema proposto
Lo schema E-R della PRENOTAZIONE
Lo star schema delle Prenotazioni
Gli strumenti utilizzati
Gli strumenti sul mercato
DB2TM
Cosa gestisce
Cosa non gestisce
Oracle 8iTM
Cosa gestisce
Cosa non gestisce
SQL Server 7.0TM
Cosa gestisce
Cosa non gestisce
SAS WarehouseTM
Cosa gestisce
Cosa non gestisce
La prova di Miner DataTM
Conclusioni
Codice di creazione tabelle
Creazione della tabella Agenti
Creazione della tabella Cat_camere
Creazione della tabella Clienti
Creazione della tabella Hotel
Creazione della tabella Tempo
Creazione della tabella Prenotazioni
Codice di importazione dati
Importazione dati nella tabella Agenti
Importazione dati nella tabella Cat_camere
Importazione dati nella tabella Clienti
Importazione dati nella tabella Hotel
Importazione dati nella tabella Tempo
Aggiornamento della tabella Tempo
Importazione dati nella tabella Prenotazioni
Codice dei test
Semplici test sullo star schema
Lo Yield Management
Lo schema proposto
DB2TM
Cosa gestisce
Cosa non gestisce
Oracle 8iTM
Cosa gestisce
Cosa non gestisce
SQL Server 7.0TM
Cosa gestisce
Cosa non gestisce
SAS WarehouseTM
Cosa gestisce
Cosa non gestisce
Lo Yield Management
Lo schema proposto
DB2TM
Cosa gestisce
Cosa non gestisce
Oracle 8iTM
Cosa gestisce
Cosa non gestisce
SQL Server 7.0TM
Cosa gestisce
Cosa non gestisce
SAS WarehouseTM
Cosa gestisce
Cosa non gestisce
Lo Yield Management
I termini ``Yield Management'' (letteralmente gestione dei redditi) sono stati coniati nell'ambito
della gestione delle linee aeree ed hanno come obiettivo il massimizzare i guadagni che possono
pervenire su un determinato volo. In altri ambienti le stesse tecniche adottate per lo yield
management le possiamo trovare sotto le voci ``Revenue Management'' o `Ìnventory Control''.
Lo yield management una disciplina economica pensata per molte industrie di servizi nelle
quali la prenotazione, il controllo degli itinerari o la durata e la partizione dei prezzi in fasce di
mercato vengono combinati con analisi statistiche al fine di espandere il mercato coperto
dall'azienda ed incrementare il guadagno per unit (camera d'albergo, posto in aereo, ecc.). un
insieme di tecniche di previsione, modelli di ottimizzazione e procedure con le quali possibile
determinare quali prenotazioni conviene accettare e quali rifiutare nell'ottica di massimizzare i
guadagni.
I settori nei quali si maggiormente sviluppato lo yield management sono: la prenotazione di
voli, treni, camere d'albergo, noleggio mezzi. Tutti questi servizi hanno le seguenti caratteristiche
comuni:
la richiesta di servizi pu essere divisa in fasce distinte di mercato e l'elasticit dei prezzi
varia in funzione del tipo di clientela,
la capacit di risposta alle richieste relativamente fissa ed molto costoso incrementarla

o decrementarla (si pensi al numero di posti a sedere in un volo o al numero di camere in
un hotel),
i servizi sono ``deperibili'' nel senso che non possono essere venduti dopo una
determinata scadenza (un posto in un volo non pu essere venduto quando l'aereo gi
decollato),
il servizio viene prenotato,
la richiesta del servizio varia in continuazione e non pu essere prevista con grande
precisione,
lo stesso servizio ``fisico'' (il posto a sedere o la camera) pu essere venduto a diverse
fasce di mercato con prezzi e modi di prenotazione diversi.
Come abbiamo visto alla base di una previsione e decisione sta un archivio consistente di dati
che ci permette di confrontare la situazione attuale con ci che accaduto nel passato per cercare
di determinare quale sar il futuro prossimo e lontano dell'attivit . Perci alla base di un sistema
di yield management troviamo un data warehouse. Quello che ci proponiamo nei prossimi
paragrafi il determinare quale possa essere uno schema di principio di un data warehouse da
applicare allo yield management di una catena d'alberghi. Ci concentreremo in particolare al solo
settore delle prenotazioni.

La base di dati utilizzata per lo sviluppo degli schemi proviene da un programma gestionale
fornito agli alberghi. Esso composto di molte tabelle per la gestione dei clienti, dei libri mastri,
degli agenti di viaggi e dei servizi ausiliari proposti dall'albergo.
Il gestionale stato scritto in ClipperTM perci le tabelle sono in formato DB IIITM, prive di
integrit referenziale e qualsiasi tipo di relazione. Questo fatto ha creato non pochi problemi dato
che anche la documentazione disponibile era un sunto molto ristretto di ci che ciascuna tabella
contiene. Si resa necessaria allora una breve fase di reverse engeneering per capire come
fossero stati memorizzati i dati nelle tabelle ed individuare le tabelle utili a popolare il data
warehouse.
La qualit dei dati e le vecchie tecnologie applicate implicano una grossa operazione di filtraggio
dei dati al fine di soddisfare le chiavi primarie ed esterne del data warehouse ed ottenere dati utili
al DSS da costruire. Nel database infatti esistono prenotazioni non connesse ad alcun cliente
oppure pernottamenti a costo zero, clienti che hanno valori nulli nei campi del cognome e del
nome ed altri dati non consistenti dovuti molto probabilmente ad un mancato controllo di ci che
inseriscono gli utenti.
Una delle parti pi difficili allora determinare quali campi e tabelle debbano far parte del data
warehouse ed in quale modo. Occorre considerare infatti che la base di dati composta da ben
243 tabelle di cui alcune sono state utilizzate anche per contenere del codice implementativo o le
descrizioni delle stampanti, altre per mantenere dati storici riassunti ed altre ancora sono
ridondanti per parti delle tabelle principali.
Il gestionale stato sviluppato da una ditta tedesca per alberghi italiani, perci il contenuto delle
tabelle e delle loro strutture mostra un intreccio di ben tre lingue: tedesco, inglese ed italiano.
L'applicazione inoltre mostra tutte le caratteristiche di un programma costruito finch le esigenze
dei clienti aumentavano senza per mai ristrutturare la base di dati, perci spesso campi che, in
tabelle diverse, si riferiscono ad uno stesso elemento, sono registrati con nomi e formati diversi
pur avendo sempre lo stesso contenuto; ad esempio il numero di codice di un cliente registrato
sia come stringa che come numero. Le tabelle non sono normalizzate e questo porta ad una certa
ridondanza dei dati ed una quasi completa mancanza di allineamento degli aggiornamenti da essi
subiti: in tabelle diverse uno stesso cliente pu avere indirizzi diversi. Sembra inoltre che non
esista una versione standard del prodotto, ma che di volta in volta venga costruita una versione
custom per ciascun albergo: infatti capitato di maneggiare strutture di dati appartenenti alla
stessa applicazione ma provenienti da alberghi diversi ed erano tutte diverse tra loro; solo alcuni
campi erano comuni alle strutture.
Per limitare lo spazio occupato nei dischi dalle tabelle, la base di dati sposta i dati provenienti da
una prenotazione in un libro mastro una volta che il pernottamento stato pagato ed alla fine
dell'anno azzera l'archivio delle prenotazioni. Questo meccanismo fa sì che vengano persi molti
dati interessanti che sarebbero di supporto alle decisioni. Per esempio vengono perse tutte le
cancellazioni di prenotazioni con i relativi motivi, gli sconti applicati ed i servizi richiesti. Se si
volesse usare questa base di dati come punto di partenza per il DSS, potrebbe essere utile solo fra
almeno due anni: in questo periodo infatti, prendendo i dati dalla tabella pi completa, si
riuscirebbe ad avere un quadro probabilmente completo di situazioni, di cancellazioni, richieste
di servizi, ecc. che amplierebbero in modo sufficiente la base di dati per il DSS.
Per poter utilizzare questa applicazione come base di partenza per la costruzione di un data
warehouse per lo yield management, sarebbe necessaria una formazione degli utilizzatori della
base di dati affinch i dati siano di un qualche interesse per il manager oppure bisognerebbe
ristrutturare completamente l'applicazione e la sua base di dati al fine di fornire una buona base
per la gestione dell'albergo ed il data warehouse. Utile sarebbe anche la figura di una persona
responsabile della qualit dei dati che entrano a far parte del data warehouse, che si preoccupa
eventualmente di avvisare il tal albergo della catena di rivedere alcuni dati spediti prima di
inserirli nel data warehouse e che comunica agli utilizzatori del data warehouse che i dati
dell'ultimo aggiornamento sono incompleti.
Lo schema proposto

Individuata l'entit PRENOTAZIONE uno schema di principio E-R quello riportato in fig. 5.1.
Attraverso una CHIAMATA un CLIENTE o un AGENTE per conto di un cliente esegue almeno
una PRENOTAZIONE presso un HOTEL. Questa operazione rappresentata nello schema dalla
relazione multipla di CHIAMATA.
Figure 5.1: Schema di principio E-R dell'entit PRENOTAZIONE.
Alla relazione devono necessariamente partecipare un CLIENTE, un HOTEL ed una

PRENOTAZIONE; invece l'AGENTE opzionale. Ovviamente molte prenotazioni potranno far
capo ad un cliente, hotel o agente.
Come si pu vedere una prenotazione fortemente caratterizzata dal tempo in quanto esistono
una DATA di prenotazione, una di ARRIVO dell'ospite ed una di PARTENZA; altri suoi attributi
sono il CONTO derivante dall'occupazione delle stanze, il numero di ADULTI e BAMBINI
presenti nel periodo di occupazione ed il TIPO_CAMERA prenotato. Un attributo opzionale
l'attributo composto CANCELLAZIONE dotato di DATA e MOTIVO.
Infine l'entit PRENOTAZIONE ha un identificatore esterno formato dagli attributi
TIPO_CAMERA, ARRIVO, PARTENZA, DATA e dalla connessione con la relazione CHIAMATA.

Poich nella base di dati utilizzata risulta che un albergo mediamente ha 10.000 prenotazioni
annue, lo schema da adottare per questa entit certamente lo star schema. Si propone uno
schema come quello di fig. 5.2 dove gli attributi di tempo e di tipo di camera prenotato si
preferito trasformarli in dimensioni perch sono elementi fondamentali di ricerca in un DSS sulle
prenotazioni.
Figure 5.2: Star schema di principio dell'entit PRENOTAZIONI.
Dall'identificatore esterno dello schema E-R risultano allora sette dimensioni:
tre individuate dal tempo: data, arrivo e partenza,
la categoria delle camere prenotate: cat_camere,
i clienti,
gli agenti e
gli hotel.
Una menzione particolare va fatta per gli agenti: infatti la maggior parte delle prenotazioni
effettuate secondo quanto dice la base di dati non stata effettuata da alcun agente. Una
soluzione a questo problema quella di aggiungere un particolare record che tiene conto di
questo nella tabella degli agenti e trattare di conseguenza i dati importati nel data warehouse.
Le dimension table sono allora: Clienti, Cat_camere, Tempo, Hotel e Agenti le cui rispettive
chiavi primarie sono: id_cliente, tipo_camera, data, id_hotel e id_agente. La chiave primaria
della fact table Prenotazioni formata dagli attributi: id_cliente, tipo_camera, data, arrivo,
partenza, id_hotel e id_agente. Una nota particolare va per le chiavi esterne della fact table
legate al tempo: infatti gli attributi data, arrivo e partenza sono tutti legati alla chiave primaria
data della dimension table Tempo.
I fatti individuati sono allora:
il numero di adulti,
il numero di bambini,
la commissione per l'agente,
il conto pagato,
la data ed il motivo di una cancellazione.
Ne risulta che lo star schema sviluppato nei fatti e nelle dimensioni si presenta come in fig. 5.3
dove sono rappresentati tutti i possibili dati ricavabili dal database di partenza.
Figure 5.3: Star schema dell'entit PRENOTAZIONI.
In appendice riportato il codice SQL utilizzato per la creazione delle tabelle dello star schema.
Si pu notare dal codice che la fact table contiene solo campi numerici per limitare lo spazio da
lei occupato: infatti, se consideriamo una catena di soli quattro alberghi, possiamo approssimare
il calcolo dello spazio della fact table con la seguente formula:
14*4*10.000*4*5=11.200.000 byte dove 14 sono i campi, 4 i byte di occupazione media di
ciascun campo, 10.000 le prenotazioni medie annue, 4 gli alberghi della catena e 5 anni l'arco di
tempo residente nella tabella del data warehouse di maggior uso. Il campo dei motivi di
cancellazione contiene dei numeri interi per evitare di sprecare spazio e per evitare che una
stessa causa sia espressa con parole diverse e quindi riconosciuta in una ricerca in modi diversi.
Questo campo connesso a una semplice tabella associativa formata da due campi uno con il
numero del motivo ed uno con la descrizione. Tenendo ad esempio 30 caratteri per l'immissione
diretta della descrizione del motivo nella fact table lo spazio occupato sarebbe aumentato di circa
il 46%:
(13*4+30)*10.000*4*5=16.400.000 byte. Per altro 30 caratteri sarebbero anche pochi per
descrivere molti motivi, in questo modo si pu dedicare anche un campo di tipo memo o di 100
caratteri per la descrizione, perch viene richiamato solo dopo aver ottenuto i risultati di una
ricerca sulle prenotazioni.
A questo punto, basandoci sul codice in appendice, possiamo calcolare anche lo spazio occupato
dalle altre tabelle:
Agenti
(4+4*30+15+60+8+3+20*5+70+8)*300*4=465.600 byte
su una base di circa 300 agenti per ogni albergo;
Cat_camere
(4+100)*10=4.000 byte;
Clienti
(4*2+7*30+15+8*20+60+8+70+3+1)*20.000*4=42.800.000 byte su una base di 20.000
clienti per ogni albergo;
Hotel
(8*4+2*40+2*30+8*2+3+3*20)*4=1.004 byte;
Tempo
(9*4+2*9+10+50)*365*5=208.050 byte
su un arco di tempo di 5 anni.
Si pu facilmente notare che la dimensione dei clienti occupa molto pi spazio della fact table e
ci suggerirebbe l'uso di minidimension, ma non c' stato modo di parlare con un manager
d'albergo per riuscire a determinare quali fattori siano importanti nelle ricerche di mercato per
definire le minidimension. A discapito dello spazio comunque bisogna dire che nelle ricerche si
usano soprattutto gli indici e pochi campi della tabella: perci dobbiamo tener conto del numero
di record piuttosto che dello spazio che questi occupano e la fact table ne contiene 200.000
contro gli 80.000 della dimension table dei clienti.
La dimensione dei clienti occupa molto spazio anche perch dai dati in mio possesso si deduce
che un cliente nell'arco di quattro anni esegue mediamente 1,7 prenotazioni, il che fa presumere
che in questo mercato la maggior parte dei clienti usufruisca del servizio una sola volta, mentre
un'altra fascia di mercato lo utilizzi periodicamente.

Per la realizzazione dello star schema si utilizzato Universal DB2 Version 5.0 Enterprise
EditionTM di IBMTM e Microsoft Access '97TM: il primo per contenere le tabelle dello star schema
ed il secondo per poter sfruttare le potenzialit di ODBC che consente di importare i dati da
tabelle DB IIITM ed esportarli in DB2TM.
DB2TM promette l'uso di algoritmi ottimizzati per la ricerca su uno star schema e l'uso di bit map
index. Il condizionale d'obbligo perch non prevede estensioni di SQL che assicurano che una
determinata query venga eseguita su un determinato indice con un algoritmo ottimizzato. L'unica
cosa che possibile scegliere il ``grado di ottimizzazione'' del compilatore SQL: la
documentazione consiglia di porlo a livello 2 con il comando:
SET CURRENT QUERY OPTIMIZATION = 2
questo livello consigliato come il migliore per applicazioni quali OLAP e DSS. Questo livello
limita l'overhead del compilatore e lascia al DBMS la scelta dell'algoritmo migliore per
l'esecuzione della query, compreso l'algoritmo di star join che riconosce uno star schema solo
quando questo raggiunge o supera le tre dimensioni. Impostando tale parametro si nota un
miglioramento dei tempi di risposta del DBMS alle query di selezione.
L'uso di Microsoft AccessTM si reso necessario per il fatto che DB2TM non permette di importare
file se non in formato testo; inoltre non prevede strumenti per la costruzione di query su
un'interfaccia grafica che faciliti il lavoro dello sviluppatore in fase di progetto. Gli strumenti
messi a disposizione da DB2TM sono molto spartani tanto che non permettono neanche la
visualizzazione di un'intera tabella una volta che stata popolata, vengono visualizzati solo circa
200 record della tabella e, data la quantit di record che si trova mediamente nelle tabelle di un
data warehouse, questa cifra suona veramente ridicola. L'unico modo di visualizzare un'intera
tabella attraverso ODBC o un'applicazione scritta ad-hoc che utilizzi le librerie messe a
disposizione per i linguaggi C++ e Java.
L'uso di ODBC e MS AccessTM rallenta i tempi di risposta e questo lo si pu osservare tenendo
aperto un processo di Task Manager dove si vede chiaramente che il processore viene prima
dedicato al DBMS e poi a MS AccessTM.
DB2TM non prevede la gestione di tabelle di dati aggregati, perci se dovessimo creare un data
warehouse con vari livelli di summarization dovremmo gestire tutta la questione della creazione
di SQL ottimizzato nel back-end della nostra applicazione che a seconda della query dell'utente
generi il codice SQL migliore. Se poi l'uso del data warehouse portasse alla scoperta della
necessit di cambiare le summarization table ci troveremmo a dover riscrivere anche
l'applicazione oltre agli schemi del data warehouse. Sarebbe di grande aiuto per lo sviluppatore
ed il Data Warehouse Administrator un compilatore SQL che riconoscesse la presenza di
summarization table (magari durante la definizione delle tabelle con un'estensione del linguaggio
SQL) e dirottasse le query su queste tabelle quando necessario. Se per esempio esistesse una
tabella che riassume i redditi in mesi e l'utente richiedesse quelli dell'intero anno, si farebbe certo
prima a rispondergli sommando quelli dei mesi piuttosto che quelli dei giorni.
Per la creazione dei dati della dimensione del tempo stato utilizzato Microsoft Excel '97TM,
perch permette in modo molto semplice di generare date consecutive per 5 anni con
corrispondenti nomi dei giorni e dei mesi; quindi sempre attraverso MS AccessTMe ODBC stato
importato il tutto nella dimension table del tempo.

I computer su cui stato realizzato lo star schema hanno le seguenti caratteristiche:
CPU: Pentium II 300 CeleronTM, RAM: 128 Mb, Hd: 8 Gb UDMA EIDE;
CPU: AMD K6-2 3dTM, RAM: 64 Mb, Hd: 10 Gb UDMA EIDE;
entrambi con sistema operativo Microsoft Windows NT 4.0TM. I tempi di risposta del DBMS
comunque suggeriscono come caratteristiche minime della macchina che ospita un data mart
delle prenotazioni mantenendo lo stesso sistema operativo dovrebbero essere:
CPU: Pentium II 400TM; RAM 256 Mb, Hd: 8 Gb SCSI con bus PCI da almeno 100 MHz.

In questa esperienza c' stato modo di utilizzare solo DB2TM, ma stata tuttavia raccolta
documentazione anche di Oracle 8iTM, MS SQL Server 7.0TM e SAS Warehouse di SAS
InstituteTM.
La versione standard di tutti questi software limitata per quel che riguarda la completa gestione
di un data warehouse; se vogliamo avere le migliori prestazioni e buoni tool di sviluppo occorre
aggiungere a ciascuno di questi DBMS dei moduli venduti separatamente.
Nel seguito sono riportate schematicamente alcune caratteristiche di data warehousing supportate
o meno dai DBMS menzionati.
DB2TM
Cosa gestisce
Cosa non gestisce
Oracle 8iTM
Cosa gestisce
Cosa non gestisce
SQL Server 7.0TM
Cosa gestisce
Cosa non gestisce
SAS WarehouseTM
Cosa gestisce
Cosa non gestisce
Cosa gestisce
bit-map index,
ottimizzazioni algoritmiche per gli star schema,
nella Parallel Edition gestisce anche ricerca parallela contemporanea su pi indici e pi

tabelle.
Cosa non gestisce
metadati (nel senso che i metadati non sono disponibili all'utente finale se non forniti
come documentazione),
summarization table (nel senso che se si creano bisogna gestirne l'utilizzo nel back-end
della nostra applicazione non c' alcun meccanismo automatico che trasformi le nostre
query a seconda dell'esistenza o meno delle summarization table),
OLAP disponibile solo con un modulo a parte (DB2 OLAP ServerTM),
Data Mining disponibile solo con un modulo a parte (Miner DataTM).
Oracle 8iTM
Cosa gestisce
Cosa non gestisce
Cosa gestisce
bit-map index,
nella Parallel Edition gestisce anche ricerca parallela contemporanea su pi indici e pi

tabelle,
summarization table.
Cosa non gestisce
metadati,
OLAP disponibile solo con un modulo a parte (Oracle ExpressTM),
Data Mining non disponibile.
SQL Server 7.0TM
Cosa gestisce
Cosa non gestisce
Cosa gestisce
bit-map index,
ricerca parallela contemporanea su pi indici e pi tabelle se in presenza di tecnologia

SMP,
motore OLAP integrato (anche se la stampa specialistica lo definisce limitato in

capacit ).
Cosa non gestisce
metadati,
summarization table,
Data Mining non disponibile.
SAS WarehouseTM
Non propriamente classificabile come DBMS, ma bisognerebbe piuttosto pensarlo come
DWMS (Data Warehouse Management System) perch stato pensato solo con questo scopo: di
conseguenza alcune caratteristiche non possono essere confrontate direttamente con un DBMS.
Per esempio sebbene a livello logico divida le tabelle di uno star schema, nel momento in cui
poniamo un'interrogazione, essa viene eseguita su un'enorme tabella denormalizzata formata
dall'unione dei record della fact table espansi in tutte le loro dimensioni (non ci sar quindi solo
l'identificativo del cliente, ma tutti i suoi dati ripetuti per ogni ordine esso abbia fatto).
SAS Warehouse stato concepito solo nell'ambito del data warehouse, mentre gli altri prodotti
qui esaminati sono pensati ancora come DBMS, perci devono essere in grado di soddisfare
dapprima le esigenze di OLTP e poi eventualmente anche quelle di data warehousing che spesso
in quest'ambito pensato solo come VLDB (Very Large Data Base).
Cosa gestisce
Cosa non gestisce
Cosa gestisce
bit-map index,
ricerca parallela contemporanea su pi indici e pi tabelle,
metadati,
summarization table.
Cosa non gestisce
OLAP disponibile solo con un modulo a parte,
Data Mining disponibile solo con un modulo a parte.

Ho avuto modo di provare nell'ambito del data mining Miner DataTM di IBMTM che, dalla
documentazione analizzata, sembra essere uno degli strumenti pi avanzati.
La prima impressione che ne ho ricavato che molto probabilmente siamo ancora lontani dalla
definizione di uno standard in questo campo. Sebbene l'utilizzo di un data mine teoricamente sia
rivolto ad un pubblico non specializzato praticamente questo strumento richiede buone
conoscenze informatiche e ottime conoscenze statistiche in quanto sono necessari molti passaggi
per definire quali siano i dati da analizzare e i risultati dell'analisi sono interpretabili solo da un
pubblico esperto di analisti.
Sebbene il data mining sia pensato come applicazione di un DSS in questo caso ci troviamo
davanti ad un applicativo che richiede personale esperto per un utilizzo al massimo delle
potenzialit e flessibilit che offre perci ritorniamo alla delega delle decisione agli analisti
piuttosto che ai manager.
Di fatto Miner DataTM sembra essere un ottimo strumento per analisti i quali redigono i loro
rapporti e li consegnano ai manager: siamo ancora lontani da un utilizzo user friendly. L'unico
modo di rendere semplice l'uso di questo strumento quello di predeterminare alcuni tipi di
analisi che vengono ripetute spesso, ma questo ne limita notevolmente la flessibilit .
Conclusioni
Qualsiasi sia lo strumento che useremo nella creazione di un data warehouse, tutti i motori hanno
in comune un prezzo molto elevato se rapportato ai prezzi a cui siamo abituati con le
applicazioni nel mercato dei PC. A questo prezzo bisogna aggiungere gli anni-uomo necessari
alla messa a punto dei database che forniscono i dati e la creazione del data warehouse
comprensivo di un'interfaccia user friendly.
Il prezzo e la necessit di manipolare grandi quantit di dati fanno sì che solo aziende con un
elevato fatturato siano interessate ad applicazioni di data warehousing.

L'introduzione di un data warehouse in azienda implica necessariamente anche un'educazione dei
manager al suo uso e quindi un cambio di mentalit e di strategia. Questo forse uno degli scogli
pi duri da affrontare soprattutto nel nord-est del nostro paese dove il buon andamento delle
aziende medio piccole legato al ``fiuto'' dei dirigenti che spesso si sentono ``spodestati''
dall'avvento delle nuove tecnologie. Il data warehouse vorrebbe essere anche un repository
dell'esperienza manageriale per poter mantenere l'azienda sempre su una fascia alta del mercato,
anche quando il manager che ha ``fiuto'' non pu pi dirigere l'azienda e questo sembra essere un
fattore duro da accettare.
L'introduzione di un data warehouse cambia molti aspetti della vita aziendale: innanzitutto
occorre porre pi attenzione a come vengono inseriti i dati nei database, perch ora lo scopo non
pi solo quello di ottenere una fattura; poi permette ai manager di effettuare nuovi metodi
d'indagine e quindi analizzare anche le fasi lavorative con nuovi strumenti. Tutto ci fa sì che
sia soprattutto la mentalit a dover cambiare quando si decide di investire in un DSS.
Un DSS permette di provare con rapporti precisi e dettagliati ci che stato ``fiutato'' dal
manager ed un ottimo strumento per gli analisti che non si devono pi affidare a lente ricerche
nei gestionali.
Un data warehouse non solo utile nel campo economico, ma pu essere applicato ad ogni
settore di un'azienda: pu ad esempio raccogliere tutti i progetti esistenti ed ordinarli secondo
varie chiavi di ricerca oppure contenere i cicli lavorativi dei singoli pezzi per analizzare le
migliori strategie di produzione e così via.
Un data warehouse sempre strettamente legato alla singola azienda ed molto difficile se non
impossibile crearne uno per una categoria di aziende, questo perch intimamente legato alle
strategie di marketing e produzione della stessa e perci unico. Le aziende che desiderano
utilizzarlo devono considerare anche la nascita di un nuovo ruolo aziendale: il Data Warehouse
Administrator che si deve occupare di mantenere il data warehouse e la sua interfaccia aggiornati
con le esigenze dell'impresa.
I metodi di progettazione di un data warehouse possono tornare utili anche nella piccola impresa
dove, sebbene non si voglia investire in computer molto potenti e DBMS costosi, sono
comunque utili dei semplici strumenti di analisi. Poich il numero di record coinvolti in questo
ambito certamente pi limitato, risultano sufficienti anche i PC con le applicazioni del calibro
di MS AccessTM se basate su schemi ben progettati.
Le tecniche su cui si basa la progettazione di un data warehouse dal mio punto di vista sono un
ottimo strumento di test sulla funzionalit e bont di un database. Se la base di dati ben
progettata e contiene dati ``puliti'' risulta facile creare degli schemi di data warehouse e
popolarlo.
Penso che nel giro di pochi anni i data warehouse cominceranno sempre pi a diffondersi
(magari sotto nomi fantasiosi di strumenti che fanno analisi di vario tipo, ma che usano questa
tecnologia come motore) specialmente laddove si abbia a che fare con molti clienti. In questo
periodo infatti sembrano `àndare di moda'' i cosiddetti CRM (Customer Relationship
Management) con i quali si cerca di annotare qualsiasi particolare riguardi un cliente in modo da
farlo sentire pi a suo agio quando chiama l'azienda.
Codice di creazione tabelle

Di seguito viene riportato il codice SQL utilizzato per la definizione delle tabelle del data
warehouse.

CREATE TABLE agenti (
id_agente INTEGER NOT NULL,
cognome VARCHAR (30) NOT NULL,
nome VARCHAR(30),
titolo VARCHAR(15),
ditta VARCHAR(30),
via VARCHAR(60),
cap VARCHAR(8),
citta VARCHAR(30),
nazione VARCHAR(3),
telefono VARCHAR(20),
telex VARCHAR(20),
fax VARCHAR(20),
commissione DOUBLE,
note VARCHAR(70),
partitaiva VARCHAR (20),
codicefiscale VARCHAR(20),
PRIMARY KEY (id_agente)
)

CREATE TABLE cat_camere (
tipo_camera VARCHAR(4) NOT NULL,
descrizione VARCHAR(100),
PRIMARY KEY (tipo_camera)
)

CREATE TABLE clienti (
id_cliente INTEGER NOT NULL,
nome VARCHAR(30),
cognome VARCHAR (30) NOT NULL,

titolo VARCHAR(15),
lingua VARCHAR(20),
ditta VARCHAR(30),
gruppo VARCHAR(30),
via VARCHAR(60),
cap VARCHAR(8),
citta VARCHAR(30),
nazione VARCHAR(3),
telex VARCHAR(20),
fax VARCHAR(20),
note VARCHAR(70),
datanascita DATE,
stanzapreferita VARCHAR(20),
chiprenota VARCHAR(30),
chipaga VARCHAR(30),
luogonascita VARCHAR(30),
tipodocumento VARCHAR(3),
nr_documento VARCHAR(20),
luogodocumento VARCHAR(20),
partitaiva VARCHAR (20),
sesso CHARACTER(1),
PRIMARY KEY (id_cliente)

CREATE TABLE hotel (
id_hotel SMALLINT NOT NULL,
nome VARCHAR(40),
proprietario VARCHAR(30),
via VARCHAR(40),
cap VARCHAR(8),
citta VARCHAR(30),
nazione VARCHAR(3),
telex VARCHAR(20),
fax VARCHAR(20),
camere SMALLINT,
letti SMALLINT,
personale SMALLINT,
cambioasciugamani SMALLINT,
cambiolenzuola SMALLINT,
comm_agente DOUBLE,
warning_1 SMALLINT,
warning_group SMALLINT,
PRIMARY KEY (id_hotel)
)

CREATE TABLE tempo (
data DATE NOT NULL,
giornosettimana VARCHAR(9) NOT NULL,
numgiornomese SMALLINT NOT NULL,
numgiornoanno SMALLINT NOT NULL,
numsettimana SMALLINT NOT NULL,
mese VARCHAR(9) NOT NULL,
anno SMALLINT NOT NULL,
nummese SMALLINT NOT NULL,
festivita SMALLINT,
infrasettimanale SMALLINT,
week_end SMALLINT NOT NULL,
stagione VARCHAR(10),
evento VARCHAR(50),
PRIMARY KEY (data)
)

CREATE TABLE prenotazioni (
id_cliente INTEGER NOT NULL,
tipo_camera VARCHAR(3) NOT NULL,
data DATE NOT NULL,
arrivo DATE NOT NULL,
partenza DATE NOT NULL,
id_agente INTEGER NOT NULL,
id_hotel SMALLINT NOT NULL,
adulti SMALLINT,
bambini SMALLINT,
commissione SMALLINT,
conto DOUBLE,
sconto SMALLINT,
datacancellazione DATE,
motivocancell SMALLINT,
PRIMARY KEY (id_cliente, tipo_camera, data, arrivo,
partenza, id_agente, id_hotel),
FOREIGN KEY (id_cliente) REFERENCES clienti (id_cliente),
FOREIGN KEY (tipo_camera) REFERENCES cat_camere (tipo_camera),
FOREIGN KEY (data) REFERENCES tempo (data),
FOREIGN KEY (arrivo) REFERENCES tempo (data),
FOREIGN KEY (partenza) REFERENCES tempo (data),
FOREIGN KEY (id_agente) REFERENCES agenti (id_agente),
FOREIGN KEY (id_hotel) REFERENCES hotel (id_hotel),
FOREIGN KEY (motivocancell) REFERENCES motivicanc (motivocancell)
)
Codice di importazione dati

Di seguito viene riportato il codice SQL utilizzato per l'importazione dei dati dal database
gestionale alle tabelle del data warehouse.

INSERT INTO agenti (
id_agente, cognome, nome, titolo, ditta, via, nazione, cap,
citta, telefono, telex, fax, note, commissione, partitaiva)
SELECT nummer, name, vorname, titel, firma,strasse1 & strasse2 AS via,
land, plz, ort, telefon, telex, telefax, notiz1, provision,
partitaiva
FROM gaestest
WHERE memo="T" OR memo="S";

INSERT INTO cat_camere ( tipo_camera, descrizione )
SELECT nr, lang & lang1 & lang2 & lang3
FROM gkat;

INSERT INTO clienti (
id_cliente, titolo, lingua, cognome, nome, ditta, via,nazione,
cap, citta, telefono, telex, fax, note, gruppo,datanascita,
stanzapreferita, chiprenota, chipaga,luogonascita, tipodocumento,
nr_documento, partitaiva, luogodocumento, sesso )
SELECT nummer, anrede, sprache, name, vorname, firma,

strasse1 & strasse2 AS via, land, plz, ort, telefon, telex,
telefax, notiz1, gruppe, gebdat, wunschzi, kontakt1, kontakt2,
birthplace, doctype, docnr, partitaiva, docplace, sex
FROM gaestest
WHERE ISNULL(memo) OR memo="C" OR memo="G"

INSERT INTO hotel (
id_hotel, nome, proprietario, via, nazione, cap, citta, telefono,
camere, letti, personale, fax, cambioasciugamani, cambiolenzuola,
comm_agente, warning_1, warning_group )
SELECT hotelid, firma, owner, strasse, land, plz, ort, telefon, zimmer,
betten, personal, telegramm, rh, rw, s6 + s5 AS comm_agente,
irooms, grooms
FROM gfirm;

INSERT INTO tempo (
data, giornosettimana, mese, anno, numgiornomese,
numgiornoanno, numsettimana, nummese , week_end )
SELECT data, giorno, mese, anno, numgiornomese, numgiornoanno,
settimanaanno, nummese,
IIF((giorno="Sabato") OR (giorno="Domenica"),1,0)
FROM [Tempo Excel];

UPDATE tempo, events SET evento = event
WHERE events.datum=tempo.data;

INSERT INTO prenotazioni (
id_cliente, tipo_camera, data, arrivo, partenza, id_agente,
id_hotel, adulti, bambini, commissione, conto)
SELECT gastnr AS id_cliente,
kat AS tipo_camera,
MIN(IIF(ISNULL(am),an,am)) AS data,
an AS arrivo,
MAX(ab) AS partenza,
VAL(IIF(ISNULL(travel), IIF(ISNULL(source),0,source),travel))
AS id_agente,
1 AS hotelid,
SUM(erw) AS adulti,
SUM(kin) AS bambini,
MAX(IIF(ISNULL(travel), IIF(ISNULL(source),0,sourcepct),travelpct))
AS commissione,
SUM(preis+fix+extras+fb) AS conto
FROM agenti, cat_camere, clienti, tempo, gauf
WHERE gastnr=id_cliente AND
kat=tipo_camera AND
an=data AND
VAL(IIF(ISNULL(travel),IIF(ISNULL(source),0,source),travel) =
id_agente
GROUP BY gastnr, kat,
VAL(IIF(ISNULL(travel),IIF(ISNULL(source),0,source),travel)), an
HAVING SUM(preis+fix+extras+fb)>=10000;
Codice dei test

La prima query conta il numero di prenotazioni avvenute tramite agenti di viaggi ogni anno per
vedere con quale agente di viaggi stipulare i migliori contratti.
SELECT cognome, nome, COUNT(prenotazioni.id_agente) as nr_prenotazioni,
anno
FROM tempo INNER JOIN (agenti INNER JOIN PRENOTAZIONI ON
agenti.id_agente = prenotazioni.id_agente) ON
tempo.data = prenotazioni.arrivo
WHERE prenotazioni.id_agente>0
GROUP BY prenotazioni.id_agente, cognome, nome, anno
ORDER BY anno DESC , COUNT(prenotazioni.id_agente) DESC;
La seconda determina quale sia il miglior cliente degli ultimi 5 anni.

SELECT cognome, nome, SUM(conto) AS sumofconto
FROM prenotazioni INNER JOIN clienti ON
prenotazioni.id_cliente = clienti.id_cliente
GROUP BY cognome, nome
ORDER BY SUM(conto) DESC;
L'ultima determina quali siano le entrate di ogni mese ed ogni anno per determinare quali siano i
mesi che attirano pi clienti.
SELECT anno, nummese, SUM(conto) AS reddito
FROM prenotazioni JOIN tempo ON arrivo=tempo.data

GROUP BY ROLLUP (anno, nummese)
ORDER BY anno, nummese

Datawarehouse

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Datawarehouse

Caricato da

Copyright:

Formati disponibili

L'ambiente del Data Warehouse

Gli obiettivi che si prefiggono i DSS sono:

ridurre il tempo di risposta alle query comunque complesse,

mantenere la segretezza delle indagini dei manager.

Definizione di Data Warehouse

dipendente dal tempo''.

Figure 1.1: Esempio di integrazione dei dati

La struttura di un Data Warehouse

Come abbiamo appena notato relativamente ad un soggetto possono esserci pi tabelle

Multidimensional DBMS e Data Warehouse

Data Warehouse e tecnologia

indici bit map,

STARindexTM, ottimizzati per le strutture a star schema.

accesso ad insiemi di record in una sola volta,

accesso ai singoli record,

uso di uno o pi indici per risolvere una query,

istruzioni specifiche per ottenere semplici informazioni statistiche e di analisi,

interfaccia SQL (Standard Query Language),

essere in grado di inserire, modificare e cancellare dati.

Il Data Warehouse distribuito

il data warehouse risulta integrato in ogni ambiente dell'organizzazione;

il volume di dati che contiene giustifica l'uso di un sistema centralizzato;

Applicazioni del Data Warehouse

On-Line Analytical Processing

Fast Analysis of Shared Multidimensional Information

Capire il concetto di multidimensionalit

Ambiente del Data Mining

Modelli di Data Mining

Funzioni del Data Mining

Table 2.1: Dati altamente riassunti.

On-Line Analytical Processing

Fast Analysis of Shared Multidimensional Information

Capire il concetto di multidimensionalit

Fast Analysis of Shared Multidimensional Information

Analysis: il sistema deve riuscire a fare analisi statistiche e di mercato in modo

Multidimensional: il requisito pi importante, l'essenza delle applicazioni OLAP. I

Information: tutto ci di cui necessita il sistema dovunque e comunque sia

Capire il concetto di multidimensionalit

Selezione: selezione o segmentazione dei dati secondo alcuni criteri;

Trasformazione: i dati non sono semplicemente trasferiti da un archivio ad uno nuovo,

Interpretazione e valutazione: i modelli identificati dal sistema vengono interpretati

Ambiente del Data Mining

Modelli di Data Mining

Funzioni del Data Mining

Ambiente del Data Mining

supervised learning: il computer impara dagli esempi dove un insegnante aiuta il

sistema a costruire un modello definendo le classi e fornendo degli esempi. Il sistema

unsupervised learning: questo il modo di imparare attraverso l'osservazione e la

Modelli di Data Mining

Funzioni del Data Mining

La progettazione del Data Warehouse

Progetto di un Data Warehouse

Data Warehouse e modelli di dati

Entity Relationship Model

Data Item Set

Physical Data Model

Caricamento dei dati dal sistema operazionale

Integrazione dei dati

Problemi riscontrabili nell'integrazione dei dati

La granularit in un Data Warehouse

Factless fact table

Slowly changing dimension

Progetto di un Data Warehouse