Data Warehouse

Nonostante il termine data warehouse (DW) sia diventato molto di moda negli ultimi anni ed un gran numero di aziende stia implementando o per implementare sistemi di DW, non esiste una unanime definizione di magazzino di dati.

Secondo alcuni autori il DW � semplicemente un sinonimo di database fisico (relazionale o multidimensionale) che contiene dati; secondo altri, il DW può essere definito come un ambiente con strutture dati finalizzate al supporto delle decisioni, fisicamente separato dai sistemi operazionali. Entrambe le definizioni, tuttavia, sembrano abbastanza limitanti e non in grado di spiegare a fondo il concetto.

Inmon, che per primo ha parlato esplicitamente di data warehouse, invece, lo definisce come una raccolta di dati integrata, subject oriented, time variant e non-volatile di supporto ai processi decisionali. Quindi, l’integrazione dei dati di un DW costituisce una delle premesse necessarie che ne consentono una progettazione adeguata e che lo distinguono da ogni altro sistema di supporto alle decisioni.

Secondo Inmon la raccolta di dati �:

Integrata: requisito fondamentale di un data warehouse � l’integrazione della raccolta dati. Nel data warehouse confluiscono dati provenienti da pi� sistemi transazionali e da fonti esterne. L’obiettivo dell’integrazione può essere raggiunto percorrendo differenti strade: mediante l’utilizzo di metodi di codifica uniformi, mediante il perseguimento di una omogeneità semantica di tutte le variabili, mediante l’utilizzo delle stesse unità di misura;
subject oriented: perché il DW � orientato a temi specifici dell’azienda piuttosto che alle applicazioni o alle funzioni. In un DW i dati vengono archiviati in modo che possano essere facilmente letti o elaborati dagli utenti. L’obiettivo, quindi, non � pi� quello di minimizzare la ridondanza mediante la normalizzazione ma quello di fornire dati che abbiano una struttura in grado di favorire la produzione di informazioni. Si passa dalla progettazione per funzioni alla modellazione dei dati al fine di consentire una visione multidimensionale degli stessi;
time variant: i dati archiviati all’interno di un DW hanno un orizzonte temporale molto pi� esteso rispetto a quelli archiviati in un sistema operazionale. Nel DW sono contenute una serie di informazioni relative alle aree di interesse che colgono la situazione relativa ad un determinato fenomeno in un determinato intervallo temporale piuttosto esteso. Ciò, tuttavia, comporta che i dati contenuti in un DW sono aggiornati fino ad una certa data, che nella maggior parte dei casi, � antecedente a quella in cui l’utente interroga il sistema.

Situazione del tutto differente, al contrario, si manifesta in un transazionale in cui i dati corrispondono sempre ad una situazione costantemente aggiornata che tuttavia non fornisce un quadro storico del fenomeno analizzato;

non-volatile: tale caratteristica indica la non modificabilità dei dati contenuti nel DW che consente accessi in sola lettura. Comporta, inoltre, una maggiore semplicità di progettazione del database rispetto a quella di un database relazionale che supporta una applicazione transazionale. In tale contesto non si fronteggiano le possibili anomalie dovute agli aggiornamenti e tanto meno si ricorre a strumenti complessi per gestire l’integrità referenziale o per bloccare record a cui possono accedere altri utenti in fase di aggiornamento.

Il data warehouse, quindi, descrive il processo di acquisizione, trasformazione e distribuzione di informazioni presenti all’interno o all’esterno delle aziende come supporto ai ‘’decision maker’’.

Esso si differenzia, però, in modo sostanziale dai normali sistemi gestionali che, al contrario, hanno il compito di automatizzare le operazioni di routine.

Inoltre, si può notare che la definizione di Inmon precedentemente citata introduce un concetto di assoluta indifferenza rispetto alle caratteristiche architetturali dei sistemi transazionali e alla dislocazione fisica dei dati nei diversi database.

Se il focus viene posto sulla capacità di supportare il processo decisionale, il data warehouse può essere costruito secondo modalità differenti che vanno da una logica completamente accentrata, a una logica completamente distribuita.

Table of contents

1 Le componenti e l'architettura del Data Warehouse
2 Data transformation layer
3 DATA PREPARATION AND STORAGE LAYER
4 Data interpretation and analysis layer
5 Data presentation layer (DW applications)
6 Gli ambiti applicativi del data warehouse

6.1 Controllo di gestione
6.2 Risk e Asset Management
6.3 Database di marketing
6.4 Supporto Call Center
6.5 Knowledge Base
6.6 Product Engineering
6.7 Sistema informativo di marketing
6.8 @-business

Le componenti e l'architettura del Data Warehouse

Le principali componenti dell’architettura sono:

I dati provenienti dai sistemi transazionali: sono quell’insieme di dati elaborati dai sistemi transazionali della banca. Essi possono essere contenuti all’interno dello stesso database o provenire da diversi database o anche esterni all’azienda. Spesso l’architettura di un data warehouse prevede l’integrazione dei dati interni con dati esterni. L’utilizzo di questi ultimi consente di arricchire il patrimonio informativo
Il data movement: tale componente � responsabile dell’estrazione dei dati dai sistemi transazionali, dell’integrazione tra dati aziendali e dati esterni, del pre-processing dei dati, del controllo della consistenza dei dati, della conversione della struttura dei dati, e dell’aggiornamento dei dizionari dati.
Il data warehouse: dopo aver estratto i dati dagli archivi transazionali essi vengono memorizzati all’interno del data warehouse. Nel data warehouse l’accesso ai dati � consentito in sola lettura. I dati contenuti nel data warehouse hanno una dimensione storica e sono riferiti a soggetti di business. Essi possono essere memorizzati in un repository centrale o in un data mart. Il termine data mart � utilizzato per identificare un data warehouse di pi� piccole dimensioni che � orientato a supportare una particolare area di attività. Si pensi, ad esempio, al data mart per il marketing in cui i dati filtrati dagli archivi transazionali sono memorizzati per supportare l’analisi della clientela. È possibile quindi che esistano all’interno della banca pi� data mart aventi finalità diverse e orientati a coprire diverse aree di business. I dati contenuti nel data warehouse possono essere aggregati e sommarizzati per rispondere a specifiche necessità informative.
I metadati: i metadati costituiscono l’addizionale base informativa che arricchisce i dati contenuti nel data warehouse. Spesso essi vengono chiamati in gergo “data about data” indicandone la provenienza, l’utilizzo, il valore o la funzione del dato. A tale proposito vengono costituiti dei veri e propri ‘’information catalog’’. Quest’ultimi sono i file che contengono i metadati. Esso consente di spiegare all’utente la natura dei dati nel data warehouse, il loro significato semantico, da quali archivi essi provengono e la loro storicità.
L’utente finale: i dati contenuti nel data warehouse vengono presentati all’utente finale che dispone di un insieme di tool che consentono di effettuare elaborazioni per produrre informazioni appropriate. I tool a disposizione dell’utente possono essere semplici generatori di query e report, interfacce grafiche che consentono la rappresentazione dei dati o sistemi di analisi dati pi� complessi.

Il data warehouse viene strutturato su quattro livelli architetturali:

qualità dei dati: � il livello che presiede all’acquisizione e alla validazione dei dati nel data warehouse;
preparazione e "stoccaggio" dati: � il livello che presiede alla delivery dei dati agli utenti e alle applicazioni analitiche;
interpretazione e analisi dati: � il livello, ad elevato valore aggiunto, che presiede alla trasformazione dei dati in informazioni ad elevato valore strategico;
presentazione dati: � il livello, a basso valore aggiunto, che presiede alla presentazione finale agli utenti delle informazioni e quindi delle risposte cercate.

Questi quattro livelli ‘operativi’ del data warehouse possono esistere sotto due condizioni fondamentali:

l’esistenza di una adeguata organizzazione di supporto al processo, con ruoli e responsabilità chiaramente definiti. Esattamente come e forse pi� delle applicazioni transazionali un sistema di ‘’decision support’’ necessita di figure organizzative con la responsabilità di mantenerlo, soprattutto in chiave evolutiva, per far sì che esso sia costantemente allineato alle esigenze degli utenti di business, condizione necessaria e sufficiente perché continui ad esistere;
il giusto rilievo alla tecnologia di supporto al processo, composta di scelte equilibrate e basate sulle esigenze funzionali del processo stesso. La tecnologia � particolarmente cruciale per il data warehouse, date le problematiche di system integration che esso porta con sé. La gestione costante della variabile tecnologica � uno dei fattori critici di successo del data warehouse, a partire dalle scelte iniziali per arrivare alla gestione operativa degli upgrade e degli ampliamenti della piattaforma.

Da un punto di vista architetturale il data warehouse � un sistema periferico, non � cio� fisicamente residente sul sistema informativo centrale. Il motivo di ciò va ricercato nel peculiare tipo di attività svolto: una piattaforma di tipo transazionale � maggiormente orientata all’esecuzione costante di operazioni di update, ragione per cui l’ottimizzazione viene fatta soprattutto sull‘I/O; una piattaforma di decision support invece deve essere ottimizzata per effettuare un numero limitato di query particolarmente complesse. L’unica eccezione a tale regola può essere rappresentata da soluzioni di tipo mainframe, ove la possibilità di definire macchine virtuali all’interno della stessa machina fisica rende possibile la coesistenza sullo stesso server fisico delle applicazioni transazionali e delle applicazioni di decision support.

Vediamo ora, da un punto di vista fisico, come � fatta un’architettura di data warehousing.

Data transformation layer

L’architettura di data warehousing vera e propria inizia dallo strato denominato data transformation, cio� dall’insieme di applicazioni che svolgono l’attività di estrazione, trasformazione e caricamento dei dati dai sistemi transazionali alimentanti verso il data warehouse.

La fase di estrazione dei dati dai sistemi alimentanti viene nella maggior parte dei casi implementata utilizzando i linguaggi proprietari delle piattaforme alimentanti. Si tratta per lo pi� di query ad hoc, parametrizzate per quanto riguarda l’arco temporale, eseguite periodicamente solitamente nei momenti di minore attività del sistema.

La fase di ‘’’trasformazione’’’, quella a pi� elevato valore aggiunto tra le tre contenute in questo layer applicativo, applica regole di integrazione, trasformazione e ‘’cleansing’’ (business rule) ai dati estratti dai sistemi alimentanti. È in questo layer che molto spesso si gioca la credibilità dei dati del data warehouse presso gli utenti. Nella maggior parte dei casi i dati estratti dai sistemi transazionali sono o incompleti o comunque non adatti a prendere decisioni in quanto non coerenti con le analisi da effettuarsi.

In alcuni casi le operazioni di trasformazione possono risultare nella casistica del ‘’reject’’: cio� dell’impossibilità, salvo intervento umano, di accettare parte del flusso alimentante per l’eccessiva e non risolvibile ‘impurità’ dei dati alimentanti.

Le trasformazioni possono essere di vari tipi:

‘’’Codifiche inconsistenti’’’. Lo stesso oggetto � codificato in modi diversi a seconda del sistema alimentante. In fase di trasformazione ogni flusso alimentante andrà ricodificato in base ad un’unica codifica convenzionale definita per il data warehouse;
‘’’Unità di misura/formati inconsistenti’’’. È il caso in cui la stessa grandezza viene misurata con unità di misura o rappresentata con formati differenti a seconda del sistema alimentante di provenienza. In fase di trasformazione ogni flusso alimentante andrà convertito in un’unica unità di misura convenzionale per il data warehouse;
‘’’Denominazione inconsistente’’’. È caso in cui a seconda del sistema transazionale alimentante lo stesso oggetto (di solito un dato) viene denominato in modo diverso. Solitamente il dato all’interno del warehouse viene identificato in base alla definizione contenuta nei metadati del sistema;
‘’’Dati mancanti o errati’’’. Nei tre casi precedenti le operazioni di trasformazione consistevano essenzialmente in attività di conversione, entro certi limiti automatizzabili. In questo caso, invece, l’operazione di trasformazione può richiedere l’intervento umano per risolvere casistiche non prevedibili e implementabili mediante le business rule.

DATA PREPARATION AND STORAGE LAYER

Questo livello coincide con il massimo dettaglio disponibile (in termini di dati) all’interno del sistema di data warehousing.

Una volta che i dati hanno superato il ‘’quality layer’’ vengono ‘stoccati’ in questo livello architetturale per garantire due tipi di utilizzi:

la creazione di sintesi informative per gli utenti (data mart e aggregazioni) mediante procedure ad hoc che vengono solitamente innescate (in termini di update) dalla completa esecuzione delle operazioni di estrazione, trasformazione e caricamento;
l’esecuzione di analisi avanzate basate prevalentemente su algoritmi di tipo statistico che richiedono l’operatività sul massimo dettaglio disponibile dei dati per restituire risultati significativi.

Data interpretation and analysis layer

A questo livello dell’architettura del sistema di data warehousing troviamo oggetti tra loro molto diversi per funzione e tecnologia. Le tre funzionalità base espletate da questo livello architetturale sono: aggregazione, analisi e interpretazione.

