Dal 30 ottobre al 2 novembre si terrà a Londra la consueta Data Management and Information Quality Conference. La new entry dell’anno è una track dedicata ai temi di Data Warehousing e Business Intelligence. Scorrendo le presentazioni degli interventi di maggior rilievo in merito alla gestione dei metadati mi sono reso conto che il focus è tutto incentrato su come costruire, alimentare e gestire un un repository centralizzato dei metadati in cui vengano integrati i metadati prodotti durante il ciclo di sviluppo del sistema. Tale integrazione viene condotta tipicamente “a posteriori” ossia, nel migliore dei casi, al termine di ciascuna fase di un’iterazione progettuale.
Questo è il medesimo approccio che ho seguito nel disegnare la metodologia su cui si basa il sistema di gestione dei metadati realizzato nell’ambito del Data Warehouse della RGS. Tale sistema è costituito da prodotti commerciali e componenti software scritte ad-hoc al fine di ricostruire una “visione integrata, omogenea e strutturata” del sistema di data warehousing nel suo complesso. Tale esperienza è riassunta in un documento (in versione DRAFT) che ho preparato a valle del processo di certificazione del sistema di data warehousing condotto da Bill Inmon anche in seguito all’interesse e agli apprezzamenti che la componente di gestione dei metadati ha suscitato in tale sede.
Il mercato dei prodotti commerciali in ambito data warehouse è pressoché allineato nel seguire tale approccio generale che prevede la generazione dei metadati relativi alle diverse componenti in maniera pressoché indipendente e scorrelata. In particolare i diversi tool (case di modellazione dati, ETL, front-end, ecc.) utilizzati per la produzione delle diverse componenti del sistema (base dati, processi di alimentazione, reposrtistica, ecc.) hanno un proprio repository di metadati che descrive la componente prodotta; un sistema di gestione dei metadati interroga ciascun repository (attraverso delle API, tramite una sua rappresentazione in XML, ecc.) per estrarre una versione dei metadati da integrare nel proprio repository.
Un repository integrato dei metadati offre una serie di servizi ritenuti fondamentali sia per migliorare la qualità del servizio offerto agli utenti del sistema,sia per suportare la gestione del sistema stesso:
- offrire all’utente indicazioni sul significato delle informazioni numeriche fornite attraverso la reposrtistica o gli ambienti di analisi multi-dimensionale (OLAP);
- aiutare gli utenti a trovare le informazioni di cui hanno bisogno con sistemi di ricerca guidata;
- suportare le attività di manutenzione attraverso le funzioni di cross-impact-analysis;
- monitorare l’esito dei caricamenti e la crescita del sistema;
- ecc.
Spesso però la qualità complessiva del sistema risulta scarsamente influenzata da una gestione dei metadati “a posteriori”; infatti l’integrazione “a posteriori” dei metadati può al limite evidenziare incongruenze fra il disegno delle diverse componenti, fra l’analisi e la progettazione delle stesse o fra la progettazione e lo sviluppo, ma non intervenendo attivamente nel processo produttivo, non migliora la qualità del prodotto.
Innovare il processo produttivo vuol dire innovare tanto le metodologie quanto gli strumenti di lavoro. Dal punto di vista metodologico il processo produttivo dovrebbe essere basato sul continuo riuso dei metadati: ogni attività dovrebbe arricchire i metadati del sistema integrando quanto già realizzato con nuove informazioni. Ad esempio la modellazione logica di un Data Mart dovrebbe partire dalla definizione del suo modello dimensionale arricchendolo con “i dettagli” utili alla sua implementazione in tecnologia ROLAP o MOLAP. Analogamente i metadati del medesimo modello dimensionale e della sua implementazione logico/fisica dovrebbero essere utilizzati nella definizione dello strato semantico attraverso cui gli utenti si interfacceranno e condurranno le proprie analisi OLAP.
Tale integrazione “a priori” dei metadati garantisce nel corso del processo produttivo una maggiore coerenza fra le componenti software realizzate. Inoltre, poiché il processo produttivo parte proprio dalla raccolta e formalizzazione dei requisiti e dall’analisi del patrimonio informativo e procede con l’integrazione dei metadati relativi agli aspetti progettuali e realizzativi del sistema, le probabilità che i requisiti utente siano sodisfatti aumentano. Si accorciano inoltre i ritardi nel rilevare problemi di incoerenza fra analisi e progettazione, progettazione e realizzazione o soddisfacibilità di requisiti.
Dal punto di vista degli stumenti software per la realizzazione di data warehouse, ad oggi non mi risulta che esista alcun tool in grado di seguire tutto il processo di analisi, progettazione e realizzazione di un sistema di Data Warehousing in modo integrato. Inoltre non sono molti i tool di front-end e back-end i cui repository di metadati siano aperti anche “in scrittura”, come avviene ad esempio per i cataloghi dei DBMS che vengono manipolati con linguaggi ormai standardizzati (DDL – Data Definition Language). Tuttavia il processo di integrazione dei diversi strumenti in suite tecnologiche può essere una spinta verso la realizzazione di un processo di questo tipo, purché l’integrazione non rimanga puramente commericale e ci sia una reale attenzione a coprire l’intero ciclo produttivo (mentre spesso fasi cruciali come l’analisi e la formalizzazione dei requisiti sono sottovalutate).
Molto interessante questo post!!!. Complimenti. Ho visto con interesse che hai lavorato/lavori presso la RGS….Un mio caro amico che lavora in Finsiel mi ha detto che presso la RGS hanno in programma di realizzare un Case per supportare l’analisi e forse la progettazione (se ho ben capito) di un intero data warehouse. Certo un progetto ambizioso anche se affascinante…..per caso ne sai qualcosa? se si perchè non ne scrivi sul blog?
Attualmente, nell’ambito della realizzazione del sistema di data warehousing della RGS, viene utilizzato un tool di tipo CASE per la modellazione dimensionale secondo il formalismo DFM (Dimensional Fact Model).
Il tool è stato realizzato da Datamat per conto di Consip ed in effetti me ne sono occupato personalmente con il ruolo di project leader quando ero in Datamat. La prima release del prodotto, cui ho partecipato attivamente, consente di definire graficamente tutti i costrutti fondamentali di un modello dimensionale (gerarchie, attributi dimensionali, fatti, misure, ecc.) andando a popolare un metamodello di riferimento. I metadati possono poi essere estratti in XML e utilizzati per generare automaticamente documentazione e script di creazione della base dati (secondo il classico modello a star-schema).
La strategia a lungo termine per il prodotto era quella di realizzare un tool che avesse caratteristiche più marcate di “forward-engineering” e di integrazione con altri fonti di metadati.
La seconda release, seguita da Antonino Battaglia (anche lui ex Datamat), consente di mettere in relazione il modello dimensionale disegato con un modello concettuale (definito secondo il formalismo E/R) in modo da definire le regole di business che consentono di derivare dal patrimonio informativo descritto da quest’ultimo le informazioni definite dal modello dimensionale stesso a supporto delle analisi di business requisito del sistema.
Dove e come si può reperire questo tool di modellazione?
Il tool è stato realizzato per Consip ed è attualmente utilizzato nell’ambto del progetto Data Warehouse della RGS. Non è disponibile in commercio e, per il momento (mai disperare…), non conosco valide alternative.
Non escludo che possa essere utilizzato anche in altri progetti riconducibili alla Ragioneria Generale dello Stato e/o al Ministero dell’Economia e delle Finanze che ne hanno finanziato la realizzazione.