Data warehouse: questo (mis)conosciuto. Un progetto in ambito sanitario

Un nostro cliente ci ha commissionato (implicitamente) un data warehouse in ambito sanitario.

In questa serie di articoli vedemo cosa è, quali sono gli strumenti, qual’è la teoria.

Partiamo dalla definizione di data warehouse.

Un Data warehouse (o DW) (termine inglese traducibile con magazzino di dati), è un archivio informatico contenente i dati di un’organizzazione. I DW sono progettati per consentire di produrre facilmente relazioni ed analisi.

Vengono considerati componenti essenziali di un sistema Data warehouse anche gli strumenti per localizzare i dati, per estrarli, trasformarli e caricarli, come pure gli strumenti per gestire un dizionario dei dati. Le definizioni di DW considerano solitamente questo contesto ampio.

Una definizione ampliata comprende inoltre gli strumenti per gestire e recuperare i metadati e gli strumenti di business intelligence

Definizione

William H. Inmonn, colui che per primo ha parlato esplicitamente di data warehouse, lo definisce come una raccolta di dati integrata, orientata al soggetto, variabile nel tempo e non volatile di supporto ai processi decisionali.

L’integrazione dei dati costituisce la principale caratteristica distintiva del DW rispetto ad altri sistemi di supporto alle decisioni.

Secondo Inmon la raccolta di dati è:

• Integrata: requisito fondamentale di un data warehouse è l’integrazione dei dati raccolti. 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;
• Orientata al soggetto: il DW è orientato a temi aziendali specifici piuttosto che alle applicazioni o alle funzioni. In un DW i dati vengono archiviati in modo da 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 organizzati in modo tale da favorire la produzione di informazioni. Si passa dalla progettazione per funzioni ad una modellazione dei dati che consenta una visione multidimensionale degli stessi;
• Variabile nel tempo: i dati archiviati all’interno di un DW coprono un orizzonte temporale molto più esteso rispetto a quelli archiviati in un sistema operativo. 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ò comporta che i dati contenuti in un DW siano aggiornati fino ad una certa data che, nella maggior parte dei casi, è antecedente a quella in cui l’utente interroga il sistema. Ciò differisce da quanto si verifica in un sistema transazionale, nel quale i dati corrispondono sempre ad una situazione aggiornata, solitamente incapace di fornire 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. Ciò comporta una semplicità di progettazione del database rispetto a quella di un’applicazione transazionale. In tale contesto non si considerano le possibili anomalie dovute agli aggiornamenti, né 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 in modo sostanziale dai normali sistemi gestionali che, al contrario, hanno il compito di automatizzare le operazioni di routine.

Si può notare che la definizione di Inmon precedentemente citata sia indifferente 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 possono andare da una logica completamente accentrata a una logica completamente distribuita.

Le componenti e l’architettura

Gli elementi costitutivi dell’architettura sono:

• I dati provenienti dai sistemi transazionali: sono quell’insieme di dati elaborati dai sistemi transazionali dell’azienda. 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 quelli 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 delle strutture dati, e dell’aggiornamento dei dizionari dei dati.
• Il data warehouse: i dati estratti dagli archivi transazionali vengono memorizzati internamente al data warehouse. Nel data warehouse l’accesso ai dati è consentito in sola lettura. Tali dati hanno una dimensione storica e sono riferiti a soggetti di business. Essi possono essere memorizzati in un archivio centrale o in un data mart. Il termine data mart identifica un data warehouse di dimensioni ridotte, specializzato per 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 consentire l’analisi della clientela. All’interno della banca possono quindi esistere più data mart, aventi finalità diverse e orientati a coprire diverse aree di business. I dati contenuti nel data warehouse possono essere aggregati e indicizzati per rispondere a specifiche necessità informative.
• I metadati: i metadatii costituiscono informazione aggiuntiva che arricchisce i dati contenuti nel data warehouse. Spesso essi vengono chiamati in gergo “data about data” indicando la provenienza, l’utilizzo, il valore o la funzione del dato. A tale proposito vengono costituiti dei veri e propri information catalog. Questi ultimi sono i file che contengono i metadati. Il catalog 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, il quale dispone di un insieme di strumenti per effettuare elaborazioni e 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 è organizzato su quattro livelli architetturali:

1. trasformazione dei dati: è il livello che si occupa di acquisire i dati e validarli;
2. preparazione e “stoccaggio” dati: è il livello che fornisce i dati agli utenti e alle applicazioni analitiche;
3. interpretazione e analisi dati: è il livello, ad elevato valore aggiunto, che presiede alla trasformazione dei dati in informazioni aventi valore strategico;
4. presentazione dati: è il livello, a basso valore aggiunto, che presiede alla presentazione finale agli utenti delle informazioni e quindi delle risposte cercate.

Nel suo complesso il data warehouse è un sistema periferico, cioè non risiede fisicamente sul sistema informativo centrale. Il motivo di ciò va ricercato nel tipo di attività svolto: una piattaforma di tipo transazionale è maggiormente orientata all’esecuzione costante di operazioni di aggiornamento, per cui l’ottimizzazione viene fatta soprattutto sull‘I/O; una piattaforma di supporto alle decisioni invece deve essere ottimizzata per effettuare un numero limitato di query particolarmente complesse. Un’eccezione a tale regola può essere rappresentata da soluzioni di tipo mainframe, ove la possibilità di definire macchine virtuali all’interno della stessa macchina fisica consente la coesistenza sullo stesso server fisico delle applicazioni transazionali e delle applicazioni di decision support.

Vediamo ora nei dettagli come è fatta un’architettura per il data warehouse.

Data transformation layer.

L’architettura parte dallo strato denominato data transformation, cioè dall’insieme di applicazioni che svolgono l’attività di estrazione, trasformazione e caricamento dei dati dai sistemi transazionali che alimentano il data warehouse.

Nella maggior parte dei casi la fase di estrazione dei dati dai sistemi alimentanti viene implementata utilizzando i linguaggi proprietari delle piattaforme alimentanti. Si tratta per lo più di interrogazioni 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 maggiore 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 incompleti o comunque inadatti a prendere decisioni, in quanto non sono coerenti con le analisi da effettuare.

In alcuni casi le operazioni di trasformazione possono causare un reject (rifiuto), il quale segnala l’impossibilità di accettare parte del flusso alimentante a causa di ‘impurità’ nei dati di origine.

Le possibili cause di rifiuto sono varie:

• Codifiche incoerenti. Lo stesso oggetto è codificato in modo diverso a seconda del sistema alimentante. In fase di trasformazione ogni flusso alimentante andrà ricodificato seguendo la codifica convenzionale definita per il data warehouse;
• Unità di misura/formati incoerenti. È 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;
• Denominazioni incoerenti. È il caso in cui, a seconda della fonte, 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 incompleti 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 a priori.

Data preparation and storage layer

Una volta che i dati hanno superato il transformation layer, essi vengono ‘stoccati’ in questo livello architetturale per consentire:

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

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

Data interpretation and analysis layer

A questo livello si trovano oggetti tra loro molto diversi per funzione e tecnologia. Le 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 precedente. Qui si deve fare un’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 a quelle di un data warehouse, l’impossibilità di arrivare a dati di dettaglio superiore a quello delle sintesi disponibili 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 controindicazioni in quanto le risorse hardware necessarie per supportare un elevato numero di utenti che eseguono interrogazioni complesse 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, contenente 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 tematici (cioè contenenti tutte le informazioni riguardo un certo soggetto) oppure per gruppi specifici di utenti.

Questa strategia architetturale fa del data warehouse un vero processo di information delivery, ove la richiesta di nuove sintesi decisionali comporta non già la costruzione di altri flussi di alimentazione ma piuttosto la creazione di altri data mart. Lo sviluppo di nuovi data mart è una normale attività 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 sugli aggregati costruiti dal sistema. Tipicamente le funzionalità di analisi di un data warehouse si appoggiano su una tecnologia di tipo OLAP (On-Line Analytical Processing).

L’OLAP è essenzialmente un approccio 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;
• (di conseguenza) 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’.

Data presentation layer.

Questo livello contiene 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 per costruire query, strumenti di navigazione OLAP (OLAP viewer) e, in un’accezione ampia, anche i Web browser, che stanno diventando l’interfaccia comune per diverse applicazioni;
• strumenti di Office Automation:
  spesso i software vendor presenti con le loro soluzioni nel layer architetturale precedente indicano come soluzioni di front end gli strumenti ordinari del lavoro quotidiano, come word processor e fogli elettronici. Questa è una soluzione rassicurante per gli utenti che si avvicinano per la prima volta al data warehouse, in quanto non sono costretti ad imparare nuovi strumenti complessi. Il problema consiste nel fatto che tale soluzione è adeguata per quanto riguarda produttività ed efficienza, lo è meno per l’utilizzo intensivo del data warehouse, dal momento che questi strumenti, in tale caso, hanno limiti architetturali e funzionali significativi;
• strumenti di grafica e publishing:
  anche qui prevale una considerazione di efficienza e produttività: gli strumenti di Business Intelligence sono capaci di generare grafici e tabelle per i propri utenti, la soluzione in oggetto serve sostanzialmente ad evitare inefficienti doppi passaggi.

