BI Modeler: un (in)utile CASE software per il disegno di Dimensional Fact Model

In questi giorni ho raccolto diversi feedback sul tool Business Intelligence Modeler (ora liberamente scaricabile dal sito www.bimodeler.com) rilasciato qualche giorno fa in versione alpha: alcuni sono stati fin troppo lusinghieri, altri rigorosamente più critici (e per questo degni di maggior interesse).

In particolare da alcune mail sono emersi diversi spunti di riflessione che ho riorganizzato in questo post sotto forma di Domanda e Risposta: non si tratta di una FAQ ma piuttosto di uno schietto scambio di opinioni sul tema.

D: Ho visto il video e ho dato un’occhiata ai due articoli sul DFM sul tuo blog, ma mi rimangono molti dubbi sull’utilità (e anche sull’essenza) del DFM e dello strumento da te sviluppato. Ho sperimentato in passato strumenti simili (di Rizzi-Golfarelli), sono abbastanza scettico sul loto utilizzo.

R: Io distinguerei preliminarmente fra la metodologia proposta da Golfarelli e Rizzi per la definizione di modelli dimensionali a partire da modelli ER e il formalismo DFM come linguaggio di modellazione. Quello di cui mi interessa maggiormente discutere è l’efficacia del formalismo DFM: il tool Business Intelligence Modeler non segue la metodologia di Golfarelli e Rizzi, ma ne utilizza il formalismo DFM.

D: Una ricerca per “dimensional fact model” su Google ha trovato quasi unicamente pagine che si riferiscono a Rizzi-Golfarelli e a te. Mi ricordavo che me ne avevano parlato R&G […] nel lontano 2002, ma reincontrandola adesso pensavo che fosse una metodologia usata a livello mondiale, anche se a me poco nota.

R: Non ho dati oggettivi per valutare il livello di adozione oltre confine del formalismo DFM (che comunque concordo non sia diventato lo standard de facto per la definizione di modeli dimensionali – ma non sono sicuro esista un standard per questo); tuttavia la sua diffusione all’estero potrà essere aiutata in futuro dall’edizione in lingua inglese del testo di Golfarelli&Rizzi (pubblicata da McGraw-Hill nel 2009).

Il formalismo è semplice ed intuitivo e graficamente efficace: caratteristiche analoghe a quelle possedute dal formalismo Entity Relationship e che ne hanno sancito l’affermazione cone standard nel disegno di basi dati relazionali.

Per quanto riguarda la realtà italiana, oltre ad una buona diffusione negli atenei (non solo a Bologna), i DFM sono stati utilizzati in diversi progetti reali di varie dimensioni e complessità. Io personalmente ho avuto modo di utilizzarlo e di vederlo utilizzare in molteplici progetti negli ultimi anni e sono in contatto con altri professionisti che lo hanno utilizzato a loro volta in diverse esperienze.

D: Guardando il video non riesco a capire quale sia il valore aggiunto del DFM e dell’oggetto BI Modeler, rispetto a seguire il metodo diciamo “classico”. Io ho progettato molti data warehouse utilizzando entrambe le architetture prevalenti (Inmon e Kimball) ma non ho mai sentito il bisogno di uno strumento che mi aiutasse a passare da una rappresentazione a livello concettuale al modello logico dei dati, e guardando il tuo video non ho cambiato idea. Non vedo francamente nessun vantaggio. Preferisco iniziare subito a disegnare lo schema logico con uno strumento di modellazione (tipo Erwin che è il top, ma esistono anche dei freeware che sono molto validi)

R: La definizione di un modello logico con ERwin (o similaria) utilizza un formalismo analogo ad un ER (evitando però l’uso delle gerarchie is-a proprie di un modello concettuale). Tale linguaggio non è adatto alla definizione di modelli dimensionali in quanto non ha l’espresività necessaria per rappresentarli in molte delle loro caratteristiche. Ad esempio in un modello logico non è possibile rappresentare i livelli di una gerarchia e le relative interdipndenze funzionali senza compiere una scelta preventiva fra star-schema e snow-flake. In particolare, scegliendo un modello di tipo star-schema (il più usato) che è caratterizzato da tabelle dimensionali denormalizzate, non è possibile rappresentare le dipendenze funzionali esistenti fra gli attributi dei diversi livelli di una gerarchia. Inoltre non esiste una distinzione sintattica fra tabelle dei fatti e tabelle delle dimensioni o ancora non è prevista l’indicazione degli operatori di aggregazione che è possibile o meno utilizzare nelle operazioni di roll-up per ciascuna misura.

Tutte queste informazioni (questi metadati) fanno parte integrante della definizione di un modello dimensionale ed è importante che vengano esplicitate formalmente nelle fasi alte del ciclo di sviluppo del progetto o della singola iterazione.

Io ho lavorato negli anni con diverse mtodologie (fra cui Iteration di Inmon) e diverse architetture di riferimento (datamart federati, EDW, ecc.) e, specie in progetti di elevata complessità e che coinvolgevano ampi gruppi di lavoro, ho sempre trovato utile l’uso dei DFM per definire formalmente questi aspetti che derivano direttamente dai requisiti informativi espressi dagli utenti. Tali requisiti vanno poi cofrontati con il patrimonio informativo a disposizione (rappresentato preferibilmente con un modello concettuale definito con il formalismo ER) al fine di verificarne la soddisfacibilità.

