Il Data Warehouse

Capitolo settimo
La filosofia Data Warehouse
Capitolo settimo
La filosofia Data Warehouse
7.1. Introduzione
Il mercato di riferimento geografico di un'azienda non è più il paese o il continente,
ma l’insieme dei grandi paesi industrializzati1. Si parla, dunque, di
globalizzazione dei mercati, intendendo con questo termine il fatto che i
mercati locali, essendo fra loro interdipendenti, diventano un tutt’uno. Tutto
ciò determina per le imprese, sia nuove opportunità, sia un aumento della
pressione competitiva. La pressione competitiva aumenta anche a causa della
deregolamentazione e liberalizzazione di tutti i settori. Linee aeree, ferrovie,
telecomunicazioni, servizi di fornitura d'energia ed acqua hanno tutti
assistito alla fine del supporto governativo delle posizioni monopolistiche
permettendo a nuovi fornitori di entrare nei mercati e di scegliersi gli utenti.
Le imprese, nell’ambito delle strategie di Business2, devono affrontare la
competizione attraverso nuovi, più veloci, più attraenti modi che
conquistarsi gli acquirenti3.
La forza della competizione è legata all’efficienza del mercato. L'efficienza del
mercato dipende dalla facilità d'accesso dello stesso da parte dell’utente e
dalla quantità d'informazioni disponibili al consumatore su tutti i prodotti
del mercato.
Le nuove tecnologie ampliano sia l’accessibilità del mercato, sia la
conoscenza dei prodotti da parte dell’utente, avvicinandolo sempre più
all’accesso perfetto e alla perfetta informazione.
In una situazione di questo tipo la competizione tende ad essere più dura4.
J.J. Lambin :”Marketing”, McGraw-Hill.
“La redditività di una impresa dipende da due fattori :la redditività del settore in cui opera
e la capacità dell’impresa di stabilire un vantaggio competitivo rispetto ai suoi rivali. La
scelta del settore o dei settori riguarda la strategia a livello corporate. Stabilire un vantaggio
entro un particolare settore è ciò che si propone di stabilire la strategia a livello di business.”
R.M. Grant : L’analisi strategica nella gestione aziendale.
3
Si possono portare alcuni esempi : assistenza diretta via telefono, home-banking e shopping via cavo o tramite Internet.. The second Age of Computing Data Warehousing with Oracle. R. Stewart. 4
“Un esempio : Un giocatore di golf residente a N.Y. prenderà in considerazione (e quindi è limitato) per il suo equipaggiamento da golf solo i fornitori di N.Y.. Al contrario con un PC ed un equipaggiamento internet, una carta di credito il nostro giocatore di golf può
velocemente acquistare da qualsiasi fornitore nel mondo che effettui pubblicità sulla rete.
297
1
2
Capitolo settimo
La filosofia Data Warehouse
Per avere un vantaggio competitivo in un ambiente caratterizzato
dall’industria globale, innovativa, deregolamentata, sempre più aggressiva,
le imprese devono migliorare la loro comprensione del business, dei loro
clienti, dei loro mercati. Devono conoscere con esattezza chi sono i clienti,
come fare a mantenerli, come e quando spendono il loro denaro, quali beni e
servizi saranno acquisiti, da chi e così via . Le imprese devono focalizzare le
loro energie su questi elementi in modo tale da poter sfruttare al massimo le
diverse e mutevoli opportunità che si presentano. Se ciò non avverrà, i clienti
andranno altrove.
Nella produzione di massa
ha sempre più importanza la cosiddetta
personalizzazione del prodotto. Oggi non è più sufficiente per un'azienda
portare un qualsiasi prodotto di massa o servizio sul mercato maturo ed
aspettarsi di venderlo abbastanza bene per un certo periodo di tempo. Il
cliente chiede un prodotto più personalizzato, che soddisfi meglio i suoi
bisogni.
Per sopravvivere in questi mercati le imprese avranno bisogno di identificare
in modo più adeguato i bisogni dei consumatori, segmentando il mercato
stesso, per offrire prodotti che si avvicinino il più possibile alle richieste di
questo o di quel segmento. Anche se il prodotto in se stesso non può essere
Questo fatto rende la vita dei fornitori di attrezzature di golf di N.K. più difficile.” The
second Age of Computing Data Warehousing with Oracle. R. Stewart.
4 Caratteristiche dello scenario Industriale :
? Maggiore concorrenza
? Diffusione/Omogeneizzazione della Tecnologia
? Incertezza economica
? Ritmo di crescita più basso
? Minore prevedibilità dei clienti
? Riduzione del Time-to Market
? Re-engineering dei processi Aziendali
? Aggiornamento dell’offerta
? Valorizzazione della base dei Clienti Esistenti
Fonte :Data Warehouse, metodologia, Architettura e prodotti. Presentazione Datamat per il
gruppo FIAT.
298
Capitolo settimo
La filosofia Data Warehouse
personalizzato, il modo di fornirlo e con cui si effettua il pagamento può
esserlo.
Questa situazione genera una maggiore richiesta di informazioni per
conoscere meglio i clienti, i mercati, la concorrenza.
Le fonti di queste informazioni si trovano all’esterno
ma innanzi tutto
all’interno dell’impresa. La tecnologia dei computer è stata applicata fin dai
primi anni di attuazione ai processi operativi di un'impresa
(sistemi di
fatturazione, emissione di ricevuta, prenotazioni, gestione degli ordini di
vendita, controllo del magazzino, finanza, ecc..).
Attraverso i sistemi operazionali attualmente in uso, una grande quantità di
dati viene raccolta e conservata. Questi dati descrivono con molta precisione,
e spesso implicitamente, gli aspetti critici del business : clienti, mercati,
prodotti, vendita e le relazioni che intercorrono tra questi. Tali informazioni
devono essere rese disponibili a coloro che ci lavorano sopra : direttori, lo
staff di marketing, gli analisti di business e di prodotti, ecc..
Così come sono prodotti, questi dati “operazionali” non riescono a
soddisfare le esigenze di chi deve lavorare con l’informazione attraverso
particolari applicazioni DSS, MIS o altro. Questi dati, così come sono raccolti,
sono destinati a servire i sistemi operazionali per i quali sono stati creati. E
non potrebbe essere altrimenti ; in altre parole non si potrebbe riconfigurare
la raccolta di questi dati, che devono servire particolari operazioni per
accogliere le esigenze informative, poiché verrebbe meno quello che è il loro
scopo originario che deve essere senz’altro soddisfatto.
Una soluzione è quella di duplicare i dati liberandoli dai confini dei diversi
sistemi per integrarli ed arricchirli con informazioni di provenienza esterna
(ricerche di mercato, analisi industriali, notizie da agenzie, reti mondiali ed
altro). Devono, inoltre, essere predisposti dei Tools (strumenti) che mettano
in grado i vari utenti di analizzare le informazioni a loro disposizione.
Il Data Warehouse si occupa proprio di questo.
299
Capitolo settimo
La filosofia Data Warehouse
In un'interpretazione più limitata un Data Warehouse è semplicemente il database o
i database in cui i dati rilevanti dei sistemi operativi sono copiati e resi disponibili
agli utilizzatori di informazioni attraverso strumenti analitici di indagine. In un
senso più ampio rappresenta l’intera struttura di estrazione di dati grezzi dai sistemi
operativi, di trasformazione in informazioni affidabili, di trasporto in apposito
ambiente per l’utente delle informazioni e la fornitura degli strumenti on-line per
analizzare questi dati (OLAP Tools, data mining, ecc..) al fine di fornire conoscenza
alla Direzione del business5.
7.2. Evoluzione dei sistemi di raccolta dati
Le aziende hanno sempre cercato di raccogliere dati. In passato ciò era
possibile solo tramite mezzi cartacei. Successivamente si è avuto l’avvento di
mezzi meccanici ed elettronici che hanno facilitato questa attività.
In un primo momento (anni ‘60) venivano create solo applicazioni con dati
legati alle applicazioni stesse. Questo faceva si che per ogni applicazione si
aveva un archivio, creando così evidenti problemi di ridondanza dei dati.
. The second Age of Computing Data Warehousing with Oracle. R. Stewart.
“il Data Warehouse è un processo, non un prodotto. Questa rappresenta una particolare
tecnica per assemblare e gestire dati provenienti da varie sorgenti per realizzare una singola
, dettagliata vista di una parte o di tutto il business.” White paper di NCR Corporation : Data
Warehousing :Clearing the Confusion.
“Il D/W nasce dalla costituzione di un ambiente, fisicamente separato dal database
operazionale, ottimizzato per le interrogazioni e il supporto alle decisioni. C’è, quindi, una
netta distinzione tra sistema operazionale e sistema decisionale.......Sono differenti anche gli
utenti dei due sistemi : nel primo caso è lo staff operazionale dell’azienda (contabili, addetti
agli sportelli..), mentre nel secondo sarà il top il middle manager a servirsi dei dati del D/W
per l’analisi, l’accesso e la produzione di report.” P. Lombardi : Nuovi strumenti per cercare
i dati, Zerouno 3/1995
B. Cortona nell’articolo di Zerouno del 4/1995 afferma :” La nascita del concetto di
warehouse (magazzino) risale alla metà degli anni ’80 ma solo dai primi anni ’90 ha iniziato
a trovare la piena attuazione. L’idea che sta alla base è molto semplice : estrarre dai database
operazionali i dati significativi, compattarli e metterli infine a disposizione degli strumenti
desktop, che effettuano le proprie interrogazioni sul warehouse e non più sui database
operazionali.”
D. Sandri nell’articolo :La soluzione del SAS Insititute di Zerouno del 4/1995 afferma : “Il
Data Warehouse è in sostanza una soluzione tecnologica con la quale i dati vengono
archiviati secondo un bes determinato formato che ne facilita l’accesso e la consultazione da
parte degli utenti. In genere interessa non tutti gli utenti di una azienda, ma per lo più i
decision maker, quelle persone che nell’ambito dell’impresa hanno bisogno di dati di sintesi
provenienti dalle varie unità aziendali, sui quali operare ulteriori elaborazioni e grazie ai
quali simulare scenari e prendere infine decisioni.”
5
300
Capitolo settimo
La filosofia Data Warehouse
Verso gli anni ’70 cominciano a diffondersi i primi gestori di basi dati in cui
si realizza una separazione fra le applicazioni e gli archivi dati. Allo stesso
modo si diffondono nuovi supporti fisici per la registrazione (dischi
magnetici). Una singola base di dati può servire più applicazioni. Verso gli
anni ’80 prendono il via le tecnologie distribuite, per cui le applicazioni che
erano dirette ai decisori potevano essere spostate più vicino ad essi
(attraverso l’uso dei PC). Si comincia a pensare di poter utilizzare i dati di
questi database, costruiti però per servire specificatamente le transazioni,
per sistemi MIS o DSS. Ma le difficoltà per realizzare questi sistemi erano
molte. Sempre negli anni ’80 si sono creati dei programmi capaci di estrarre i
dati da una base di dati, secondo vari criteri, per trasferirli altrove. Questi
dati a loro volta possono essere trasferiti ancora in altri database creando la
possibilità di avere schemi come quelli in figura.
Software per
estrarre i dati
Figura 7.1. Legacy system
Questa “ragnatela” viene chiamata legacy system.
301
Capitolo settimo
La filosofia Data Warehouse
7.3. Problemi con la naturale evoluzione della architettura. L’evoluzione di questa architettura pone alcuni problemi per l’utilizzo diretto di applicazioni DSS, EIS ed analisi6 . I principali problemi sono :
?
la credibilità dei dati
?
la produttività
?
l’incapacità di trasformare i dati in informazioni.
Mancanza di credibilità dei dati.
Il primo di questi problemi è quello della mancanza di credibilità dei dati.
Inmon porta il caso di due dipartimenti che realizzano due report sullo
stesso tema con i dati del legacy ottenendo due risultati differenti. Di fronte
a queste incongruità il management non sa bene cosa fare. Ci sono alcune
ragioni che possono causare questa incongruità :
?
i report non si sono effettuati nello stesso tempo
?
scelta di parametri differenti per l’analisi dei di dati
?
problemi con i dati esterni
?
utilizzo di fonti diverse
Realizzare i report in istanti di tempo differenti può portare a dei risultati
diversi poiché nel tempo trascorso si sono verificate delle transazioni che
possono aver mutato i dati. La scelta di parametri differenti per l’analisi dei
di dati può allo stesso modo produrre risultati differenti qualora, ad
esempio, si decida di prendere in considerazione tutte le polizze vita o solo
quelle più vecchie. I dati esterni che spesso vengono utilizzati nei report non
sono coordinati fra di loro e non c’è neppure coordinamento con i dati interni
utilizzati. Ad esempio, per realizzare un report possono essere stati utilizzati
dati del Wall Street Journal mentre in un altro i dati di Business Week. I dati
dei due giornali, anche se riguardano lo stesso argomento, possono essere
“......Convinti delle promesse dei produttori che il loro sistema di gestione dati sarebbe
stato in grado di soddisfare sia le necessità di produzione (l’OLTP) che di supporto alle
decisioni, gli EDP aziendali hanno per qualche tempo scelto di far accedere gli utenti
direttamente ai database operazionali. In breve hanno dovuto fare marcia indietro dopo
aver constatato che le operazioni sui dati tipiche dell’analisi per il supporto decisionale sono
molto diverse da quelle tipiche dell’OLTP e pesanti nell’esecuzione.” B. Cortona :Come
accedere ai patrimoni di dati, Zerouno 4/1995
302
6
Capitolo settimo
La filosofia Data Warehouse
diversi Più in generale poi, ci possono essere delle discrepanze nei risultati
dovuti alla scelta di fonti diverse per realizzare lo stesso report.
Il problema della produttività
Un altro problema è quello relativo alla produttività, ovvero alla efficienza
dovuta alla naturale evoluzione di questa struttura. Per realizzare i report
occorrerà localizzare i dati che sono sparsi nel legacy, estrarli e realizzare
programmi di analisi dei dati.
I dati che servono in un report sono sparsi nel legacy. Questi si sono
stratificati nel tempo senza pensare che un giorno si sarebbero dovuti
integrare. Per cui, stessi dati potranno avere nomi diversi come dati diversi
potranno avere lo stesso nome. Quindi, localizzare i dati è un processo
difficile e noioso.
Una volta localizzati, i dati devono essere estratti. Per ogni fonte di dati si
dovrà realizzare un programma per l’estrazione. Infine, si dovrà realizzare il
report. Tutte queste attività occupano tempo, ed un eccessivo impiego dello
stesso può portare a realizzare dei report che non hanno nessun valore
perché non sono più attuali.
Dai dati all’informazione
Un altro limite della architettura legacy è quello relativo alla capacità di
fornire informazioni. I decisori hanno bisogno di informazioni di carattere
complesso derivanti dall’aggregazione di
più
fonti.
Spesso
questa
integrazione è difficile poiché i dati vengono estratti da database che non
sono stati progettati per servire questi scopi, ma per supportare delle
transazioni. Inoltre, un altro limite è rappresentato dall’orizzonte temporale
dei dati. Mentre i decisori hanno bisogno di informazioni storiche che
mostrino gli andamenti passati e le previsioni sul futuro, ai database
operazionali interessa solo mantenere aggiornati i dati e, quindi, tendono ad
avere la memoria più corta (perché si tengono in linea solo i dati correnti).
303
Capitolo settimo
La filosofia Data Warehouse
7.4. Il magazzino dei dati
Per superare l’empasse dei problemi visti fino ad ora si è trovata la soluzione
Data Warehouse. Il cuore di questa architettura si basa su due tipi di dato.
Quello primitivo residente nel legacy e quello derivato residente nel
Warehouse. I dati derivati sono ricavati in tutto o in parte da quelli primitivi
e posti nel Warehouse (o repository), vale a dire un grande database. Il Data
Warehouse è di sola lettura e periodicamente viene aggiornato. Quindi, fra
un aggiornamento e l’altro i dati sono sempre gli stessi, al contrario dei
database operazionali che sono soggetti ad un continuo mutamento.
Si possono distinguere nel Data Warehouse quattro livelli.
Il primo è il livello operazionale composto di dati primitivi del legacy ed
eventualmente di altre fonti esterne. Il secondo è quello del Warehouse (o
repository) in cui i dati, dopo una attività di acquisizione vengono inseriti a
livello atomico. I dati non vengono letti direttamente da qui ma verranno
ulteriormente estratti o sintetizzati nei Datamart (terzo livello, o livello
dipartimentale)7, che rappresentano database destinati a servire particolari
funzioni richieste dall’utente finale (analista DSS, data mining, ecc..). Il
quarto livello è quello individuale, ovvero quello dell’analista o del decisore
che con il suo PC utilizza delle applicazioni che vanno a “pescare” dati dal
Datamart per effettuare l’attività di analisi.
Se la struttura logica di un Data Warehouse si dispone su questi quattro
livelli, la struttura “fisica”, o meglio hardware, è un Client Server. Infatti,
l’analista opera con le sue applicazioni da PC mentre i vari database
risiedono su server. Quindi, l’ambiente è quello di una rete con elaborazione
distribuita8.
Un Datamart rappresenta uno speciale subset di dati estratti da una unità centrale e tali
dati vengono selezionati per servire una particolare funzione o applicazione.” White Paper
di NCR corporation : Data Warehousing :Clearing the Confusion
8
L’architettura C/S può essere a due o atre livelli. I sistemi a due livelli sono piuttosto semplici.
Il client spesso definito Fat client perché svolge la maggior parte della elaborazione, comunica al server
le richieste di accesso al database mediante SQL o attraverso una interfaccia come ODBC. Nei sistemi
a tre livelli, l’elaborazione viene in buona parte affidata ad un application server distinto. In questo
modo l’interfaccia utente, l’aspetto elaborativo e la gestione del database vengono separati. A.
Dickman Zerouno 2/1996 (trasduzione da InformationWeek)
304
7
Capitolo settimo
La filosofia Data Warehouse
Figura 7.2. Livelli del Data Warehouse
7.5. Il costo del Data Warehouse
La valutazione dell’investimento in strutture Data Warehouse non può
essere fatta tramite tecniche classiche come, ad esempio,
il
ROI. E’
impossibile “pianificare” e verificare quali siano i reali costi e benefici che
questo tipo di architettura determina 9. Fortunatamente il Data Warehouse è una
architettura incrementale, per cui si può costruire un primo Data Warehouse con un
“Realizzare una soluzione di Data Warehousing ben dimensionata sulle esigenze aziendali
comporta tutta una serie di difficoltà da superare ; non soltanto nei criteri e nei metodi di
implementazione ma anche nella capacità dell’azienda di supportare nel tempo questa scelta
a fronte di una chiara valutazione dei costi diretti (software, hardware, reti) e soprattutto
quelli indiretti, quali la definizione e il mantenimento della organizzazione preposta al ruolo
di gestore del Data Warehouse (con figure professionali dedicate) , con tutte le complesse
problematiche relative all’aggiornamento periodico dei dati estratti
dai data base
operazionali e inseriti nel Data Warehouse in funzione delle differenti esigenze di supporto
decisionale sparse nell’azienda” S. Uberti Foppa :Quando serve un D/W, Zerouno 4/1995
Inmon in una intervista rilasciata a Giorgio Marras di Zerouno del giugno 1996 affermava
che per ogni dollaro speso per soddisfare le esigenze dell’executive community se ne
spendono almeno 9 per acquisire dati dalle applicazioni legacy e trasferirli all’ambiente EIS.
Questo in assenza di un ambiente Data Warehouse. Attraverso il D/W questa componente
di costo tende a scendere.
9
305
Capitolo settimo
La filosofia Data Warehouse
modesto impiego si denaro. Una volta che la prima porzione di D/W è stata costruita
l’analista può esplorarne le possibilità10.
Comunque una società di ricerche, Metrica, ha realizzato una indagine su
117 aziende Europee (non ci sono aziende italiane) al fine di valutare quale
fossero i vantaggi economici e commerciali del D/W legati a sistemi DSS.
Il 55% del campione ha già inserito sistemi di Data Warehouse e il 30% ha
deciso di realizzarlo nei prossimi due anni.
Solo 31 delle 64 aziende che hanno implementato sistemi DSS e D/W hanno
potuto o saputo quantificare in termini economici il vantaggio portato dalla
scelta effettuata. Le altre non sono state capaci di definire i criteri di
valutazione economica o di misura dei risultati.
Queste 31 aziende hanno valutato in media un guadagno attribuito all’uso di
un DSS basato su D/W pari a 5,4 milioni di dollari. Il settore delle
telecomunicazioni mostra un guadagno maggiore
(10,1 milioni), seguito
dalla distribuzione (8,6 milioni), dalla finanza (7,8 milioni) e dagli altri (3,2
milioni).
Il guadagno che un DSS può portare
12
Milioni di $
10
8
6
Finanza
4
Distrib
2
Telecom
0
Altri
1
10
W.H. Inmon :”Building The Data Warehouse”
306
Capitolo settimo
La filosofia Data Warehouse
Figura 7.3. Guadagno che un Dss può portare (fonte Zerouno)
Più visibili dei benefici economici sono i vantaggi commerciali. Il
miglioramento del servizio al cliente rappresenta uno dei risultati maggiori,
seguito dall’aumento dell’efficienza operativa, dal miglioramento della
redditività del cliente dalla migliore comprensione del mercato tramite
segmentazione. Ovviamente le ricadute sul business variano da comparto a
comparto. Le aree di maggiore applicazione del D/W sono oggi quelle delle
vendite e marketing e (nelle società finanziarie) della gestione dei rischi e
redditività.
Una delle principali sfide che si presenta, ad esempio, alle
banche per lo sviluppo delle attività a livello regionale è quella di garantire
un servizio al giusto prezzo alle persone giuste e nel giusto modo, vale a dire
in termini redditizi. L’unica via per raggiungere questo scopo è possedere
informazioni su ogni cliente e saperle utilizzare al momento opportuno.
Utilizzi di Data Warehouse
Dati totali
30%
55%
15%
Giallo :non previsto
Azzurro :previsto entro due anni
Granata :Dispone di un DSS
307
Capitolo settimo
La filosofia Data Warehouse
Dati per settore
Distribuzione
Finanza
21%
17%
62%
33%
0%
67%
Altri
Telecomunicazioni
33%
36%
40%
56%
11%
24%
Giallo : Dispone di un DSS
Granata : Non previsto
Azzurro :previsto entro 2 anni
Figura 7.4. Data Warehouse attuali o pianificati nelle aziende europee (Fonte : METRICA)
7.6. L’ambiente Data Warehouse
Il vero cuore dell’ambiente architetturale Data Warehouse è il warehouse o
repository. Questo rappresenta una singola integrata sorgente di dati
destinata a fornire materiale utile per il DSS processing.
Un Data Warehouse è una collezione di dati che supporta le decisioni del
management ed è orientato al soggetto, integrato, non instabile e a tempo
differente11.
Orientato al Soggetto
11
W.H. Inmon “Building of the Data Warehouse”
308
Capitolo settimo
La filosofia Data Warehouse
Si può portare come esempio di orientamento al soggetto12 quello di una
compagnia assicuratrice. Le classiche operazioni di sistema sono organizzate
intorno alle applicazioni della compagnia. Per una compagnia assicuratrice le
applicazioni possono essere auto, vita, danni, ecc.. Invece le grandi aree
soggetto della compagnia possono essere cliente, polizze, premi e richieste.
Ambiente operazionale
Auto
Vita
Salute
Danni
Applicazioni
Ambiente Data
Warehouse
Clienti
polizze
premi
richieste
Soggetti
Figura 7.5. Un esempio di orientamento al soggetto
In generale il Data Warehouse è orientato su quelli che sono i grandi soggetti
della organizzazione, i quali sono stati definiti nel modello dei dati.
I soggetti tipici sono :
?
cliente
?
prodotto
?
transazione o attività
?
ecc..
Le tabelle presenti nella base dei dati sono strutturate sui soggetti
dell’azienda come si vede nell’esempio in figura.
Sicuramente il Data Warehouse contiene solo tipi di informazioni utili al processo
decisionale ; ad esempio i dati non sono organizzati per applicazione (come acquisti,
spedizioni, ecc..) bensì per soggetto (per nome del cliente, piuttosto che per vendite dei
maglioni in una determinata area, oppure per richieste di indennizzi, ecc..). Inoltre, i dati
devono essere memorizzati in base a regole definite. Non è un problema da poco se si
considera che i data base operazionali da cui provengono i dati, sono strutturati secondo
12
309
Capitolo settimo La filosofia Data Warehouse
Base dei dati del
cliente 1985-1987
Base dei dati del
cliente 1988-1990
Attività del cliente 1986-1989
Cliente ID
dalla data
Alla data
nome
indirizzo
telefono
sesso
..........
Cliente ID
dalla data
Alla data
nome
valutazione del credito
Impiego
indirizzo
telefono
...........
sesso
Cliente ID
mese
Numero di transazioni
medie nel mese
Numero di transazioni
più elevate per mese
Numero di transazioni
più basse per mese
......................................
Figura 7.6. Esempio di organizzazione del D/W per soggetto cliente (Building the D/W)
Un aspetto fondamentale delle tabelle riguardanti il soggetto è che queste
sono tutte collegate da una chiave comune (in questo esempio Cliente ID) in
modo tale da realizzare una correlazione fra tutti i dati riguardanti un
cliente. Un altro aspetto fondamentale è che i dati relativi al soggetto
possono risiedere anche su differenti mezzi di memorizzazione.
Cliente
Dati del cliente
1985-1987
Attività del cliente
dettagli
1987-1989
Dati del cliente
1988-1990
Attività del cliente
1986-1989
Attività del cliente
dettagli
1990-1991
Figura 7.7. Il soggetto può essere tenuto in differenti mezzi di memorizzazione
convenzioni (codici di identificazione clienti, merci) e modelli (gerarchici, relazionali, flat
file). S. Umberti Foppa : Quando serve un D/W, Zerouno 4/1995
310
Capitolo settimo
La filosofia Data Warehouse
I dati che hanno una maggiore probabilità di accesso e un basso volume di
immagazzinamento, risiederanno su mezzi che possono garantire un accesso
più veloce e che sono relativamente più cari. Invece i dati che hanno una
bassa probabilità di accesso e che sono di volume considerevole risiederanno
su di un mezzo più economico e meno veloce.
Un elemento importante è che esiste nel D/W un livello di sintesi ed un
livello di dettaglio per gli stessi dati (granularità). Saranno, quindi, i dati
dettagliati, i quali sono più voluminosi e con minore probabilità di accesso ad
essere registrati su mezzi più economici, come i nastri magnetici ad esempio,
mentre i dati di sintesi meno voluminosi e con maggiore probabilità di acceso
saranno registrati invece su dischi fissi.
Altro elemento fondamentale che deve essere sempre presente nelle tabelle è
il tempo.
Integrato
I dati che derivano dalle varie fonti aziendali presentano delle caratteristiche
differenti. Questi dati devono per questo essere integrati e resi uniformi nel
D/W che li andrà ad accogliere.
Integrazione
Operazionale
Data Warehouse
Codice
Applic. A
Applic. B
Applic. C
Applic. D
m,f,
1,0
x,y
m,f
Maschio, femmina
Attributi di misura
Applic. A
Applic. B
Applic. C
Applic. D
cm,
pollici
yards
mcf
cm
sorgenti multiple
311
Capitolo settimo Applic. A
Applic. B
Applic. C
Applic. D
La filosofia Data Warehouse
descrizione
descrizione
descrizione
descrizione
?
Descrizione
conflitti di chiavi
Applic. A
Key char (12)
Applic. B
Applic. C
Applic. D
Key dec fixed (9,2)
pic ‘9999999’
Key char (10)
Key char
(12)
Figura 7.8. Esempi di integrazione
Non instabile
L’ambiente operazionale è soggetto ad una regolare attività di accesso e
manipolazione. Si effettua un continuo aggiornamento dei dati nell’ambiente
operazionale. Invece nel D/W i dati vengono tutti caricati (solitamente in
massa) nel Warehouse, e poi una volta caricati si accede ad esso. Ma
l’aggiornamento dei dati (in senso lato) non viene effettuato nell’ambiente
D/W.
Tempo differente
L’ultima caratteristica rilevante è quella della differenza di tempo rispetto
all’ambiente operazionale. La differenza di tempo si può verificare in diversi
modi :
? L’orizzonte temporale del D/W solitamente è molto più lungo di quello
operazionale. Ad esempio, l’orizzonte temporale di un ambiente
operazionale può essere dai 60 ai 90 giorni mentre quello D/W può essere
dai 5 ai 10 anni.
? I database operazionali contengono solo “valori correnti” i quali possono
essere in ogni momento acceduti e modificati, mentre il D/W rappresenta
niente altro che una sofisticata serie di istantanee prese in un dato istante
di tempo.
312
Capitolo settimo La filosofia Data Warehouse
? La struttura delle chiavi nell’ambiente operazionale può avere come non
avere alcuni elementi di tempo (giorno, mese, anno) mentre nell’ambiente
D/W la struttura della chiave deve sempre contenere un elemento
temporale.
7.6.1. Il Data Warehouse come evoluzione
Inmon afferma che il Data Warehouse non è una rivoluzione ma bensì una
evoluzione nel tempo. Quindi, il D/W si costruisce gradualmente. Questo
permette di poter realizzare delle modifiche “in corsa” e di poter verificare
qual è l’utilità nelle varie parti per le quali è stato creato. Questo può
spingere l’azienda ad estendere la positiva esperienza anche ad altre parti
della stessa.
In un primo momento il popolamento del Warehouse sarà limitato ad una
sola area soggetto. In momenti successivi anche i dati riguardanti le altre aree
soggetto identificate dall’azienda popoleranno il Warehouse (detto anche
repository). Una volta popolato il repository, si collegheranno ad esso alcuni
Datamart i quali estrarranno dal repository stesso i dati necessari alle
specifiche analisi DSS e saranno sistemati in una forma (modello) più
consono al tipo di funzione che si dovrà svolgere. L’esperienza positiva a
livello dipartimentale potrà a questo punto essere ripetuta per altre parti
dell’azienda realizzando altri Datamart per finalità differenti.
Tutto questo processo si svolgerà in un arco di tempo che può essere molto
lungo che di norma si aggira intorno a qualche anno.
7.6.2.Due elementi concettuali del Data Warehouse
I due elementi concettuali di maggior peso in un Data Warehouse sono la
granularità dei dati e la partizione dei dati.
Con la granularità dei dati ci si riferisce ai diversi livelli di dettaglio che
caratterizzano il D/W, mentre con partizione dei dati ci si riferisce invece ad
313
Capitolo settimo
La filosofia Data Warehouse
una separazione dei dati in diverse unità fisiche e che possono essere maneggiati in
maniera indipendente13.
7.6.2.1. La granularità
In una architettura D/W esistono solitamente diversi livelli di dettaglio dei
dati. Questo, ovviamente, riflette gli usi che si dovrà fare di quei dati. In
questo ambito si possono stabilire solo una serie di indicazioni riguardo le
scelte del livello di dettaglio da realizzare nel D/W ma ogni caso fa storia a
se.
Un esempio di diversi livelli di dettaglio può essere dato dalla figura
sottostante. In questo caso viene mostrata una struttura D/W in cui a livello
più basso si trovano i dettagli relativi alle vendite di un certo periodo molto
indietro nel tempo. A livello più elevato si pone il repository, cioè il nostro
Warehouse, in cui si trova quello che, in questo caso, viene detto livello di
dettaglio corrente delle vendite. Da questo magazzino dei dati saranno poi
estratti e portati al livello più elevato di Datamart dei dati che verranno
ulteriormente sintetizzati (vendite di un particolare prodotto per mese o per
settimana) ed utilizzati per le varie ricerche DSS o DataMining.
M
E
T
A
D
A
T
A
13
Dati sintetici (Datamart)
ES : vendite mensili
per linea di prodotto ‘81-‘92
Dati sintetici (Datamart)
ES : vendite settimanali
per linea di prodotto ‘84-‘92
Dettaglio corrente
ES : vendite ‘90-‘91
W.H. Inmon : “Building of the Data warehouse”
314
Capitolo settimo
La filosofia Data Warehouse
Vecchio dettaglio
ES : vendite 84-89
Figura 7.9. Esempio di struttura del Data Warehouse
Questo rappresenta solo uno dei tanti esempi di struttura D/W il quale non
deve però essere minimamente considerato come regola. Diversa all’interno
dei livelli esaminati può essere l’articolazione del dettaglio, come può essere
diverso anche il tipo di informazioni residenti, ad esempio, nei mezzi di
registrazione più economici. Possono essere inserite non solo delle
informazioni di dettaglio più vecchie ma anche informazioni di minor
importanza che vengono tenute per motivi ad esempio legali, oppure hanno
un grado di dettaglio maggiore che nel repository e costituiscono quello che
viene chiamato true archival.
L’importanza della granularità (cioè del livello di sintesi dei dati) si pone in
rapporto all’uso che si deve effettuare dei dati nelle analisi DSS, MIS o altro.
Ad esempio, cercare delle informazioni ad un livello di dettaglio più basso
può essere più laborioso che cercare le stesse informazioni ad un livello di
dettaglio meno elevato poiché si dovrà ricercarle in un minor numero di
record i quali, inoltre, occuperanno anche un minore spazio in memoria.
Granularità
Basso livello di dettaglio
ESEMPIO :
dettaglio delle chiamate
telefoniche per mese dei
clienti
40.000 bytes per mese
200 records per mese
Alto livello di dettaglio
ESEMPIO :
sintesi delle chiamate
telefoniche per mese dei
clienti
200 bytes
1 record per
mese
Figura 7.10. Esempio di diversi livelli di sintesi
315
Capitolo settimo
La filosofia Data Warehouse
In generale si può parlare di due livelli di granularità dei dati all’interno di
un’azienda. Questi due livelli riflettono due bisogni diversi. Il primo
risponderà a quelle che sono le esigenze di automazione di certe procedure,
per cui si tratta di un livello eminentemente operazionale in cui i dati che
servono all’azienda devono essere manipolati. Anche per questo il data base
avrà una struttura particolare che faciliti le operazioni da realizzare (in
questo caso l’ambiente è quello operazionale e l’orizzonte temporale è breve).
L’altro livello è quello in cui i dati risultano da una sintesi di dei precedenti.
Questi ultimi sono deputati al servizio di sistemi DSS di supporto alle
decisioni.
Ora, solitamente nel repository entrano dati di natura operazionale che
possono essere sia di dettaglio che leggermente sintetizzati. Questi dati non
saranno sfruttati direttamente dall’analista DSS, ma costituiranno quel
magazzino da cui i vari Datamart dipartimentali estrarranno i dati necessari
per le loro analisi producendo eventualmente una ulteriore sintesi dei dati
stessi.
7.6.2.2. La partizione dei dati
IL secondo grande elemento di natura concettuale è quello relativo alla
partizione. Partizionare i dati significa dividere i dati in separate unità fisiche
in modo tale che questi possano essere meglio “maneggiati”, in quanto le
unità sono indipendenti ed in caso di eventuali guasti la gestione delle parti
rispetto ad un tutto indistinto può essere per questo più facile.
E importante sapere non se la partizione deve essere fatta ma come la partizione deve
essere fatta14.
14
W.H. Inmon :”The Building of the Data Warehouse”
316
Capitolo settimo
La filosofia Data Warehouse
1991
1993
******
******
******
******
******
******
1992
******
******
******
1994
******
******
******
1990
******
******
******
1995
******
******
******
La partizione dei dati
?
?
divisione dei dati in più piccole unità
fatta a livello di applicazione o a livello di DBMS
Figura 7.11. Esempio di partizione di dati
Molti sono i criteri secondo cui i dati possono essere suddivisi, ad esempio :
? per data
? per linea di business
? per distribuzione geografica
? per unità organizzative
? per uno o più criteri insieme
? ecc..
La partizione può avvenire sia a livello DBMS che a livello di applicazione.
In quest’ultimo caso questa partizione viene effettuata dal codice del
programma ed è controllata strettamente dal programma e dall’utente che
svolge le sue funzioni e le sue analisi.
317
Capitolo settimo
La filosofia Data Warehouse
Nell’ambito D/W la partizione dei dati ha senso solo a livello di
applicazione, in quanto i criteri per partizionare i dati e per ottenere da
questi informazioni, aggregandoli ogni volta in maniera differente, possono
essere molteplici. Se questa partizione di dati avvenisse a livello di sistema (o
DBMS) si limiterebbero possibili aggregazioni dei dati scegliendo dei criteri
di aggregazione che poi rimarrebbero costanti e rigidi nel tempo. Questo
inficerebbe la flessibilità di utilizzo dei dati in un modo differente da quello
prestabilito.
Il DBMS, quindi, deve essere considerato nel D/W come una unica parte da
cui le varie applicazioni o le interrogazioni possono di volta in volta
selezionare i dati a loro necessari seguendo criteri diversi. I DBMS dovranno
avere caratteristiche tali da non ostacolare la diversa suddivisione dei dati a
seconda dei diversi criteri scelti.
7.6.3. Struttura dei dati nel Data Warehouse:
Le strutture dei dati nel D/W possono essere molteplici ed ognuna riflette al
meglio quelli che sono i bisogni dell’azienda. Possono però essere indicati
alcuni tipi di strutture più conosciute come:
? simple cumulative
? rolling summary
? simple direct
? continuous
Nella simple cumulative le transazioni quotidiane vengono trasportate
dall’ambiente operazionale a quello D/W e sintetizzate in un record. La
sintetizzazione può essere effettuata per cliente, per conto, oppure per tutti
gli altri grandi soggetti del D/W. La sintetizzazione avviene solitamente in
maniera giornaliera, per cui i dati relativi ai clienti, ai conti ecc.. saranno nel
repository su base giornaliera.
318
Capitolo settimo
La filosofia Data Warehouse
Transazioni quotidiane
Dati operazionali
Sintesi
su base
giornaliera
1 gen 2 gen
3 gen ....
1 feb 2 feb
3 feb ....
1 mar 2 mar
3 mar ... ........................................
Figura 7.12. Struttura dati simple cumulative
Nella struttura rolling summary le sintetizzazioni sono più di una. E’ simile
alla precedente però, raggiunto un certo numero di sintetizzazioni
giornaliere (mettiamo siano trascorsi 7 giorni), il dato viene sintetizzato in
una nuova struttura (che in questo caso prende il nome di settimana). A loro
volta i dati così sintetizzati possono subire ulteriori sintetizzazioni ( ad
esempio per mesi, anni ecc..). Questa struttura di dati è adatta nei casi in cui
le unità di dati siano molto poche ed abbiano una struttura cumulativa.
319
Capitolo settimo
La filosofia Data Warehouse
Transazioni quotidiane
Dati operazionali
Sintesi
su base
giornaliera
.........
1 day 2 day 3 day ............. 7 day .........
week1 week 2 week 3......... week5
.........
mon1 mon2
mon3 ...........mon12
.........
year 1
year 2 year 3 ............year n
Figura 7.13. Struttura rolling summary
Nella struttura simple direct i dati vengono estratti direttamente dall’ambiente
operazionale senza sintetizzarli. Questa struttura non rappresenta che una
fotografia dei dati operazionali in un certo istante di tempo. I dati non sono
estratti su base giornaliera come i precedenti. I periodi di tempo scelti
possono essere più lunghi come la settimana o il mese. Quindi, potremo
avere, ad esempio, dati sui clienti per il mese di gennaio, febbraio ecc..
Clienti di Gennaio
320
Capitolo settimo
La filosofia Data Warehouse
Rossi Mario
via Verdi 45
Roma
Bianchi Antonio via Magellano 2
Genova
Boghetto Maurizio via Lavagnini 23
Agliana
Paolino Paperino via Vicolo stretto
Paperopoli
........................... ........................... .................
.......................... ........................... .................
Dati operazionali
Figura 7.14. Struttura simple direct
Quando si hanno 2 o più semplici file direct si può creare un file continuous.
In esso confluiscono i dati, ad esempio, di tutti i mesi considerati.
Clienti di Gennaio
Rossi Mario
via Verdi 45
Roma
Bianchi Antonio via Magellano 2
Genova
Boghetto Maurizio via Lavagnini 23
Agliana
Paolino Paperino via Vicolo stretto Paperopoli
........................... ........................... .................
.......................... ........................... .................
Clienti di Febbraio
Dei Paperoni Paperon via Dell’oro
Paperopoli
Bianchi Antonio via Magellano 2
Genova
Boghetto Maurizio via Lavagnini 23
Agliana
Paolino Paperino via Vicolo stretto
Paperopoli
Baldo Bracco
viale Dei giardini
Monopoli
........................... ........................... .................
Rossi Mario
via Verdi 45
Roma
Dei Paperoni Paperon via dell’oro
Paperopoli
Bianchi Antonio via Magellano 2
Genova
Boghetto Maurizio via Lavagnini 23
Agliana
Paolino Paperino via Vicolo stretto
Paperopoli
Baldo Bracco
viale Dei giardini
Monopoli
........................... ........................... .................
Figura 7.15. Creazione di un continuous file da direct files
7.7. Il disegno del Data Warehouse
I due maggiori aspetti realizzativi del Data Warehouse sono l’interfaccia di
estrazione dai Database operazionali (fase di acquisizione dei dati) e il
321
Capitolo settimo
La filosofia Data Warehouse
disegno della architettura Data Warehouse vera e propria (architettura
D/W)15.
Parlare solo di disegno per la realizzazione di un
Data Warehouse è
riduttivo. In un primo momento il D/W viene “popolato” di dati (in base alle
prime specifiche di mapping concordate fra progettisti e utenti finali). I dati
inseriti nella struttura di D/W vengono poi utilizzati dagli strumenti DSS.
Successivamente, in base alle informazioni di ritorno che si otterranno dagli
utilizzatori finali, questo Data Warehouse potrà variare, nel senso che nuovi
dati, nuove fonti di dati o modifiche dei dati già presenti nello stesso
potranno verificarsi col tempo (feedback).
7.7.1. Si parte dai dati operazionali
Il punto di partenza è senz’altro rappresentato dai dati operazionali. Questi
si trovano nei database e nelle applicazioni deputate a svolgere funzioni di
carattere operazionale. E’semplicistico affermare che i dati provenienti dalle
varie fonti saranno estratti da queste ed inseriti nel Warehouse perché tutto
ciò non riflette esattamente la realtà.
Estrarre i dati dai più database o applicazioni implica tutta una serie di
problematiche che devono essere accuratamente valutate e risolte.
Mancanza di integrazione
Un primo problema è quello della mancanza di integrazione dei dati in
quanto questi possono provenire da più fonti. Tali dati sono sorti, non tanto
per soddisfare le esigenze del D/W, ma piuttosto per determinati problemi
di carattere operazionale senza pensare che questi , un giorno, avrebbero
dovuto integrarsi con altri. Può accadere, ad esempio , quello che la figura
mostra.
“Spesso la costruzione di un magazzino dei dati separato dai data base operazionali
rientra all’interno di più ampi progetti di revisione del sistema informativo, come un
15
322
Capitolo settimo
La filosofia Data Warehouse
Mutui
Stessi dati,
differenti nomi.
Leasing
Differenti dati,
stesso nome.
Fidi
Dati che si
trovano solo qui
Port.glio Clienti
Differenti chiavi,
stessi dati.
Figura 7.16. Difficoltà nel riconoscere i dati fra le varie applicazioni (Building the D/W)
Come si vede può accadere che gli stessi dati abbiano nomi differenti oppure
dati differenti possano avere gli stessi nomi ecc..
Occorre effettuare un’attività di analisi dei dati volta a realizzare una
integrazione degli stessi portandoli tutti ad un formato uniforme, a
controllarne
la
validità
arricchendoli,
eventualmente,
di
ulteriori
informazioni che si possono ricavare implicitamente dai dati stessi16.
Un esempio di attività di integrazione è rappresentata dalla codifica dei dati
(vedere la figura sugli esempi di integrazione).
Questi esempi mostrano come di per sé le attività di integrazione non siano
difficili ma, moltiplicando queste
per un numero elevato di file coinvolti
nella integrazione, provenienti da una moltitudine di fonti, si potrà vedere
come gli intrecci fra i vari tipi di file rendano tale attività di integrazione
molto complessa.
Efficienza di accesso
Un altro problema è quello della efficienza di accesso ai sistemi operazionali
esistenti. Come si fa ad accedere ai sistemi operazionali esistenti e scaricarli
nel Warehouse e come si fa nell’attività di aggiornamento a riconoscere quali
downsizing delle applicazioni da ambiente mainframe centralizzato ad architetture client
server”. S Umberti Foppa :Quando serve un D/W , Zerouno 4/1995
323
Capitolo settimo
La filosofia Data Warehouse
sono i dati già scansionati precedentemente (e quindi già esistenti nel Data
Warehouse) da quelli nuovi. E’ impensabile che ogni volta i dati vengano
scansionati e trasferiti nel Warehouse. I tipi di caricamenti nel D/W per
Inmon sono tre :
1. Scarico da archivio dati (dati storici)
2. Scarico di dati correnti contenuti nell’ambiente operazionale (dati correnti)
3. Scarico nel Warehouse dei cambiamenti intervenuti nell’ambiente
operazionale dall’ultimo aggiornamento (modifiche dati)
Lo scarico dei dati storici presenti nell’ambiente operazionale non determina
grandi problematiche poiché avviene raramente, ovvero quando si ha il
primo popolamento del Data Warehouse e in seguito quando nuove fonti
vengono aggiunte. Allo stesso modo i dati correnti (nuovi) non danno grossi
problemi perché possono essere caricati in un file sequenziale e poi da questo
nel Data Warehouse senza provocare una modifica dell’insieme dei dati già
esistenti nello stesso. E’il terzo caso, quello relativo alle modifiche dei dati
esistenti, che pone i maggiori problemi.
Si devono riconoscere in questo ambito le modifiche intervenute nei file
esistenti. Occorre, dunque, individuare particolari tecniche affinché queste
modifiche dei dati già residenti nel Data Warehouse, intervenute fra un
aggiornamento e l’altro, siano riconosciute in fretta e scaricate nel Data
Warehouse. Vengono proposte per questo alcuni procedimenti.
Una prima pratica è quella del time stamp. Si scansionano tutti i dati delle
fonti prendendo come discriminante il tempo di modifica. Si sceglieranno
per l’aggiornamento solo quei dati con tempo di modifica posteriore a quello
dei dati esistenti nel Warehouse. Però questa tecnica è molto gravosa per il
sistema perché si devono controllare tutti i dati. Un’altra tecnica è quella dei
file delta, che sono file destinati ad accogliere solo i cambiamenti intervenuti
nelle applicazioni in un certo periodo di tempo. Quando viene costruito un
delta file il processo di scansione dei dati diviene efficiente in quanto
16
Per vedere queste fasi in dettaglio consultare il capitolo relativo al progetto MIDA nella
324
Capitolo settimo
La filosofia Data Warehouse
vengono toccati solo quei dati che in un certo tempo T si modificano. Ma la
realizzazione di un delta file non è un caso molto frequente. Può essere
utilizzato in luogo di un delta file i log file. Il log file contiene essenzialmente
gli stessi dati del delta, ma rispetto a questo ci sono alcune differenze. I log
sono costruiti per il processo di recovery ed è proprio perché è destinato a
servire questa funzione che il suo utilizzo è molto problematico17.
Una ulteriore tecnica è quella del before and after. Attraverso questa tecnica,
più teorica che pratica, si effettuerà prima di ogni estrazione una immagine
del database fonte e si confronterà con quella effettuata l’estrazione
precedente. Dal confronto dei due file si evidenzierà solo le variazioni
intervenute nel tempo intercorso fra le due estrazioni. Tuttavia questo
procedimento è molto laborioso e si può utilizzare solo come ultima risorsa.
Dati correnti
Un altro problema è rappresentato dai dati correnti ed in particolare dalla
validità di questi dati. Con questo si intende che un dato corrente al
momento in cui viene catturato ed inserito nel Warehouse ha una sua
validità. Ma in un momento immediatamente successivo può perdere questa
validità poiché nel frattempo tale dato è mutato. Di conseguenza, nel Data
Warehouse vengono a trovarsi dei dati che non sono veritieri e non possono
essere modificati per un certo periodo. Per limitare questa situazione di
“errore” dovuta a dati che cambiano velocemente nel tempo si dovrà
realizzare degli accorgimenti. Certi tipi di dati che si modificano con grande
velocità nel tempo possono essere valutati non singolarmente ma
complessivamente entro un certo ? T(daily balance, weekly balance, monthly
balance). Si valuterà cioè, il loro mutamento nel tempo. Sarà questo dato
complessivo che entrerà nel Warehouse rendendolo certamente più stabile e
veritiero del singolo dato.
parte che riguarda l’acquisizione dei dati.
17
Per vedere queste fasi in dettaglio consultare il capitolo relativo al progetto MIDA nella parte che riguarda l’acquisizione dei dati.
325
Capitolo settimo
tx
La filosofia Data Warehouse
Current value
Current value
Bilancia
gior.era
Bilancia
sett.le
Bilancia
Mensile
Figura 7.17. La condensazione dei dati è un fattore vitale nella gestione del d/w
Scelta dei dati.
Occorre stabilire in maniera accurata quali sono i dati di cui si abbisogna. Il
rischio che si corre è quello di creare degli enormi database con una massa di
dati inutilizzati di cui, con l’andare del tempo, se ne può perdere il controllo
poiché le dimensioni del Data Warehouse aumentano smisuratamente
rispetto alle esigenze reali, mandando in crisi il sistema.
7.7.2. Modello dei dati
Un passo molto importante nel disegno del Data Warehouse è quello della
progettazione concettuale e della scelta del modello dei dati del grande
database centrale (repository o warehouse). La scelta del modello può essere
diversa a seconda della architettura che si è progettato. Ad esempio, se si
realizza una struttura classica di Data Warehouse in cui c’è un grande
database centrale che dovrà servire tutta una serie di Datamart, allora
occorrerà garantire a questo una certa flessibilità nel tempo. Ovvero, il
326
Capitolo settimo
La filosofia Data Warehouse
repository dovrà essere in grado di accogliere sia dati che si modificheranno
nel tempo, sia nuovi dati, sia nuovi tipi di dati.
Si deve garantire, quindi, che questo database non sia di ostacolo ad una
evoluzione del progetto ma che, al contrario , ne favorisca l’evoluzione
inserendo le nuove componenti senza difficoltà come i tasselli di un grande
puzzle. La struttura, inoltre, dovrà garantire il massimo dell’affidabilità.
Per questo tipo di esigenze viene scelta solitamente una struttura relazionale
che oltre a basarsi su solide fondamenta matematiche (che ne fanno una
struttura dalle caratteristiche ben definite), permette una integrazione e una
modifica dei dati senza grandi stravolgimenti. Si costruisce, quindi, un vero e
proprio magazzino dei dati che sarà sempre stabile nel tempo e facilmente
integrabile.
L’utente per i suoi bisogni non accederà ai dati direttamente dal magazzino
ma dai vari Datamart, che “pescano” le informazioni dal magazzino stesso.
Questi Datamart sono database costruiti per soddisfare le particolari richieste
dell’utente in modo più efficiente possibile. I modelli che possono essere
scelti
sono
molteplici
e
vanno
dal
relazionale
(con
qualche
denormalizzazione), allo schema a stella o a quello a fiocco di neve ( che
sono, però, anch’essi una derivazione del modello relazionale), al modello ad
oggetti, ai modelli multidimensionali.
Se il progetto non prevede la realizzazione di un magazzino centrale che
serve più Datamart, ma la sola realizzazione di un Datamart è logico che il
modello scelto rifletterà direttamente le esigenze dell’utilizzatore. Però ,
questo fatto può limitare molto gli sviluppi futuri del progetto di Data
Warehouse proprio per le caratteristiche del modello scelto che è destinato a
servire certe funzioni piuttosto che altre
e che spesso ha una struttura
proprietaria come i modelli ad oggetti e quelli multidimensionali
limitandone le possibilità di espansione e di accesso.
327
Capitolo settimo
La filosofia Data Warehouse
7.7.3. Data Warehouse come istantanea
I Data Warehouse che si possono costruire per servire le funzioni più diverse all’interno di una azienda sono di vario tipo (marketing, finanza, vendite,
produzione, ecc..). Nonostante però le diversità che si possono trovare nei
vari d/w esiste un elemento che non varia mai . Internamente ogni Data
Warehouse fa perno su di una struttura di dati chiamata “snapshot”.
Le istantanee sono create come risultato di determinati eventi. Ogni evento determina una snapshot, vale a dire un record che presenta certe componenti. Si ha, quindi, una interazione fra :
EVENTO? SNAPSHOT
Evento
Snapshot
Tempo
Chiave
Dati primari Dati secondari
Figura 7.18. Rappresentazione della struttura di una snapshot
Questi eventi possono essere generati da particolari attività oppure dal
passare del tempo. Le prime sono attività che si verificano in base ad un
determinato accadimento e non si sa se e quando si verificheranno
(telefonata di un cliente, una polizza di assicurazioni ecc..), mentre le seconde
si verificano per il naturale passare del tempo, come la fine del giorno, della
settimana, del mese.
Un record di Data Warehouse è una istantanea fatta in un determinato
istante di tempo ed include una varietà di dati.
Una snapshot contiene molti componenti i quali possono essere distinti in 4
gruppi :
1. la chiave
2. l’unità di tempo
3. i dati primari legati alla chiave
4. i dati secondari non legati alla chiave
328
Capitolo settimo
La filosofia Data Warehouse
La chiave è l’elemento identificativo del record, però identifica solo i dati che
sono direttamente legati ad essa (dati primari). L’altro elemento caratteristico
nel D/W è il tempo. Questo indica il momento in cui il dato è stato catturato
e ha preso posto nel D/W. In alcuni casi si distinguerà fra il momento in cui
il dato è stato catturato dal D/W da quello in cui il dato è effettivamente
sorto. I dati primari sono campi che non costituiscono la chiave e che sono
direttamente legati ad essa. Ad esempio, si supponga che la chiave identifichi
le vendite dei prodotti. L’elemento di tempo descrive quando questa vendita
è avvenuta. I dati primari descrivono quale prodotto è stato venduto, a quale
prezzo, le condizioni di vendita, chi è stata la controparte, e così via.
I dati secondari descrivono altre informazioni non propriamente legate
all’oggetto primario del record ma che si possono catturare al momento della
creazione delle snapshot. Un’informazione secondaria , ad esempio, relativa
alla vendita del prodotto può essere quella del tasso di interesse applicato
dalle banche al cliente al momento in cui si verifica la vendita stessa. Si tratta,
cioè, di informazioni incidentali che si otterranno a causa di quella
particolare operazione. Queste informazioni non hanno una correlazione
diretta con la chiave che identifica quel particolare evento ma comporranno
insieme agli altri dati la snapshot. Come è logico pensare, i componenti che
sicuramente costituiranno i record di snapshot saranno i primi tre mentre i
dati secondari possono anche non apparire.
Nel più semplice caso di D/W ogni individual activity (ogni singolo evento),
che risulta essere interessante per l’utente finale, viene inserita nel
Warehouse. Si può così, stabilire un rapporto uno ad uno fra questa attività e
la snapshot (una attività, una snapshot).
Si consideri un esempio particolare, quello relativo al pagamento di una
polizza assicurativa. Il premio viene pagato semestralmente , per cui ogni sei
mesi verrà creato un record nel Warehouse che descrive il pagamento del
premio, la cifra pagata, il luogo dove deve essere pagato, e così via.
329
Capitolo settimo
La filosofia Data Warehouse
Quando si ha a che fare con un piccolo volume di dati stabili e quando c’è
bisogno di un meticoloso livello di dettaglio, allora si può pensare di
impiegare semplicemente le individual actiivity. Ma non sempre è così.
In molti casi si ha a che fare con un volume elevato di dati i quali possono
essere soggetti a numerosi cambiamenti col passare del tempo. Inoltre, è
difficile che le analisi di business richiedano un elevato livello di dettaglio.
Quando si verifica una sola di queste situazioni occorre creare una nuova
categoria di dati nel D/W. Si parlerà di aggregate o profile record. Questo
record rappresenta l’aggregazione di un certo numero di individual activity.
Quindi , la differenza fra i due tipi di record è che l’individual activity è un
singolo evento mentre il profile rappresenta una aggregazione di eventi
uguali (ad esempio, si può considerare come singolo evento la rilevazione
del chilometraggio di una vettura, mentre si può considerare una
aggregazione la media di più rilevazioni). Si può dire , allora, che il profile è
un dato di sintesi che potrà trovare posto nel repository o nel Datamart.
Operazionale
Data Warehouse
Clienti
Chiamata 1
Chiamata 2
Chiamata 3
Chiamata 4
.
.
.
.
Cliente/mese
......................................
......................................
......................................
......................................
......................................
......................................
......................................
Chiamata n
Figura 7.19. Creazione di un profile record da una serie di record dettagliati relativi alle
chiamate giornaliere dei clienti di una azienda.
330
Capitolo settimo
La filosofia Data Warehouse
Creare dei profile record è una vera e propria tecnica di gestione del volume
dei dati, poiché attraverso la realizzazione di questi record si può ottenere
una riduzione notevole del volume dei dati presenti nel D/W.
La creazione del profile può essere mirata alla realizzazione di record che
hanno diversi livelli di sintesi. Inoltre, gli stessi profile possono essere
soggetti a loro volta a sintesi. Tutto dipende dalle specifiche che l’utente
fornisce. Però, ogni volta che si usa la tecnica del profiling si ha una perdita
di dettaglio, quindi di dati. Ma la perdita non può e soprattutto non deve
essere una cosa negativa quando a perdersi sono quei dati che non hanno
rilevanza ai fini dell’analisi DSS. In questo modo, anzi, ne guadagnerà la
capacità informativa del dato. Occorre, quindi, che questi dati siano ben
identificati dall’utente insieme all’architetto D/W.
Si può decidere, qualora non si vogliano perdere i dettagli, di realizzare degli
archivi appositi che li contengano.
Attraverso il D/W si è detto che si realizza una istantanea. L’ambiente
monitorizzato nel D/W è quindi quello che si ha in un istante di tempo. Fra
un aggiornamento e l’altro molti dati possono cambiare e quindi la fotografia
può non essere più così vera. Per cui si può correre il rischio di effettuare
delle analisi che possono in un determinato momento non rispecchiare più la
verità. Si parla in questo caso di ciclicità dei dati riferendosi all’intervallo di
tempo trascorso fra un aggiornamento e l’altro. Il problema, quindi, è quello
di individuare, in base al tipo di dati inseriti nel D/W e alle necessità
dell’utente, qual è il tempo che dovrà trascorrere tra un aggiornamento ed un
altro. Si parla anche di wrinkle of time18.
18
W.H. Inmon :”building the Data Warehouse”
331
Capitolo settimo
La filosofia Data Warehouse
Wrinkle of time
24 h di ritardo
Cambia
Cambia
Figura 7.20. Wrinkle of time
7.7.4. IL Metadata
Un aspetto molto importante dell’architettura Data Warehouse è il Metadata.
Il Metadata viene definito come il dato dei dati ed assomiglia molto da vicino
ad un dizionario dei dati. E’, dunque una base dei dati che descrive la base
dei dati stessa. Concettualmente viene visto come un tutt’uno in cui si danno
informazioni su cosa si trova dentro il D/W19.
“Il Metadata è il dato dei dati. Il Metadata fornisce le informazioni richieste riguardo
all’automazione del processo di raccolta, trasformazione e caricamento dei dati nel
warehouse. Provvede all’amministrazione del Warehouse con tutte le strutturali e
monitorate informazioni che permettono una efficiente organizzazione del warehouse.
Inoltre, provvede alla visualizzazione del contenuto dei dati del warehouse, permettendo
all’utente finale di navigare nel warehouse attingendo da esso i dati che gli servono. S.
Anderson and E. Walker “Building a SAS Data Warehouse”, SAS Institute, 1995”. IBM nella sua White Paper sul Data Warehouse (Data Management solution) descrive in
metadata in questi termini : Il Metadata descrive le informazioni gli elementi dei dati o i tipi dei dati, come file, report, processi di workfow, e altro. Viene tipicamente utilizzato nei
database tradizionali, ma nell’ambiente Data Warehouse esso assume un importante
funzione per gli end-users.....Essi hanno bisogno di conoscere i dati di cui possono disporre, che cosa essi effettivamente rappresentano, quali occorrono , e così via.....” F Turconi nell’articolo apparso su Informatica oggi & Unix afferma : Il Metadata indica il
componente di controllo e di relazione fra oggetti...........Esempi intuitivi di metadata sono :
? la modalità di utilizzo di un dato
? un algoritmo di encode/decode dati ;
? del codice usato frequentemente ;
? La descrizione dei processi di conversione/trasformazione.
Il Metadata ha diverso significato e utilizzo a seconda del livello in cui si trova e viene
utilizzato :
332
19
Capitolo settimo
La filosofia Data Warehouse
Le notizie che tipicamente sono inserite nel Metadata riguardano :
? la struttura dei dati come è conosciuta dal progettista
? la struttura dei dati come è conosciuta dell’analista
? le sorgenti di dati che alimentano il D/W
? la trasformazione dei dati nel passaggio dalle fonti al d/w
? il modello dei dati
? le relazioni fra il modello dei dati e il D/W
? La storia delle estrazioni
C’è, comunque, una profonda differenza del ruolo del Metadata in un
ambiente operazionale rispetto ad un ambiente D/W.
Ambiente operazionale
Data Warehouse
Metadata
Uso
saltuario
Progettista
Metadata
Uso
continuativo
Analista
DSS, EIS
Figura 7.21. Diverso uso del Metadata ni due ambienti operazionale e D/W
?
?
?
Negli ambienti di produzione e operazionali per documentare i dati esistenti e arricchire
i processi di manutenzione ;
nel warehouse per indirizzare gli utenti ai dati e documentare il mapping fra i dati ;
negli ambienti distribuiti e dipartimentali per disciplinare e organizzare evitando che le
visioni parziali influenzino i contenuti attuali dei dati.
333
Capitolo settimo
La filosofia Data Warehouse
Una prima differenza nasce dal tipo di utente del Metadata nei due ambienti.
Nell’ambiente operazionale è il progettista che usa il Metadata quando deve
“agire” su esso, e cioè quando si devono portare delle modifiche, ad esempio
su delle tabelle di dati. L’uso in questo caso è saltuario.
Nel D/W è l’analista DSS che deve utilizzare il Metadata per verificare quali
sono i dati a sua disposizione, da dove provengono, qual è il loro grado di
sintesi, e così via. L’utilizzo del Metadata è in questo caso continuo.
Un’altra ragione delle differenze fra Metadata nell’ambiente operazionale e
di quello D/W è dovuto al fatto che nel D/W il Metadata deve accogliere la
gestione del mapping .
Ambiente operazionale
Data Warehouse
Mapping
Metadata
Figura 7.22. Il Mapping dei dati da inserire nel D/W (Building the D/W)
Questa attività di mapping è molto più complessa nell’ambiente D/W
rispetto a quello operazionale. Occorre, in effetti, realizzare attività come la
conversione, il filtraggio, la sintesi, cambi di struttura e così via. Queste sono
tutte attività che non rientrano in una mappatura operazionale.
Una terza ragione sta nel fatto che mentre nell’ambiente operazionale si ha
una sola definizione dei dati poiché contiene dati correnti, il D/W deve
gestire più strutture/definizioni dati. Tutto ciò è dovuto al fatto che il D/W è
un contenitore di dati storici e nel tempo la struttura e la definizione dei dati
334
Capitolo settimo
La filosofia Data Warehouse
possono variare mentre questi problemi nel sistema operazionale non si
hanno per il semplice motivo che questo si occupa solo della gestione dei dati
correnti.
Ambiente operazionale
Data Warehouse
Metadata
Metadata
Struttura
Contenuto
Struttura
...........
............
Contenuto
93
94
95
96
97
00
Figura 7.23. Il D/W contiene dati che riguardano un lungo periodo di tempo che devono essere
gestiti che hanno strutture/definizioni diverse. L’ambiente operazionale contiene solo una
singola e corretta definizione dei dati di un solo tempo.
Comunque, anche se concettualmente il Metadata è un tutt’uno, fisicamente
si suddivide in più Metadata. Ci sarà un Metadata ad uso del progettista che
da notizie relative al processo di acquisizione dei dati oltre che dei dati
335
Capitolo settimo
La filosofia Data Warehouse
presenti nell’architettura e ci sarà un Metadata ad uso degli utenti finali
legati alle applicazioni da essi utilizzate.
7.7.5. Ritorno dei dati all’ambiente operazionale
Il normale processo che caratterizza il D/W prevede un’acquisizione dei dati
dalle varie fonti, ma non prevede che ci sia un procedimento inverso, vale a
dire un ritorno dei dati dall’ambiente D/W a quello operazionale. E’
possibile, comunque, che qualche volta si verifichino casi di D/W in cui si
abbia questa situazione.
Query
Data Warehouse
Applicazione legacy
Risultato
della query
Figura 7.24. Ritorno del risultato di una query al l'ambiente legacy (Building of the D/W)
La figura mostra un caso in cui viene effettuato sul D/W una query. Il
risultato di questa query porterà a modificare i dati della legacy application
da cui è partita.
336
Capitolo settimo
Richiesta di
finanziamento
La filosofia Data Warehouse
Banca
query
ON-LINE
Dati storici sui
clienti
Dati
correnti sul
cliente
Risposta
Preapprovazione
Richiesta
Approvata
o
Rigettata
Figura 7.25. Richiesta di finanziamento in un Istituto bancario
7.8. Dati esterni/non strutturati e Data Warehouse
I dati che interessano l’azienda sono di due tipi : interni ed esterni.
I dati interni sono quelli su cui l’azienda costruisce in un primo momento il
proprio d/w. Sono caratterizzati dall’essere strutturati, ovvero hanno un
formato regolare e stabilito a priori.
337
Capitolo settimo
La filosofia Data Warehouse
I dati esterni sono invece definiti non strutturati e cioè di formato non
prevedibile data la molteplicità delle fonti da cui possono derivare20.
Il d/w può prevedere il loro immagazzinamento e ciò sarebbe auspicabile.
Ma più frequentemente questi dati vengono inseriti manualmente da PC
nell’elaborazione dei rapporti. Questo crea alcuni problemi :
il dato viene preso all’esterno ed utilizzato nel report senza avere esatte
indicazioni relative alla fonte dei dati da cui provengono ed inoltre,
entrando all’interno dell’azienda sotto forma di report, sarà difficile
richiamare questi dati in momenti successivi per essere utilizzati di nuovo.
Occorre, quindi, che l’entrata di dati esterni nel d/w sia prevista e in qualche
modo disciplinata, affinché il dato esterno risulti da fonti certe ed affidabili,
potendo così essere facilmente trovato come qualunque dato interno.
7.8.1. Inserimento dei dati esterni/non strutturati nel Data Warehouse
Ci sono alcune questioni che devono essere risolte per realizzare
l’inserimento dei dati esterni/non strutturati nel d/w. Queste possono
essere riassunte in quattro categorie :
1. frequenza di apparizione
2. forma del dato
3. imprevedibilità della cattura
4. dati multimediali
20
Le fonti esterne dei dati possono essere molteplici. Inmon ne indica qualcuna :
? the Wall street Journal
? Business Week
? Forbes
? Fortune
? Corrispondenze industriali
? Rapporti tecnologici
? Dun and Bradstreet
? Rapporti creati da consulenti specificatamente per l’azienda
? Rapporti di analisi competitive
? Rapporti di raffronti ed analisi di vendita
? Internet
? ecc.
338
Capitolo settimo
La filosofia Data Warehouse
La prima questione riguarda la realizzazione di un appropriato sistema di
monitoraggio per la cattura sistematica del dato quando questo viene in
essere in maniera regolare21. La seconda riguarda la forma dei dati esterni, la
quale è totalmente indisciplinata. Per poter essere utilizzati i dati devono
essere trasformati in un formato che sia compatibile con quello dei dati
interni del d/w. La terza riguarda l’imprevedibilità della venuta in essere
del dato che può venire da una sorgente e in un tempo imprecisato che ne
rende estremamente ardua la cattura. La quarta questione è relativa alle
difficoltà di immagazzinare un nuovo tipo di dato che è quello
multimediale. I due più comuni tipi di dati multimediali sono la voce e
l’immagine. I problemi con questi dati derivano dalla immaturità della
tecnologia necessaria per poterli immagazzinare e consultare. A questo
riguardo esiste una particolare tecnologia che si sta imponendo per il
trattamento ed immagazinamento di questi dati multimediali che è quella
degli oggetti (vedi capitolo 5). In più, il dato multimediale, essendo per
natura un dato “pesante” dal punto di vista della occupazione dello spazio
di memoria, può produrre un enorme aumento delle dimensioni del d/w e
un rallentamento del tempo di caricamento dei dati.
7.8.2. Metadata e dati esterni
Sappiamo come il Metadata sia un componente fondamentale per il d/w in
ogni scenario. Anche nel caso dei dati esterni presenti nel d/w assume un
ruolo fondamentale. Attraverso il Metadata si può accedere e controllare i
dati esterni che sono stati inseriti attraverso tutta una serie di informazioni
presenti nello stesso22. Scorrendo il Metadata l’utilizzatore può verificare
Spesso un dato esterno può essere naturalmente ripetitivo e quindi può essere sottoposto
anche ai cosiddetti ”report secondari” che non sono altro che una sintesi del dettaglio
primario inserito nel d/w. Per maggiori informazioni vedere Building of the Data Warehouse di
W.H. Inmon pag. 270
22 Il contenuto tipico di un Metadata per i dati esterni comprende :
? documento ID
? data di entrata nel warehouse
? descrizione del documento
339
21
Capitolo settimo
La filosofia Data Warehouse
quali dati esterni sono disponibili per la sua ricerca e se quei dati gli servono
o no. In associazione con il Metadata può essere utilizzato il Notification file
che è un file creato per gli utilizzatori del sistema indicante quali classi di
dati possono essere rilevanti per loro.
Quando un dato viene inserito
nell’ambiente d/w e nel Metadata viene comunicato a chi può essere
interessato a ciò in modo tale che questo utilizzatore sia a conoscenza
della presenza di tali dati.
Spesso, soprattutto per ragioni di costo, non è conveniente immagazzinare
tutte le informazioni esterne nel d/w. Si può tenere traccia di queste nel
Metadata ed indicare in quale altro mezzo (schedari, nastri magnetici, ecc. ) è
possibile ritrovarle.
I dati esterni hanno un loro periodo di vita utile per l’azienda per cui, una
volta trascorso il periodo in essere, si dovranno eliminare per far posto ad
informazioni più attuali. Queste, comunque, possono essere sempre inserite
in archivi esterni di cui se ne può dare notizia nel Metadata.
7.8.3. Confronti fra dati interni e dati esterni
Uno dei più importanti usi delle informazioni esterne è quello di confrontare
i dati interni all’azienda con quelli esterni. Ad esempio, si può confrontare
l’andamento del mercato di un prodotto di un settore con quello
dell’azienda. Affinché i dati possano essere confrontabili occorre però che
dati interni e dati esterni siano letti sulla base di una chiave comune. Ad
esempio, se l’impresa vende una bibita a base di cola e vuole comparare
l’andamento delle sue vendite con quelle del settore delle bibite dovrà
accertarsi che i dati esterni non comprendano anche la vendita di altre bibite
?
?
?
?
?
?
?
?
sorgente del documento
data della sorgente del documento
classificazione del documento
indice delle parole
data di eliminazione
riferimento alla locazione fisica
lunghezza del documento
riferimenti ad altri documenti
340
Capitolo settimo
La filosofia Data Warehouse
come, ad esempio, la birra. L’andamento della vendita della birra può falsare
la lettura dei dati esterni nel confronto con quelli interni. Occorre quindi
cautela nel utilizzo dei dati esterni i quali devono essere resi comparabili con
quelli interni, “depurandoli” di tutti quei fattori che ne possono falsare la
lettura.
7.9. Data Warehouse o Datamart
L’architettura di un Data Warehouse classica prevede un repository centrale
nel quale confluiscono i dati da tutte le fonti (legacy o esterne). Questi dati
verranno poi “ribaltati” sui Datamart, dai quali accederanno direttamente gli
utenti.
Un’alternativa a questa architettura sarebbe quella di costruire
direttamente dei Datamart (si parla in questo caso di Dipartimantal Data
Warehouse) in cui i dati entrino direttamente dalle varie fonti per essere
utilizzati senza che vi sia la “mediazione” del repository. Questo tipo di
approccio nella parte iniziale della prima implementazione è molto meno
costoso di quello classico mentre nelle fasi successive di sviluppo il costo
cresce notevolmente per problemi di integrazione23. Avere un repository
centrale con dati in forma atomica e normalizzati, in modo tale che si possa
sempre effettuare una integrazione degli stessi senza creare stravolgimenti,
permette di avere a disposizione dati che potranno essere utilizzati da
qualunque Datamart che in seguito si volesse creare. Realizzare direttamente
dei Datamart può provocare alcuni problemi :
Un Data Warehouse centrale fornisce una crescita per future espansioni e abilità alla
realizzazione successiva di un Data Warehouse a più livelli, ma ha costi di sviluppo più
elevati (oltre 200-300 milioni di lire) e tempi di realizzazione lunghi (oltre i 18- 24 mesi) e
impone carichi di lavoro e prestazioni più elevate sui sistemi e sulla rete. Una architettura
alternativa è costituita dai Datamart, database disegnati per una singola funzione o
applicazione. Questi sono più facili da realizzare. I Datamart richiedono investimenti di
sviluppo di software nell’ordine di 30-40 milioni di lire in tempi di tre o quattro mesi (spesso
si adattano a pacchetti esterni), offrono una buona disponibilità e prestazioni con assetti
tecnologici esistenti ;tuttavia i dati non sono integrati e possono sorgere problemi con le
applicazioni successive.” F. Turconi :Il costo nascosto dei D/W, Zerouno, 6/1996
341
23
Capitolo settimo La filosofia Data Warehouse
? Moltiplicazione dei processi di acquisizione dati. Si avrà un processo di
acquisizione per ogni Datamart.
Applic a
Marketing
Applic b
Finanza
Vendite
Applic c
Produzione
Applic d
Applic e
engineering
Applic f
Risorse
umane
Produzione
Applic g
Figura 7.26. Esemplificazione di problemi di Acquisizione dati (Building the D/W)
? Non c’è integrazione fra i dati dei diversi Datamart.
? Difficoltà di manutenzione di una struttura di soli Datamart. Ad esempio,
un singolo cambiamento in una vecchia applicazione legacy può
costringere ad effettuare tante
modifiche quanti sono i Datamart che
utilizzano questa fonte.
342
Capitolo settimo La filosofia Data Warehouse
? Impossibilità di realizzare un unico metadata e, in caso di integrazione,
difficoltà di aggiornamento dello stesso. La complessità di aggiornamento dei
cataloghi informativi, distribuiti, eterogenei, fra di loro e provvisti a volte di
interfaccie diverse è costosa se il numero di applicazioni cresce nel futuro24.
7.10. Il Data Warehouse distribuito
La maggior parte delle organizzazioni costruisce e mantiene un singolo data
warehouse centralizzato. In effetti, per molte ragioni il data warehouse
centralizzato è preferito rispetto al data warehouse distribuito in quanto un
data warehouse centralizzato offre una maggiore garanzia di integrazione
dei dati i quali possono essere efficacemente utilizzati a livello di corporate.
Però, esistono dei casi in cui in data warehouse distribuito si impone. Questo
ha senso nelle organizzazioni che hanno una forte autonomia a livello locale
e dipartimentale e nelle quali l’elaborazione è distribuita in maniera
fortemente decentralizzata. E’il caso, ad esempio, di società multinazionali
che devono operare in realtà molto diverse l’una dall’altra per cui la scelta
dei dati necessari per le analisi dei decisori spesso ha un “taglio” ed un
significato differente. Esistono diverse forme di data Warehouse distribuito.
7.10.1. Il Data Warehouse locale e il Data Warehouse globale
Il d/w distribuito può solitamente essere composto da tanti d/w locali e da
un eventuale d/w globale. Il d/w locale contiene dati che sono solo di
interesse locale. Questo tipo di d/w ha le stesse funzioni dei d/w
centralizzati eccetto lo scopo che è invece locale. In altre parole, il d/w locale
contiene dati storici locali e non ci si preoccupa dell’integrazione dei propri
dati del d/w locale con quelli di altre parti dell’organizzazione.
24
F. Turconi :I costi nascosti del D/W , Zerouno 6/1996
343
Capitolo settimo
La filosofia Data Warehouse
Europa
Africa
Sistema
Operazionale
Locale
Local
D/W
Sistema
Operazionale
Locale
USA :
sede generale
Local
D/W
Asia
Sistema
Operazionale
Locale
D/W Globale
Local
D/W
Figura 7.27. Esempio di D/W locali e D/W globale
Nella figura possiamo vedere come possono essere articolati dei d/w locali.
I d/w locali possono essere articolati, ad esempio, in base alle diverse
dislocazioni geografiche o in base alle diverse comunità tecnologiche o di
prodotto che animano la corporate. Ognuno dei d/w locali estrae dal proprio
sistema operazionale i dati che gli servono e li inserisce nel proprio d/w
senza badare a realizzare una integrazione dei propri dati con quelli degli
altri d/w locali. Ma per alcuni aspetti la corporate può essere interessata ad
avere un d/w globale. Questo interesse è tanto maggiore quanto maggiori
sono i “punti di contatto” , ovvero la comunanza dei dati esistenti fra i vari
siti locali. Questi dati comuni fra i vari siti “indipendenti”, proprio in quanto
interessano la corporate nel suo insieme, devono essere estratti in via di
principio direttamente dai sistemi operazionali locali e non dai d/w locali
perché questi ultimi inseriscono questi dati nel loro d/w locale seguendo
344
Capitolo settimo
La filosofia Data Warehouse
solamente quelle che sono le loro finalità, mentre la corporate vede gli stessi
dati sotto un interesse diverso che è quello globale25.
Essenziale per la corretta realizzazione di un d/w distribuito è la mappa dei
dati dai sistemi operazionali locali al d/w globale. Questa mappa dovrà
comprendere tutti i dati che sono comuni ai vari siti e che potranno essere
efficacemente utilizzati a livello di corporate. Un’alternativa alla estrazione
diretta dei dati dai sistemi operazionali è quella di creare delle aree di
immagazinamento locale dei dati per il d/w globale per poi scaricarli nel d/w
globale seguendo sempre, però, le indicazioni della mappa. Una delle
caratteristiche del d/w globale è che i dati si presentano all’interno del
Warehouse sicuramente sintetizzati, mentre la grande massa di dati grezzi
rimane nei siti locali. Proprio questa sintesi dei dati può essere effettuata già
a livello locale nelle suddette aree di immagazzinamento le quali possono in
loco raccogliere i dati, sintetizzarli ed inviarli alla sede centrale.
7.10.2. Gestione degli sforzi di sviluppo di Data Warehouse multipli
Il primo passo che molte organizzazioni fanno nel data warehousing è di
costruire un d/w per le organizzazioni di marketing o finanza. Una volta che
si è riscontrato un successo, questa esperienza può trovare applicazione in
altri settori organizzativi. Da qui nasce lo sforzo e l’esigenza di una gestione
e di un coordinamento dei dati comuni di una organizzazione da parte
dell’architetto d/w.
Comunque, si afferma che ci dovrebbe essere una reciproca esclusività dei dati fra i
d/w locali e il d/w globale al fine di eliminare al massimo il problema della
ridondanza dei dati e poi anche perché è essenziale distinguere esattamente quali
debbano essere le questioni locali da quelle globali, cosa che anche se è difficile deve
essere perseguita in un sistema di d/w distribuito. In effetti, a livello di principio il
dato globale deve essere utilizzato per questioni di rilevanza globale, mentre il dato
locale deve essere utilizzato per questioni di rilevanza locale. Per maggiori
approfondimenti vedere Building of the Data Warehouse di W.H. Inmon pag. 209-211
345
25
Capitolo settimo La filosofia Data Warehouse
D/w
Marketing
D/w
Produzione
D/w finanza
?
D/w globale
Figura 7. 28. Problemi di gestione multipla degli sforzi di sviluppo
7.10.3. Natura degli forzi di sviluppo
La prima questione che deve affrontare un architetto d/w che deve gestire i
diversi sforzi di sviluppo all’interno dell’azienda è quello della natura di
questi sforzi. A meno che l’architetto conosca esattamente quali sono i tipi di
sforzi di sviluppo del d/w che bisogna realizzare e come questi si collegano
all’architettura complessiva, questi avrà molti problemi a coordinare e gestire
questi sforzi. I diversi sforzi di sviluppo del d/w richiedono diversi approcci
di gestione perché le questioni di sviluppo sono molto differenti a seconda
dei diversi casi che si presentano. Inmon elenca quattro casi tipici :
1. Business non integrati
2. Costruzione di un d/w per ciascuna delle parti di una
organizzazione
3. Diversi gruppi di una corporate curano i diversi livelli di dettaglio
4. Gruppi diversi che costruiscono lo stesso livello di dettaglio
Il primo
caso ed il quarto non si presentano molto spesso, mentre più
frequentemente ci si imbatte in casi come quelli descritti nel secondo e terzo
punto.
1) Business non integrati
346
Capitolo settimo
La filosofia Data Warehouse
Questo caso si presenta per corporate che hanno business non integrati,
ovvero business che presentano uno stato di correlazione quasi nullo. Si può
portare come esempio un’impresa che abbia quattro business :
una catena di fast food, acciaierie, abbigliamento bambino, manutenzione di
campi da golf.
Come si vede la correlazione fra questi quattro business è pressappoco che
nulla, per cui ogni business può sviluppare un d/w a se stante senza cercare
delle correlazioni con gli altri business. L’unica forma d’integrazione a livello
corporate che è possibile per business non integrati è quella relativa al
bilancio finanziario. Il d/w relativo al bilancio finanziario della corporate
dovrà prendere in considerazione semplici ed astratte entità come spese,
introiti, aumenti di capitale, inflazione, ecc. E’logico che in un documento di
bilancio i dati business (come clienti, prodotti, vendite) non trovano molto
spazio. Quindi, si può dire che si tratta di un d/w “leggero” che analizza
solamente l’aspetto finanziario della corporate ; per questo l’importanza del
metadata del d/w a livello corporate sarà relativa. Molto importante è invece
il metadata per i singoli d/w di business.
Acciaierie
Abbigliamento
Bambino
Catena di
Fast Food
Manutenzione
campi da golf
D/W finanziario
della corporate
Figura 7.29. Esempio di business non integrati
2) Il Data Warehouse distribuito
E’ raro che i vari business di una corporate si presentino completamente
scollegati come nel caso precedente. Bene o male esiste un certo grado di
347
Capitolo settimo
La filosofia Data Warehouse
correlazione che occorre sfruttare. Il caso in esame può essere rappresentato,
ad esempio, come quello di una corporate che ha una serie di business che
presentano fra loro un certo grado di correlazione. Inoltre, la corporate ha siti
sparsi un po’in tutto il mondo (USA, Africa, Canada, Europa, Sud America)
ed è convinta che in ognuno di questi siti si applichino pratiche di business
differenti.
Un primo approccio che la corporate può compiere nella costruzione di un
d/w è quello di lasciare che ogni sito costruisca in loco con gruppi autonomi
il proprio d/w che riguarderà tutti i business dell’impresa . I vantaggi di
questo approccio derivano dal fatto che il sito locale conosce molto meglio la
realtà locale e muovendosi in autonomia dalla sede centrale può meglio
“attrezzare” il proprio d/w rispetto a quelli che sono i suoi bisogni. Un altro
vantaggio
sta
nella
riduzione
dei
tempi
e
quindi
dei
costi
di
implementazione che altrimenti, in caso di coordinamento a livello di
corporate, sarebbero più lunghi. Gli svantaggi sono rappresentati da una
mancata visione d’insieme a livello corporate dei vari business e delle
interrelazioni esistenti fra questi. Tali interrelazioni derivano da un mancato
coordinamento dei vari siti locali.
Un approccio alternativo a quello sopra descritto può essere quello di
stabilire tra i gruppi che costruiscono un singolo d/w locale un
coordinamento a livello centrale. Ma questo rallenta notevolmente i tempi di
implementazione del d/w sia per i problemi impliciti al coordinamento sia
per il fatto che la costruzione dei vari d/w locali difficilmente possono
svilupparsi tutti di pari passo. Inoltre, il coordinamento a livello centrale può
essere visto, talvolta, dagli stessi implementatori locali come una limitazione
allo sviluppo del loro d/w. Si stabilirà che ogni sito locale abbia il proprio
modello dei dati a fondamento del proprio d/w.
Una volta che si è verificato che il d/w a livello locale ha prodotto dei
benefici si può decidere di realizzare un d/w a livello corporate il quale
rifletta un’integrazione dei business fra le differenti divisioni e località.
348
Capitolo settimo
La filosofia Data Warehouse
Il primo passo da compiere deve essere quello di identificare un modello dei
dati a livello corporate che accolga i dati di business che siano significativi
per la corporate e nella forma (cioè il grado di sintesi) che interessa la
corporate26. Inoltre, come regola generale, il d/w corporate all’inizio deve
essere piccolo e semplice, e cioè limitarsi ad uno ristretto subset di dati
riguardanti il business. Questo perché si può rischiare di inserire all’inizio un
quantitativo eccessivo di dati che poi l’uso ne dimostrerà la inutilità. Ma
questo produrrà dei danni sia per l’eccessivo tempo di implementazione e
quindi di costo del d/w, sia per l’eccessiva “pesantezza” del d/w che ne
risentirà sempre in termini di costo di gestione e di efficienza di utilizzo.
Il modello dei dati corporate riflette l’integrazione del business a livello
corporate. Spesso si può creare una sovrapposizione dei dati a livelli
corporate con quelli a livello locale. Ma questa sovrapposizione dei dati può
essere vista come benefica quando gli scopi per i quali viene fatta sono
diversi. I dati di cui la corporate abbisogna per analizzare i business sono
caricati direttamente dalle organizzazioni locali le quali hanno una
conoscenza più approfondita del dato locale. Comunque, l’archiviazione
verrà fatta seguendo le specifiche del Metadata a livello corporate.
La sorgente di questi dati potrà essere sia il d/w locale, sia i sistemi
operazionali e comunque, spetterà sempre alle organizzazioni locali stabilire
come comportarsi al riguardo.
Il Metadata nell’ambito del d/w distribuito gioca un ruolo essenziale, perché
è attraverso questo che si effettua un coordinamento della struttura dei dati
che sono archiviati nei differenti siti autonomi. Il metadata rappresenta il
veicolo principale per effettuare un’archiviazione dei dati uniforme e
consistente. Si può dire che questo fornisce quelle che sono “le specifiche
standard” della archiviazione.
26 Il grado di sintesi a livello locale e a livello di corporate può essere differente. Spesso i dati
che un analista DSS locale considera di sintesi sono per l’analista DSS a livello corporate un
349
Capitolo settimo
Africa
d/w
La filosofia Data Warehouse
Canada
d/w
Europa
d/w
USA
d/w
Sud
America
d/w
Corporate d/w
Figura 7.30. Esempio di Data Warehouse distribuito
3)Costruzione del Data Warehouse a livello multiplo
Questo caso si presenta quando la costruzione del d/w viene effettuata
contemporaneamente da gruppi diversi i quali curano ognuno un livello di
dettaglio. Ad esempio, il gruppo A si occupa dell’alto livello di sintesi dei
dati, il gruppo B si occupa del medio livello di sintesi dei dati mentre il
gruppo C si occupa del livello di dettaglio. Questo è un caso che si verifica
molto frequentemente nella costruzione del d/w e fortunatamente è quello
che presenta i minori problemi. Ovviamente ci dovrà essere un buon
coordinamento fra i gruppi che nella realizzazione del d/w dovranno
procedere sempre di pari passo. Gli sforzi di coordinamento riguarderanno
la specificazione del contenuto e la struttura dello stesso nonché i termini e i
tempi di sviluppo. Anche in questo caso il Metadata gioca un ruolo
fondamentale in quanto riflette fedelmente qual è il disegno di sviluppo che
si intende realizzare.
mero dettaglio. Per maggiori approfondimenti vedi W.H. Inmon Building of the Data
Warehouse pag. 222 e seguenti
350
Capitolo settimo
La filosofia Data Warehouse
Un problema rilavante in questo terzo caso è rappresentato dalla scelta da
parte dei diversi gruppi di piattaforme differenti e dalla capacità che tali
piattaforme hanno di comunicare fra loro. Non è usuale che i diversi gruppi
scelgano la stessa piattaforma. In effetti, i diversi livelli di sintesi dei dati
impongono spesso piattaforme con caratteristiche differenti (e questo può
essere valido anche più in generale). Ad esempio, il livello di dettaglio,
contenendo una grande massa di dati, ha bisogno di piattaforme che
riducano al massimo i tempi di accesso ai dati. Quindi dovranno essere
molto più performanti di quelle necessarie per i livelli di sintesi dove la
massa dei dati è minore. Questo ha come conseguenza un risvolto sui costi
diversi delle piattaforme che saranno scelte. Un’altra ragione della scelta di
piattaforme diverse fra il livello di dettaglio e i livelli di sintesi sta nel fatto
che, acquisendo una piattaforma diversa, si arricchisce la varietà di software
specializzati necessari ad esempio per gli analisti DSS.
Ma la scelta di piattaforme diverse pone giocoforza anche il problema della
comunicazione fra di loro.
Gruppo B
OLAP
Gruppo A
Alto livello di sintesi
Dettagli dei
Dati
Gruppo C
Livello di dettaglio
Figura 7.31. Differenti gruppi sviluppano differenti parti del d/w
Si tratta del problema della connettività che viene attualmente risolto tramite
architetture software che rendono trasparenti le varie sorgenti di dati.
4) Costruzione di uno stesso livello di dettaglio
Questo caso non è molto frequente. Si determina quando gruppi diversi
operano per la costruzione dello stesso livello di dettaglio. Ciò viene fatto
perché evidentemente i diversi gruppi hanno un interesse particolare su certi
dati che possono curare in maniera più appropriata. Non sorgerebbero
351
Capitolo settimo
La filosofia Data Warehouse
problemi se per ogni gruppo si potesse individuare un set esclusivo di dati,
ma così non è. Il pericolo più grosso è rappresentato da una ridondanza dei
dati che porta dietro di se essenzialmente due problemi.
Il primo, meno importante riguarda il costo. Una forte ridondanza dei dati
produce un d/w di dimensioni più grandi di quanto non sia strettamente
necessario con riflessi evidenti sulla scelta delle eventuali piattaforme ad hoc
che devono essere scelte. Il secondo, più importante, è che questa grande
massa di dati ridondanti avrà senz’altro dei riflessi negativi sulla efficacità
attendibilità dell’analisi
DSS compromettendo quindi, lo scopo principale
per il quale il d/w è stato creato. E’compito del Metadata far si che ciò non si
verifichi cercando di limitare al massimo i problemi di ridondanza.
Gruppo
B
Gruppo C
Gruppo A
Gruppo D
Gruppo E
Figura 7.32. La costruzione di uno stesso livello di dettaglio da parte di più gruppi può portare
alla creazione di zone di ridondanza.
7.11. Un piano di migrazione
La costruzione di un ambiente Data Warehouse è un’attività che deve essere
realizzata passo dopo passo. Di conseguenza, lo si può definire come un
processo iterativo che si sviluppa nel tempo. Quindi si può partire all'inizio
attraverso un “esiguo” quantitativo di risorse e si può cominciare a costruire
quest’architettura con un minimo intaccamento dell’ambiente operazionale.
352
Capitolo settimo
La filosofia Data Warehouse
Sono le dimensioni e la velocità di sviluppo iterativo che risultano essere le
variabili dominanti nella costruzione di un ambiente D/W.
In queste pagine verrà esposto in estrema sintesi un generico piano di
migrazione27 in ambiente Data Warehouse proposto da Inmon nel suo libro
The building of the Data Warehouse. Questo approccio, nelle sue linee guida, a
detta dell’autore, è stato seguito con successo da un grande numero di
compagnie.
7.11.1. I passi del piano
Il punto di inizio di un piano di migrazione è senz’altro il modello dei dati. Il
modello è espressione delle informazioni di cui l’azienda necessita. Questo
rappresenta cosa l’impresa ha bisogno e non cosa l’impresa in questo
momento ha (cioè non si deve adattare le finalità ai mezzi, ma i mezzi alle
finalità) . Inoltre la sua realizzazione deve essere sganciata da ogni
considerazione di carattere tecnologico. Il modello dei dati deve identificare
perlomeno i seguenti dati :
? i maggiori soggetti dell’azienda
? le relazioni fra i soggetti dell’azienda
? i raggruppamenti di chiavi ed attributi che possono più efficacemente
rappresentare i maggiori soggetti, incluso :
? gli attributi dei maggiori soggetti
? le chiavi dei maggiori soggetti
? gruppi ripetuti di chiavi ed attributi
? connessioni fra le aree dei maggiori soggetti ? sottotipi di relazioni
Inmon fa una distinzione netta tra piano di migrazione e metodologia di migrazione. Secondo
quanto afferma l’autore di The building of the Data Warehouse, mentre un piano di migrazione
descrive generali attività in maniera dinamica (modo schematico), la metodologia si occupa
di descrivere le stesse attività in maniera specifica e seguendo l’ordine delle attività (modo
analitico). Ma così facendo, la dinamica iterativa della creazione del Data Warehouse non
apparirà in tutta la sua interezza.
353
27
Capitolo settimo
La filosofia Data Warehouse
In teoria è possibile realizzare un’architettura senza un modello dei dati ma
sarebbe come navigare senza mappa28.
Il secondo passo è quello relativo alla definizione del sistema dei record, cioè
i record scelti dall’esistente sistema che entreranno nel Warehouse. Con
sistema dei record ci si riferisce ai “migliori” dati che un’azienda possiede.
Quindi, questa fase determinerà quali sono i dati che entreranno nel
Warehouse.
E’ il modello dei dati che verrà utilizzato come termine di raffronto per
determinare, in ultima analisi, quali sono i migliori dati. In altre parole,
l’architetto dei dati chiederà all’azienda (ovvero agli utenti che dovranno
svolgere le diverse funzioni come analisi DSS, Data Mining ed altro) quali
sono i dati
dall’azienda
giudicati necessari e che possono essere messi a disposizione
stessa.
Inoltre,
giudicherà
se
questi
si
adattano
alle
caratteristiche del modello dei dati prescelto o no.
L’identificazione delle migliori fonti di dati dal sistema esistente si stabilisce
attraverso alcune caratteristiche proprie dei dati. Questi dati saranno, ad
esempio :
? i più tempestivi
? i più completi
? i più accurati
? i più vicini alle fonti esterne
? strutturalmente compatibili con il modello dei dati prescelto in termini di
chiavi, di attributi o in termini di chiavi ed attributi insieme.
Attraverso questi criteri ed il confronto con il modello dei dati si definisce
quindi quale sarà il sistema dei record.
Avendo a questo punto definito quali dati inserire nel Warehouse, il passo
successivo sarà quello di identificare quale sarà il disegno del Data
Warehouse.
28
Inmon “Building of the Data Warehouse”
354
Capitolo settimo
La filosofia Data Warehouse
Se l’attività di modellazione dei dati (progettazione concettuale, logica e
fisica) è stata effettuata in maniera accurata si dovranno modificare solo
alcuni aspetti del modello prescelto nel disegno del D/W. Alcuni di questi
riguarderanno :
? L’elemento tempo deve essere sempre inserito nella struttura della chiave
se questo non è già presente
? Tutti i dati che riguardano solo le operazioni di transazione dovranno
essere eliminati
? Modifica delle relazioni di integrità
? I dati di cui più frequentemente si ha bisogno devono essere inseriti nel
disegno
? La struttura del dato, dove necessario, deve essere alterata :
? per aggiungere serie di dati
? per aggiungere dati ridondanti
? ulteriore separazione dei dati sotto giuste condizioni
? assorbimento di tabelle quando il caso lo richiede
? ecc.
? Effettuare un’analisi di stabilità dei dati
Il Data Warehouse una volta disegnato deve essere organizzato per aree
soggetto. Le tipiche aree sono :
? clienti
? prodotti
? vendite
? spedizioni
? attività
? conti
All’interno di ogni area soggetto ci sono molte tabelle collegate fra loro da
un sistema di chiavi comuni.
Una volta disegnato il D/W il passo successivo è quello di disegnare e
costruire delle interfaccie fra i sistemi di record residenti nell’ambiente
355
Capitolo settimo
La filosofia Data Warehouse
operazionale esistente ed il D/W.
Si possono elencare le attività che si verificano a livello di interfaccia:
? integrazione dei dati dell’ambiente operazionale e di quello legato alle
applicazioni
? alterazione della base di tempo dei dati
? efficiente scansione degli ambienti esistenti
Arrivati al termine di questo passo, Inmon stima che circa l’80% delle risorse
destinate alla realizzazione del D/W sono state consumate. Tutto ciò ci dice
che tali attività richiedono uno sforzo non indifferente.
Una volta terminata l’attività di interfaccia inizia quella di popolamento del
Warehouse cominciando dal primo soggetto di area.
Esistono molte ragioni che inducono a questo punto al popolamento di una
sola piccola frazione dei dati di cui c’è bisogno in un D/W. E’ molto
probabile, infatti, che cambiamenti riguardanti i dati dovranno essere
effettuati. Operare solo su di una piccola parte dei dati significa che quei
cambiamenti che dovranno essere effettuati potranno essere realizzati
facilmente e velocemente. In effetti, popolare il D/W di una grande quantità
di dati rende il D/W stesso meno flessibile ai cambiamenti che possono
essere realizzati in momenti successivi. Di conseguenza, soprattutto nei
momenti iniziali in cui le questioni relative alla scelta dei dati, alla necessità e
alla natura degli stessi non sono ancora ben definite, è essenziale partire solo
con una minima quantità di dati per permettere di testare la bontà delle
scelte effettuate realizzano poi, delle correzioni “in corsa”.
Sarà l’utilizzatore finale (ad esempio un analista DSS) che dovrà, ovviamente,
esprimersi sulla bontà di ciò che è stato realizzato. Sarà lui a fornire
indicazioni all’architetto D/W su cosa funziona, su cosa potrebbe funzionare
meglio e su cosa non funziona, garantendo delle informazioni di ritorno
(feedback) che avranno come effetto una modifica del D/W per meglio
rispondere alle esigenze dell’utilizzatore. Il processo di popolamento e di
feedback continuano per un lungo periodo di tempo (indefinito).
356
Capitolo settimo
La filosofia Data Warehouse
Questa fase dovrà arrivare alla realizzazione di un sistema che sia il più
vicino possibile alle richieste dell’utilizzatore, compatibilmente a tutti quelli
che sono i vincoli di risorse, di costi e di tempo che limitano la realizzazione
della struttura D/W. Per cui, anche per questo, lo scambio di informazioni
fra utilizzatore finale ed analista porterà certamente ad un miglioramento
della struttura iniziale non potendo arrivare però, alla realizzazione di un
sistema che possa essere considerato veramente ottimale.
Sistema esistente
Modello
dei dati
Disegno del d/w
Definizione
del sistema
dei record
Estrazione integrazione
cambio della base di tempo dei dati
condensazione dei dati
efficiente scansione dei dati esistenti
Figura 7.33. a)Passi di un piano di migrazione.
357
Capitolo settimo
La filosofia Data Warehouse
Primo poopolamento del
Data Warehouse e
continuo popolamento
Feedback
Architetto
D/W
Analista
DSS
Figura 7.34 b) passi di un piano di migrazione
358
Capitolo settimo
La filosofia Data Warehouse
7.12. Executive information system nel Data Warehouse
L’EIS (Executive Information System) è una delle più potenti forme di
calcolo. Grazie all’EIS l’analista può specificare problemi ed individuare
tendenze che sono di vitale importanza per il management29. L’elaborazione
EIS è creata per aiutare l’esecutivo a prendere delle decisioni e può essere
vista come la “finestra” dell’esecutivo sull’azienda considerando gli aspetti
che sono rilevanti nella gestione del business. L’EIS non è altro che l’evoluzione
dei sistemi DSS (Decision Support System), MIS (Management Information
System) e di BI (Business Intelligence)30.
Sistemi
d’informazione
EIS
per i
decisori
MIS
DSS
Sistemi di produzione
Figura 7.35. Sistemi di informazioni nelle imprese (fonte : Gentium Corporation)
Alcune delle attività che rientrano in EIS sono :
? OLAP (On-Line Analytical Processing)
? Query e reporting
“....gli EIS (Executive information system) sono gli strumenti tecnologici più utilizzati per
sviluppare i cosiddetti cruscotti direzionali e rispondono con diversa modalità alla stessa
finalità ultima dei data warehouse : avvicinare ai decisori i dati per decidere.”D. Sandri :La
soluzione del SAS Institute, Zerouno 4/1995
30 Gentium eis :”Palnning Sciences” , white paper
359
29
Capitolo settimo
La filosofia Data Warehouse
? Information retrivial
? Data Mining
? Analisi in genere
? ecc..
Figura 7.36. EIS per Oracle Corporation (tratto da CD ROM Oracle Warehouse)
Non c’è una definizione precisa di quelle che sono le attività che rientrano in
EIS. Tutte, comunque, sono rivolte al supporto dell’attività decisionale del
management. Il Data Warehouse rappresenta il serbatoio di informazioni di
questi sistemi. Informazioni poste nelle forme più adatte alle funzioni che
devono essere svolte.
7.12.1. On-Line Analytical Processing
OLAP (on-line analytical processing) è il nome che viene dato all’analisi dinamica
d’impresa richiesta per creare, manipolare, animare e sintetizzare informazioni in
forma esegetica, contemplativa, e formulare dei modelli di analisi . Questo include
l’abilità a comprendere cose nuove o relazioni sconosciute fra le variabili, l’abilità ad
identificare i parametri necessari e a maneggiare una grande quantità di dati, per
360
Capitolo settimo
La filosofia Data Warehouse
creare un illimitato numero di dimensioni ( percorsi consolidati), e per specificare
condizioni ed espressioni trasversali alle dimensioni31.
Un’applicazione OLAP è predisposta a cogliere le diverse relazioni esistenti
fra le diverse variabili di dati e a realizzare in maniera efficiente una indagine
multidimensionale. Questa indagine coinvolge un numero molto elevato di
dati in relazioni complesse.
Le applicazioni OLAP sono differenti dalle applicazioni OLTP (on-line transaction
processing)32 le quali riguardano un grande numero di relativamente semplici
transazioni. Le transazioni , normalmente, ritrovano e modificano un piccolo numero
di record che sono contenuti in molte distinte tavole. Le relazioni fra le tavole sono
generalmente semplici33.
Quindi, le applicazioni OLAP si occupano di effettuare delle interrogazioni
di dati che coinvolgono un grande numero di dati, più variabili
contemporaneamente e si fondano in un modello detto multidimensionale
MDM (Multidimensional Modelling). Diventa essenziale nell’ambito OLAP il
tempo di accesso ai tanti dati impiegati rispetto anche alla complessità delle
interrogazioni da effettuare.
In generale, le attività che caratterizzano l’OLAP, e che gli OLAP database
dovranno supportare, sono la Consolidation, lo Sclicing and Dicing e il DrillDown.
Con Consolidation si intende far riferimento all’aggregazione dei dati.
Questi possono essere un semplice raggruppamento o complesse espressioni
che coinvolgono dati interrelati. Per esempio, le vendite di un negozio
possono essere raggruppate in un distretto, quelle di un distretto in una
E.F. Codd S.B. Codd, and C.T. Salley : “Providing OLAP (on-line analitical processing) to
User-Analists : An IT Mandate . http :// www. Arborsoft.com/papers/ coddTOC.html
N. Radennel suo articolo Data, Data Everywere definisce l ‘OLAP così :
L’OLAP spesso viene confuso con il supporto alle decisioni. Ma praticamente, l’OLAP attività di query interattive, seguendo una linea di analisi tra più passi, come con il “Drill-
Down” si sviluppa su più passi analizzando livelli di dettaglio più bassi.” Tratto da http :// www.strategy.com/dfw/iw_mct01.htm
32 L’
ambiente OLTP è solitamente l’ambiente operazionale.
33 R. Finkelstein :”Understanding the Need for On-Line Analytical Servers”, http//www.arborsoft.com/papers/finkTOC.html
361
31
Capitolo settimo
La filosofia Data Warehouse
regione. Lo Slicing and Dicing si riferisce all’abilità di guardare i dati di un
database da più punti di vista. L’analista prende le informazioni di base che
gli servono e le analizza in un modo, quindi le raggruppa in un altro modo e
le rianalizza. Quindi, effettuare questa attività permette al manager di avere
differenti prospettive della situazione che si trova ad affrontare.
Il Drill-
Down si occupa, infine, di indagare una certa informazione approfondendo
in maniera mirata il grado di analiticità della stessa.
7.12.1.1. Analisi Drill-Down
Per effettuare lo sclicing and dicing , è necessario essere abili nell’effettuare
una analisi di “drill-down” sui dati.
Questo tipo di analisi si riferisce
all’abilità d’iniziare ad analizzare le informazioni partendo da un dato
fortemente aggregato per “spezzarlo”, successivamente, in set di dati ad un
livello di sintesi più basso. Il manager ha in questo modo uno strumento
diagnostico per approfondire passo dopo passo la sua analisi, partendo da
dati fortemente aggregati per poi puntare l’attenzione, attraverso un
approfondimento del grado di analiticità del dato, su quei dati che sembrano
nascondere la risposta alle sue domande.
Si può pensare al drill-down in termini di un percorso che il manager segue
da un livello di sintesi dei dati più elevato ad uno via via sempre più basso,
per arrivare alla soluzione del suo problema.
C’è tutta una serie di software sofisticati per presentare i risultati ad un
manager. La parte più difficile delle indagini drill-down ed EIS in generale
non è la rappresentazione grafica, ma i numeri che le compongono.
EIS è perfettamente capace di supportare indagini drill-down se i dati
esistono alla base.
Ma se i dati adatti non esistono il processo diventa
difficile da realizzare.
362
Capitolo settimo
La filosofia Data Warehouse
Questa simulazione mostra come DSS AGENT (un tool di analisi DSS) può
essere usato per risolvere un problema di cattiva gestione delle scorte.
IL PROBLEMA :
Le vendite per articoli promozionali sono diminuite nel New England al disotto di quanto stabilito nel piano.
A questo punto il DSS Agent provvede a dare intuitivo accesso alle
informazioni richieste per risolvere il problema delle vendite in New England.
363
Capitolo settimo
La filosofia Data Warehouse
Gli articoli promozionali hanno avuto una caduta del 9% nel New England
rispetto al piano di questo trimestre. Il report Articoli promozionali mette
subito in allerta del problema esistente in New England. Questo report può
essere visto in diversi formati.
364
Capitolo settimo
La filosofia Data Warehouse
Formato MAP
Formato GRAPH
365
Capitolo settimo
La filosofia Data Warehouse
Formato Griglia. L’Users può vedere i dati in un formato multidimensionale dai
quali dati può far partire la sua indagine. Attraverso una indagine Drill-Down si
può partire da un’analisi dei dati fortemente sintetizzata per poi approfondire
l’indagine selettivamente via via che il grado di analiticità dei dati utilizzati
aumenta.
366
Capitolo settimo
La filosofia Data Warehouse
L’indagine eseguita ci mostra che il New England ha un dato negativo. Si vuole
per questo scoprirne le cause. Si procede, quindi, approfondendo con una
indagine Drill-Down.
Se si punta l’attenzione sui negozi del New England (Boston, Portland, Concord)
solo Boston è fuori piano.
367
Capitolo settimo
La filosofia Data Warehouse
Allora si torna al menu generale. Si può scegliere a questo punto una nuova
analisi che contenga informazioni sulle scorte di articoli promozionali.
Il tool DSS AutoPrompt permette di selezionare il negozio di Boston
368
Capitolo settimo
La filosofia Data Warehouse
Il Power-Drill viene identificato come potenziale problema
Si sceglie a questo punto un report che analizzi giornalmente il “guasto” sul
prodotto Power-Drill.
369
Capitolo settimo
La filosofia Data Warehouse
Si cerca a questo punto di evidenziare meglio i dati della griglia relativi al
Power-Drill attraverso un grafico che mostri l’andamento delle vendite
contrapposto al livello delle scorte.
Si può notare che c’è una cattiva gestione delle scorte perché, mentre le vendite sono regolari, le scorte “lasciano a secco” il negozio per alcuni giorni durante il mese non potendo soddisfare pienamente la clientela.
Quindi : occorre aumentare il livello delle scorte.
Si provvederà, di conseguenza, ad informare di questo problema il responsabile regionale perché provveda a regolare meglio le scorte.
7.12.1.2. Il Data Warehouse per l ‘OLAP
L’analista deve avere la possibilità di considerare i dati in modi diversi (slice
and dice) e di poter andare a fondo nella sua analisi percorrendo via via
370
Capitolo settimo
La filosofia Data Warehouse
gradi di dettaglio sempre più analitici. Per questo deve disporre di una
struttura dati che gli permetta di essere “attivo” ; in altre parole egli non
deve “costruire” le informazioni ogni volta che ne ha bisogno. Con questo
s'intende che l’analista non deve preoccuparsi ogni volta della fonte da cui
arrivano i dati, né di creare appositi programmi per estrarli, integrarli,
sintetizzarli in maniera appropriata alle sue ricerche. La struttura Data
Warehouse garantisce proprio questo. I dati finiscono tutti in un repository
centrale in forma atomica o leggermente sintetizzati e poi saranno sintetizzati
e ribaltati nei Datamart dove si troverà un database con una struttura capace
di gestire adeguatamente i dati in modo da servire meglio le richieste
dell’utente EIS. Esistono, quindi, più livelli di sintesi dei dati e strutture
capaci di garantire le flessibilità d'utilizzo dei dati.
Individuale
Datamart
Repository
Figura 7.37. La struttura del D/W è adatta a realizzare un'indagine Drill-Down che si sviluppssu
duversi livelli di sintesi d'analisi.
7.12.2. Analisi e Modello Multidimensionale MDM (MultiDimensional Modelling)
Il Multidimensional modelling è una tecnica sviluppata per strutturare i dati
intorno ai concetti di Business aziendali e per fornire un fondamento
371
Capitolo settimo
La filosofia Data Warehouse
all’esecuzione d'elaborazioni sofisticate di Data Analysis. Mentre la tecnica
utilizzata per il disegno degli OLTP poggia sul modello E/R realizzando la
scomposizione delle informazioni su di un numero elevato di tabelle
bidimensionali (colonne e righe), ognuna descrivente un'entità, il modello
multidimensionale e l’analisi usano i fatti (dati numerici : ad esempio il
numero delle vendite), le dimensioni (parametri di business : Mercato)34 e le
gerarchie (delle dimensioni :ad esempio Il mercato nazionale, regionale,
locale).
Si analizzerà più approfonditamente queste caratteristiche
successivamente, attraverso lo studio di schemi relazionali (a stella e a fiocco
di neve) realizzati per supportare l’analisi multidimensionale.
Il MDM non
riguarda
l’evolversi delle informazioni degli eventi in generale,
piuttosto riguarda una serie di “slice in time”. Il primo passo nella costruzione di un
modello è scegliere il soggetto dell’area di business (vendite settimanali, reporting,
situazione finanziaria mensile, ecc..) e fare a questo modello sei fondamentali
domande :
1. Quale processo di business occorre modellare ?
2. Quali sono le misure (o i fatti) ?
3. A quale livello di dettaglio è “attiva” l’analisi che si deve condurre35 ?
4. Quali sono le misure che hanno in comune (le dimensioni) ?
5. Quali sono gli attributi e le dimensioni ?
6. Ci sono attributi stabili o variabili nel tempo, se le cardinalità sono limitate
oppure no36 ?
“Ogni dimensione rappresenta una categoria differente di classificazione (vendite,
prodotto, canale di vendita, città, e così via)”. Coniugando assieme le dimensioni si ottiene
una sorta di cubo in cui ogni cella rappresenta una particolare situazione. P. Lombardi :Una
nuova dimensione per i Database ?, Zerouno 9/1995
35 Per analisi attiva si intende l’
abilità di manipolare l’informazione.
36 N. Raden :Modelling the Data Warehouse, http :// www. Strategy.
com/d/wf/raden/iw0196_1.htm
372
34
Capitolo settimo La filosofia Data Warehouse
Argomenti/
Funzioni
Operational
Decision Support
Dati contenuti
Valori correnti
Organizzazione dei dati
Natura dei dati
Struttura dei dati,
Formato
Probabilità di accesso
Modifica dei dati
Per applicazione
Dinamica
Complesso ; adatto per
operazioni di calcolo
Alta
Modifiche a livello di
campo
Processi ripetitivi
altamente strutturati
Intorno al secondo
Dati storici, aggregazioni,
dati calcolati
Aree di interesse trasversali
Statica dopo ogni load
Semplice ;adatto per
l’analisi di business
Bassa
Modifiche non dirette
Utilizzo
Tempi di risposta
Processi analitici altamente
non strutturati
Secondi, minuti
Figura 7.38. Tabella di raffronto fra le funzionalità del sistema operazionale con il Decision
Support (fonte :INFORMIX)
Un modello altamente normalizzato di dati che poggia sull’E/R come il
relazionale classico è utile per fornire un numero elevato di transazioni che
coinvolgono un numero piccolo di righe. In un sistema DSS, ad esempio, il
numero di transazioni concorrenti è minimo mentre il numero di righe
interessate è molto elevato (milioni di righe).
Questa è la differenza sostanziale fra i sistemi OLAP e i sistemi OLTP.
Si possono indicare 4 tipi di differenze :
1. Transazione contro lo “slice of time”. L’OLTP registra gli eventi o le
transazioni. Esempi sono gli ordini di vendita, le telefonate dei clienti, ecc..
Il modello dati multidimensionale considera gli eventi in un arco di tempo
come il giorno, la settimana, il mese.
2. Contenuto particolare contro contenuto globale. Gli OLTP sono disegnati
per soddisfare uno scopo particolare di origine operazionale. Invece, i
modelli multidimensionali servono per soddisfare scopi di carattere
decisionale ed hanno una visione unitaria dell’impresa.
3. Mantenere traccia di ogni transazione contro un “grande quadro”. Gli
OLTP mantengono ogni singola transazione che si è verificata e per
ricostruire una certa situazione occorre prendere in considerazione tutte le
373
Capitolo settimo
La filosofia Data Warehouse
transazioni che si sono verificate. Invece, il modello multidimensionale
può mostrare la stessa situazione con un dato sintetico.
4. Relazioni esplicite contro relazioni implicite. Nel modello E/R si
analizzano solo quelle che sono le relazioni esplicite fra le varie entità,
mentre nel modello multidimensionale si analizzano più relazioni che
ruotano intorno alle dimensioni e all’esistenza di determinati fatti.
Un’applicazione multidimensionale permette
quindi
di
vedere
un
determinato fatto sotto diversi aspetti quante sono le dimensioni che possono
essere legate a questo fatto. Coniugando assieme le dimensioni si ottiene una
sorta di cubo in cui ogni cella rappresenta una particolare situazione ed ogni
cella contiene un particolare valore37. Si può ricomporre un fatto in modo
diverso a seconda delle dimensioni utilizzate (slicing and dicing) e si può
analizzare questo fatto con diversi gradi di analisi (ad esempio a livello
regionale, di provincia, comune ecc.. a seconda delle gerarchie degli elementi
individuati). E’come avere a disposizione un cubo magico in cui si può far
mutare continuamente le facce e quindi gli scenari che ci si trova davanti. In
effetti, queste tecniche vengono dette a cube fondation, ma spesso il numero
delle dimensioni prese in considerazione supera quelle del cubo e per ciò si
parla in alcuni casi di ipercubo (vedi nota a fondo pagina)38.
“Si tratta di una sorta di spreadsheet :in ciascuna cella sono così contenuti i dati risultanti
dall’interrelazione tra più dimensioni :per esempio una cella potrà fornire il totale delle
vendite di un certo prodotto per canale di vendita di una certa zona in un determinato
giorno dello scorso anno” P. Lombardi :Un nuova dimensione per i database, Zerouno
9/1995
38
“L’ipercubo (di cui è esempio EssBase, gestore di basi di dati multidimensionale di Arbor
Software) intende descrivere un oggetto che abbia più di tre dimensioni, sempre con le facce
piane e ciascuna dimensione ad angolo retto rispetto a tutte le altre. Non riuscite a
visualizzarlo ? Non siete i soli : anche se lo si può estrarre dal modello matematico del foglio
di calcolo, la nostra immaginazione non va oltre le tre dimensioni. La progettazione del
modello a ipercubo è un processo Top-Down. Prima si selezione l’aspetto dell’attività
aziendale da catturare, per esempio le vendite, la situazione finanziaria o i reclami. Poi si
identificano i valori da catturare, per esempio i saldi delle vendite o dei conti (informazioni
che sono quasi sempre di tipo numerico). Infine si identificano le dimensioni. Dimensioni
tipiche sono :misura, tempo, scenario, geografia, prodotto e cliente. Una singola cella in un
cubo può memorizzare il valore delle vendite in lire di gennaio in Lombardia della tintura
blu per capelli ai grandi magazzini XYZ...... Uno degli svantaggi principali di una struttura
di questo tipo è che anche le minime modifiche nella struttura dimensionale richiedono
374
37
Capitolo settimo
La filosofia Data Warehouse
Figura 7.39. Analisi multidimensionale secondo Oracle (Catturato da immagini del CD ROM
Oracle Warehouse)
Per poter gestire le analisi multidimensionali occorrono dei DBMS
multidimensionali. Questi DBMS possono essere o multidimensionali, vale a
dire con modello multidimensiolale, per cui i dati sono organizzati
fisicamente in “cubi” di dati39, oppure sono dei RDBMS in cui il modello dei
dati risulta modificato per facilitare le applicazioni multidimensionali oppure
le altre funzionalità EIS in genere.
una riorganizzazione del database......” N. Raden :Troppi dati per decidere, Zerouno 1/1996
(tradotto da Informationweek)
39
L’MDM non registra le informazioni in tabelle legata da chiavi, ma in schieramenti di dati
logicamente legati. Ma non esiste un solo modello multidimensionale. L’MDM non ha allo
stesso modo uno standard per l’accesso ai dati........” Tratto da
...ograms/cmp_wiasgate ?RF=832869835.900&num=6 # head. : Articolo di InformationWeek
di N. Raden :Tecnology Analysis
375
Capitolo settimo
La filosofia Data Warehouse
Gerarchia degli attributi
Attributi
Dimensione
G
E
O
G
R
A
F
I
A
Regione
Mid
Atlantic
Stato
VA
MD
Southeast
NC
GA
Città
Fairfax
Richmond
Norfolk
Annapolis
Baltimore
Potomac
Reileigh
Charlotte
Durham
Atlanta
Auguasta
Norcriss
G
E
O
G
R
A
F
I
A
Elementi degli
attributi
Tempo
Prodotti
Figura 7.40. Analisi Multidimensionale (Microstrategy)
La Gartner Group40 ha identificato otto caratteristiche che questi DBMS, sia
relazionali che multidimensionali, devono avere. Da quest’analisi si
rivalutano i database relazionali.
1. I database devono provvedere alla gestione dei Tool.
2. Supporto del Drill-Down fino al livello di dettaglio atomico. I database
multidimensionali non permettono di arrivare ad un livello di dettaglio
dei dati in maniera trasparente quando l’utente usa il metodo Drill-Down.
Mai i database multidimensionali registrano i dati a livello atomico di
dettaglio, per cui occorrerà estrarli tramite appositi software dal
reposytory centrale, se esiste. Comunque sia, il livello di dettaglio è
registrato in forma relazionale ed è più semplice per i database relazionali
accedere a questi dati (SQL) integrandoli ai propri.
3. Aggiornamento dei dati. Spesso l’aggiornamento di un multidatabase si
risolve in un dover ricaricare completamente l’intero “data cube”, mentre
376
Capitolo settimo La filosofia Data Warehouse
il relazionale accetta più facilmente le modifiche senza dover di nuovo
ricaricare tutti i dati.
4. Supporto di array multipli. Il database multidimensionale non supporta
la creazione di più array correlati in una singola struttura database. Al
contrario la tipica struttura relazionale permette la definizione fino a 256
tavole collegate in un singolo database.
5. Database join. Il database multidimensionale non supporta le join logiche
di più multidimensional array. L’impossibilità di realizzare delle join fra
più database multidimensionali limita, quindi, la possibilità di effettuare
query se varia la composizione delle tabelle
6. Selezione di un subset di dati. Il database relazionale può provvedere,
come il database multidimensionale, a limitare l’ammontare dei dati per
le proprie analisi.
7. Accesso
ai dati. I database multidimensionali sono caratterizzati
attualmente da strutture “proprietarie”. Vale adire che ogni produttore
propone la sua. Al contrario la struttura relazionale si fonda su regole
certe e soprattutto esiste un linguaggio comune per l’accesso ai dati che è
l’SQL. Questo fa si che tutti i dati relazionali siano trasparenti fra loro
mentre così non si può dire per i diversi dati multidimensionali.
Metadata
INPUT
Query Generator
SQL
OUTPUT
Mathematical Processor
Cross-Tabulation
Engine
Data Warehouse
Applicazione DSS
Motore DSS
40
Tratto da :Decision Support Viewpoint. White Paper di Microstrategy
377
Capitolo settimo
La filosofia Data Warehouse
Figura 7.41. Architettura di un notore DSS (Microstrategy)
8. Interfaccia SQL. I database multidimensionali non supportano una
interfaccia SQL per l’accesso ai dati. L’accesso avviene tramite un software
apposito (un’API, Application Program Interface) che però è proprietario. Al
contrario, l’analisi multidimensionale può essere tradotta per mezzo di un
motore in linguaggio SQL e quindi comprensibile al DBMS.
7.12.3. Strutture relazionali per l’EIS
Il modello relazionale classico, cioè quello altamente normalizzato , viene
detto general-purpose. In effetti, questo modello deve perseguire più scopi :
l’inserimento, l’aggiornamento e l’accesso. Deve, cioè, garantire il massimo
della flessibilità di utilizzo che prevede più operazioni sia di lettura che di
scrittura. Inoltre, è una struttura, quella relazionale, che poggia su
fondamenta certe e quindi è stabile e garantisce un accesso ai dati
trasparente tramite SQL. Ma nel Data Warehouse la situazione cambia. Si
hanno Database molto grandi che sono prevalentemente in lettura. Quindi, il
punto critico, sia che si tratti di OLAP o di attività di query in genere, è
quello di facilitare l’accesso ai dati poiché si passa da una situazione, quella
dell’ambiente operazionale
caratterizzata da un grande numero di
transazioni e query che coinvolgono un piccolo numero di righe, ad una in
cui le transazioni sono minime e il numero di righe coinvolte nelle query è
molto elevato. I punti chiave di questa situazione sono rappresentati :
1. dalla necessità di limitare il numero di join complesse che comprendano,
cioè, un alto numero di righe : tutto ciò per problemi di performance
2. dall’avere un modello chiaro comprensibile all’utente. Spesso un database
suddiviso in una miriade di tabelle può far perdere all’utilizzatore la
visione di insieme dei dati a disposizione. In effetti, visionare dei dati
relativi ad un oggetto di interesse sparsi su un certo numero di tavole è
diverso che vederli raggruppati in poche logiche unità.
378
Capitolo settimo
La filosofia Data Warehouse
Occorrerà, di conseguenza, adattare il nostro modello in modo tale da
servire in maniera più efficiente gli scopi dell’utente finale. Si parlerà , in generale, di attività di denormalizzazione fino ad arrivare a
parlare di schemi a stella o a fiocco di neve.
7.12.3.1. Normalizzazione/Denormalizzazione
Una prima attività per migliorare le performance e la comprensione del
modello relazionale (normalizzato) è quella di realizzare una attività di
denormalizzazione. Il modello dei dati produce tutta una serie di tavole
legate fra loro, le quali contengono dati. Quindi, per trovare i dati il
programma salta da una tavola all’altra. La dislocazione dei dati su più
tabelle aumenta i tempi di ricerca dei dati (cioè l’accesso). Se gli archivi sono
molto grandi i tempi di attesa saranno multo lunghi. Per migliorare l’accesso
si usano delle tecniche di denormalizzazione. Queste possono essere :
? fusione delle tavole
? gli array
? deliberata introduzione di ridondanza dei dati
? dati derivati
? indici creativi
? ecc..
La fusione delle tavole ha come scopo quello di limitare le join fra le tavole
coinvolte nella ricerca dei dati e quella di dare una rappresentazione di
insieme dei dati più comprensibile all’utilizzatore degli stessi.
Un’altra tecnica è quella della creazione di array di dati. In uno schema
normalizzato, ritrovare fisicamente l’occorrenza n, n+1, n+2, ....., richiede un
certo numero di accessi. Se i dati che normalmente vengono acceduti più
spesso sono posti fisicamente in un singolo array, si ha un singolo accesso.
379
Capitolo settimo
La filosofia Data Warehouse
Programma
.......
n
.......
.......
n+2
.......
.......
Programma
.......
n+1
.......
n+4
.......
.......
n+3
.......
.......
n
n+1
n+2
n+ 3
n+4
.......
Figura 7.42. Nel primo caso il programma dovrà saltare da un blocco fisico all’altro per trovare
i dati, nel secondo invece se li troverà disposti in uno stesso array (Building the D/W)
La tecnica della duplicazione cerca di limitare gli accessi per quei dati che
sono richiesti con maggior frequenza duplicandoli su più tabelle. In questo
modo, come si vede dalla figura sotto, si moltiplicano gli aggiornamenti del
dato in quanto questo si trova su più tabelle. Per quei dati che, invece devono
essere estratti, elaborati tutte le volte ed in maniera sempre uguale per poi
essere utilizzati nelle diverse ricerche, si può inserire direttamente la forma
sintetica degli stessi, e cioè dei dati già pre-elaborati che così potranno essere
direttamente utilizzati senza realizzare quegli accessi ed elaborazioni che
peggiorano le performance. Si possono creare, inoltre , particolari indici,
come i Bit Map, ad esempio , per velocizzare la ricerca dei dati.
7.12.3.2. Schema a stella
Questo schema ha come scopo quello di organizzare i dati in tabelle in modo
tale da supportare un’analisi di tipo multidimensionale.
380
Capitolo settimo
La filosofia Data Warehouse
Sappiamo come gli elementi fondamentali del modello multidimensionale
siano i fatti e le dimensioni41.
I fatti sono i “dati numerici” che devono essere rintracciati. Essi sono
memorizzati in una tabella centrale detta Fact table (FT). Le dimensioni sono
i “parametri di Business” che definiscono ogni transazione. Le dimensioni
sono memorizzate in tabelle satellite dette Dimension table (DT) legate alla
tabella centrale.
Esempio :
I dati memorizzati nella FT includono
Vendite - Inventario - sottoscrizioni di magazzino - Spese
I dati memorizzati nelle DT includono
Tempo - Luoghi geografici - Account - Prodotti
Le FT sono completamente normalizzate, quindi non vi sono dati duplicati
nella tabella.
Colonne chiave che legano la FT e DT
Prod_Code
101
102
Time_code
2045
2045
Acct_code
501
502
Valori numerici
Sales
3999
333
QTV
0
2
Figura 7.43. Fact Table (Informix)
Le informazioni nelle DT sono utilizzate per specificare interruzioni di
subtotali o vincoli sulla query.
Esempio di query :
“Le vendite mensili per tutte le vendite al dettaglio nelle regioni orientali”
“Il Data Warehouse richiede una vista query centrica dei dati e lo schema a stella provvede
a realizzare tutto ciò. La premessa base di uno schema a stella è l’informazione che può
essere classificata in due gruppi :i fatti e le dimensioni. I fatti sono il cuore degli elementi che
devono essere analizzati. Le dimensioni sono gli attributi dei fatti.” Tratto
da :http ://www.redbrick.com/rbs/wuitepapers/star_wp.html
381
41
Capitolo settimo
La filosofia Data Warehouse
In questo caso le vendite sono prelevate dalla FT che è messa in Join con le DT di
prodotto, time, Aree geografiche. Prodotto (linea di prodotto) e Time (Mese) sono
usati come chiave di rottura nel report, mentre area geografica (regione) è usata
come vincolo di ricerca42.
Le DT memorizzano tutte le informazioni associate con ogni particolare
dimensione. Questa include :
? la traccia delle relazioni gerarchiche di ogni dimensione
? la traccia degli attributi descrittivi di ogni dimensione
Le dimensioni possono essere spesso organizzate in gerarchie. Ogni livello
della gerarchia è in grado di raggiungere la successiva.
Esempio :
Nella dimensione del prodotto il prodotto raggiunge la Linea di Prodotto che a sua
volta raggiunge il Marchio43.
La gerarchia è importante nel l’MDM in quanto definisce l’intelaiatura per
le funzioni Drill-Down e Drill-Up44.
Chiaramente la scomposizione gerarchica non è lineare, questo vuol dire che
non tutti i livelli della gerarchia non possono raggiungere i livelli successivi
(anche se logicamente potrebbe essere possibile).
Giorno
Mese
Anno
Settimana
Figura 7.44. Gerarchia del tempo : poiché il mese non è suddiviso in settimane dal livello
settimana non posso raggiungere il mese.
Dimension Elements
Tratto da documenti Informix :Designing the Data Warehouse on Relational Database.
Tratto da documenti Informix :Designing the Data Warehouse on Relational Database.
44
“Drill-Up è la funzione inversa del Drill-Down ; è la richiesta di una vista riassuntiva dei dati”.
Tratto da documenti Informix :Designing the Data Warehouse on Relational Database.
42
43
382
Capitolo settimo
La filosofia Data Warehouse
Un Dimension Element è una speciale categoria di dato che rappresenta un particolare livello nella gerarchia delle dimensioni. Esiste un Dimension
Element per ogni livello.
Esempio :
Per la dimensione del prodotto esistono tre dimension element :prodotto, linea di
prodotto, marchio45.
In questo modello un livello può rappresentare il Livello massimo o il livello minimo.
Esempio :
Livello minimo - Prodotto ; Livello massimo - Marchio46.
Dimension Attributes
I Dimension Attributes descrivono un particolare Dimension Element.
Esempio :
Manage_del_marchio descrive la dimensione del Marchio.
I Dimension Attributes consentono di descrivere i dati nella gerarchia.
Uno schema articolato in questo modo prende il nome di schema a stella
poiché la sua rappresentazione da luogo ad una figura a stella in cui al centro si trova la Fact table e legata ad essa ci sono le Dimension Tables.
Time
Geography
Day
Month
Season
Years
Week
Sales
Geography Code
Time Code
Product Code
Amount
Units
Region code
Postal Code
State Code
City Code
Region Mngr
State Name
Store Name
City Mngr
Product
Product Code
Brand Code
Prod Line Code
Product Name
Product Color
Brand Manager
Brand name
P. Line Manag.
45
Tratto da documenti Informix :Designing the Data Warehouse on Relational Database.
383
Capitolo settimo
La filosofia Data Warehouse
Figura 7. 45. Schema a stella (Informix)
Una caratteristica dello schema a stella è che le DT sono denormalizzate, per
cui i dati sono ripetutamente memorizzati nelle singole tabelle a beneficio
della semplicità del disegno e delle performance. Può avvenire, quindi, che
un dimension attribute sia memorizzato più volte in una dimension table in
relazione al livello della gerarchia delle dimensioni che esso descrive.
Esempio :
Una compagnia ha 100 prodotti relativi a un totale di 5 marche. Per ogni prodotto
elencato nella DT del prodotti vi è la relativa marca come anche tutti gli attributi
della marca (brand Mamager-Brand Name...). In un modello normalizzato gli
attributi della Marca sarebbero memorizzati in una tabella delle marche, e solo la
chiave esterna a questa tabella sarebbe istanziata più volte47.
Un modello di questo genere permette di realizzare 4 vantaggi :
1. Permette di definire una struttura multidimensionale con un modello
molto semplice. Consente di definire relazioni gerarchiche in ogni
dimensione, e semplifica il processo di creazione delle join che
coinvolgerebbero più tabelle.
2. Riduce il numero di join fisiche che una query potrebbe generare
migliorando le performance.
3. Semplificando la vista del modello dei dati si riducono le possibilità che
un utente realizzi query che richiedono notevoli risorse per essere risolte.
4. Consente uno sviluppo ed una evoluzione del Data Warehouse con un
basso livello di manutenzione.
Questo modello pone, come altri però, dei problemi di aggregazione dei dati.
I fatti, ovvero le misure, memorizzate nella FT devono essere al massimo
dettaglio. Ora, la FT tende ad essere molto grande per cui estrarre i dati al
massimo dettaglio di atomicità può produrre delle performance non proprio
ottimali. Inoltre, un numero significativo di query richiedono totalizzazioni o
46
47
Tratto da documenti Informix :Designing the Data Warehouse on Relational Database.
Tratto da documenti Informix :Designing the Data Warehouse on Relational Database.
384
Capitolo settimo
La filosofia Data Warehouse
aggregazioni di dati. Realizzare un processo di pre-sintesi dei dati che poi
potranno essere utilizzati nelle query può essere utile. A questo punto il problema non è se aggregare ma come e quando aggregare.
Quando si effettua un’aggregazione occorre prendere in considerazione
questi due elementi :
? La densità dei dati :dove sono concentrati i dati e in quali Dimension
Elements il numero di righe aumenta.
? Modelli di utilizzo : quali aggregazioni potrebbero aumentare le
performance per specifiche query eseguite frequentemente.
Se un dato dimension element è rappresentato in un grande numero di
righe qualora sia
confrontato con un altro elemento nella gerarchia,
effettuare delle aggregazioni per questo elemento può migliorare le
performance. Se si combina più dimensioni questa analisi diventa ancora
più significativa.
Un altro elemento, come detto, è la densità dei dati. E’difficile, ad esempio,
che ogni prodotto sia venduto in ogni magazzino in tutti i giorni. Ed anche
se questo prodotto fosse venduto tutti i giorni, la densità sarebbe bassa. La
densità dei dati rende difficile determinare quanti record il DBMS dovrà
processare.
Esempio :
Quando si decide, per esempio, di aggregare per Linee di prodotto vendute per
Regione , può essere cruciale individuare il numero di differenti prodotti venduti
per ogni magazzino nelle differenti regioni.
Si consideri un semplice database contenente 4 magazzini per due regioni ( totale 8
magazzini), che vendono 4 prodotti per due Linee di prodotto (8 prodotti). Solo
uno dei prodotti in una linea di prodotto è venduto in ogni regione su base
giornaliera, il numero dei prodotti per linea di prodotti per quel giorno si riduce ad
uno. Per la richiesta “Linee di prodotto vendute giornalmente per regione”, una
riga di prodotto sarà trovata per ogni linea di prodotto (2) per ogni regione(2), per
un totale di quattro righe. In questo caso l’aggregazione non offre particolari
vantaggi.
385
Capitolo settimo
La filosofia Data Warehouse
All’estremo opposto, se ogni prodotto in ogni linea di prodotto è venduto in ogni
magazzino ogni giorno, allora questa richiesta dovrà processare 4 prodotti per
ognuna delle 2 linee di prodotto e ognuno dei 4 magazzini in ogni regione , per un
totale di 64 record. Un’aggregazione che sommi le linee di prodotto vendute per
regione potrebbe risolvere questa richiesta usando solo 4 record, riducendo
drasticamente i consumi48.
Per determinare il numero di aggregazioni ottimali nel Data Warehouse,
occorrerà
realizzare
una
simulazione
delle
dimensioni
del
Data
Warehouse. Esistono particolari strumenti che permettono di realizzare
questa simulazione.
7.12.3.3. Schema a fiocco di neve
In alcuni a casi la realizzazione di uno schema a stella può non essere la
soluzione più adeguata perché lo schema denormalizzato richiede una
occupazione di spazio eccessiva o perché la dimensione eccessiva di una
tabella può avere effetti negativi sulle prestazioni, riducendo gli effetti
delle aggregazioni.
Quindi, la denormalizzazione, anche se
è un metodo che migliora le
performance riducendo la necessità di join, può comportare elevati costi di
occupazione dello spazio.
La normalizzazione delle DT potrebbe risolvere questo problema passando
così da uno schema a stella a uno a fiocco di neve, definito così per
l’aggiunta di complessità alla struttura49.
48
Tratto da documenti Informix :Designing the Data Warehouse on Relational Database.
49 Vantaggi e svantaggi dello schema a stella e dello schema a fiocco di neve :
Schema a stella :
Vantaggi :Facile da capire, facile definizione delle gerarchie, riduce i # join fisici, bassa manutenzione, semplice metadata.
Svantaggi :dati atomici nelle fact table , grandi dimensioni nelle Dimension tables
Schema a fiocco di neve :
Vantaggi :Migliori vantaggi per le query che richiedano aggregazione
Svantaggi : complicazione della manutenzione e metadata più complesso, esplosione del numero delle tavole del metadata. Tratto da http ://www.strategy.com. d/wf/raden/str101_q.htm
386
Capitolo settimo
La filosofia Data Warehouse
Esempio :
consideriamo un database in cui esista un livello di aggregazione delle vendite per linea di prodotto e marca. Time
Geography
Mounth
......
.......
........
.......
......
Region code
Postal Code
State Code
City Code
..........
...........
..........
City Mngr
Day
Region
Sales
.....
......
Geography Code
Time Code
Product Code
Amount
Units
Product
Product Code
Brand Code
Prod Line Code
.
State Code
State Name
Product
Product Code
Product Name
Product Color
Linea
Prod.Line Code
P. Line Manag
Region Code
Region Mngr
State
Store
Store code
Store Name
Brand
Brand Code
Brand Manager
Brand name
Figura 7.46. Schema a fiocco di neve
Assumiamo inoltre che la FT contenga 10 milioni di righe e la DT di prodotto
100.000 dove i manager di una linea di prodotto sono 15.
Consideriamo ora una richiesta di vendite per Manager di linea di prodotto. Sia nel
caso dello schema a stella che dello schema a fiocco di neve le informazioni possono
essere lette direttamente dalla tabella di aggregazione della linea di prodotto. Però
nel caso dello schema a stella le 100.000 righe della dimension table di prodotto
devono essere messe in join per leggere le informazioni del managar della linea di
prodotto. Nel caso dello schema a fiocco di neve gli attributi della linea di prodotto
saranno separati dalla dimension table del prodotto. Quindi, le informazioni del
Manager della linea di prodotto possono essere recuperate effettuando una join con
una tabella di volume (15) notevolmente inferiore.
387
Capitolo settimo
La filosofia Data Warehouse
Vendite per linea di prodotto
250righe di aggregazione
Fiocco di neve
Vendite per linea di prodotto
250righe di aggregazione
Stella
Dimensione Linea di prodotto
15 righe
Dimensione Prodotto
100.000 righe
Figura 7. 47. Stella vs. Fiocco di neve (Informix)
Comunque, la completa normalizzazione riporterà ai problemi sopra analizzati50.
7.12.4. Il Data Mining
I dati possono essere visti come una miniera d’informazioni. Infatti, come
le miniere, non è possibile definire esattamente i contorni (vale a dire che è
difficile stabilire le dimensioni esatte dei contorni) ed è difficile l’estrazione
dei materiali utili (le informazioni) dai dati grezzi.
Se il patrimonio dati equivale a un giacimento, le tradizionali tecniche di
query ( quelle che si realizzano tramite SQL) riescono a portare in
superficie solo il “minerale” allo stato grezzo.
L’SQL permette di rispondere solo a domande semplici aggregando e
selezionando i dati. Con l’analisi multidimensionale è stato possibile
effettuare
delle
interrogazioni
più
complesse
che
prendono
in
considerazione più dimensioni. Si tratta, comunque di un modo più
complesso di effettuare delle aggregazioni con tecniche tradizionali.
L’aumento della potenza dei computer e la contemporanea riduzione di
costo ha permesso di applicare algoritmi di analisi ed esame dei dati molto
più sofisticati. Spesso si tratta di applicare tecniche statistiche conosciute da
decenni per scoprire nuove relazioni fra i dati.
50
Tratto da documenti Informix :Designing the Data Warehouse on Relational Database.
388
Capitolo settimo
La filosofia Data Warehouse
Queste tecniche dette di “Data Minimg” permettono di identificare nuove
relazioni fra i dati, nuovi pattern, e di attribuire a questi delle regole, o meglio delle
regolarità51.
Il “Data Mining” equivale, quindi, alla raffinazione del materiale grezzo da
cui si può estrarre delle informazioni. Ma ciò non sarebbe possibile senza
una architettura come il D/W che fornisce dati di diversa provenienza,
integrati e pronti ad essere utilizzati in queste elaborazioni di “Data
Mining”.
L’analisi statistica produce 5 classi di informazione : associazioni, sequenze,
classificazioni, raggruppamenti e tendenze.
Si ha un’associazione quando più eventi o fatti elementari vengono collegati ad
un unico evento globale52. Ad esempio, l’analisi delle vendite di un certo tipo
di automobile può rilevare che se è una donna ad acquistare un’auto, nel
15% questa è blu e che se nel mese precedente all’acquisto è stata effettuata
una campagna pubblicitaria in cui un noto testimonial appariva a fianco di
quel tipo di auto di colore blu la percentuale sale al 25%. Una casa
automobilistica può utilizzare questi dati per decidere se gli conviene
aumentare la produzione di auto blu oppure se è meglio per essa utilizzare
sui vari media auto di colore differenti per non creare problemi di
concentrazione degli ordini su di un certo colore, cosa che potrebbe
rivelarsi fastidiosa per la pianificazione.
Si ha una sequenza se gli eventi elementari vengono collegati nel tempo. Si può
scoprire, ad esempio, che se una famiglia compra una casa, nel 60% dei casi
acquisterà entro un mese un frigorifero e nel 40% dei casi entro due mesi
una lavastoviglie53.
Si ha una classificazione quando vengono identificati schemi o insiemi di
caratteristiche che definiscono il gruppo cui appartiene un dato elemento54. La
classificazione parte dalla considerazione di classi già identificate e a
B. Cortona :”Minatori nei giacimenti dei Dati” Zerouno 9/1996
B. Cortona :”Minatori nei giacimenti dei Dati” Zerouno 9/1996
53
B. Cortona :”Minatori nei giacimenti dei Dati” Zerouno 9/1996
51
52
389
Capitolo settimo
La filosofia Data Warehouse
scoprire particolari regolarità. Ad esempio, l’insieme dei clienti perduti.
Oppure si possono scoprire le caratteristiche dei clienti apparentemente
fedeli che invece non acquisteranno probabilmente più di un dato prodotto
e
identificare le promozioni che sono state efficaci nel ribaltare le
regolarità. Quindi, i benefici che si possono ottenere da queste informazioni
sono notevoli.
Il raggruppamento è simile alla classificazione ma consente di produrre nuovi
gruppi, prima ancora non definiti. Il raggruppamento, o clustering, produce,
ad esempio, quelle suddivisioni in “tribù” delle popolazioni sulla base
dell’atteggiamento verso certi argomenti o del comportamento nel
consumo (stili di vita)55.
Il quinto tipo di informazione prodotto dal Data Mining è costituito dalle
tendenze. Mentre gli altri tipi di informazioni permettono di realizzare
delle previsioni, le tendenze sono esse stesse previsioni : stime del valore di
certe variabili continue (ad esempio, le vendite) sulla base di schemi
identificati dei dati.
Tutte
queste
informazioni
possono
essere
prodotte
attraverso
l’applicazione di una serie di tecniche combinate fra loro
fra cui le
principali sono : Le reti neurali, alberi di decisione, induzione di regolarità
e analisi visuale dei dati56.
B. Cortona :”Minatori nei giacimenti dei Dati” Zerouno 9/1996
“Lo stile di vita è l’insieme di valori, di attività, di interessi, e opinioni degli individui che
maggiormente determina i diversi comportamenti di consumo......I sistemi d’analisi degli
stili di vita sviluppati finora sono indirizzati soprattutto all’analisi delle attività, degli
interessi, delle opinioni e in misura minore dei valori.” J.J. Lambin :”Marketing”, McGrawHill
56
Per un esame più approfondito delle tecniche sopra enunciate si rinvia ai seguenti siti
internet :
http ://.Info-Mine.com/
http ://www.Kdd.ORGL
http ://Info. GTE.com/
http :// Miningnet.com
54
55
390