I dati

Un data warehouse comprende diversi livelli di dati:

• Dati attuali di dettaglio:
  sono i dati al massimo livello di dettaglio che si ritiene possa essere utile 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 accessibili meno comodamente.
• 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.

La progettazione di un Data warehouse

Come accennato precedentemente, il data warehouse è un sistema OLAP (On-Line Analytical Processing) che differisce dai sistemi OLTP (On Line Transaction Processing), sebbene i dati provengano da questi ultimi. I sistemi OLAP sono sistemi orientati al soggetto, sono integrati, storici e permanenti. Non comprendono dati analitici e statici come i sistemi OLTP, inoltre i dati OLAP non sono adatti ad uso corrente, ma vengono usati per analisi.

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

La fonte dei dati per un data warehouse è un sistema operativo, anche se la prima non è una pura copia del secondo: i dati in un sistema decisionale sono filtrati, classificati cronologicamente, sono aggiunti dei valori riassuntivi e sono cambiati prima di essere caricati nel data warehouse. In particolare, per i microdati, i dati sono riassunti a due livelli di aggregazione distinti: 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 minore 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 poi usato 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 data warehouse semplice, ampliabile nel tempo per soddisfare utenti con richieste crescenti e diventare un ambiente che contenga sistemi di data warehouse interconnessi. In un ambiente di data warehouse semplificato bisogna organizzare tre aree:

• l’estrazione e la trasformazione dei dati dai sistemi operativi;
• la base di dati del data warehouse;
• gli strumenti per interpretare i dati.

È necessario monitorare la rete che consente l’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 individualmente e complessivamente. 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 la dipendenza dal data warehouse. Questo livello aggiuntivo 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 continua ad evolvere tramite la creazione di data warehouse multipli. In alcuni di questi casi, le complessità di amministrazione diventano opprimenti.

Nell’approccio con 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;
• gli strumenti per interpretare i dati.

Poiché questo ambiente non contiene grandi volumi di data warehouse esso è 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 ad un data mart e, una volta che vengono aggiunti altri data mart, la situazione diventa più complicata. Il compito di portare numerosi 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 un’architettura centralizzata di amministrazione dello sviluppo del sistema.

Il data warehouse potrebbe arrivare a contenere volumi molto grandi di dati, non sempre interessanti per tutti gli utenti. Lavorare con questi volumi di dati non correlati può essere inefficiente e consumare molte risorse di calcolo. In questa situazione è possibile suddividere il data warehouse in aree di interesse specializzate.

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 di gestione centrale. Anche dove la responsabilità dell’amministrazione dei tool di sfruttamento dei dati è a livello locale, serve un collegamento tra il sistema di amministrazione centrale e gli ambienti distribuiti. Questo collegamento è necessario per assicurare che i cambiamenti dei tool degli ambienti distribuiti possano essere identificati anche centralmente.

Altri aspetti progettuali

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

• l’esistenza di un’adeguata organizzazione di supporto al processo, con ruoli e responsabilità definiti. In modo analogo alle 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 è cruciale per il data warehouse, date le problematiche di system integration che esso comporta. La gestione costante della variabile tecnologica è uno dei fattori di successo del data warehouse, a partire dalle scelte iniziali per arrivare alla gestione operativa degli aggiornamenti e degli ampliamenti della piattaforma.

Applicazioni del data warehouse

Il data warehouse è un sistema informativo dove i dati sono organizzati e strutturati per un facile accesso da parte dell’utente e per fornire supporto ai processi decisionali. I seguenti sistemi sono abilitati dal data warehouse:

• DSS (Decisional Support System)
• EIS (Executive/Enterprise Information System).

Il primo è utilizzato per risolvere problemi specifici, mentre il secondo consente una continua circolazione dei dati non dipendente da problemi specifici.

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’interno 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’ verso 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 del DW in prospettiva: di utilizzo del DW come piattaforma di decision support.

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 pensano di realizzarlo;
• la seconda fase, chiamata opportunità (basso utilizzo del DW esistente, alto utilizzo prospettico del DW), è la fase in cui 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.
• 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 intrapreso con successo 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 le aziende in cui il data warehouse è maturo, la metodologia di implementazione consolidata e 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) ben noti nella loro struttura.

Risk e Asset Management

Un’altra area applicativa interessante è identificabile nelle attività di Risk e Asset Management (vedi Gestione del rischio), 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 da fonti esterne all’azienda. In questo caso il data warehouse va dotato di strumenti di analisi avanzati e basati su algoritmi statistici di analisi e simulazione.

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

Supporto alle vendite