Da un modelo dimensionale così definito è facile derivare un modelo logico di tipo relazionale che renda possibili le analisi richieste dall’utente. In questa fase successiva di disegno della base dati vengono considerati altri requisiti funzionali e non funzionali come l’inserimento di campi di audit per le procedure di alimentaizone o la gestione di dimensioni storicizzate (slowly changing dimension), ecc. Separando le due fasi è più semplice garantire la soddisfacibilità di tuti i requisiti (divide et impera) favorendo una riduzione dei rischi di progetto (vedi post).

D: Esistono già degli strumenti simili nei fatti a quello da te realizzato ma molto più maturi, come ad esempio wherescape red che ho provato in maniera approfondita e che trovo un ottimo strumento, e anche altri (BI ready, Data Academy…). Credo comunque che questi strumenti, anche quelli maturi come wherescape, dimostrino i loro limiti nella realizzazione di data warehouse complessi, dove sono presenti strutture ben più complicate dello star schema puro.

R: Non conosco (lo ametto) i tool da te citati, cercherò di colmare tale lacuna. Tuttavia l’intento era quello di realizzare un software che contemplasse specificamente il disegno di Dimensional Fact Model inserendo tale funzionalità all’interno di un processo di progettazione di sistemi di Data Warehousing e Business Intelligence in grado di rappresentare tutte le scelte progettuali.

Concordo sul fatto che il modello di analisi del “cubo delle vendite” con relativi star-schema è spesso molto lontano dalla complessità dei progetti reali. Proprio per questo il BI Modeler intende essere uno strumento di supporto alla progettazione indipendente da una specifica metodologia o modello architetturale. A tal proposito il modello relazionale generato “semi-automaticamente” a partire da un modelo dimenisonale è modificabile ed integrabile in ogni sua parte: in effetti sarebbe possibile disegnare un modelo relazionale from scratch senza definire preventivamente un modello dimenisonale.

D: Non vedo (almeno nel video) il passo successivo alla generazione delle ddl, che dovrebbe essere la generazione delle procedure etl, supportate da una robusta struttura di metadati, e non trovo nemmeno quello successivo ancora (gestione dell’operatività del dw, lancio dei caricamenti, trattamento degli errori…). Notare che entrambi questi passi sono gestiti da wherescape

R: Come è evidente, il tool è ancora immaturo (anche senza confrontarlo con prodotti comerciali e/o con una storia di anni alle spalle), ma nella sua concezione ha proprio la mira di integrare tutte le scelte progettuali che coinvolgono la definizione di un progetto di DW&BI nelle sue diverse componenti sia lato back-end che lato front-end.

L’idea alla base del progetto (abbozzata in un post di qualche anno fa) è quella di realizzare un tool che sia in grado di definire progressivamente ed integrare “a priori” i metadati di progetto che generalmente sono sparpagliati in diversi documenti word (analisi, progettazione, ecc.) favorendone l’integrazione e la propagazione verso i tool di svilupo e le componenti tecnologiche che implementano il sistema.

A tale scopo il BI Modeler è stato progettato in modo modulare per favorire la sua potenziale evoluzione nel tempo (ad avercelo), così da integrare altri (meta)modelli per la progettazione di altre componenti come le strategie e le procedure di alimentaizone, lo strato semantico, ecc.

Una delle componenti fondamentali per il ruolo centrale che riveste in un progetto di DW&BI è proprio il modello logico/fisico della base dati. Per questo le prime funzionalità implementate sono state quelle relative alla sua definizione.

D: In diversi progetti software viene utilizzato UML come linguaggio di modellazione per cui esistono diversi programmi commerciali e open source. Per il disegno di modelli dati mediante il formalismo DFM esistono altri tool (magari open source)? Rendere BI Modeler un progetto open source non consentirebbe di velocizzarne lo sviluppo?

R: Che io sappia esistono al momento solo due altri CASE basati sul formalismo DFM:

  • WAND – fornito in allegato al testo (prima e seconda edizione) di Golfarelli-Rizzi – non consente il disegno diretto di schemi di fatto ma implementa la metodologia degli autori che prevede la trasformazione di un modello ER in DFM (potatura degli alberi di attribti, ecc.).
  • DFM Case – realizzato da Consip per il MEF ed attualmente utilizzato in ambito PA – consente il disegno di modelli DFM e una loro mappatura rispetto ad un modello ER di riferimento.

WAND non credo sia più manutenuto/distribuito da anni. Per quanto riguarda il DFM Case, fintanto che ne ho seguito la realizzazione, non era prevista alcuna commercializzaizone/distribuzione da parte di Consip né del MEF e non credo ci siano state evoluzioni in tal senso.

Il formalismo ha destato un certo interesse e mi risulta che ci siano alcune realtà industriali italiane che stanno (o stavano) lavorando sulla realizzazione di CASE che supportino i DFM: c’è da sperare che almeno uno di questi progetti possa sfociare presto in un prodotto commerciale.

In assenza di strumenti disponibili sul mercato da poter utilizzare internamente ai gruppi di lavoro nei progetti di DW&BI che seguo, qualche anno fa ho cominciato a teorizzare, disegnare e realizzare il BI Modeler.

Al momento BI Modeler non è un progetto open source. Io non ho (purtroppo) un’esperienza tale nella partecipazione a progetti open source da poterne coordinare uno, anche se ho più volte preso in considerazione l’ipotesi proprio per velocizzare ed elevare la qualità del prodotto.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *