Approccio metodologico al data warehouse

In ogni disciplina esiste un guru.
Nel frenetico mondo del data warehouse ne esistono almeno due: Ralph Kimball e Bill Inmon che proiettano le loro fosche ombre sulle scelte di ogni Data warehouse architect.

L’approccio metodologico relativo alla realizzazione di soluzioni di data warehouse dipende direttamente dall’organizzazione aziendale, dalla tipologia di utenti dall’architettura tecnica del sistema e dalle criticità evidenziate.

Nel corso del tempo sono stati suggeriti diversi approcci per la realizzazione dei progetti, poi rivisitati grazie al bagaglio di esperienze maturate da varie Organizzazioni.

"L’elevata mortalità delle prime implementazioni di soluzioni di data warehouse ha accelerato l’evoluzione di metodologie più focalizzate sul business, si parla pertanto di approccio top-down, approccio bottom-up, approccio incrementale, a cui corrispondono diverse topologie di data warehouse (Enterprise data warehouse, datamart, Multi-tier Warehouse)" scriveva qualcuno solo un paio di anni fa, ma si sa, anche nel campo della business intelligence due anni sono un'enormità, e oggi (metà del 2002) accanto ai classici approcci metodologici si inseriscono vere e proprie "filosofie di approccio metodologico" che aiutano a rendere ancora più confuso il mondo del data warehouse...


Approccio top down

L’approccio top-down è quello che prevede una implementazione estensiva del sistema, il cui disegno originale tiene in considerazione tutte le principali aree di interesse aziendale.

Si parla in questo caso di Enterprise data warehouse, che può essere successivamente suddiviso in un insieme di datamart, per motivi tecnici ed organizzativi, pur mantenendo rigorosamente accorpata la visione totalitaria d’insieme della soluzione.

I datamart dipendenti costituiscono un subset di dati aziendali altamente specializzati per aree di interesse o dipartimenti aziendali.

Il punto debole di questo approccio teoricamente rigoroso è nella difficoltà di gestione del progetto onnicomprensivo, che rischia di paralizzare l’attività e di fornire risultati troppo in avanti nel tempo, questo tipo di approccio (caldamente suggerito da Bill Inmon) rappresenta l'approccio migliore per la costituzione del data warehouse, va valutata la sua applicabilità relativamente allo sforzo che il cliente prevede di sostenere, se il sistema di data warehouse rappresenta (come dovrebbe) un progetto strategico per il cliente il budget non può che essere correttamente proporzionato.


Approccio bottom-up

L’approccio bottom-up prevede una implementazione non coordinata nella quale ogni datamart viene realizzato per rispondere ad uno specifico fabbisogno informativo di una utenza dipartimentale.

In questo caso l’Enterprise data warehouse è il risultato dell’insieme dei singoli datamart indipendenti, che si alimentano direttamente dai sistemi operazionali.

Il vantaggio di tale approccio pragmatico è unicamente conseguire risultati utili per l’utente in un arco temporale limitato con costi diretti relativamente contenuti.

Tale approccio può essere valutato solo per progetti con budget di sviluppo molto bassi e, soprattutto, il cliente deve essere ben informato sui rischi del costo di manutenzione di un data warehouse di tale tipo.
  

Approccio “incrementale” : Enterprise datamart Architecture (EDMA)

L’approccio “incrementale” combina i vantaggi dei due approcci sopra descritti (e vede in Ralph Kimball il primo sostenitore).
Alla base di questo approccio, definito in letteratura anche approccio “federato”, infatti, è la creazione di un modello informativo comune.
Dal modello informativo comune vengono sviluppati in maniera coerente modelli dati dell’Enterprise data warehouse e/o dei datamart; questi ultimi possono essere sia dipendenti che indipendenti.
L’implementazione prevede di mettere a fattor comune tra diversi progetti di datamart i processi di acquisizione di dati dai sistemi transazionali.
E' tuttavia fondamentale segnalare che è comunque opportuno consigliare l'eliminazione datamart indipendenti, non appena sviluppati quelli derivanti direttamente dall'ambiente integrato del data warehouse; è importante verificare tempi e costi dello sviluppo temporaneo di datamart indipendenti.
Il risultato dei processi di acquisizione viene centralizzato su aree di appoggio comuni (cosiddette aree di staging) su cui vengono svolti i successivi processi di trasformazione.
Il modello informativo comune e la fruizione delle aree di staging minimizza i problemi di integrazione tra datamart, l’utilizzo di un’architettura data warehouse Bus consente l’individuazione e la condivisione di dimensioni e fatti razionalizzate rispetto ai processi aziendali.
Il concetto di Warehouse Bus (partorito da Ralph Kimball) è l'uovo di Colombo che in molti casi consente un approccio incrementale paragonabile nei risultati a quello Top Down di Inmon.
Alla definizione di dettaglio nel data warehouse di un particolare processo basato sul concetto di dimensioni e fatti conformi è possibile rilasciare velocemente il datamart aggregato, certi che le successive attività a livello di data warehouse non potranno creare isole informative.

Privacy Policy