‘’’Aggregazione’’’ La funzionalità di ‘’’aggregazione’’’ provvede a costruire sintesi decisionali partendo dai dati di dettaglio presenti nel layer precedentemente descritto. Qui si deve fare una importante precisazione architetturale.

In una situazione in cui non esiste il data warehouse gli utenti sono costretti ad accedere ai sistemi legacy per ottenere le informazioni loro necessarie.

In alcuni casi si può decidere di estrarre dai sistemi legacy una o pi� sintesi (data mart) per gli utenti che effettueranno l’analisi su di esse. In questa situazione, anche se la tecnologia e l’architettura assomigliano molto a quelle di un data warehouse, l’impossibilità di arrivare a dati di dettaglio superiore di quello delle sintesi disponibili (drill-through) ne riduce la potenza informativa.

Peraltro il data warehouse non va necessariamente considerato come una base dati a cui tutti gli utenti accedono liberamente per le proprie analisi. Questo può essere vero dove gli utenti siano particolarmente addestrati e, comunque sia, ha delle serie controindicazioni in quanto le risorse hardware necessarie per supportare un elevato numero di utenti che eseguono ‘’query multijoin’’ sono difficilmente prevedibili e pianificabili. Molti presunti progetti di Warehousing falliscono proprio perché ci si limita a ‘portare dentro i dati ’ senza però di fatto renderli disponibili agli utenti meno esperti.

La situazione ideale � quella in cui esiste un data warehouse centrale che contiene tutti i dati al minimo livello di dettaglio richiesto per effettuare analisi avanzate e per costruire aggregazioni per tutti gli utenti. In questo caso i data mart possono essere o ‘’’tematici’’’ (cio� contenenti tutte le informazioni riguardo un certo soggetto) o per ‘’’gruppi specifici di utenti’’’.

Questa strategia architetturale fa del data warehouse un vero processo di ‘’information delivery’’, ove la richiesta di altre e diverse sintesi decisionali comporta non già la costruzione di altri flussi di alimentazione ma piuttosto la creazione di altri data mart. Lo sviluppo di nuovi flussi generanti nuovi data mart � un’attività routinaria di gestione del data warehouse. La differenza con quanto si dovrebbe fare utilizzando i sistemi legacy � essenzialmente di costo: generare un nuovo data mart all’interno di un’architettura di warehousing ha costi e tempi di sviluppo e di controllo qualità dei dati nettamente inferiore.

‘’’Analisi e interpretazione’’’ La funzionalità di ‘’’analisi’’’ consente di effettuare indagini sulle aggregazioni costruite dal sistema. Tipicamente le funzionalità di analisi di un data warehouse sono supportate da tecnologia di tipo ‘’’OLAP’’’ (On-Line Analytical Processing).

L’OLAP � essenzialmente un approccio tecnologico ai processi decisionali che si focalizza sull’analisi dimensionale delle informazioni. Le sue caratteristiche principali sono:

‘’’� orientato agli utenti di business:’’’ il business � fatto a ‘’dimensioni’’ e non a ‘’tabelle’’ e chi analizza e tenta di comprenderlo ragiona appunto per dimensioni; � per questo che una volta intuiti i due concetti fondamentali (‘’’dimensione e gerarchia’’’) qualsiasi utente di business � in grado di utilizzare uno strumento OLAP;
‘’’� pensato per la risoluzione di problemi non strutturati’’’: a differenza dei tradizionali strumenti di reporting che presentano già le risposte preconfezionate, gli strumenti OLAP stimolano le domande e consentono analisi di causa-effetto. Ciò avviene grazie alla loro struttura che permette la navigazione tra le informazioni utilizzando le gerarchie e le relazioni tra le informazioni stesse come ‘sentieri’;
‘’’si focalizza sulle informazioni:’’’ i motori OLAP non sono di per sé strumenti di presentazione delle informazioni ma architetture ottimizzate di data storage e navigazione; ne segue che tutto ciò che un utente trova in questo ambiente sono solo le informazioni di cui ha bisogno, organizzate secondo la logica delle dimensioni di analisi di business;
(conseguentemente) ‘’’crea efficienza:’’’ ovviamente il risultato netto di tutto ciò � l’efficienza creata da questi sistemi con la loro capacità di andare dal generale al particolare e di aiutare l’utente a trovare l’informazione necessaria in base a percorsi logici e non ‘scartabellando’.