Non necessariamente il data warehouse è appropriato per affrontare e risolvere questo tipo di esigenza, a meno che esista la necessità di immagazzinare e gestire rilevanti masse di dati. In molti casi il database di marketing è banalmente un’anagrafica clienti arricchita di alcune informazioni “non amministrative”, in casi più avanzati diventa uno strumento fondamentale di supporto al ‘’marketing one-to-one’’. In questo caso il database di marketing costituisce una base di informazioni fondamentale per indirizzare correttamente campagne e iniziative promozionali o per attivare servizi avanzati di ‘’customer care’’. In questo caso, data la rilevante massa di dati da gestire, il data warehouse può diventare la piattaforma tecnologica ideale.

Nel settore bancario il marketing one-to-one è ancora allo stadio embrionale, almeno dal punto di vista del marketing centrale, e questo è dovuto al fatto che molto spesso il marketing one-to-one viene fatto dalla filiale, l’unica struttura aziendale in grado storicamente di instaurare un rapporto fiduciario con il cliente finale, che identifica l’azienda nello ‘sportello’ e nel suo ‘impiegato’.

Sistema informativo di marketing

Si tratta di utilizzare il data warehouse come una sorta di ‘backbone’ per supportare una serie di applicazioni integrate orientate alle analisi commerciali e di marketing. Gli aspetti fondamentali che caratterizzano questo tipo di architettura sono essenzialmente due:

• la possibilità di integrare basi di dati transazionali diverse in un’unica base dati analitica e produrre quindi ‘viste’ integrate della clientela, del mercato e dei prodotti;
• la possibilità di effettuare analisi con strumenti e logiche diverse su una base unica.

L’idea di fondo del sistema informativo di marketing è quella di sviluppare un percorso evolutivo che parta dal reporting di base per arrivare ad analisi avanzate, passando attraverso sistemi di analisi del portafoglio prodotti e clienti e procedure di budgeting e simulazione.

 

Supporto al Call Center

Anche in questo caso il data warehouse è un’opzione tecnologica, non l’unica praticabile e non necessariamente la più economica. Utilizzare un’architettura di data warehousing a supporto di un’attività di Call Center ha sicuramente senso nel caso in cui le richieste non sono necessariamente di tipo strutturato e quindi risolvibili con il classico “inquiry (interrogazione) da terminale”. È evidente però che la tipologia di utente per questo tipo di sistema è più evoluto del normale operatore di Call Center.

Knowledge Base

Anche in questo caso valgono le considerazioni fatte per il Database di Marketing: non necessariamente il data warehouse è la tecnologia più idonea per questo tipo di esigenza, ma lo diventa nel momento in cui la conoscenza in oggetto è costituita prevalentemente da informazioni strutturate e preferibilmente numeriche. In questo caso, anche dal punto di vista tecnologico, un database relazionale è sicuramente la soluzione più idonea, efficiente ed economica. Non è così se invece le informazioni sono di tipo destrutturato, in questo caso la soluzione più adatta è una piattaforma di groupware. Si deve però fare attenzione a non confondersi con i cosiddetti database multimediali: il fatto che un database relazionale abbia funzionalità multimediali non significa che sia un data warehouse. Infatti, ciò che distingue un data warehouse da ciò che non lo è, non è la tecnologia utilizzata, ma l’architettura applicativa e il disegno della base di dati.

Engineering di prodotto

Il data warehouse può essere una piattaforma decisionale per l’analisi e la concettualizzazione di nuovi prodotti da offrire alla clientela e/o per aggredire nuovi mercati o segmenti di mercato. Tale funzionalità è ovviamente supportata se il data warehouse è dotato non solo di strumenti di analisi dei risultati, ma anche di ambienti di simulazione che consentono la costruzione ed il testing ‘in laboratorio’ di nuove soluzioni da proporre ai clienti. In tali ambienti è possibile individuare alcuni importanti aspetti come la marginalità, il punto di pareggio economico, il segmento di clientela interessato, i meccanismi di cannibalizzazione, l’elasticità della domanda e l’impatto sull’equilibrio finanziario aziendale.

e-business

La diffusione del canale digitale nel settore finanziario pone una serie di problemi e di opportunità nuove. In primo luogo questo tipo di canale implica una velocità di cambiamento e quindi di reazione nettamente superiore. Il data warehouse può essere lo strumento analitico che consente di cogliere dinamiche all’interno di rilevanti masse di transazioni on-line. In secondo luogo l’informazione può essere uno strumento di supporto o l’oggetto stesso della transazione e in questo caso il data warehouse può essere la piattaforma utilizzata per coprire tale ambito applicativo.

Il data warehouse può essere quindi di supporto a sistemi di trading on-line  sia dal punto di vista dell’analisi che dal punto di vista dell’architettura dati