1 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
1
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.
1.1 Definizione di Data Warehouse
La definizione di data warehouse fornitaci da W. H. Inmon, uno degli ideatori di questa
metodologia, è la seguente[4]:
``il 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
2
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.
1.2 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).
3
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 ``altamente
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
``invecchiati'' passano automaticamente agli altri livelli di dettaglio.
1.3 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.
4
1.3.1 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`i è 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`i il
numero di accessi ai supporti magnetici e l'uso del DBMS. Questo processo è detto Drill Down.
1.3.2 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.
1.4 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.
5
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'``affettare 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`i
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'end-user. 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.
6
Figure 1.4: Relazioni tra le applicazione in ambiente legacy e più strutture multidimensionali.
2 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
7
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.
2.1 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`i :
•
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.
8
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.
9
2.2 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.
2.2.1 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.
2.2.2 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.
Prodotto
Regione
Questo mese
Confronto
Yogurt
Nord
110
12%
Yogurt
Centro
179
-3%
Yogurt
Sud
55
5%
Table 2.1: Dati altamente riassunti.
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.
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%
10
Yogurt
Centro
Pietri
11
-15%
Yogurt
Sud
Stani
25
5%
Yogurt
Sud
Gralli
30
6%
Table 2.2: Dati più dettagliati dopo una singola operazione di drill down.
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.
2.2.3 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.
2.3 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.
2.4 Fast Analysis of Shared Multidimensional Information
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.
11
•
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.
2.5 Capire il concetto di multidimensionalità
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.
3 Data Mining
Il termine Data Mining, che letteralmente significa ``estrarre 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:
12
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 ``usare 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 ``usabili 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.
13
•
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.
3.1 Ambiente del Data Mining
Il data mining ha attratto attorno a sè molti nuovi campi della Computer Science, tra questi
spiccano l'inductive learning e il machine learning.
3.1.1 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.
3.1.2 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
14
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.
3.2 Modelli di Data Mining
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.
3.2.1 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.
3.2.2 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.
3.3 Funzioni del Data Mining
I metodi usati dal data mining per estrarre la conoscenza sono descritti nelle seguenti sotto
sezioni.
3.3.1 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).
15
3.3.2 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: ``il 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.
3.3.3 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.
3.3.4 Raggruppamento e segmentazione
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.
4 La progettazione del Data Warehouse
4.1 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
16
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 top-down 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.
4.2 Data Warehouse e modelli di dati
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.
4.2.1 Entity Relationship 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.
4.2.2 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,
17
•
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 ER 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
applicato all'entità CONTO
18
di
DIS
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.
4.2.3 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'enduser 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.
4.3 Normalizzazione e denormalizzazione
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
19
(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.
4.3.1 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
20
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.
4.3.2 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'``istantanea'' del database e quindi
confrontare in modo seriale l'immagine ``precedente'' con quella ``attuale'' 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.
4.4 Integrazione dei dati
Nel seguito sono riportati alcuni dei problemi che sorgono quando si vuole passare da un
21
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.
4.4.1 Problemi riscontrabili nell'integrazione dei dati
•
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.
4.4.2 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
22
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.
4.5 La granularità in un Data Warehouse
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à.
23
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.
4.5.1 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
4.5.2 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
24
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.
4.5.3 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.
25
4.5.4 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.
4.5.5 Slowly changing dimension
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
26
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`i 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`i , 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.
4.5.6 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`i è 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.
27
4.5.7 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.
5 Lo Yield Management per una catena di hotel
5.1 Esperienza di data warehouse
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 ``Inventory 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
28
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.
5.2 La base di dati di partenza
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`i 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
29
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.
5.3 Lo schema proposto
5.3.1 Lo schema E-R della PRENOTAZIONE
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.
30
5.3.2 Lo star schema delle Prenotazioni
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.
31
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
su una base di circa 300 agenti per ogni albergo;
•
byte
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
32
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
su un arco di tempo di 5 anni.
byte
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.
5.4 Gli strumenti utilizzati
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
33
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.
5.5 Gli strumenti sul mercato
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.
5.5.1 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.
34
5.5.2 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).
5.5.3 Oracle 8iTM
5.5.3.1 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,
•
summarization table.
5.5.3.2 Cosa non gestisce
•
metadati,
•
OLAP è disponibile solo con un modulo a parte (Oracle ExpressTM),
•
Data Mining non è disponibile.
5.5.4 SQL Server 7.0TM
5.5.4.1 Cosa gestisce
•
bit-map index,
•
ottimizzazioni algoritmiche per gli star schema,
•
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à
).
5.5.4.3 Cosa non gestisce
•
metadati,
35
•
summarization table,
•
Data Mining non è disponibile.
5.5.5 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).
5.5.5.1 Cosa gestisce
•
bit-map index,
•
ricerca parallela contemporanea su più indici e più tabelle,
•
metadati,
•
summarization table.
5.5.5.2 Cosa non gestisce
•
OLAP è disponibile solo con un modulo a parte,
•
Data Mining è disponibile solo con un modulo a parte.
5.6 La prova di Miner DataTM
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
36
predeterminare alcuni tipi di analisi che vengono ripetute spesso, ma questo ne limita
notevolmente la flessibilità .
6 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`i 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`i 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`i 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 ``andare 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.
37
6.1 Codice di creazione tabelle
Di seguito viene riportato il codice SQL utilizzato per la definizione delle tabelle del data
warehouse.
6.1.1 Creazione della tabella Agenti
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)
)
6.1.2 Creazione della tabella Cat_camere
CREATE TABLE cat_camere (
tipo_camera VARCHAR(4) NOT NULL,
descrizione VARCHAR(100),
PRIMARY KEY (tipo_camera)
)
6.1.3 Creazione della tabella Clienti
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),
telefono VARCHAR(20),
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)
)
38
6.1.4 Creazione della tabella Hotel
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),
telefono VARCHAR(20),
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)
)
6.1.5 Creazione della tabella Tempo
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)
)
6.1.6 Creazione della tabella Prenotazioni
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)
)
39
6.2 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.
6.2.1 Importazione dati nella tabella Agenti
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";
6.2.2 Importazione dati nella tabella Cat_camere
INSERT INTO cat_camere ( tipo_camera, descrizione )
SELECT nr, lang & lang1 & lang2 & lang3
FROM gkat;
6.2.3 Importazione dati nella tabella Clienti
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"
6.2.4 Importazione dati nella tabella Hotel
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;
6.2.5 Importazione dati nella tabella Tempo
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];
6.2.6 Aggiornamento della tabella Tempo
UPDATE tempo, events SET evento = event
WHERE events.datum=tempo.data;
40
6.2.7 Importazione dati nella tabella Prenotazioni
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;
6.3 Codice dei test
6.3.1 Semplici test sullo star schema
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
41
INDICE GENERALE
1
L'ambiente del Data Warehouse .....................................................................................................................................................................1
1.1
Definizione di Data Warehouse ...........................................................................................................................................................2
1.2
La struttura di un Data Warehouse ....................................................................................................................................................3
1.3
L'orientazione al soggetto.....................................................................................................................................................................4
1.4
Multidimensional DBMS e Data Warehouse .....................................................................................................................................5
2
Data Warehouse e tecnologia ...........................................................................................................................................................................7
2.1
Il Data Warehouse distribuito .............................................................................................................................................................8
2.2
Applicazioni del Data Warehouse .....................................................................................................................................................10
2.3
On-Line Analytical Processing ..........................................................................................................................................................11
2.4
Fast Analysis of Shared Multidimensional Information.................................................................................................................11
2.5
Capire il concetto di multidimensionalità.........................................................................................................................................12
3
Data Mining .....................................................................................................................................................................................................12
3.1
Ambiente del Data Mining .................................................................................................................................................................14
3.2
Modelli di Data Mining.......................................................................................................................................................................15
3.3
Funzioni del Data Mining...................................................................................................................................................................15
4
La progettazione del Data Warehouse ..........................................................................................................................................................16
4.1
Progetto di un Data Warehouse.........................................................................................................................................................16
4.2
Data Warehouse e modelli di dati......................................................................................................................................................17
4.3
Normalizzazione e denormalizzazione ..............................................................................................................................................19
4.4
Integrazione dei dati ...........................................................................................................................................................................21
4.5
La granularità in un Data Warehouse..............................................................................................................................................23
5
Lo Yield Management per una catena di hotel ............................................................................................................................................28
5.1
Esperienza di data warehouse............................................................................................................................................................28
5.2
La base di dati di partenza .................................................................................................................................................................29
5.3
Lo schema proposto ............................................................................................................................................................................30
5.4
Gli strumenti utilizzati........................................................................................................................................................................33
5.5
Gli strumenti sul mercato...................................................................................................................................................................34
5.6
La prova di Miner DataTM ..................................................................................................................................................................36
6
Conclusioni.......................................................................................................................................................................................................37
6.1
Codice di creazione tabelle .................................................................................................................................................................38
6.2
Codice di importazione dati ...............................................................................................................................................................40
6.3
Codice dei test ......................................................................................................................................................................................41
42