Le funzioni di base di uno strumento OLAP sono:

‘’’Slicing:’’’ � l’operazione di rotazione delle dimensioni di analisi. È un’operazione fondamentale se si desidera analizzare totali ottenuti in base a dimensioni diverse o se si vogliono analizzare aggregazioni trasversali;
‘’’Dicing:’’’ � l’operazione di ‘estrazione’ di un subset di informazioni dall’aggregato che si sta analizzando. L’operazione di dicing viene eseguita quando l’analisi viene focalizzata su una ‘fetta del cubo ’ di particolare interesse per l’analista. In alcuni casi l’operazione di dicing può essere ‘fisica’ nel senso che non consiste solo nel filtrare le informazioni di interesse ma magari nell’estrarle dall’aggregato generale per distribuirne i contenuti;
‘’’Drill-down:’’’ � l’operazione di ‘esplosione’ del dato nelle sue determinanti. L’operazione di drill-down può essere eseguita seguendo due tipologie di ‘sentiero’: la ‘’’gerarchia’’’ costruita sulla dimensione di analisi (p. es.: passaggio dalla famiglia di prodotti all’insieme dei prodotti che ne fanno parte) oppure la ‘’’relazione matematica’’’ che lega un dato calcolato alle sue determinanti (p. es.: passaggio dal margine al ricavo e costo che lo generano). Si può comprendere l’importanza di tale operazione ai fini analitici in termini di comprensione delle determinanti di un dato;
‘’’Drill-across:’’’ � l’operazione mediante la quale si naviga attraverso uno stesso livello nell’ambito di una gerarchia. Come visto precedentemente il passaggio dalla famiglia di prodotti alla lista dei prodotti � un’operazione di drill-down, il passaggio da una famiglia ad un’altra famiglia � un’operazione di drill-across;
‘’’Drill-through:’’’ concettualmente simile al drill-down, � l’operazione mediante la quale si passa da un livello aggregato al livello di dettaglio appartenente alla base dati normalizzata. Molti software vendor proclamano che i loro prodotti hanno la capacità, mediante l’operazione di drill-through, di passare dal data warehouse ai sistemi transazionali alimentanti. Tale operazione, anche se tecnicamente fattibile sotto una serie di condizioni abbastanza rilevanti, � poco sensata per le problematiche di security e di performance indotti nei sistemi transazionali stessi.

I punti deboli degli strumenti OLAP sono:

‘’’Inaccessibilità/difficoltà ad accedere al livello atomico del dato:’’’ gli strumenti OLAP funzionano molto bene su dati di sintesi, non � conveniente usarli su dati analitici;
‘’’Sistemi di backup / restore / security / rollback non molto sofisticati o inesistenti:’’’ pur essendo in molti casi dei motori database, gli strumenti OLAP non hanno ancora raggiunto il livello di completezza dei database relazionali, principalmente perché, a differenza di questi ultimi, non hanno un paradigma concettuale di riferimento come la teoria di Codd, ma sono soggetti alle interpretazioni dei diversi software vendor;
‘’’Richiede una struttura denormalizzata per funzionare in maniera efficiente:’’’ i motori OLAP generano grandi masse di dati per il semplice fatto che per migliorare le performance di accesso sono costretti a memorizzare chiavi ridondanti e sommarizzazioni;
‘’’(Potenziale) significativa generazione e proliferazione di codice SQL:’’’ nel caso in cui il database su cui vengono effettuate le analisi OLAP non sia multidimensionale (MOLAP) ma sia relazionale (ROLAP), ognuna delle operazioni sopra descritte (slicing, dicing, drilling) comporta la generazione e l’esecuzione di query SQL estremamente complesse e richiedenti grandi capacità di elaborazione.

Data presentation layer (DW applications)

Questo livello, ingiustamente considerato il pi� importante da chi pensa che costruire un sistema di decision support voglia dire disegnare degli spettacolari report layout, contiene tutti i sistemi di presentazione delle informazioni agli utenti.

I sistemi appartenenti a questo layer architetturale possono essere raggruppati in tre grandi categorie:

‘’’strumenti specialistici di Business Intelligence:’’’ in questa categoria, molto vasta in termini di soluzioni presenti sul mercato, troviamo strumenti di query building, strumenti di navigazione OLAP (OLAP viewer) e, in un’accezione molto lata del concetto, anche i Web browser, che per la verità stanno diventando sempre pi� l’interfaccia universale per diverse applicazioni;
‘’’strumenti di Office Automation:’’’ sempre pi� i software vendor presenti con le loro soluzioni nel layer architetturale precedente indicano come soluzioni di front-end gli ordinari strumenti del lavoro quotidiano, come word processor e fogli elettronici. È ovvio che per molti utenti poco esperti che si avvicinano per la prima volta al data warehouse questa sia una soluzione psicologicamente rassicurante in quanto non sono costretti ad imparare nuovi e complessi strumenti. Il problema consiste nel fatto che tale soluzione � ideale per questioni di produttività ed efficienza, lo � meno per l’utilizzo intensivo del data warehouse, dal momento che questi strumenti, in tale caso, hanno significativi limiti architetturali e funzionali;
‘’’strumenti di grafica e publishing:’’’ in questo caso ciò che prevale ancora una volta � una considerazione di efficienza e produttività: gli strumenti Business Intelligence hanno la capacità di generare grafici e tabelle per i propri utenti, la soluzione in oggetto serve sostanzialmente ad evitare inefficienti doppi passaggi.

Un data warehouse comprende diversi livelli di dati:

‘’’Dati attuali di dettaglio’’’: sono i dati al massimo livello di dettaglio che si ritiene possano essere utili ai processi decisionali, sulla base delle esigenze note e di quelle ragionevolmente prevedibili. In realtà, questa parte comprende non solo i dati propriamente attuali (cio� validi al momento dell’interrogazione), ma anche una certa finestra temporale di dati storici. Oltre all’eventuale prima aggregazione, i dati di questo livello hanno già subito rispetto ai dati operativi tutte le altre operazioni: filtraggio delle informazioni non necessarie, interrogazione delle informazioni da fonti diverse, trasformazione rispetto allo schema dati del data warehouse.
‘’’Dati storici di dettaglio’’’: i dati di dettaglio che superano la finestra temporale del dato “attuale” ma che rientrano comunque nella finestra temporale del data warehouse vengono collocati su supporti meno impegnativi e costosi, ma anche meno comodamente accessibili.
‘’’Dati aggregati’’’: la presenza dei dati aggregati nel data warehouse deriva da considerazioni di efficienza e praticità nella risposta alle richieste degli utenti; infatti tutte le informazioni ricavabili dai dati aggregati sono in teoria ricavabili dai dati di dettaglio, ma ciò richiederebbe di volta in volta il loro ri-calcolo. In questo modo, però, non potranno essere soddisfatte esigenze non previste che richiedano aggregazioni diverse da quelle predisposte, ma a questo scopo sono comunque conservati i dati di dettaglio.

Gli ambiti applicativi del data warehouse

Del data warehouse ne parlano in molti ma lo praticano in pochi, e questo � un motivo che rende difficile identificare e motivare le aree applicative del data warehouse.

Nelle banche e in generale nelle istituzioni finanziarie gli ambiti di utilizzo sono molteplici, poiché tutte le aree gestionali di tali organizzazioni sono caratterizzate da volumi considerevoli di dati su cui devono essere prese decisioni strategiche. Poiché il data warehouse può avere un valore strategico, all’interni di tali tipi di organizzazioni � fondamentale per il management definire una strategia per il data warehouse. La strategia per il data warehouse � essenzialmente un percorso evolutivo che porta l’azienda da applicazioni DW non ‘mission-critical’ a una situazione in cui il data warehouse � una componente fondamentale del sistema informativo aziendale.

La strategia di data warehousing di un’azienda può essere classificata in base a due dimensioni fondamentali:

utilizzo del DW esistente: livello di maturità degli utenti e delle funzioni di supporto del DW nell’utilizzo dell’esistente;
utilizzo prospettico del DW: obiettivi strategici di utilizzo del DW come piattaforma di decision support.

Tutte le aziende attraversano dunque quattro fasi nella storia dell’utilizzo del data warehouse:

la prima fase, chiamata supporto (basso utilizzo del DW esistente, basso utilizzo prospettico del DW), � la fase in cui si trovano le aziende che hanno fallito uno o pi� progetti di warehousing e non pensano di ampliarne l’utilizzo prospettico. In questa fase si possono trovare anche aziende che non hanno un DW e non stanno pensando di realizzarlo;
la seconda fase, chiamata ‘’’opportunità’’’ (basso utilizzo del DW esistente, alto utilizzo prospettico del DW), � la fase in ci si trovano le aziende che, pur avendo fallito uno o pi� progetti di warehousing o avendo semplicemente esplorato la tematica senza approfondirla, puntano a sviluppare le attività di decision support tramite il data warehouse. In questa fase possono trovarsi anche aziende che non hanno un data warehouse ma stanno pensando di realizzarlo;
la terza fase (alto utilizzo del DW esistente, alto utilizzo prospettico del DW), � quella fase in cui il data warehouse diviene ‘’’strategico’’’ per i processi decisionali aziendali. In questa fase si trovano tutte quelle aziende che hanno con successo intrapreso un progetto di warehousing e che ne stanno sfruttando a pieno le potenzialità;
la quarta fase, chiamata ‘’’factory’’’ (alto utilizzo del DW esistente, basso utilizzo prospettico del DW) � la fase in cui si trovano tutte le aziende in cui il data warehouse � maturo, la metodologia di implementazione consolidata e tutte le aree decisionali critiche sono presidiate. In questa fase l’imperativo principale � l’efficienza e il risparmio di costi derivanti dal data warehouse e nel suo utilizzo. Un processo di sclerotizzazione nell’uso del data warehouse può in alcuni casi far tornare l’azienda alla prima fase.

Individuiamo ora quali sono le aree applicative pi� indicate per il data warehouse nel settore finanziario.

Controllo di gestione

Questa può essere l’area applicativa di base per un sistema di data warehousing in qualunque organizzazione. In questo caso il data warehouse viene utilizzato sostanzialmente come piattaforma di reporting e analisi di redditività. È inutile e pericoloso ipotizzare di realizzare un data warehouse solo per il controllo di gestione. Tale iniziativa ha senso solo se questo � il primo passo evolutivo nella strategia di data warehousing dell’azienda. Infatti, costruire un data warehouse per il controllo di gestione consente di analizzare e risolvere rapidamente esigenze estremamente rilevanti ed il cui beneficio � immediatamente chiaro, affrontando problemi (a livello di struttura, validazione e calcolo dei dati) estremamente noti nella loro struttura.

Risk e Asset Management

Un’altra area applicativa di estremo interesse � identificabile nelle attività di Risk e Asset Management, soprattutto in due attività ben specifiche: l’analisi e la simulazione dei portafogli e dei relativi rischi; il reporting.

Tali aree applicative sono di particolare importanza e strategicità ed il data warehouse � lo strumento appropriato per affrontarle, anche per la possibilità di integrare al suo interno dati provenienti anche da fonti esterne all’azienda. In questo caso il data warehouse va dotato di strumentistica di analisi avanzata e basata su algoritmi statistici di analisi e simulazione.

Un’altra sotto-area di grande interesse può essere lo sviluppo di sistemi di individuazione delle frodi. Anche in questo caso � necessario il ricorso a strumentazione di tipo statistico per l’implementazione di questo genere di applicazione.

Il data warehouse � un sistema OLAP (come accennato precedentemente) che differisce dai sistemi OLTP (On Line Transaction Processing), sebbene i dati provengono dal secondo. I sistemi OLAP sono sistemi subject-oriented, sono integrati, storici e permanenti. Non comprendono dati analitici e statici come i sistemi OLTP, inoltre i dati OLAP non sono dati ad uso corrente, e vengono usati per analisi.

Un data warehouse � sempre diviso dal suo ambiente operativo e comprende tutti i dati dell’ambiente operativo. I dati del data warehouse non vengono mai cambiati; sono memorizzati all’inizio e messi a disposizione, e non sono aggiornati mai come nei sistemi OLTP. Prima di essere memorizzati nel data warehouse, i dati sono integrati seguendo diverse strategie.

La fonte dei dati per un sistema delle decisioni (come data warehouse) � un sistema operativo, anche se la prima non � una pura copia del secondo: i dati in un sistema delle decisioni sono filtrati, classificati dal tempo, sono inclusi valori sommarizzati e sono cambiati prima di essere caricati nel data warehouse. In particolare, per i microdati, i dati sono riassunti in due livelli di aggregazione diversi: il primo livello (‘’primo livello di data mart’’) specifica l’unità del tempo, e nel secondo livello (‘’data mart finale’’) sono memorizzati permanentemente soltanto dati a pi� alta frequenza. Così, se i dati sono acceduti pi� frequentemente, il livello di sommarizzazione � pi� elevato. In altre parole, � memorizzato un numero pi� piccolo di dati, e l’accesso ai dati � pi� veloce ed efficiente.

I principali approcci per sviluppare un ambiente di data warehouse sono due: il primo � basato sulla creazione di un data warehouse centrale, usando dati dal sistema principale ed altre fonti. Questo data warehouse centrale può essere utilizzato poi per creare/ aggiornare data warehouse dipartimentali o data mart locali. Il secondo approccio � basato sulla creazione di data mart indipendenti, ognuno memorizzato direttamente dal sistema centrale e altre fonti dei dati.

L’approccio di un data warehouse centrale può iniziare con un semplice data warehouse, diffuso col tempo per soddisfare utenti con crescenti richieste e diventare un ambiente che contiene sistemi di data warehouse collegati. In un semplice ambiente di data warehouse le aree che hanno necessità di essere monitorate sono tre:

l’estrazione e la trasformazione dei dati dai sistemi operativi;
la base di dati del data warehouse;
i tools per l’esplorazione dei dati.

È necessario monitorare la rete che provvede all’accesso agli utenti. Ci sono di solito almeno tre repository per i metadati e per le altre informazioni collegate: uno per descrivere la struttura dei dati, per la loro trasformazione e per l’estrazione dei dati; uno per il database del data warehouse; ed uno o pi� per gli strumenti di navigazione. Questi repository devono essere curati, sia individualmente che nelle totalità. I dati nell’ambiente del database del data warehouse dovrebbero essere maneggiati con la stessa cura. La complessità di questo compito dipende dalla complessità del database scelto, ma include copie di backup, recovery, riorganizzazioni, archiviazioni, operazioni di monitoraggio e tuning. Sono creati sub-set di dati dipartimentali o locali (data marts) per migliorare la performance delle consultazioni dell’utente e ridurre dipendenza sul data warehouse. Questo livello supplementare di dati aumenta la complessità di gestione dell’ambiente: aggiunge un altro livello di metadati e possibilmente un altro repository, richiede controllo e gestione della distribuzione dei dati dei data mart, e, a meno che l’amministrazione dei data mart sia completamente devoluta a livello locale, richiede anche la gestione di dati del database del data mart. La situazione diventa anche pi� difficile se l’ambiente evolve ulteriormente tramite la creazione di data warehouse multipli. In alcuni di questi casi, le complessità di amministrazione diventano opprimenti.

Nell’approccio di data mart indipendenti, la creazione di un solo data mart orientato a risolvere un particolare problema rappresenta una soluzione semplice. Le tre aree da amministrare sono:

l’estrazione dei dati dalle fonti e la trasformazione nelle strutture dei dati corrette per il database del data mart;
il database del data mart stesso;
i tools di sfruttamento.

Poiché questo ambiente non contiene volumi grandi di data warehouse � pi� maneggevole. Nel caso si adotti una tale semplice soluzione di data mart nella realizzazione di data warehouse e nell’organizzazione, il compito dell’amministratore sarebbe relativamente facile. Questo approccio non si ferma di solito con un data mart e, una volta che vengono aggiunti altri data mart, la situazione diventa pi� complicata. Il compito di portare un numero di data mart separati in un solo ambiente di data warehouse � estremamente difficile. Ogni data mart viene sviluppato di solito individualmente. Tali data mart hanno il potenziale di diventare parte del sistema centrale. In questo modo, possono porre il problema di discordanze nella definizione dei dati che il data warehouse � stato disegnato per risolvere. Questa situazione poco attraente si evita solamente se esiste una sola architettura di amministrazione dello sviluppo del sistema.

È probabile che il data warehouse contenga volumi molto grandi di dati, non sempre attinente a tutti gli utenti. Lavorare attraverso questi volumi di dati non correlati può essere inefficiente e consuma molto tempo nell’esecuzione. In questa situazione � possibile suddividere il data warehouse in specifiche aree di interesse.

Inoltre, molti tool per lo sfruttamento dei dati creano i loro primi ambienti, ognuno col proprio repository. Tale repository contiene le informazioni richieste per l’esplorazione dei dati. Se il data warehouse � amministrato centralmente, questi ambienti devono essere incorporati nella struttura centrale della gestione. Anche dove la responsabilità dell’amministrazione dei tool di sfruttamento dei dati � a livello dell’utente locale, � richiesto un collegamento tra il sistema di amministrazione di data warehouse centrale e gli ambienti distribuiti. Questo collegamento � necessario per assicurare che i cambiamenti dei tool degli ambienti distribuiti possono essere identificati anche centralmente.