I metadati nel Data Warehouse: un prototipo per SpagoBI di modellazione OLAP e rappresentazione CWM

Transcript

1 Università degli Studi di Padova Facoltà di scienze matematiche, fisiche e naturali Tesi di Laurea Specialistica in Informatica I metadati nel Data Warehouse: un prototipo per SpagoBI di modellazione OLAP e rappresentazione CWM Relatore: Ch.ma Prof.ssa Susi Dulli Correlatore: Ch.ma Dott.ssa Daniela Tura Laureando: Giulio Gavardi Anno accademico 2006/2007

2 2

3 Indice 1 Introduzione I metadati SpagoBI e il prototipo Struttura della tesi I Metadati I metadati nell azienda Metadati tecnici e metadati di business La gestione dei metadati Managed Metadata Environment I metadati nel Data Warehouse Il problema dell integrazione L approccio model-driven Common Warehouse Metamodel Breve storia del CWM Tecnologie fondanti UML MOF XML XMI Struttura del meta-modello L approccio model-driven di CWM L integrazione con CWM i

4 ii INDICE 4 Open Source e SpagoBI L open source Storia dell Open Source Definizione di Open Source SpagoBI Architettura di SpagoBI Il meta-modello di SpagoBI Implementazione OnLine Analytical Processing (OLAP) Funzionalità del prototipo Strumenti di sviluppo Esecuzione dell applicazione Estrazione dei metadati relazionali Creazione dei meta-oggetti Il modello relazionale Il modello OLAP Mappatura dei modelli logici al modello fisico Scrittura del file XML Conclusioni Prototipo e sviluppi futuri Il futuro dei metadati A JMI/CWM 133 Bibliografia 139

5 Elenco delle figure 2.1 Piramide della conoscenza Metadati tecnici e di business Managed Metadata Environment Flusso dei dati Esempio di metadati attivi Information Supply Chain Point to point architecture Hub and Spoke architecture Esempio di meta-modello Approccio Model-Driven Meta-oggetti a livello M Meta-modello di esempio e interfacce Modello UML e rappresentazione in file XML Il meta-modello CWM Package Core Riuso di associazioni Use case relazionale Use case file strutturato Equivalenza tra classifier Estensione mediante ereditarietà Estensione mediante TaggedValue e Stereotype La specifica CWM iii

6 iv ELENCO DELLE FIGURE 3.13 Scambio dei metadati CWM Interoperabilità Architettura di SpagoBI Approccio MVC per SpagoBI Architettura di SpagoBI nel dettaglio Livelli del meta-modello di SpagoBI Assenza di meta-modello globale Livello SBI-L2 per QbE Un livello SBI-L2 per ogni componente Esempio di cubo OLAP Funzionalità del sistema Passi di esecuzione Entità estratte Package relazionale e dipendenze Principali classi relazionali Esempio di schema relazionale Modello istanza Il meta-modello OLAP Livelli di dettaglio del modello logico Schema di esempio La dimensione Geografia Livelli della dimensione Tempo I livelli della dimensione Geografia Gerarchie della dimensione Geografia Chiave della dimensione Geografia Schema OLAP Il cubo Vendite Esempio di CubeRegion Meta-modello Deployment Transformation Package

7 ELENCO DELLE FIGURE v 5.22 Mappatura della gerarchia alle sue componenti Esempio di misura derivata Mappatura livello-relazionale Associazione listofvalues Associazione immediateparent Mappatura CubeRegion-Relazionale Utilizzo del livello SBI-L Funzionalità di SpagoBI A.1 Meta-modello relazionale

8 vi ELENCO DELLE FIGURE

9 Elenco delle tabelle 3.1 Livelli di astrazione Livelli CWM vii

10 viii ELENCO DELLE TABELLE

11 Capitolo 1 Introduzione La presente tesi è consistita nello sviluppo di un prototipo per il progetto SpagoBI di Engineering. L applicazione, sviluppata in Java, estrae i metadati da un database relazionale, permette all utente di organizzarli secondo una logica multidimensionale e fornisce in output un file XML, in cui sono rappresentati come istanza del meta-modello CWM il modello relazionale, il modello OLAP e le corrispondenze tra i relativi elementi. A partire dal modello logico dimensionale sarà possibile sviluppare altri modelli, che soddisfino il bisogno di metadati che le varie componenti del sistema SpagoBI hanno per produrre documenti analitici. Il primo capitolo è così strutturato: la sezione 1.1 introduce il contesto dei metadati all interno di un azienda e in un sistema di Data Warehouse, a cui segue in sezione 1.2 una descrizione del progetto SpagoBI; si illustra infine come la tesi è strutturata in capitoli. 1.1 I metadati Aziende e organizzazioni investono ogni anno grandi quantità di tempo e denaro nel loro sistema informativo, che include le componenti hardware, middleware, software e le persone e processi coinvolti nello sviluppo, mantenimento e utilizzo di tali risorse. Ciascuna di queste entità, definibili come asset aziendali, genera meta-dati, che le aziende devono saper gestire per 1

12 2 CAPITOLO 1. INTRODUZIONE ottimizzare e sfruttare al massimo i propri investimenti. Il contesto è quello della conoscenza aziendale, definibile come la capacità, a partire dai dati, di ricavare informazioni utili a prendere decisioni vantaggiose. Il concetto di utilità per un azienda è misurabile in termini di vantaggio economico, ovvero, con una definizione semplice ma esplicativa, di minimizzazione delle spese e massimizzazione dei guadagni. Uno dei vantaggi cruciali che offre una gestione appropriata dei metadati è svincolare la logica di business dalla realtà tecnica e tecnologica sottostante che, in quanto mezzo e non scopo, deve essere al servizio dell economia aziendale e non limitarne l espressività e la crescita. Le entità che generano e utilizzano metadati in un azienda sono di natura estremamente eterogenea, in quanto spaziano dalle componenti fisiche alle risorse umane, dalle applicazioni software ai processi aziendali; ne consegue che i metadati si presentano con una notevole varietà di strutture e semantiche. Sorge la necessità di una gestione centralizzata mediante l adozione di un repository, che memorizzi i metadati della azienda, anche nella loro evoluzione storica, e ne consenta ad utenti e ad applicazioni esterne la visione e l accesso. Una descrizione astratta ma completa di un sistema di gestione dei metadati aziendali, denominata Managed Metadata Environment (MME), è stata fornita nel 2004 da D. Marco e M. Jennings [5]. Hanno delineato il flusso dei metadati che, una volta estratti dalle sorgenti e memorizzati nel repository, di cui viene specificato l intero meta-modello, sono distribuiti agli utenti interessati. I vantaggi che una gestione appropriata dei metadati porta ad un azienda sono molteplici: in particolare consente di attribuire ad ogni risorsa un significato in termini di business e di controllarne l efficienza e la qualità. Fornisce una visione globale del sistema e dei processi, permettendo di individuare eventuali sprechi di risorse e di analizzare a priori l impatto di cambiamenti strutturali, favorendone così l espansione e l integrazione con altri sistemi. Nel contesto del Data Warehouse i metadati giocano un ruolo fondamentale, in quanto documentano e guidano l intero flusso dei dati dalle sorgenti

13 1.2. SPAGOBI E IL PROTOTIPO 3 all analisi, attraverso il processo ETL e la memorizzazione nel Data Warehouse e nei Data Mart. In una realizzazione fisica i vari passi del flusso di dati sono tipicamente eseguiti da prodotti diversi, appartenenti a vendor differenti; ottenere interoperabilità tra questi è quanto mai desiderabile, specialmente per massimizzare l automatizzazione nella gestione del flusso di dati e minimizzare l intervento manuale, costoso e foriero di errori. Requisito necessario alla interoperabilità è che tali prodotti siano in grado di condividere i dati e, di conseguenza, di comprenderne le reciproche strutture e semantiche, ovvero i metadati. L integrazione dei dati richiede dunque a priori una integrazione a livello di metadati, concetto non facilmente realizzabile in quanto tipicamente prodotti diversi gestiscono la propria conoscenza in forme e strutture differenti, ciascuno secondo le proprie esigenze e seguendo propri criteri di efficienza. Lo standard CWM fornisce un linguaggio standard e un formato di scambio condiviso per descrivere i metadati nei contesti del Data Warehouse e della Business Analysis. Nel definire un meta-modello standard, CWM realizza un approccio model-driven alla integrazione dei metadati, consentendo al progettista di realizzare una architettura di gestione dei metadati senza preoccuparsi della loro integrazione, garantita dall aderenza allo standard, ma guidato soltanto dalle proprie esigenze aziendali e da criteri di business. 1.2 SpagoBI e il prototipo Realizzato da Engineering Informatica Spa, SpagoBI è una soluzione completa e open-source per lo sviluppo di progetti di Business Intelligence in un ambiente integrato; soddisfa l intera gamma delle esigenze analitiche, dall analisi OLAP al reporting statico, dalle tecniche di data mining al controllo delle performance aziendali. Supporta inoltre i processi di estrazione, trasformazione e caricamento dei dati (ETL). SpagoBI offre diverse soluzioni per ogni area analitica, lasciando libero l utente finale di scegliere la composizione della soluzione più adatta alle proprie esigenze, allo scopo di massimizzare il ritorno degli investimenti (ROI) e di salvaguardare il patrimonio informativo

14 4 CAPITOLO 1. INTRODUZIONE aziendale. SpagoBI non si avvale attualmente di un meta-modello, con la conseguenza che i vari documenti analitici devono recuperare i dati e metadati direttamente dalle sorgenti, situazione che può essere causa di inconsistenze e incorrettezze all interno del sistema e nelle analisi. Il meta-modello che si intende integrare si struttura su quattro livelli; il primo rappresenta i metadati che descrivono le risorse fisiche, organizzati nel livello successivo secondo una logica multi-dimensionale. Il terzo livello permette di descrivere come le applicazioni analitiche si interfacciano al Data Warehouse per la produzione dei documenti e infine il quarto consente di definire gli utenti e la loro navigazione all interno del sistema integrato. Il prototipo si focalizza sui primi due livelli: si tratta di un applicazione Java che permette all utente di estrarre i metadati da un database relazionale ed organizzarli secondo una logica multi-dimensionale, definendo cioè livelli, gerarchie, dimensioni, fatti e misure. I metadati estratti e la loro modellazione logica vengono dunque salvati in un file XML nel formato di scambio definito dalla specifica CWM [9], che fornisce infatti uno standard per rappresentare modelli istanze del meta-modello CWM in un file XML, utilizzato come formato di scambio tra tool diversi. 1.3 Struttura della tesi Segue una breve descrizione di come gli argomenti trattati sono suddivisi nei diversi capitoli della tesi. Il capitolo 2 introduce il concetto di metadato ed è articolato in due sezioni, la prima ne offre una visione all interno dell azienda e tratta le possibili scelte logiche e architetturali per una loro appropriata e sistematica gestione. In particolare si descrive il Managed Metadata Environment e i vantaggi che garantisce all azienda. La seconda sezione illustra il problema dell integrazione dei metadati tra i vari prodotti coinvolti in un sistema di

15 1.3. STRUTTURA DELLA TESI 5 Data Warehouse, delineando i possibili approcci ed illustrando in particolare quello definito model-driven. Il capitolo 3 è dedicato al Common Warehouse Metamodel. Dopo averne analizzato le tecnologie fondanti e la struttura del meta-modello, si evidenzia come lo standard sia la realizzazione di un approccio model-driven alla integrazione dei metadati. Si descrive dunque come applicazioni in grado di comprendere il CWM possono scambiarsi la conoscenza e quindi interoperare. Il capitolo 4 introduce il concetto di open-source, seguito dalla descrizione del progetto SpagoBI e della sua futura intenzione di appoggiarsi ad un meta-modello. Il capitolo 5 descrive l implementazione del prototipo, gli strumenti di sviluppo utilizzati e le funzionalità implementate. Fornisce un esempio di esecuzione dell applicazione su un semplice modello relazionale, evidenziando come gli elementi forniti dal meta-modello CWM siano utilizzati per rappresentare il modello fisico relazionale, quello logico OLAP e come le entità dell uno siano mappate in quelle dell altro. Il capitolo 6 descrive infine i risultati ottenuti, identifica delle possibili estensioni al prototipo e analizza la futura adozione del meta-modello da parte di SpagoBI. Sono anche illustrate le attuali direzioni di ricerca nel contesto dei metadati aziendali.

16 6 CAPITOLO 1. INTRODUZIONE

17 Capitolo 2 I Metadati Now we can see why we didn t know what this metadata was about! It s everything, except for the data itself! [Ralph Kimball] Nel presente capitolo si introduce il concetto di metadato, sottolineando l importanza che assume nel contesto aziendale e in un sistema di Data Warehouse. La sezione 2.1 individua nei metadati la chiave per una gestione efficace della conoscenza all interno di un azienda; si evidenziano dunque i benefici a cui può portare un loro trattamento appropriato e sistematico. In particolare si offre una panoramica del Managed Metadata Environment, una soluzione astratta ma completa alla gestione sistematica dei metadati all interno di un azienda. La sezione 2.2 contestualizza invece i metadati all interno di un sistema di Data Warehouse e introduce la necessità di ottenere interoperabilità tra prodotti diversi, col conseguente requisito fondamentale di permettere lo scambio di metadati. 2.1 I metadati nell azienda La parola metadato ha etimologia mista dal greco meta ( oltre, al di là ) e dal latino datum, che significa informazione. Posto che ogni dato è la descrizione di qualcosa, possiamo considerare un metadato come un dato in cui l oggetto descritto è un altro dato. La semplice definizione dati che de- 7

18 8 CAPITOLO 2. I METADATI scrivono altri dati non rende peró la vastità e complessità di tale argomento applicato alla realtà informatica, per questo motivo ogni studioso ha adottato una propria definizione; riportiamo in particolare quella proposta da Charles Betz nel 2003 [7]: Dati che descrivono altri dati, il sistema che li gestisce, le persone e i processi che li creano e consumano. Si intuisce pertanto come tutti gli aspetti di un sistema aziendale sono potenziali sorgenti di metadati, che si presentano dunque in forme estremamente eterogenee. Andrew S. Tanembaum nel 2002 [23] ha definito alcune domande generiche, relative a un dato, a cui i metadati devono fornire risposta: di cosa si tratta, quali sono il suo significato e la sua origine, dove è allocato e come è possibile accedervi. Una gestione corretta dei metadati permette però di rispondere a domande ben più complesse: ad esempio si possono fornire informazioni sulle persone coinvolte nel suo utilizzo, contestualizzarlo all interno del business, rintracciare la presenza di altri dati che da esso dipendono. Lo scopo dei metadati è fornire conoscenza, concetto che, come evidenziato in figura 2.1, deve essere distinto da quelli di dato e informazione. I dati, ad esempio il nome e l indirizzo di un cliente che ha effettuato un ordine, sono i mattoni che fondano i sistemi IT, tuttavia da soli non possiedono molto significato; non informano ad esempio sui motivi di un acquisto, sulle aspettative del cliente, tanto meno sono in grado di affermare se un azienda è ben gestita ed efficiente. Come sostenuto da Thomas Davenport e Laurence Prusak [8], si può aggiungere valore informativo ai dati individuando la ragione per cui sono stati raccolti, le unità di analisi, le funzioni di calcolo, eventuali correzioni ed aggregazioni; si ottengono così informazioni legate al business dell azienda. Se ad esempio per ogni cliente sommiamo la spesa totale degli acquisti da lui effettuati in un anno e sottraiamo i costi dell azienda per servirlo, siamo in grado di determinare quali sono i clienti più convenienti per l azienda: il dato, contestualizzato nel business, è diventato informazione. Per ottenere conoscenza, ovvero capacità di prendere decisioni

19 2.1. I METADATI NELL AZIENDA 9 Figura 2.1: Piramide della conoscenza utili, è necessario analizzare come il proprio business si relaziona alla realtà circostante, comprendendo come impatta sul mercato, come ne è influenzato e come interagisce con altre compagnie attive nello stesso settore. Una corretta gestione dei metadati consente di catturare e analizzare le informazioni aziendali e le loro variazioni nel tempo nel contesto del business, che è in costante evoluzione. Come evidenziato in figura 2.1, un segnale di maturità per un sistema IT è il passaggio dalla gestione dei dati alla gestione della conoscenza Metadati tecnici e metadati di business Nel contesto aziendale distinguiamo i metadati tecnici e quelli di business (figura 2.2). I primi forniscono informazioni riguardanti gli aspetti fisici e tecnici del sistema, permettendone lo sviluppo e il mantenimento. Esempi di metadati tecnici sono nomi di tabelle e attributi, modelli fisici e logici dei dati, frequenze di aggiornamento, definizione delle sorgenti e delle destinazioni nelle trasformazioni dei dati; sono pertanto di interesse per gli sviluppatori e gli utenti tecnici del sistema. All interno dell azienda vi sono però altre figure, che chiamiamo utenti di business, ai quali non è richiesto di possedere particolari conoscenze tecniche; sono ad esempio i commerciali,

20 10 CAPITOLO 2. I METADATI statisti, analisti del mercato e della finanza. I metadati di business permettono a tali utenti di ignorare la realtà tecnica del sistema e di accedere ai dati in modo comprensibile dal punto di vista economico/aziendale, tipicamente ricavando informazioni dal sistema tramite query e report predefinite. Esempi di metadati di business sono le regole di aggregazione dei dati e le regole di business, le aree tematiche, nomi logici delle strutture fisiche. La Figura 2.2: Metadati tecnici e di business figura 2.2 mostra il ruolo di Amministratore dei dati, il cui scopo è quello di intermediario tra la realtà tecnica del sistema informativo e l astrazione del business. Si tratta di un ruolo che può essere assegnato a un gruppo di persone, le cui attività principali consistono nella definizione dei metadati tecnici, di business e delle rispettive mappature, delle regole di business e dei vincoli di qualità dei dati La gestione dei metadati La gestione dei metadati è la chiave per il successo del business; ma cosa significa effettivamente gestire i metadati? Significa progettare e realizzare

21 2.1. I METADATI NELL AZIENDA 11 una strategia che permetta ad utenti e applicazioni di accedere e manipolare i metadati, nella consapevolezza che questi siano aggiornati, consistenti e sicuri. Ralph Kimball ha individuato in [6] alcune attività fondamentali da svolgere per progettare una strategia di gestione, a prescindere dall architettura fisica sottostante. É necessario compilare una lista di tutti i metadati che descrivono le risorse nell azienda e, possibilmente, stabilire degli ordini di importanza; dato il loro valore informativo, a ogni gruppo di metadati deve essere assegnata una persona responsabile, e tali responsabilità vanno documentate. É necessario quindi definirne le modalità di memorizzazione, compresa una possibilità di backup, assicurarne la qualità e l aggiornamento, renderne possibile il controllo e il mantenimento centralizzati e la facoltà di accesso alle persone interessate. I metadati all interno dell azienda descrivono entità estremamente diverse, dalle strutture fisiche ai documenti cartacei, dai processi aziendali alle persone coinvolte. Data una realtà così eterogenea, una loro gestione centralizzata offre una serie di indubbi vantaggi all azienda, che spesso è divisa in vari dipartimenti e aree lavorative impossibilitate a comunicare tra loro. La scelta più efficace si rivela essere l utilizzo di un repository centrale, ovvero un database relazionale che si occupi di memorizzare i metadati provenienti dalle varie sorgenti, permettendone la gestione centralizzata e la diffusione all interno di tutta la struttura aziendale; come indicato in [2] deve essere generico, integrato, aggiornato e storico. Generico significa che deve memorizzare i metadati per aree tematiche e non a seconda della provenienza da particolari applicazioni. Ad esempio un repository generico potrà contenere una tabella dedicata alle colonne dei database relazionali, non una specificatamente dedicata alle colonne dei database Oracle o MySql. Deve essere Integrato in quanto contiene i metadati di tutti gli asset aziendali; tali caratteristiche garantiscono una visione globale dell azienda e facilitano l adozione di nuove tecnologie e prodotti. É fondamentale che i contenuti del repository siano costantemente aggiornati per riflettere la realtà del sistema; inoltre deve essere tenuta traccia della storicità dei metadati, mem-

22 12 CAPITOLO 2. I METADATI orizzando date di inserimento, modifica e cancellazione: in questo modo è possibile effettuare analisi storiche sull azienda, evidenziandone ad esempio cambiamenti strutturali. L ultima caratteristica è fondamentale soprattutto qualora il repository supporti strutture che contengono dati storici, come un Data Warehouse o un applicazione di Customer Relationship Management (CRM). Consideriamo ad esempio un azienda che possieda tre punti vendita situati in tre città italiane; potrebbe definire un cliente come chiunque abbia effettuato un acquisto presso uno dei tre punti vendita. Immaginiamo che l azienda, in espansione, aggiunga un ulteriore canale di distribuzione, un sito web da cui l utente può effettuare ordinazioni e acquisti. La definizione di cliente dovrà cambiare di conseguenza in chiunque abbia effettuato un acquisto presso uno dei tre punti vendita o attraverso il sito. Il repository dovrà memorizzare entrambe le definizioni, in quanto entrambe potrebbero essere valide a seconda del periodo a cui si riferiscono i dati che l utente analizza. L utilizzo di una tale struttura permette una gestione centralizzata dei metadati di tutta l azienda; è pertanto possibile automatizzare operazioni come il versionamento o il backup, garantire la sicurezza, l integrità e la consistenza dei contenuti. Vi è una proporzione tra la complessità dell architettura e i benefici che ne derivano per l azienda, misurabili in termini di ROI (Return of Investment), un acronimo che indica l indice di redditività del capitale investito. Le architetture più semplici si limitano a raccogliere le definizioni e rappresentazioni dei dati, funzionalità già realizzata dai data dictionary, che già negli anni 70 memorizzavano le definizioni tecniche degli attributi e delle entità usate nel sistema IT. Sebbene tali informazioni siano di interesse per qualsiasi tipo di utente, la possibilità di visualizzarli ha un valore limitato per l azienda in quanto non è in alcun modo indirizzata al business. Architetture più elaborate possono garantire benefici maggiori, ad esempio permettendo di controllare la qualità dei dati e consentendo lo sviluppo di interfacce utente. Settori aziendali come l e-business, il CRM e sistemi di supporto alle de-

23 2.1. I METADATI NELL AZIENDA 13 cisioni si fondano sui dati presenti nei sistemi legacy delle aziende; è ovvio come da dati inaccurati, ridondanti e inconsistenti non possano derivare informazioni corrette. I metadati forniscono i meccanismi per migliorare la qualità dei dati, permettono di definire delle metriche di qualità e monitorare eventuali casi limite presenti nel sistema. Ad esempio, si può stabilire che qualora per più del due per cento dei dati coinvolti in una trasformazione venga segnalato un errore, l intera transazione sia da ritenersi non valida. Abbiamo già evidenziato come un utente di business non sia tipicamente interessato a sapere quale sia la fonte delle informazioni di cui ha bisogno, sia che si tratti di un database, di un Data Warehouse o di un documento esterno; ciò che gli interessa è trovarle rapidamente e con minimo sforzo. I metadati forniscono uno strato semantico tra i sistemi IT e gli utenti di business che può essere sfruttato per la creazione di un interfaccia che permetta di navigare attraverso le risorse utilizzando una terminologia attinente al business e, una volta trovata l informazione cercata, comprenderla e sfruttarla al meglio Managed Metadata Environment We build systems to manage every aspect of the business, except one to manage the systems themselves [D. Marco] Vi è una contraddizione in aziende che spendono denaro per dotarsi di sistemi che gestiscano ogni aspetto del business e non si dotano di un sistema che gestisca i sistemi stessi e ne permetta l ottimizzazione. Il Managed Metadata Environment (MME) è una soluzione alla gestione dei metadati proposta nel 2004 da David Marco [5]; rappresenta le componenti architetturali, persone e processi richiesti per raccogliere, mantenere e distribuire i metadati attraverso l azienda in maniera appropriata e sistematica. Si tratta di una descrizione astratta, in quanto non si lega ad alcuna specifica piattaforma, applicazione o prodotto; tuttavia si presenta completa nel definire l intero meta-modello (ovvero le strutture logiche) per memorizzare i metadati di tutta l azienda. La struttura del Managed Metadata Environment, mostrata in figura 2.3, si sviluppa in sei livelli logici:

24 14 CAPITOLO 2. I METADATI livello sorgenti livello di integrazione livello repository livello gestione livello (opzionale) meta-data mart livello di distribuzione Figura 2.3: Managed Metadata Environment Il livello sorgente si occupa di estrarre i metadati dalle varie sorgenti, che possono essere tool software (in particolare database relazionali o tool di

25 2.1. I METADATI NELL AZIENDA 15 modellazione), utenti finali del sistema, documenti, messaggi e transazioni, siti web o terze parti esterne all azienda, come clienti e fornitori. É importante separare l estrazione dei metadati in una piattaforma distinta dalle singole sorgenti; in tale modo il sistema si rivela maggiormente adattabile all aggiunta di nuove sorgenti e si garantisce un backup dei metadati estratti. Inoltre, qualora dovessero verificarsi errori nelle fasi successive, sarebbe poco auspicabile dover estrarre nuovamente parte dei metadati dalle sorgenti: potrebbero infatti generarsi inconsistenze se le sorgenti dovessero essere cambiate, senza contare che potrebbero essere in uso e ulteriori accessi altererebbero inutilmente le loro performance. Il livello di integrazione ha il compito di integrare i metadati estratti e caricarli nel repository; poichè la quantità di metadati è comunque minore dei dati presenti in un Data Warehouse, l approccio all integrazione è diverso dal processo ETL, in quanto non distingue i passi della trasformazione (integrazione) e del caricamento. L azienda può implementare questo livello secondo le proprie particolari necessità oppure affidarsi a uno dei tool di integrazione disponibili sul mercato, che solitamente forniscono anche funzionalità di gestione del repository. Il terzo livello del sistema è appunto il repository, le cui caratteristiche sono già state delineate nella sezione precedente, dove vengono memorizzati fisicamente i metadati. David Marco specifica completamente la sua struttura delineando diagrammi entità-relazione in grado di descrivere l intera realtà aziendale. Suddivide gli asset in aree tematiche: sistemi hardware, software e infrastrutturali, strutture di memorizzazione dei dati, processi aziendali e persone coinvolte, regole del business, movimenti e trasformazioni dei dati; per ciascuna area definisce il diagramma in grado di descriverne gli elementi. Fornisce inoltre suggerimenti su eventuali estensioni da applicare ai meta-modelli da lui proposti per trattare situazioni aziendali specifiche. Il livello successivo permette la gestione sistematica dei metadati nel repository e delle altre componenti del Managed Metadata Environment. L ultimo livello si occupa della distribuzione dei metadati agli utenti finali

26 16 CAPITOLO 2. I METADATI del sistema o alle componenti che li richiedono; comunemente i destinatari sono, oltre agli utenti tecnici e di business, applicazioni, il sistema di Data Warehouse, transazioni, siti web e terze parti esterne all azienda. I vantaggi del MME nell azienda In assenza di una gestione sistematica dei metadati, un azienda deve gestire comunque la conoscenza dei propri sistemi informativi; tipicamente questa viene affidata a singoli dipendenti, con il palese svantaggio che in assenza della persona che detiene la conoscenza di un particolare asset, magari in seguito alle sue dimissioni, diventa necessario recuperare la conoscenza attraverso l analisi a posteriori della struttura, con evidente spreco di risorse. Analizziamo alcune problematiche che comunemente affliggono un azienda e mostriamo come il Managed Metadata Environment risulti essere una soluzione. Riassumendo, i benefici cruciali di una gestione sistematica dei metadati sono: riuso di soluzioni prevenzione dal fallimento dei processi riduzione dei costi adesione a regolamentazioni o standard gestione globale della conoscenza e visione orientata al business interfaccia verso i clienti Un azienda che non gestisce la conoscenza in maniera centralizzata tipicamente approccia ogni nuovo problema ripartendo ogni volta da zero, con un così chiamato sforzo eroico di un singolo o di un gruppo di persone, in quanto non è disponibile alcuna informazione relativa ad eventuali soluzioni al problema già sviluppate in precedenza. Documentare invece sistematicamente i progetti e le soluzioni aziendali favorisce il riuso, concetto fondamentale in informatica, di soluzioni già individuate, siano esse applicazioni

27 2.1. I METADATI NELL AZIENDA 17 software o scelte di marketing. Una visione globale dell azienda permette di trasferire tali soluzioni tra i vari dipartimenti della struttura e di considerare, nelle decisioni di business, le lezioni imparate in passato. Le aziende assistono spesso al fallimento dei propri progetti, specialmente quelli di modifica strutturale al sistema, in quanto non sono in grado di prevedere l impatto di un cambiamento di una risorsa con il resto della struttura. I metadati possono individuare le dipendenze tra risorse, rendendo così possibile sapere in anticipo quanti e quali dati sarebbero influenzati da un cambiamento. Il gruppo incaricato del progetto può pertanto valutarne realisticamente la fattibilità, minimizzando il rischio di fallimento. Un altra situazione comune e indesiderabile nelle aziende che evolvono in maniera disordinata e senza conoscenza globale è la notevole ridondanza in termini di dati, processi e applicazioni. Non è la ridondanza in sè da biasimare, dato che può avere utilità di backup o di efficienza (i meta-data mart ne sono un esempio), bensì la sua natura e crescita incontrollata; ad un evidente spreco di risorse si aggiunge un oggettiva difficoltà di mantenere il sistema aggiornato e consistente. La gestione centralizzata della conoscenza permette sia di individuare ridondanze già presenti nel sistema, sia di evitare lo sviluppo di applicazioni o l avvio di processi già esistenti; le risorse inoltre possono essere contestualizzate, motivate, e quindi ottimizzate dal punto di vista funzionale. Nella realtà del business inoltre, a causa della variabilità del mercato e della costante innovazione tecnologica, è molto frequente la necessità di estendere il sistema, magari integrando un altro sistema informativo già esistente. In ambito finanziario, ad esempio, può capitare che una banca più grande inglobi una più piccola, con la conseguente necessità di integrare il sistema informativo della seconda al primo. Questa risulta un operazione particolarmente difficoltosa qualora le risorse non siano descritte e sia quindi necessario comprendere a posteriori la funzione e struttura di ognuna, al fine di individuare le corrispondenze tra i due sistemi,. Vi sono inoltre settori, come quello farmaceutico o finanziario, soggetti

28 18 CAPITOLO 2. I METADATI a numerose regolamentazioni, il cui mancato rispetto può portare anche a problemi legali; mediante la gestione della conoscenza è possibile garantire l aderenza a tali vincoli; ad esempio, in tema di privacy, è possibile identificare operazioni non legali tracciando, per ogni accesso ai dati, l autore con relativi privilegi. Per quanto riguarda gli utenti di business dell azienda, il Managed Metadata Environment offre la possibilità di astrarre dalla realtà tecnica e visualizzare ogni asset aziendale secondo una logica di business. Per localizzare l informazione desiderata ad esempio l utente può navigare i dati selezionando la categoria di prodotto commerciale a cui è interessato, l area geografica coinvolta, una particolare tipologia di cliente. É possibile inoltre condividere definizioni di termini, di regole, di standard all interno di tutta l azienda e gestire centralmente i processi di business valutandone le performance. Infine il repository offre la possibilità alle varie applicazioni che si interfacciano ad esso di comunicare tra loro in un linguaggio comune; in questo modo non è necessario costruire di volta in volta degli adattatori appositi per ogni coppia di tool che intende stabilire una comunicazione di metadati. Come vedremo nella sezione successiva, tale approccio non è ancora la soluzione ideale alla integrazione della conoscenza tra le applicazioni di un sistema, in quanto il repository di cui si dota un azienda ha un modo proprietario di gestire i dati e quindi un particolare linguaggio per esprimerli, pertanto gli sviluppatori sono comunque costretti ad implementare dei ponti di comunicazione tra le varie applicazioni e il sistema centrale. 2.2 I metadati nel Data Warehouse Fornita una panoramica dei metadati a livello aziendale, focalizziamo l attenzione sul ruolo che svolgono nei contesti del Data Warehouse e della Business Analysis; in particolare analizziamo il bisogno di interoperabilità tra le applicazioni coinvolte nel sistema, e la conseguente necessità di comunicazione di metadati tra prodotti diversi.

29 2.2. I METADATI NEL DATA WAREHOUSE 19 Data Warehouse Il Data Warehouse è la struttura fondamento di un sistema di supporto alle decisioni aziendali; può essere pensato come un particolare database ottimizzato per l analisi dei dati provenienti dalle varie realtà aziendali; deve essere orientato al soggetto, integrato, non volatile e storico. Orientato al soggetto significa che i dati sono suddivisi in aree tematiche secondo i soggetti coinvolti nell azienda, a differenza dei sistemi operazionali che solitamente sono orientati alle funzioni. É integrato in quanto raccoglie dati provenienti da sorgenti diverse, ciascuna delle quali li tratta con sintassi e semantiche proprie; prima dell inserimento nel Data Warehouse i dati sono dunque convertiti e aggregati in modo da avere un immagine fisica uniforme. Non volatile significa che nessun dato è mai cancellato; ciascuno è caratterizzato da una data di creazione, qualora un dato sia modificato la versione precedente viene marcata con la data di modifica e viene aggiunta la nuova versione. Questo garantisce la natura storica del sistema, ovvero il requisito fondamentale che ogni singolo dato debba essere sempre collegato alla dimensione temporale. I dati contenuti nel Data Warehouse sono utilizzati per effettuare analisi del sistema e analisi di mercato, specialmente in relazione al variare del tempo. Il processo indicato in figura 2.4 identifica il movimento dei dati che, dalle sorgenti operazionali presenti nell azienda, vengono integrati all interno del Data Warehouse mediante l acquisizione ETL (Extract,Transform, Load); i tool di analisi e visualizzazione li accedono direttamente dal Data Warehouse o dai Data Mart. Questi ultimi sono sottoinsiemi dei dati presenti nel Data Warehouse indirizzati a gruppi di utenti con bisogni informativi omogenei, costruiti in modo tale da ottimizzarne l accesso e l analisi. Può essere presente un Operational Data Store (ODS), un sistema operazionale con il ruolo di memorizzare i dati estratti non ancora integrati, per ragioni di backup ed efficienza. Il concetto di metadato è nato coi sistemi operazionali, dove ha assunto però un importanza relativa, paragonabile a quella di una documentazione strutturata. Nel contesto del Data Warehouse la situazione è differente: la

30 20 CAPITOLO 2. I METADATI Figura 2.4: Flusso dei dati natura storica del sistema, con la conseguente presenza simultanea di più versioni dello stesso dato, le trasformazioni dei dati durante le acquisizioni e la presenza degli utenti di business sono state le ragioni principali che hanno fatto crescere l importanza di gestire la conoscenza, e dunque i metadati. La difficoltà di individuare una definizione generale dei metadati in tale contesto è conseguenza del fatto che sono presenti e attivi lungo tutto il processo dei dati, dall estrazione all analisi, come evidenziato in figura 2.4. Descrivono infatti le sorgenti dei dati, sia strutturalmente che funzionalmente, le trasformazioni durante l acquisizione ETL, modelli fisici e logici delle risorse, guidano la formulazione di report e query e fungono da indice per permettere agli utenti sia tecnici che di business di trovare i dati a cui sono interessati. Permettono inoltre di tracciare il percorso dei dati e individuare eventuali errori o incongruenze: dalle sorgenti all ODS, quindi durante l acquisizione nel Data Warehouse fino ai concetti di business rappresentati nelle analisi. L utente di business è spesso interessato a comprendere i cambiamenti subiti dai dati lungo un certo periodo di tempo, sfruttando la natura storica di un Data Warehouse; i metadati facilitano l analisi storica e

31 2.2. I METADATI NEL DATA WAREHOUSE 21 permettono una gestione efficiente dei cambiamenti del sistema. Un esempio di metadati attivi Vediamo un esempio, descritto da Ralph Kimball in [6], di come i metadati possano svolgere un ruolo attivo nella costruzione di un Data Warehouse, basandoci su un semplice diagramma di flusso che ne descrive i passi di creazione (figura 2.5), dal caricamento dei dati alle analisi utente. Kimball definisce attivi i metadati che consentono di guidare i processi, non soltanto di documentarli; immaginiamo che nella costruzione del Data Warehouse ci si affidi a tre tool: uno che consenta la definizione dei metadati, uno che si occupi di memorizzare i dati, uno infine che permetta all utente finale di accedere ai dati secondo una logica di business. Il passo 1 è la creazione di un modello del Data Warehouse, che comprenda modelli sia fisici che logici mediante la definizione di metadati tecnici e di business; si tratta di un - operazione facilmente ottenibile con un tool di modellazione. E necessario gestire il movimento dei dati dalle sorgenti al Data Warehouse e la loro memorizzazione, possibilmente affidandosi a un tool apposito; le informazioni sui target sono fornite dai modelli precedentemente creati. Il passo 2 consiste nel catturare le definizioni delle sorgenti, che sappiamo possono essere di varia natura. Il passo 3 si occupa di reperire le informazioni relative a eventuali trasformazioni durante il processo di memorizzazione; è possibile svolgere questo compito basandosi sui metadati catturati nel passo 1. Nel passo 4 si salvano tali informazioni in un database relazionale fornito dal tool di memorizzazione. Si noti che il processo di creare le mappature nel passo 3 consiste sostanzialmente nel definire una relazione tra due realtà di metadati già esistenti; pertanto il grosso del lavoro è stato effettuato con la definizione del modello. Completati i passi finora descritti si hanno i dati caricati; infatti nel passo 5 il tool di memorizzazione, tramite query ai metadati, si occupa di reperire le informazioni riguardanti sorgenti, trasformazioni e target e, eventualmente, può interrogare il database target (passo 5a) riguardo a informazioni sul suo stato fisico corrente, ad esempio su quanto spazio sia ancora

32 22 CAPITOLO 2. I METADATI Figura 2.5: Esempio di metadati attivi

33 2.2. I METADATI NEL DATA WAREHOUSE 23 disponibile. Nel passo 6 avviene l estrazione dei dati e col passo 7 si caricano i dati trasformati all interno del Data Warehouse. Il passo 8 calcola dunque statistiche e informazioni riguardo al caricamento, e le salva nel database dei metadati. Una volta che i dati sono stati caricati, gli utenti per accedervi necessitano di sapere dove e con quali criteri sono memorizzati i dati; tali informazioni sono contenute ancora una volta nel modello definito inizialmente, ad esempio i nomi di tabelle, colonne, descrizioni e informazioni sul contenuto. É necessario però dotare il tutto di una visione orientata al business; un ordinamento alfabetico di tutte le tabelle e colonne ad esempio non sarebbe utile, in quanto l utente tenderà a pensare in termini di raggruppamenti secondo logiche di business; sarebbe molto più utile una organizzazione strutturata in tabelle dei fatti e delle dimensioni. Il passo 9 mostra l utilità di un tool di front-end, mediante il quale gli utenti possano navigare con una interfaccia web i raggruppamenti di business, visualizzare con maggiore dettaglio quali tabelle sono coinvolte in un determinato raggruppamento e quali colonne in una determinata tabella. Una volta individuati i dati cercati, l utente può formulare una query da sottomettere al database nel passo 10 ; si noti come il sistema necessiterà dei metadati recuperati nel passo 9 per formulare la corretta sintassi. I risultati sono tornati all utente nel passo 11 ; un buon tool di front-end ritornerà anche alcune informazioni di utilizzo e di esecuzione (passo 12 ). La descrizione di tale processo evidenzia il ruolo fondamentale che la memorizzazione centralizzata dei metadati gioca nella costruzione di un Data Warehouse; solo tre delle dodici interazioni infatti coinvolgono dati, le restanti riguardano solo i metadati. Inoltre lo stesso metadato è sfruttato in più passi; ad esempio il modello creato nel passo 1 contiene le definizioni fisiche delle tabelle; il tool di memorizzazione dei dati necessita di esse per effettuare le mappature sorgente-target e di nuovo quando deve effettivamente trasformare e caricare i dati. Infine il tool di query ne ha bisogno per formulare la query con la corretta sintassi. Evidenziata l importanza dei metadati in un sistema di Data Warehouse

34 24 CAPITOLO 2. I METADATI illustriamo il problema della integrazione, la cui soluzione è necessaria al fine di ottenere interoperabilità tra i vari tool coinvolti nello sviluppo e utilizzo del sistema Il problema dell integrazione Come evidenziato in [4], il contesto del Data Warehouse può essere rappresentato in termini di una Information Supply Chian, per sottolineare il fatto che l informazione passa dalle sorgenti fornitrici di dati attraverso una serie di trasformazioni, fino a diventare informazione, ovvero ad avere valore strategico per prendere decisioni di business. La figura 2.6 evidenzia i passi della catena, ciascuno dei quali è al tempo stesso generatore e consumatore di metadati. É improbabile che un singolo vendor sia in grado di offrire una Figura 2.6: Information Supply Chain soluzione architetturale completa e integrata per l intera catena; per questo i vari passi sono tipicamente gestiti da tool specifici, appartenenti solitamente a vendor diversi; la loro integrazione è tutt altro che semplice. Posto che la catena consiste di un flusso di dati, ogni tool coinvolto deve essere in grado di comprendere la natura dei dati che utilizza, la loro origine, il significato e le trasformazioni di cui necessitano. Pertanto ogni tool deve appoggiarsi su dei metadati, la cui definizione deve essere comprensibile a tutti i prodotti coinvolti nella catena. Tuttavia i vari prodotti software sono tipicamente sviluppati secondo criteri che ne massimizzino l efficacia ed efficienza interna e non secondo una ottica di integrazione con altri tool; hanno quindi tipi-

35 2.2. I METADATI NEL DATA WAREHOUSE 25 camente modelli implementativi proprietari e memorizzano i metadati con formati diversi, rendendoli accessibili mediante la pubblicazione di interfacce (anche esse specifiche di ogni prodotto). Tool con metadati in formati differenti sono integrabili mediante lo sviluppo di complessi ponti in grado di tradurre i metadati memorizzati in un formato di uno specifico prodotto in un altro formato specifico di un altro prodotto. Si rende necessaria pertanto l implementazione di un ponte per ogni coppia di prodotti che necessitano di comunicare, costituendo la cosí chiamata point to point architecture (figura 2.7). Lo spreco di risorse é evidente: sebbene tali ponti adempiano gli stessi compiti finali è necessario implementare ogni volta un meccanismo di traduzione nuova. Figura 2.7: Point to point architecture Ne concludiamo che, per poter integrare i dati in maniera efficiente, è necessaria innanzitutto una integrazione e sincronizzazione globale di tali isole di metadati, al fine di avere un unica interfaccia e modalità di trattamento dei metadati sia tecnici che di business. É necessario fornirne una visione centralizzata, soluzione che permette una riduzione dei costi, degli errori e una maggiore comprensione del sistema, non solo da parte dell utente finale ma anche dello sviluppatore. Una parziale soddisfazione di tali requisiti di integrazione è l utilizzo di un repository, che memorizzi i metadati dell intero sistema e ne permetta il controllo. Si noti come, ai fini dell integrazione,

36 26 CAPITOLO 2. I METADATI non specifichiamo alcun requisito sulla effettiva memorizzazione; più che di un repository fisico intendiamo ora una entità logica che offra una visione centralizzata, a prescindere dalla effettiva implementazione. In figura 2.8 si può notare come il numero di ponti necessari decresca notevolmente; il repository infatti pubblica una propria interfaccia tramite la quale i vari tool possono accedere ai metadati dell intero sistema. Se consideriamo n il numero di prodotti coinvolti, siamo passati da n 2 a n ponti necessari. L architettura Figura 2.8: Hub and Spoke architecture così composta viene denominata hub and spoke arhcitecture. La soluzione non è ancora ottimale, in quanto ogni ponte é legato ad uno specifico tool e uno specifico repository, che memorizza i metadati con un formato proprietario. L idea fondamentale per garantire al sistema flessibilità e riusabilità, con conseguente diminuzione dei costi, è che vi sia un formato di memorizzazione dei metadati universalmente conosciuto, in modo tale che gli sviluppatori dei vari prodotti possano realizzare la traduzione tra esso e i formati proprietari inerentemente ai prodotti, liberando così l azienda cliente dalla resposabilità di implementare la comunicazione tra i prodotti scelti. L eventuale repository, intendendo ora il database fisico, dovrebbe anche esso implementare

37 2.2. I METADATI NEL DATA WAREHOUSE 27 la traduzione tra il formato universale e il proprio, oppure adottare direttamente il primo nella memorizzazione dei metadati. L idea di creare una rappresentazione esterna e universalmente conosciuta dei metadati è il fondamento dell approccio denominato model-driven; prima di procedere alla sua descrizione è necessario definire i concetti di modello e meta-modello. Modello e meta-modello Il termine modello è spesso usato per designare una rappresentazione precisa ma astratta di qualcosa del mondo reale; precisa in quanto descritta secondo un linguaggio formale che non permetta ambiguità nell interpretazione, astratta in quanto si concentra su alcuni aspetti dell oggetto reale, tralasciandone intenzionalmente altri. Si consideri come esempio il progetto tecnico di una casa: è espresso secondo delle regole formali, altrimenti la realizzazione sarebbe lasciata alla libera interpretazione dei costruttori, e astrae da alcuni particolari, tanto che possono esistere piú modelli per la stessa casa, focalizzati su particolari aspetti (impianto elettrico, mura, arredamento). Da queste considerazioni intuiamo come i metadati possano essere considerati un modello dei dati: sono infatti una descrizione astratta del dato e sono rappresentati secondo regole formali, le quali garantiscono che ogni tool in grado di comprenderle sia anche in grado di interpretare i metadati in maniera non equivoca. La definizione del linguaggio formale per descrivere i modelli (o metadati) può essere considerato un modello di modello, ovvero un meta-modello dei dati descritti. A titolo di esempio individuiamo i concetti appena delineati in un contesto relazionale: distinguiamo innanzitutto i dati memorizzati nel database, come i nomi dei dipendenti o i prezzi della merce, e il modello che li descrive, ovvero i metadati, come i nomi delle tabelle, delle colonne, delle relazioni. In figura 2.9 è rappresentato, in notazione UML, il metamodello che definisce una tabella come un insieme di colonne; una sua istanza permette di descrivere una particolare tabella relazionale. I meta-modelli sono solitamente indipendenti dalle caratteristiche fisiche

38 28 CAPITOLO 2. I METADATI Figura 2.9: Esempio di meta-modello della piattaforma che sviluppa la struttura informativa; ne concludiamo che i metadati, se descritti con un meta-modello indipendente dalla piattaforma, possono esistere al di fuori di una particolare infrastruttura fisica, ed essere solo successivamente tradotti in modelli specifici per una particolare piattaforma L approccio model-driven L approccio ideale al problema dell integrazione consiste dunque nello sviluppare una rappresentazione esterna dei metadati, non dipendente da un particolare prodotto, a cui i singoli tool possono interfacciarsi. Il ponte di traduzione dal formato proprietario di un prodotto al meta-modello universalmente compreso può essere implementato dagli sviluppatori all interno del tool, una volta per tutte, diminuendo in maniera decisiva l onere per l azienda cliente. Si noti come non si obblighino i singoli prodotti ad adottare internamente il meta-modello condiviso; ciascuno infatti può avere il proprio formato di memorizzazione dei metadati, ottimizzato a seconda delle proprie esigenze, e sviluppare quindi un ponte verso lo standard. É necessario assicurarsi che il meta-modello condiviso sia semanticamente completo, ovvero sia in grado di fornire una descrizione astratta di tutti gli oggetti di un particolare dominio di interesse, ed al più mettere a disposizione dei meccanismi di estensione per trattare ulteriori esigenze informative richieste dalla rappresentazione interna di un particolare prodotto. Per essere universalmente compreso deve inoltre essere costruito secondo delle regole formali; se i prodotti coinvolti ne condividono la conoscenza sono in grado di interpretare istanze di queste regole, ovvero ogni metadato descritto

39 2.2. I METADATI NEL DATA WAREHOUSE 29 da esse. L approccio presentato segue queste linee guida ed è denominato model-driven (figura 2.10). Figura 2.10: Approccio Model-Driven Siamo quindi in grado di delineare i requisiti di un sistema in grado di gestire i metadati presenti nel Data Warehouse e di permettere ai prodotti coinvolti di scambiarsi le informazioni per poter interoperare, secondo un approccio model-driven. É fondamentale distinguere la strategia di gestione dei metadati da quella volta all integrazione. La prima determina quali tool sono responsabili della creazione, pubblicazione, memorizzazione, controllo e gestione dei metadati. La seconda si preoccupa di definire come i vari prodotti possono scambiarsi i metadati e le informazioni associate. Si elencano dunque le componenti di una tale architettura: 1. un linguaggio formale in grado di specificare i metadati in termini di modelli condivisi e indipendenti dalla piattaforma 2. un meta-modello comune che descrive il dominio di interesse: i modelli condivisi e scambiati tra le applicazioni sono istanze di questo metamodello. 3. un formato comune di scambio dei metadati

40 30 CAPITOLO 2. I METADATI 4. una interfaccia per l accesso ai metadati 5. meccanismi standard per estendere i modelli 6. meccanismi standard per estendere il meta-modello 7. software per l importazione/esportazione dei metadati verso i singoli prodotti 8. una strategia generale di gestione dei metadati 9. (opzionale) un repository centrale dei metadati; come descritto nella sezione precedente. 10. un architettura tecnica dei meta dati: descrive come è realizzata la strategia. I punti dall 1 al 6 riguardano l approccio alla integrazione, i punti 8 e 9 trattano la strategia di gestione dei metadati, il punto 10 concerne infine l implementazione fisica della strategia. La realizzazione di un approccio model-driven, soluzione al problema dell integrazione, è indipendente dalla configurazione fisica della architettura che realizza la gestione dei metadati, che puó essere point to point o hub and spoke; il progettista può dunque effettuare le proprie scelte architetturali (punto 10 ) guidato soltanto dalla strategia di gestione dei metadati adottata (punto 9 ), non da problemi di integrazione tra i vari prodotti. Conclusioni Nel presente capitolo è stato introdotto il concetto di metadato, contestualizzandolo nella realtà aziendale e in un sistema di Data Warehouse. In particolare abbiamo illustrato l importanza che i prodotti che svolgono diversi compiti di un processo possano interoperare. E necessario a tal scopo garantire una integrazione dei metadati tra i vari tool, requisito che può essere risolto in diversi modi; abbiamo dunque evidenziato come l approccio

41 2.2. I METADATI NEL DATA WAREHOUSE 31 denominato Model Driven, fondato su una rappresentazione esterna ed indipendente dei metadati, sia il più conveniente. Nel successivo capitolo si analizza come lo standard CWM sia una soluzione model-driven alla integrazione dei metadati, che lascia al progettista piena libertà nello sviluppo del repository, della strategia e dell architettura realizzativa.

42 32 CAPITOLO 2. I METADATI

43 Capitolo 3 Common Warehouse Metamodel Il capitolo descrive il Common Warehouse Metamodel, standard per la rappresentazione e lo scambio dei metadati nei contesti del Data Warehouse e della Business Analysis. La sezione 3.1 offre una breve introduzione storica, a cui segue, in sezione 3.2, una panoramica delle tecnologie fondanti. La sezione 3.3 descrive dunque il meta-modello CWM e come sia in grado di rappresentare l intero dominio di interesse, la sezione 3.4 mostra invece come il Common Warehouse Metamodel sia la realizzazione di un approccio modeldriven alla integrazione dei metadati di un sistema di Data Warehouse. Infine la sezione 3.5 illustra come lo standard possa essere utilizzato per ottenere interoperabilità tra prodotti diversi. OMG e CWM L Object Management Group (OMG) è un consorzio creato nel 1989 dall intesa di undici aziende, tra cui Hewlett-Packard, IBM, Sun Microsystems, Apple Computer, American Airlines e Data General con l obiettivo di creare un sistema di gestione di un architettura distribuita, tramite la standardizzazione e la promozione di software orientato agli oggetti. Si è proposta dunque di specificare standard per ogni aspetto riguardante i sistemi dis- 33

44 34 CAPITOLO 3. COMMON WAREHOUSE METAMODEL tribuiti, dalle fasi di analisi e progettazione alle strutture e infrastrutture fisiche. Tra i principali standard prodotti, solo alcuni dei quali d interesse per la presente tesi, menzioniamo CORBA, UML, MOF, XMI. Ogni specifica è disponibile gratuitamente al sito Il Common Warehouse Metamodel(CWM) è uno standard adottato dall Object Management Group (OMG) per la condivisione dei metadati nei contesti del Data Warehouse e della Business Analysis. Fornisce un linguaggio comune per la descrizione dei metadati, fondato su un meta-modello generico ma semanticamente completo e su un formato di scambio basato su XML. CWM ha rapidamente guadagnato consenso ed è stato incorporato in numerosi prodotti e tool. 3.1 Breve storia del CWM Una quantità consistente di storia nel campo dell integrazione dei metadati precede l adozione del Common Warehouse Metamodel. Contemporaneamente ai primi lavori di sviluppo del CWM videro la luce altri tentativi di soluzione al problema. Nel 1993 l Electronics Information Group pubblicò il CASE Data Interchange Format (CDIF), uno standard per lo scambio di metadati generato dai CASE tool che non ebbe il consenso sperato. Nel 1995 un gruppo di aziende leader fondarono la Meta Data Coalition(MDC), che nel 1996 rilasciò la Meta Data Interchange Specification(MDIS), un meccanismo di scambio dei dati consistente di un meta-modello condiviso, un linguaggio per specificare istanze di metadati e la definizione di interfacce per accedervi. Si rivelò scarsamente applicabile in quanto focalizzato soltanto sul contesto di schemi database e basato su specifiche proprietarie (in contrasto con l adozione di UML e XML da parte di CWM). L importanza di MDIS fu comunque notevole nel definire un approccio basato su un meta-modello condiviso e un linguaggio di scambio tag-oriented. Negli stessi anni la Microsoft Corporation sviluppava l Open Information Model (OIM), fondato su UML, la cui prima versione fu resa disponibile nel Nel 1999 numerose

45 3.2. TECNOLOGIE FONDANTI 35 aziende membri dell OMG, in risposta a un RFP (Request For Proposal) pubblicato dalla stessa, decisero di collaborare allo sviluppo di un progetto di condivisione dei metadati nell ambito del Data Warehouse. Nel dicembre 1998 Microsoft diventó membro della MDC proponendo di sviluppare ulteriormente il progetto OIM. Il settore si trovó di fronte a due standard simili e concorrenti; l adozione di uno o l altro da parte dei vari prodotti avrebbe compromesso l idea di una integrazione universale dei metadati. Analizzando le differenze tra i due standard, OIM proponeva l integrazione dei metadati nell intero contesto aziendale, incluse le architetture informatiche, elementi di analisi e progettazione dei sistemi, database, Data Warehouse, gestione della conoscenza. CWM si focalizzava invece sugli ambiti del Data Warehouse e della Business Analysis, ovvero i contesti che maggiormente beneficiano (in termini di ROI) di una riuscita integrazione dei metadati. Cominciò una serie di trattative e di accordi tra i due gruppi, auspicando anche lo sviluppo di un meccanismo di traduzione da uno standard all altro. Nel Giugno 2000 tuttavia i membri della MDC decisero di interrompere lo sviluppo del proprio standard e di focalizzarsi su CWM; il settore ebbe finalmente un unico standard model-driven per la integrazione dei metadati, supportato da un gran numero di vendor. 3.2 Tecnologie fondanti Il Common Warehouse Metamodel si fonda sulle seguenti tecnologie OMG: 1. Unified Modeling Language (UML) per definire il meta-modello condiviso in grado di descrivere i metadati. 2. extensible Markup Language (XML) per definire il formato di scambio 3. CORBA Interface Definition language (IDL) per generare le interfacce che permettono l accesso ai metadati. Le definizioni del formato di scambio e delle interfacce si affidano al linguaggio Meta Object Facility (MOF), in particolare si basano rispettivamente su XMI

46 36 CAPITOLO 3. COMMON WAREHOUSE METAMODEL (XML Meta Data Interchange) e sulle mappature da MOF a IDL. Java è finora stata la piattaforma più usata per implementare CWM. Nelle sezioni successive illustriamo i concetti fondamentali relativi alle tecnologie UML, XML, XMI e MOF UML UML, acronimo di Unified Modeling Language, è un linguaggio per specificare, visualizzare, costruire e documentare le componenti di un sistema software; consiste di elementi di costruzione e vincoli su essi. I primi sono concetti tipicamente Object-Oriented come classi, oggetti, interfacce, e relazioni tra essi. UML definisce inoltre un insieme di simboli grafici usati per rappresentare tali elementi, per cui vi sono diagrammi di classi, di oggetti, diagrammi use-case ecc. I vincoli assicurano che un modello rispetti le regole sintattiche e semantiche definite da UML; le seconde in particolare sono espresse mediante il linguaggio Object Costraint Language (OCL). UML può essere utilizzato per esprimere vari aspetti di un sistema: strutturali, funzionali e comportamentali. Per descrivere i metadati sono sufficienti i costrutti di modellazione statica e strutturale, i cui elementi fondamentali sono le classi, gli oggetti, gli attributi e le operazioni. Una classe è la descrizione di un insieme di oggetti che condividono gli stessi attributi, operazioni e semantiche; possiede attributi che ne descrivono gli oggetti istanza e operazioni che li manipolano. Gli attributi sono caratterizzati da un nome, una visibilità e un tipo, che può essere un tipo primitivo oppure un altra classe. Una operazione invece è descritta da un nome, un tipo, zero o più parametri e una visibilità. Le relazioni definibili tra queste strutture statiche sono l associazione, distinguibile nei casi particolari di aggregazione e composizione, la generalizzazione e la dipendenza. Non dedicheremo ulteriore spazio alla descrizione di tali costrutti, che presumiamo già ben noti al lettore. Aggiungiamo però che UML li organizza in gruppi semanticamente correlati mediante l utilizzo di package, entità in grado di possedere elementi, ciascuno dei quali non può essere posseduto da più di un package. É possibile

47 3.2. TECNOLOGIE FONDANTI 37 però per un package importarne altri, ovvero aggiungere ai propri contenuti il contenuto pubblico di quello importato. CWM è basato su un sottoinsieme della versione 1.3 di UML, adottata dall OMG nel 1999; ne utilizza le semantiche del meta-modello e la sintassi grafica per specificarle MOF Affinché i modelli siano universalmente compresi è fondamentale che anche i meta-modelli siano definiti secondo delle regole formali, che nel caso di CWM sono fornite dal linguaggio Meta Object Facility (MOF). MOF é uno standard OMG che definisce un linguaggio astratto per rappresentare meta-modelli; si tratta dunque di un modello di meta-modello, definibile anche come metameta-modello. Sia CWM sia UML sono definiti tramite la sintassi MOF, col vantaggio che meta-modelli dissimili e referenti ad ambiti diversi possono essere acceduti anche senza particolare conoscenza del dominio, attraverso delle apposite interfacce generiche (denominate reflective interfaces ). Se poniamo i dati come la realtà concreta, i metadati come un primo livello di astrazione e i meta-modelli come un secondo, MOF si posiziona su un terzo livello di astrazione. Tale visione è esemplificata nella tabella 3.1, in cui un elemento appartenente a un particolare livello è un istanza del livello immediatamente superiore. Meta-Livello Termine MOF Esempi M3 Meta-meta-modello Modello MOF M2 Meta-modello Meta-modello UML, Meta-modello CWM M1 Modello, metadato Modello UML M0 Dato Sistema modellato, dato del DW Tabella 3.1: Livelli di astrazione Il meta-meta modello delineato da MOF (denominato Modello MOF ) è organizzato in package, all interno dei quali gli elementi sono definiti in

48 38 CAPITOLO 3. COMMON WAREHOUSE METAMODEL termini di sintassi astratte (diagrammi di classe), regole di buona formazione (espresse in OCL) e semantiche espresse in linguaggio naturale. Nella definizione del linguaggio MOF i progettisti hanno scelto di riutilizzare la stessa sintassi di UML, in virtù della sua qualità espressiva e della sua già notevole diffusione nella comunità informatica. I costrutti MOF si pongono però ad un livello di astrazione superiore, in cui gli oggetti modellati non risiedono a livello M1 (metadati) bensì al livello dei meta-modelli (M2 ). Per comodità, nella presente tesi denomineremo meta-modelli MOF quei meta-modelli che sono istanze del meta-meta modello MOF, metadati MOF invece i metadati che sono istanze di meta-modelli MOF. CWM si fonda su MOF 1.3, adottato dall OMG nel settembre 1999, la cui specifica consiste di tre parti: il modello MOF, le reflective interfaces, che permettono a un programma di accedere ai metadati senza utilizzare interfacce specifiche di un meta-modello, e le mappature MOF-IDL, che specificano come mappare un meta-modello MOF in CORBA IDL, permettendo così la generazione automatica di interfacce specifiche di un meta-modello. MOF definisce cinque tipi di meta-oggetti, di livello M1, che rappresentano i metadati per consentirne l accesso e la manipolazione; instance, classproxy, association, package e packagefactory. Sono condivisi sia dalle reflective interfaces che dalle mappature MOF-IDL; le relazioni tra essi sono mostrate in figura 3.1. Analizziamo dunque come possono essere rappresentate le entità di livello M1 ; una ipotetica istanza A di un package a livello M2 sarà rappresentata con un meta-oggetto package, che fornisce accesso a una serie di meta-oggetti descritti dal meta-modello. In particolare saranno definiti: un attributo di tipo package per ogni package di livello M2 incluso nel package A un attributo di tipo classproxy per ogni classe di livello M2 nel package A

49 3.2. TECNOLOGIE FONDANTI 39 Figura 3.1: Meta-oggetti a livello M1 un attributo di tipo association per ogni associazione di livello M2 nel package A Un meta-oggetto package è ottenuto invocando una operazione di creazione su un meta-oggetto PackageFactory. Un meta-oggetto classproxy è invece un contenitore di meta-oggetti instance e fornisce operazioni per la loro creazione e accesso. Le istanze di una classe di livello M2 sono rappresentate da oggetti instance, che forniscono operazioni per accedere ai propri attributi, operazioni, associazioni. Infine, poiché una associazione di livello M2 non è rappresentata da un oggetto, un meta-oggetto association di livello M1 possiede una serie di collegamenti che la rappresentano, ed include operazioni per creare, modificare, cancellare tali collegamenti. MOF reflective interfaces Permettono a un programma di creare, modificare e invocare operazioni sui meta-oggetti instance di livello M1, di modificare i collegamenti sui meta-oggetti association e navigare la struttura dei meta-oggetti package;

50 40 CAPITOLO 3. COMMON WAREHOUSE METAMODEL tutte operazioni invocabili senza l utilizzo di interfacce specifiche di un metamodello. Includono quattro interfacce astratte. RefBaseObject: fornisce operazioni comuni per tutti i meta oggetti di livello M1. Da essa ereditano RefBaseObject, RefObject, RefAssociation, RefPackage. RefObject: fornisce operazioni comuni per tutti i meta-oggetti instance e classproxy RefAssociation: operazioni comuni per i meta-oggetti association. RefPackage: operazioni comuni per i meta-oggetti package. Mappature MOF-IDL Definiscono la mappatura standard da un meta-modello MOF alle interfacce CORBA IDL; le interfacce risultanti permettono a un utente di creare e accedere le istanze del meta-modello (ovvero i meta-oggetti di livello M1 ). La figura 3.2 mostra, a sinistra, un esempio di meta-modello composto da un package P1 contenente due classi C1 e C2 e una associazione A, a destra invece un grafo rappresentante le corrispondenti interfacce generate. La radice del grafo è il gruppo di quattro interfacce che compongono le reflective interface, analizzate in precedenza. Si nota dunque come le interfacce di meta-oggetti package ereditino da RefPackage, quelle di meta-oggetti association da RefAssociation, quelle di meta-oggetti classproxy da RefObject e infine quelle di oggetti instance dalle interfacce del classproxy contenitore. Se inoltre una classe C2 a livello M2 eredita da una classe C1, sempre a livello M2, allora ereditano anche i corrispondenti meta-oggetti instance e classproxy. Poiché le interfacce generate ereditano dalle Reflective Interface, le operazioni generali precedentemente descritte sono utilizzabili anche dalle interfacce specifiche. Come evidenziato in figura 3.2 le regole di mappatura MOF-IDL sono definite con l assunzione che vi sia un package di livello M2 che contenga tutto il resto, e che i suoi contenuti siamo mappati in CORBA IDL come un unità singola.

51 3.2. TECNOLOGIE FONDANTI 41 Figura 3.2: Meta-modello di esempio e interfacce XML XML, acronimo di extensible Markup Language, è un meta-linguaggio creato e gestito dal World Wide Web Consortium (W3C), ovvero un linguaggio che permette di definire la grammatica di diversi linguaggi specifici derivati, utili per la memorizzazione o lo scambio di dati. CWM utilizza XML 1.0, adottato dal W3C nel Febbraio 1999, la cui specifica definisce le strutture fisiche e logiche che costituiscono un documento XML e le regole grammaticali che possono essere definite per vincolare tali strutture. Fisicamente un documento è composto da unità denominate entità, logicamente è composto da elementi, dichiarazioni, commenti, riferimenti e istruzioni. Gli elementi sono specificati da un etichetta di apertura e una di chiusura o, nel caso siano vuoti, da un etichetta unica; ciascuno ha un tipo, identificato da un nome, e un insieme di attributi, caratterizzati da una coppia <nome,valore>. Il testo compreso tra le etichette di apertura e chiusura è chiamato contenuto e

52 42 CAPITOLO 3. COMMON WAREHOUSE METAMODEL può essere solo testuale oppure consistere a sua volta di altri elementi. I documenti cominciano con una dichiarazione che specifica la versione di XML, seguita generalmente da un riferimento a una risorsa denominata Document Type Declaration (DTD) che, utilizzando la sintassi XML, fornisce le regole sintattiche per una determinata classe di documenti. Tali regole includono la dichiarazione dei tipi degli elementi utilizzabili, la lista di attributi che possono possedere e limitazioni sul tipo del loro contenuto. Qualora la struttura del documento rispetti le regole definite nel DTD a cui si riferisce è considerato valido. Poiché un documento XML tipicamente contiene elementi e attributi che saranno usati da un grande numero di sistemi software, vi sono frequentemente problemi di collisione di nomi. I namespace XML forniscono il meccanismo che permette ai tipi degli elementi di avere nomi universali; i nomi contengono infatti un prefisso, che seleziona il namespace, e una parte locale XMI XMI è uno standard che specifica come sia possibile esprimere in formato XML meta-modelli e metadati, garantendo così la possibilità di scambio di tali informazioni tra applicazioni che comprendono il linguaggio XML. XMI si presenta come una coppia di mappature: la prima tra i meta-modelli MOF e documenti XML/DTD, la seconda tra metadati MOF e documenti XML. La specifica XMI 1.1 consiste dunque delle seguenti componenti: mappatura meta-modello MOF - DTD: regole per trasformare i metamodelli MOF in documenti XML/DTD. regole XML/DTD: regole per la creazione del documento XML/DTD. mappatura metadati MOF - XML: regole per la codifica e decodifica dei metadati MOF in documenti XML. regole XML: regole per la creazione dei documenti XML.

53 3.3. STRUTTURA DEL META-MODELLO 43 La validazione di un documento XML secondo il DTD rappresentante il metamodello di riferimento garantisce che i metadati espressi siano conformi ad esso, pertanto potranno essere compresi da qualsiasi tool che abbia conoscenza del meta-modello. Illustriamo brevemente le regole che mappano un meta-modello MOF in un documento DTD: ogni classe del meta-modello è rappresentata da un elemento XML con lo stesso nome, la definizione dell elemento ne specifica possibili attributi e relazioni. Ogni attributo di una classe del meta-modello è rappresentato come un elemento XML dello stesso nome o, qualora sia di tipo primitivo o enumerazione, come un attributo XML. Le associazioni infine sono rappresentate mediante due elementi XML, che ne specificano gli estremi. La figura 3.3 mostra un semplice modello espresso in notazione UML e la relativa mappatura a un documento XML secondo le regole definite da XMI. L utilizzo di XML offre i vantaggi di una comunicazione asincrona e di contenuti in grado di auto-descriversi, particolarmente adatta quindi ad ambienti eterogenei e distribuiti. 3.3 Struttura del meta-modello CWM é la realizzazione di un paradigma di integrazione dei metadati modeldriven e fornisce sia la sintassi sia la semantica necessaria a descrivere i metadati nei contesti del Data Warehouse e della Business Analysis. La tabella 3.2 mostra come l architettura OMG, precedentemente illustrata in tabella 3.1 a pagina 37, è mappata alla realtà CWM e alle tecnologie utilizzate. Riprendendo la metafora della casa, i mattoni o i tubi corrispondono al livello M0, il progetto di un particolare edificio al livello M1, il meta-modello CWM corrisponde ad un archivio contenente molti piani per vari edifici. É importante prendere consapevolezza di come sia l aderenza a questo tipo di architettura che permette a CWM di essere un meta-modello indipendente da particolari vendor o piattaforme. Procediamo con una descrizione del meta-modello CWM e di come perme-

54 44 CAPITOLO 3. COMMON WAREHOUSE METAMODEL Figura 3.3: Modello UML e rappresentazione in file XML Meta-Livello Componente OMG CWM Esempio edile M3 MOF, XMI MOF,XMI Archivio dei progetti M2 UML, XMI CWM, XMI Classe di progetti M1 XMI file clienti Progetto di costruzione M0 Sistema di memorizzazione Mario Rossi Mattoni Tabella 3.2: Livelli CWM

55 3.3. STRUTTURA DEL META-MODELLO 45 tta la rappresentazione dell intero dominio di interesse; mostreremo dunque come CWM sia realmente la realizzazione di un approccio model-driven alla integrazione dei metadati, ovvero come soddisfi i primi sei requisiti elencati nel capitolo 2 a pagina 29. Il meta-modello CWM si compone di un certo numero di meta-modelli indipendenti (chiamati package): ciascuno rappresenta un sotto-dominio dell area di interesse, ovvero le sue istanze sono metadati che descrivono dati appartenenti al sotto-dominio rappresentato. Il diagramma a blocchi in figura 3.4 ne descrive l organizzazione in livelli. La suddivisione in piccoli metamodelli ha indubbi benefici specialmente nel rendere più semplice la comprensibilità e l implementazione del meta-modello globale, che può essere effettuata in maniera incrementale. La maggior parte delle entità presenti nei meta-modelli ereditano da altre entità, magari possedute da package diversi; tale situazione, sviluppata per evitare ridondanza di costrutti, genera dipendenze tra i package. Essi sono organizzati in cinque livelli, in modo tale che un package possa dipendere soltanto da package situati in livelli sottostanti; per comprenderne uno è sufficiente analizzare quelli da cui esso dipende, ignorando i restanti. Il meta-modello CWM permette, a prescindere dalla reale esistenza dei dati, di effettuare una descrizione del dominio in maniera indipendente da una particolare piattaforma, tecnologia o prodotto. Illustriamo dunque i singoli package e descriviamo per ciascuno il sottoinsieme del contesto rappresentato. I package CWM Come specificato nel capitolo precedente, è fondamentale disporre di un linguaggio formale e condiviso per descrivere i metadati; CWM utilizza un sottoinsieme di UML, estendendolo per includere concetti tipici degli ambiti del Data Warehouse e della Business Analysis. Corrisponde al livello più basso del diagramma in figura 3.4, chiamato Object Model. É suddiviso in quattro meta-modelli e rappresenta la base dell intero meta-modello CWM. Il metamodello Core definisce gli elementi statici fondamentali del linguaggio UML,

56 46 CAPITOLO 3. COMMON WAREHOUSE METAMODEL Figura 3.4: Il meta-modello CWM come classi e attributi, estesi da tutti gli altri package CWM. Il meta-modello Behavioural permette di rappresentare aspetti comportamentali come operazioni e procedure. Il meta-modello Relationship definisce le relazioni fondamentali tra elementi, mentre il meta-modello Instance definisce elementi che rappresentano istanze attuali di altri elementi (ad esempio un oggetto di una classe). CWM utilizza il concetto di ereditarietà per estendere gli elementi dei package di base appena descritti e definire nuovi elementi in grado di rappresentare interamente i contesti di interesse. Continuiamo dunque con l esaminare i livelli superiori del diagramma in figura 3.4. Il livello denominato Foundation permette di descrivere caratteristiche comuni a tutte le componenti del contesto di Data Warehouse. Il metamodello Data Types definisce i tipi fondamentali, mentre il meta-modello Type Mapping permette di relazionare differenti sistemi di tipi (fondamentale per garantire interoperabilità tra tool diversi). Il meta-modello Keys and Indexes introduce i concetti di chiavi uniche, chiavi esterne e vincoli di ordinamento su insiemi di dati. Si vuole evidenziare come il concetto di chiave unica sia derivabile per rappresentare, ad un livello superiore, i concetti di chiave

57 3.3. STRUTTURA DEL META-MODELLO 47 primaria sia in un database relazionale sia in uno multidimensionale. Il metamodello Business Information permette di rappresentare concetti fondamentali del business, mentre il meta-modello Software Deployment consente di relazionare un modello logico ai nodi di una piattaforma distribuita. Infine il meta-modello Expression consente di costruire espressioni strutturate. Il livello successivo, denominato Resource, permette di definire risorse dati come database relazionali, database record-oriented, server multidimensionali o documenti XML. I concetti tipici dell analisi di business sono rappresentati dai meta-modelli che compongono il livello denominato Analysis. Il meta-modello Transformation permette di definire sorgenti, destinazioni e regole di trasformazioni tra diversi modelli di dati, anche appartenenti a diversi livelli di astrazione; ad esempio è possibile relazionare un modello logico OLAP (definito con il meta-modello OLAP) con il modello fisico di uno star schema relazionale (definito con il meta-modello relational). I meta-modelli data mining, information visualization e business nomenclature forniscono i costrutti semantici necessari a definire metadati relativi alle fasi di analisi. Il primo permette di descrivere metadati associati a tool di data mining, utilizzati sulle risorse dati per ricavare informazioni rilevanti ai fini del business. Il meta-modello information visualization definisce metadati riguardanti tool di visualizzazione e report, mentre il meta-modello business nomenclature definisce metadati relativi alla definizione di concetti di business e la loro organizzazione in tassonomie. Infine il livello Management offre una vista del Data Warehouse nel suo insieme, dall estrazione all analisi. Il meta-modello warehouse process permette di definire processi specifici del contesto, come l ETL (Extraction Transformation Loading) o il delivery, mentre il meta-modello warehouse operation permette di rappresentare le operazioni specifiche o periodiche del sistema. Non ci addentriamo nel dettaglio di ogni singolo package, in quanto ne risulterebbe una descrizione lunga e non rilevante ai fini della tesi. Illustriamo però, a titolo di esempio, il meta-modello Core, dal quale dipendono tutti

58 48 CAPITOLO 3. COMMON WAREHOUSE METAMODEL gli altri, e mostriamo come le entità fondamentali sono estese per descrivere l intero dominio. Core Package Il package Core contiene classi e associazioni utilizzati da tutti gli altri package CWM, pertanto non dipende da alcuno. La figura 3.5 ne identifica le classi principali. Ogni classe CWM è per definizione sottoclasse di Element, che non fornisce attributi nè servizi ma ha il ruolo di padre comune, quasi tutte sono inoltre sottoclassi di ModelElement, che fornisce attributi base, come il nome, e serve da punto di connessione tra le altre classi. Ad esempio la classe Costraint, che definisce regole limitanti il comportamento degli oggetti CWM, possiede una associazione a Model Element indicante gli elementi a cui il vincolo si applica. In tal modo è possibile definire vincoli per ogni sottoclasse di ModelElement. Questo approccio vale per tutti i servizi CWM che si applicano ad entità dotate di un nome, ovvero sottoclassi di ModelElement: ad esempio Dependency, TaggedValue, Stereotype. Numerose realtà dei sistemi informatici possono essere considerate entità strutturate, ad esempio le tabelle di database relazionali, record in file strutturati, gerarchie di una dimensione OLAP; il package Core permette di descriverle. I singoli oggetti di una entità strutturata, ad esempio le colonne di una tabella relazionale, sono denominate feature e sono rappresentate dalla classe Structural Feature o, qualora abbiano un valore iniziale, dalla classe Attribute. La classe Classifier rappresenta qualsiasi entità dotata di struttura ed è in grado di possedere zero o più oggetti Feature. La nozione di classifier è simile all idea di tipo utilizzata nei moderni linguaggi di programmazione; la classe StructuralFeature è legata mediante due associazioni a Classifier: la prima, denominata classifierfeature, permette ad un oggetto istanza di Classifier di possedere oggetti Feature, ad esempio consente a una tabella relazionale di possedere colonne. La seconda invece, denominata StructuralFeatureType, indica il tipo della particolare Feature, che può essere primitivo o composto. La classe Class rappresenta Clas-

59 3.3. STRUTTURA DEL META-MODELLO 49 Figura 3.5: Package Core

60 50 CAPITOLO 3. COMMON WAREHOUSE METAMODEL sifier che possono avere istanze multiple; ad esempio le tabelle relazionali sono sottoclassi di Class in quanto possono contenere righe di dati multiple. La classe Namespace permette agli oggetti individuali di essere identificati univocamente dal loro nome; l associazione elementownership permette ad un istanza di Namespace di contenere un oggetto Model Element, che può essere a sua volta un altro Namespace, consentendone così una organizzazione gerarchica. Tuttavia un oggetto ModelElement può essere posseduto dal al più un solo Namespace; per permettere dunque a ModelElement di accedere a oggetti contenuti esternamente al namespace di appartenenza è stata creata la classe Package, sottoclasse di Namespace, che aggiunge la capacità di importare oggetti ModelElement. Descriviamo dunque come CWM estende i concetti appena presentati per rappresentare l intero contesto del Data Warehouse. Ereditarietà per massimizzare il riuso Secondo la nozione Object-Oriented di ereditarietà la sottoclasse acquisisce attributi, operazioni e associazioni delle classi superiori; si rivela un meccanismo particolarmente utile per gestire la complessità del meta-modello in maniera intuitiva ed esplicativa. Infatti le classi del livello Object Model individuano le principali tipologie di classi dell intero sistema definendone attributi, operazioni e associazioni; pertanto i meta-modelli appartenenti ai livelli superiori sono in grado di specializzarsi nel loro ambito e riutilizzare le relazioni definite dalle super-classi. La figura 3.6 mostra come la classe che definisce lo schema relazionale, in quanto sottoclasse di Package, erediti l associazione elementownership e sia quindi in grado di possedere più tabelle; similmente la classe che definisce le tabelle eredita da Classifier la associazione ClassifierFeature e può quindi possedere colonne. I vincoli, definiti in linguaggio OCL, impediscono associazioni insensate, ad esempio che uno schema XML possa possedere una colonna relazionale. Il riuso di nomi di classi non è proibito, in quanto le regole definite da

61 3.3. STRUTTURA DEL META-MODELLO 51 Figura 3.6: Riuso di associazioni MOF richiedono che tutti i nomi siano identificati anche dal package in cui occorrono, prevenendo così il rischio di collisioni. Ampliamo dunque la visuale alle altre risorse dati esprimibili con CWM, le figure 3.7 e 3.8 mostrano due diagrammi di sequenza che descrivono le chiamate alle funzioni di ipotetiche interfacce per creare rispettivamente una tabella relazionale e un istanza di un file strutturato. Precisiamo che la specifica CWM non comprende tali interfacce, esse sono un esempio di mappatura del meta-modello a delle interfacce specifiche. Le entità strutturate modellate nell esempio contengono una feature Nome su cui è definito un vincolo di chiave unica. Con le figure 3.7 e 3.8 si vuole evidenziare che le sole differenze tra le due modalità di creazione sono nei tipi degli oggetti creati, mentre la struttura e le funzioni chiamate sono le stesse. Infatti sia una tabella relazionale che un file strutturato sono rappresentati da classi sottotipi di Classifier, pertanto ereditano un associazione verso la classe Feature, di cui sono sottotipi le classi rappresentanti rispettivamente una colonna relazionale o un campo di file. Non è dunque necessario definire una associazione speciale per collegare una tabella alle sue colonne, o un file strutturato ai suoi campi. Lo stesso riuso è evidenziato dalla creazione di una chiave primaria, in quanto la classe UniqueKey del package Keys and Indexes definisce una relazione alla classe StructuralFeature.

62 52 CAPITOLO 3. COMMON WAREHOUSE METAMODEL Figura 3.7: Use case relazionale Figura 3.8: Use case file strutturato

63 3.3. STRUTTURA DEL META-MODELLO 53 Riassumendo, CWM astrae le caratteristiche che sono comuni a più entità del contesto di interesse e le raggruppa in un unico package fondante; sono dunque ereditate dalle classi e riutilizzate in molte altre definizioni di entità. I vantaggi di un simile approccio sono principalmente due: innanzitutto le dipendenze tra package diversi sono minimizzate allo stretto necessario, e gli utenti di CWM possono così focalizzare l attenzione soltanto sulle porzioni del meta-modello strettamente necessarie. In secondo luogo si ottiene la cosiddetta equivalenza tra classifier, ovvero tutte le entità di tipo Classifier e Feature sono create sfruttando le stesse chiamate di funzioni. La figura 3.9 evidenzia l equivalenza esistente tra i concetti di schema relazionale, schema multidimensionale, schema XML e file strutturato, le cui classi rappresentanti sono sottoclassi di Package del livello ObjectModel. Vi è poi equivalenza tra i concetti di tabella relazionale, dimensione, elemento XML, rappresentati da classi che ereditano da Classifier, infine vi è equivalenza tra i concetti di colonna relazionale, campi di file, attributi XML, rappresentati da classi ereditate da Feature. Grazie a tali equivalenze la definizione del meta-modello diventa più semplice e comprensibile all utente, che una volta capito il funzionamento di un package può, con minimo sforzo, comprendere i restanti. Figura 3.9: Equivalenza tra classifier

64 54 CAPITOLO 3. COMMON WAREHOUSE METAMODEL Meccanismi di estensione I progettisti del meta-modello CWM hanno dovuto affrontare la realizzazione di uno standard che, per garantire l effettiva utilizzabilità ai fini dell integrazione tra vari prodotti, fosse semanticamente completo nel descrivere il dominio di interesse; tuttavia un eccessivo grado di dettaglio ne avrebbe complicato l adozione, pertanto si è scelto di non comprendere la descrizione di alcune caratteristiche del dominio, in particolare quelle più legate alla fisicità dei sistemi e quindi necessariamente dipendenti da un particolare prodotto o piattaforma. CWM fornisce dei meccanismi grazie ai quali è possibile estendere i modelli o il meta-modello, per venire incontro a particolari esigenze informative non esplicitamente trattate. Una tecnica di estensione dei meta-modelli CWM particolarmente efficace è l ereditarietà. Il secondo volume della specifica CWM include un package Entity-Relationship costruito secondo tale principio, le cui entità permettono la modellazione di schemi entità-relazione (ER); la figura 3.10 ne mostra alcune classi, ereditate da classi CWM. A parte RelationshipEnd e Domain le estensioni sono sotto-classi delle corrispondenti CWM e, non aggiungendo attributi, hanno la semplice funzione di rinominare la classe CWM al fine di utilizzare una terminologia comprensibile agli utenti che conoscono la modellazione ER; nel caso di Attribute, trattandosi di un termine utilizzato anche nel contesto ER, non è stato necessario ereditare. Le classi RelationshipEnd e Domain invece aggiungono degli attributi specifici della modellazione ER; inoltre sono definite due nuove associazioni, tra RelationshipEnd e ForeignKey e tra Domain e Classifier. L estensione mediante ereditarietà è espressiva ma può risultare eccessivamente pesante qualora sia necessaria solo una modifica superficiale, ad esempio l aggiunta di un attributo. Per questo motivo CWM mette a disposizione le classi TaggedValue e Stereotype, presenti nel package Core. In figura 3.11 è presentato il package Entity-Relationship formulato utilizzando questi due meccanismi invece del ereditarietà. La classe Stereotype permette di assegnare una etichetta testuale ad una classe che ne aggiunga significa-

65 3.3. STRUTTURA DEL META-MODELLO 55 Figura 3.10: Estensione mediante ereditarietà to semantico, di solito comprensibile ad utenti umani, non a sistemi software; nell esempio in figura 3.11 <<Entity>> è uno stereotipo della classe Class del package Core. Le istanze della classe TaggedValue sono coppie <nome,valore> che possono essere aggiunte a qualsiasi istanza di ModelElement; in figura 3.11 sono utilizzate per esprimere i valori di attributi specifici della modellazione ER. Un limite di tale meccanismo è che il nuovo attributo deve necessariamente essere di tipo stringa, per cui valori di tipo intero, booleano o di tipo composto devono essere convertiti in stringa per poter essere salvati e riconvertiti al tipo originario quando acceduti. Un oggetto Stereotype può possedere un insieme di oggetti TaggedValue; pertanto può, se applicato a una classe, provvedere sia alla funzionalità di rinominazione che di aggiunta di attributi. La maggiore semplicità di queste tecniche rispetto alla ereditarietà ha per contro l impossibilità di definire nuove associazioni: sono quindi consigliate soltanto qualora le estensioni da effettuare siano limitate e totalmente esprimibili da tali meccanismi. In generale l uso di esten-

66 56 CAPITOLO 3. COMMON WAREHOUSE METAMODEL Figura 3.11: Estensione mediante TaggedValue e Stereotype sioni allo standard deve essere minimizzato e, possibilmente, utilizzato dai prodotti solo per scopi interni, altrimenti l integrazione è limitata tra i tool che possiedono conoscenza semantica delle estensioni utilizzate. 3.4 L approccio model-driven di CWM In figura 3.12 sono mostrate le componenti fornite dall Object Management Group come parte della specifica CWM. Il meta-modello CWM è rappresentato graficamente da un insieme di diagrammi UML. Vi sono poi un file XML che descrive il meta-modello CWM rappresentato in notazione MOF 1.3 e un DTD che gli utenti di CWM possono utilizzare per validare documenti contenenti metadati istanze del meta-modello CWM. Infine l OMG fornisce un insieme di file che contengono una rappresentazione in IDL del meta-modello. Uno dei punti di forza dell approccio model-driven di CWM è che tutto parte dal meta-modello e, ad eccezione della specifica testuale, tutto è automaticamente generato. Qualora si intenda modificare qualcosa, è sufficiente cambiare il meta-modello e conseguentemente la specifica, mentre le modifiche sono propagate automaticamente al file XML, al DTD e alle IDL.

67 3.4. L APPROCCIO MODEL-DRIVEN DI CWM 57 Figura 3.12: La specifica CWM Intendiamo dunque evidenziare come lo standard CWM sia la realizzazione di un approccio model-driven alla integrazione dei metadati nei contesti del Data Warehouse e della Business Analysis; nella presente sezione analizziamo pertanto come i requisiti relativi alla integrazione (dall 1 al 6 ) elencati nel capitolo 2 a pagina 29 siano soddisfatti da CWM. Abbiamo già evidenziato come il dominio di interesse è interamente rappresentato; CWM fornisce dunque il meta-modello indipendente e semanticamente completo che un approccio di integrazione dei metadati model-driven richiede (requisito 2 ). Se i vari prodotti software, applicazioni e database coinvolti ne condividono la conoscenza, sono in grado di comprendere le sue istanze, ovvero i metadati, che possono essere dunque scambiati, condivisi, riutilizzati. Ogni prodotto utilizza la porzione del meta-modello globale a cui è interessato; un database relazionale, ad esempio, può leggere metadati riguardanti uno schema relazionale e utilizzarli per la costruzione di un catalogo interno, un server OLAP invece può leggere metadati concernenti uno schema multi-dimensionale insieme alle mappature delle strutture logiche (cubi, dimensioni, livelli) a quelle fisiche. Il requisito 1 impone l uso di regole formali per la definizione del meta-modello, col fine di assicurare che i vari prodotti software ne interpretino le istanze allo stesso modo: MOF, come meta-meta modello, rende disponibili tali regole. XMI fornisce il formato comune di scambio del meta-modello e delle sue istanze, come richiesto dal

68 58 CAPITOLO 3. COMMON WAREHOUSE METAMODEL requisito 3. Per garantire l accesso ai metadati (requisito 4 ), MOF definisce delle mappature formali da qualsiasi meta-modello MOF alle IDL del OMG, una notazione indipendente da particolari linguaggi per specificare interfacce di programmazione. La specifica CWM include la completa definizione delle IDL per CWM, che è possibile compilare nella sintassi di un linguaggio particolare (ad esempio Java, o C++). Infine i requisiti 5 e 6 richiedono che una soluzione alla integrazione dei metadati fornisca dei sistemi per estendere i modelli e i meta-modelli: i primi col fine di definire eventuali metadati specifici di particolari prodotti e non previsti dal meta-modello CWM, i secondi col fine di definire eventuali sotto-domini da aggiungere all intero sistema. Essendo CWM fondato su UML è possibile appoggiarsi ai meccanismi di estensione standard di UML, ovvero TaggedValue, Stereotype e Costraint, definiti nel meta-modello Core dello strato Object Model. Abbiamo dunque dimostrato come CWM rispetti tutte le caratteristiche di un approccio model-driven alla integrazione dei metadati. Vi sono però aspetti dell architettura che non sono responsabilità di CWM e che dovranno comunque essere risolti in una soluzione completa. CWM non specifica ad esempio un architettura implementativa, tutti gli elementi sono utilizzati soltanto per la creazione di interfacce per l accesso alle istanze di metadati che rappresentano: come questi siano memorizzati, importati o esportati è responsabilità dello sviluppatore. CWM non definisce inoltre la struttura di un repository e neppure una strategia di gestione dei metadati, sebbene ne influenzi notevolmente le possibili scelte architetturali, come già evidenziato nel capitolo 2. Ricordiamo infatti che il vantaggio principale offerto da CWM come meta-modello universalmente condiviso è quello di permettere allo sviluppatore di effettuare le scelte architetturali dell intero sistema concentrandosi sulle esigenze della strategia di gestione dei metadati e non su esigenze integrative.

69 3.5. L INTEGRAZIONE CON CWM L integrazione con CWM Analizziamo come il sistema può trarre vantaggio dalla integrazione a livello di metadati ottenuta mediante l utilizzo di CWM. Il fatto che sia garantita interoperabilità anche tra prodotti appartenenti a vendor differenti consente al progettista del sistema di scegliere il tool migliore per ogni area di applicazione, risparmiando i costi di una gestione separata, in quanto i prodotti possono cooperare tra loro. CWM non è stato progettato per risolvere tutti i problemi che i tool di un sistema di Data Warehouse devono affrontare, intende invece essere un massimo comune denominatore delle funzionalità offerte dai vari vendor attivi nel contesto di interesse. Per interoperare i tool devono avere una comprensione comune delle strutture e semantche dei dati scambiati, pertanto deve essere garantita innanzitutto integrazione a livello di metadati. Questa è ottenuta mediante lo scambio di modelli indipendenti da specifici prodotti o piattaforme, descritti a loro volta da un meta-modello comune. I prodotti gestiscono i propri modelli con un formato proprietario, ottimizzato secondo le proprie esigenze, che rappresenta dunque i concetti utilizzando sintassi e semantiche specifiche; è necessario dunque implementare una traduzione dal linguaggio condiviso. Nel nostro contesto i modelli corrispondono ai metadati che i vari tool intendono scambiare, che ricordiamo esistono al di fuori di ogni specifica piattaforma o tecnologia, diventando una risorsa informativa indipendente. Responsabilità dei prodotti che intendono beneficiare delle informazioni fornite dai metadati è comprendere il meta-modello comune ed essere in grado di pubblicare i propri metadati nella forma di modelli condivisi, funzionalità implementabile una volta per tutte inerentemente al prodotto stesso. La figura 3.13 illustra lo scambio di metadati tra due tool A e B. É reso possibile dalla implementazione di due adattatori, la cui logica legge o scrive i metadati istanze del meta-modello specifico del tool grazie a interfacce proprietarie, ed effettua dunque una loro traduzione dal formato proprietario al meta-modello CWM, o viceversa. I metadati espressi in formato XML/CWM possono essere dunque scambiati attraverso l infrastruttura sottostante, la

70 60 CAPITOLO 3. COMMON WAREHOUSE METAMODEL cui implementazione è oltre lo scopo dello standard, e acceduti mediante le interfacce CWM. Figura 3.13: Scambio dei metadati CWM La figura 3.14 mostra invece un sistema di Data Warehouse in cui lo sviluppatore ha scelto di appoggiarsi ad alcuni tool per lo svolgimento di determinati compiti. Vi è dunque un tool per modellare l implementazione logica e fisica, un altro per gestirne la creazione, produzione e mantenimento, inclusa la capacità di implementare le varie transazioni e trasformazioni, infine un tool per l analisi utente, dalla semplice creazione di report ad algoritmi di data mining. L intersezione tra gli insiemi di metadati che i tool utilizzano è tutt altro che vuota, pertanto questi sono replicati, gestiti e usati da ogni tool in maniera differente. Si considerino ad esempio i metadati relativi ai modelli logici e fisici, che possono allo stesso tempo consentire ad un utente di disegnare graficamente i modelli, includere informazioni utili per la implementazione fisica del sistema e servire per la generazione di query. CWM consente la condivisione di tali metadati tra tutti i tool in grado di esportarli o importarli nel formato standard. La presenza di metadati condivisi e facilmente individuabili e gestibili (denominati da Gartner metadati ubiqui in [17]) facilita l interoperabilità tra le componenti software, possibilità che garantisce innumerevoli vantaggi. Ad esempio consente di documentare e guidare lo scambio di dati tra risorse diverse, con relative

71 3.5. L INTEGRAZIONE CON CWM 61 Figura 3.14: Interoperabilità trasformazioni. Da un punto di vista operazionale l amministrazione del Data Warehouse è notevolmente facilitata, grazie anche alla possibilità di automatizzare processi coinvolti nelle fasi di ETL e di delivery. É possibile integrare nuovi prodotti nel sistema senza necessità di costruire ponti appositi per la comunicazione e senza dover ripetere fasi di installazione già effettuate in precedenza, in quanto un nuovo tool può importare informazioni generali sul sistema esportate da un altro prodotto già installato, quindi avviare da solo il processo di configurazione; ad esempio il tool per lo sviluppo potrà importare la conoscenza esportata da quello di modellazione. É possibile inoltre descrivere la generazione di schemi logici a partire da una definizione condivisa degli elementi; ad esempio sia un database relazionale che un server OLAP possono costruire una rappresentazione interna di un modello dimensionale accordandosi su una definizione condivisa di dimensione. Applicazioni che si occupano di analisi possono sfruttare il significato di business che i metadati conferiscono ai dati per predisporli all analisi o alla visualizzazione; ad esempio definizioni di termini di business, glossari e tassonomie sono tutti metadati condivisibili. Ciascuna componente soft-

72 62 CAPITOLO 3. COMMON WAREHOUSE METAMODEL ware può conoscere le caratteristiche relative alle altre risorse con cui deve interoperare, donando pertanto al sistema una natura più dinamica, in cui la pubblicazione di un nuovo modello nel repository induce le risorse del sistema ad adattarsi automaticamente ai nuovi cambiamenti. Utenti che non possiedono specifiche competenze tecniche possono modificare la struttura e il comportamento del sistema effettuando dei cambiamenti sui modelli, ovvero sui metadati. Forniamo alcuni esempi più concreti del vantaggio che lo standard CWM offre agli sviluppatori di un sistema o di una applicazione. Una azienda produttrice di software che rende il proprio prodotto in grado di esportare e importare il formato CWM ha buone probabilità di espandere il proprio mercato; il vantaggio competitivo è dato dall aumento del numero di sistemi in cui l installazione del prodotto sarà preferibile rispetto ai concorrenti. Sia Oracle che IBM DB2 ad esempio possono esportare una descrizione dei loro schemi in formato CWM/XMI; Cognos, un tool per effettuare report, è in grado di leggere tale formato: il suo utilizzo per chi possiede i due database sopra menzionati è altamente conveniente rispetto alla concorrenza, in quanto agli utenti è richiesto un minore sforzo di configurazione nel descrivere le relazioni tra gli oggetti nel database. Allo stesso tempo Oracle e IBM hanno buone probabilità di essere scelti come database dalle aziende che necessitano di effettuare report. Come già evidenziato, CWM velocizza inoltre notevolmente lo sviluppo di un sistema; la costruzione di un Data Warehouse è un processo complesso che comprende svariate implementazioni di codice: dall ETL alle tabelle di memorizzazione di fatti e dimensioni, dai data mart alle regole per l accesso degli utenti all analisi. Rappresentare il Data Warehouse secondo lo standard garantisce una base comune per le varie componenti che facilita notevolmente l automatizzazione nella generazione di codice e il suo riuso, possibilità particolarmente significativa data la ripetitività di molte funzioni da implementare; si pensi ad esempio alle diverse dimensioni, che spesso presentano notevoli similitudini nelle strutture e nel modo di relazionarsi alle

73 3.5. L INTEGRAZIONE CON CWM 63 tabelle dei fatti. Allo stesso modo vi sono notevoli somiglianze nelle strutture delle varie tabelle dei fatti e nei file utilizzati come sorgenti dati. E possibile dunque generare automaticamente numerose componenti di un sistema, tra cui file database DDL (Data Definition Language), codice per l analisi OLAP, codice per l ETL e file XML di configurazione per i report OLAP. Si intende infine menzionare alcuni prodotti che sfruttano lo standard CWM. Abbiamo già citato Cognos come tool di report; vi è poi Oracle Warehouse Builder, che permette di modellare un Data Warehosue utilizzando CWM, esportarlo in formato XMI e generare i file DDL necessari alla generazione del Data Warehouse nascondendone la complessità della creazione. MofEditor è un prodotto open source che permette di creare graficamente modelli basati su componenti MOF; non consente di generare file DDL, ma ne aiuta notevolmente la creazione. Conclusioni Nel presente capitolo abbiamo descritto lo standard Common Warehouse Metamodel, le tecnologie fondanti, la struttura del meta-modello e come questo permetta la rappresentazione dei contesti di Data Warehouse e Business Intelligence. Abbiamo dunque analizzato come si tratti realmente di una realizzazione di un approccio model-driven alla integrazione dei metadati, e quindi come consenta a prodotti diversi di interoperare tra loro. Il CWM è stato lo standard fondante lo sviluppo del prototipo; prima di descriverne l implementazione concediamoci una digressione nel capitolo 4 introducendo il concetto di Open Source e il progetto SpagoBI, una piattaforma di integrazione per lo sviluppo di progetti di Business Intelligence.

74 64 CAPITOLO 3. COMMON WAREHOUSE METAMODEL

75 Capitolo 4 Open Source e SpagoBI Il lavoro di tesi è consistito nello sviluppo di un prototipo per il progetto opensource SpagoBI, una soluzione completa per progetti di Business Intelligence in un ambiente integrato, sviluppato da Engineering Informatica SPA. Nella sezione 4.1 si illustra il concetto di open-source e la sua evoluzione nel tempo. A seguire, nella sezione 4.2, si descrive il progetto SpagoBI. 4.1 L open source Il termine open source, che in inglese significa letteralmente codice aperto, indica un software rilasciato con un tipo di licenza per la quale il codice sorgente é lasciato alla disponibilitá di eventuali sviluppatori, in modo che con la collaborazione, in genere libera e spontanea, il prodotto finale possa raggiungere una complessitá maggiore di quanto potrebbe ottenere un singolo gruppo di programmazione. L open source ha ovviamente tratto grande beneficio da Internet Storia dell Open Source Considerato che la condivisione del codice é nata insieme all informatica, piuttosto che di origini dell open source appare piú appropriato parlare di origini del software proprietario. Fu l introduzione dei sistemi operativi negli 65

76 66 CAPITOLO 4. OPEN SOURCE E SPAGOBI anni Sessanta a rendere possibile l utilizzo dello stesso programma anche su hardware differente, aumentando cosí le possibilità di riutilizzo dello stesso codice e dunque l utilitá nell impedire la duplicazione non autorizzata dei programmi. Negli anni Ottanta si diffuse infatti la pratica di non rendere disponibili i sorgenti dei programmi mediante la firma di accordi di non divulgazione (in inglese NDA, ovvero Non-Disclosure Agreement). In questo contesto Richard Stallman, che allora lavorava nel laboratorio di intelligenza artificiale del MIT (Massachusetts Institute of Technology), rifiutò di lavorare per una società privata e fondò nel 1985 la Free Software Foundation (FSF), una organizzazione senza fini di lucro per lo sviluppo e la distribuzione di software libero. Il progetto principale era lo sviluppo di un sistema operativo completo, compatibile con UNIX ma distribuito con una licenza permissiva. Si trattava di GNU, acronimo ricorsivo che definisce la sua relazione e contemporaneamente distinzione da UNIX, ovvero GNU s Not UNIX. L obiettivo principale di GNU era essere software libero, anche qualora non avesse avuto alcun vantaggio tecnico su UNIX, avrebbe avuto sia un vantaggio sociale, permettendo agli utenti di cooperare, sia un vantaggio etico, rispettando la loro libertà. Nacque la GNU General Public License (GPL); il preambolo del suo manifesto comincia con: Le licenze per la maggioranza dei programmi hanno lo scopo di togliere all utente la libertá di condividerlo e di modificarlo. Al contrario, la GPL é intesa a garantire la libertá di condividere e modificare il free software, al fine di assicurare che i programmi siano liberi per tutti i loro utenti. Pertanto lo scopo primario delle licenze open source non é la gratuitá del software, bensí la sua sopravvivenza, ovvero la certezza che vi sia la possibilitá per chiunque di apportare miglioramenti, o comunque modifiche, al programma. La libertá del software é posta come valore principe, anche piú importante dell aspetto tecnologico. All inizio degli anni Novanta, il progetto GNU non aveva ancora raggiunto il suo obiettivo principale, non riuscendo a completare il kernel del suo sis-

77 4.1. L OPEN SOURCE 67 tema operativo (HURD). Fu nel 1991 che Linus Torvald, studente al secondo anno di informatica presso l Universitá di Helsinki, cominció lo sviluppo di un proprio sistema operativo, imitando le funzionalità di Unix. Torvalds distribuì il proprio lavoro tramite Internet e ricevette immediatamente un ampio riscontro positivo da parte di altri programmatori, i quali apportarono nuove funzionalitá e contribuirono a individuare e correggere errori e imperfezioni. Nacque cosí il kernel Linux, distribuito fin da subito con una licenza liberale. Linux può essere considerato come il primo vero progetto open source, facente cioé affidamento essenzialmente sulla collaborazione via Internet per progredire. Si contravveniva per la prima volta a uno dei principi standard dell ingegneria del software, la cosiddetta legge di Brooks, secondo cui aggiungere sviluppatori a un progetto in corso di implementazione rallenta in realtà il suo sviluppo. All inizio degli anni Novanta le licenze liberali per eccellenza erano la GPL e la LGPL, ritenute contagiose in quanto a partire da un codice licenziato con la GPL qualsiasi ulteriore modifica deve avere la stessa licenza. La diffusione del software libero era compromessa dal fatto che le posizioni intransigenti di Stallman erano viste con sospetto dall ambiente commerciale statunitense. Per favorire l idea delle licenze liberali nel mondo degli affari, alcuni membri della FSF come Bruce Perens, Eric S. Raymond e Tim O Reilly coniarono nel 1997 il termine Open Source, col fine principale di evitare l equivoco dovuto al doppio significato di free nella lingua inglese, interpretato spesso come gratuito invece che come libero. L iniziativa venne portata avanti soprattutto da parte di Raymond che, in occasione della liberalizzazione del codice sorgente di Netscape, intendeva utilizzare un tipo di licenza meno restrittivo per le aziende di quanto fosse il GPL. La scelta a favore dell Open Source da parte di alcune importanti imprese del settore come la Netscape, l IBM, la SUN e l HP facilitarono l accettazione del movimento Open Source presso l industria del software, proponendola come metodologia di produzione efficace.

78 68 CAPITOLO 4. OPEN SOURCE E SPAGOBI Definizione di Open Source L Open Source Initiative (OSI) è una organizzazione senza fini di lucro che si dedica alla promozione di software open source. È stata fondata nel febbraio 1998 da Bruce Perens e Eric S. Raymond quando Netscape rese pubblico il codice sorgente di Netscape Communicator come free software, a causa della progressiva riduzione dei margini di profitto e della competizione con il programma Internet Explorer di Microsoft. Ha pubblicato un documento, denominato Open Source Definition, che specifica i requisiti necessari affinché una licenza possa essere considerata open source. La prima bozza fu scritta da Bruce Perens, intitolata Linee guida per il software libero in Debian ; venne ampiamente discussa e migliorata nelle mailing list del progetto Debian nel giugno L attuale documento è il risultato della rimozione di ogni riferimento a Debian e della successiva pubblicazione del risultato. Le condizioni necessarie affinché una licenza possa essere considerata open source sono: 1. Libera redistribuzione: la licenza non puó limitare alcuno dal vendere o donare il software come componente di una distribuzione aggregata. La licenza non puó richiedere diritti o altri pagamenti a fronte di tali vendite. 2. Codice Sorgente: deve essere permessa la distribuzione del codice sorgente, in una forma facilmente modificabile da un programmatore, al fine di porre migliorie al programma. 3. Prodotti Derivati: devono essere permessi prodotti derivati e la loro distribuzione sotto le stesse condizioni della licenza del software originale. 4. Integritá del codice sorgente originale: deve essere permessa la distribuzione del software prodotto con un codice sorgente modificato, si puó peró imporre che i prodotti derivati portino un nome o una versione diversa dal software originale.

79 4.1. L OPEN SOURCE Discriminazione contro persone o gruppi: la licenza non deve discriminare alcuna persona o gruppo di persone 6. Discriminazione per campo d applicazione: la licenza non deve impedire di far uso del programma in un ambito specifico. Ad esempio non si puó impedire l uso del programma in ambito commerciale o nell ambito della ricerca genetica. 7. Distribuzione della licenza: i diritti allegati a un programma devono essere applicabili a tutti coloro a cui il programma è redistribuito, senza che sia necessaria l emissione di ulteriori licenze. 8. Specificità ad un prodotto: i diritti allegati al programma non devono dipendere dal fatto che il programma sia parte di una particolare distribuzione di software. 9. Vincoli su altro software: la licenza non deve porre restrizioni su altro software distribuito insieme al software licenziato. 10. Neutralità rispetto alle tecnologie: la licenza non deve contenere clausole che dipendano o si basino su particolari tecnologie o tipi di interfacce. Illustriamo brevemente le motivazioni di tali requisiti. Imponendo la libera redistribuzione (requisito 1 ) si elimina la tentazione di rinunciare a importanti guadagni a lungo termine in cambio di un guadagno materiale a breve termine, ottenuto con il controllo delle vendite. Senza questa imposizione, i collaboratori esterni sarebbero tentati di abbandonare il progetto, invece che di farlo crescere. L accesso al codice sorgente (requisito 2 ) e la possibilità di sperimentarne modifiche mediante redistribuzione (requisito 3 ) sono presupposti fondamentali all evoluzione del programma. Gli utenti hanno tuttavia diritto di sapere chi è responsabile del software che stanno usando e gli autori hanno diritto di proteggersi la reputazione; per questi motivi una licenza open source, posto l obbligo di garantire che il codice sorgente sia facilmente

80 70 CAPITOLO 4. OPEN SOURCE E SPAGOBI disponibile, può eventualmente richiedere che esso sia redistribuito solo in forma originale accompagnato da file patch (requisito 4 ). In questo modo le modifiche non ufficiali possono essere rese disponibili pur rimanendo distinte dal codice sorgente originale. Per ottenere il massimo beneficio nell evoluzione del software il massimo numero di persone devono avere eguale possibilità di contribuire allo sviluppo del software. Pertanto viene proibita l esclusione arbitraria dal processo di persone o gruppi (requisito 5 ). I requisiti 6, 7, 8 hanno lo scopo di impedire trappole nelle licenze che impediscano al software di essere usato liberamente, ad esempio limitandone l ambito di applicazione, obbligando la sottoscrizione di accordi di non diffusione, vincolando il software a un prodotto specifico. I distributori di software open source inoltre hanno il diritto di fare le loro scelte riguardo al software che intendono distribuire (requisito 9 ). Il requisito 10 è indirizzato in particolar modo a quelle licenze che richiedono un gesto esplicito di approvazione da parte dell utente al fine di stabilire un contratto. Clausole che ad esempio richiedono un interazione con una interfaccia web possono essere in conflitto con importanti metodi di distribuzione del software, come i siti FTP, le raccolte su Cd-Rom e le copie distribuite sul Web. Le licenze valide devono permettere la possibilità che il software venga distribuito mediante canali diversi dal Web, sui quali non si possa richiedere una interazione esplicita dell utente prima di iniziare il download; si richiede inoltre che il programma in oggetto, o sue porzioni, possano essere utilizzare in ambienti privi di interfaccia grafica, nei quali non si possa richiedere la presenza di specifiche finestre di dialogo. 4.2 SpagoBI SpagoBI è una soluzione completa per la realizzazione di progetti di Business Intelligence in un ambiente integrato. É sviluppata da Engineering Ingegneria Informatica SPA, una società per azioni italiana, costituita nel 1980, avente come attività lo studio, progettazione e realizzazione di prodot-

81 4.2. SPAGOBI 71 ti software, in particolare per i settori bancario, finanziario e assicurativo, e la gestione in outsourcing di servizi informatici. SpagoBI è una soluzione completamente open source in grado di soddisfare l intera gamma di esigenze analitiche: il reporting statico, la ricerca di informazioni nascoste attraverso tecniche di data mining, il controllo delle performance aziendali con cruscotti (dashboard) in grado di monitorare gli indicatori significativi (KPI) in tempo reale o differito, l interrogazione libera dei dati tramite uno strumento visuale (QbE). Copre altri aspetti funzionali quali l organizzazione dei dati (statici e dinamici) e la creazione di un ambiente di pubblicazione e di controllo strutturato e dinamico. Supporta inoltre i processi di estrazione, trasformazione e caricamento dei dati (ETL). SpagoBI è sviluppato a componenti e realizza le singole funzionalità con moduli specifici; esistono infatti numerosi prodotti open source che coprono particolari aspetti della Business Intelligence, tuttavia una soluzione completa che tratti l intero contesto è offerta soltanto da grossi prodotti commerciali. SpagoBI fornisce un infrastruttura comune che consente una visione globale della piattaforma; utilizza dunque le soluzioni open source ritenute più interessanti e sviluppa nuovi componenti al fine di realizzare un intera piattaforma realmente integrata. Offre diverse soluzioni per ogni area analitica, lasciando libero l utente finale di scegliere la composizione della soluzione più adatta rispetto alle proprie esigenze, allo scopo di massimizzare il ROI e di salvaguardare il patrimonio informativo aziendale. Permette anche di combinare componenti open source e proprietarie. SpagoBI adotta come principio fondamentale quello che gli sviluppatori hanno chiamato modello olistico, così nominato in quanto, come l idea fondante la posizione filosofica dell olismo, si basa sull assunto che le proprietà di un sistema non possano essere spiegate esclusivamente tramite le sue componenti: l insieme è dunque maggiore della somma delle sue parti. SpagoBI si pone infatti come piattaforma di integrazione dei migliori progetti open source; partendo dalla considerazione che è inutile reinventare la ruota per sviluppare soluzioni già esistenti. La forza dell open source è infatti l oppor-

82 72 CAPITOLO 4. OPEN SOURCE E SPAGOBI tunità di aggiungere valore alle soluzioni adottate o di riceverne da queste. SpagoBI è inoltre una componente rilasciata all interno di un insieme tecnologico ben più ampio; è inserito fra le soluzioni del Consorzio ObjectWeb. Grazie alle sinergie prodotte con altre comunità di sviluppo, può facilmente essere integrata con ulteriori soluzioni, siano esse open source o proprietarie, per soddisfare diverse esigenze aziendali: dalla integrazione di dati e applicazioni, agli application server, ai portali, alle soluzioni di workflow e alla business integration. A titolo di esempio citiamo alcune delle applicazioni open source che è possibile utilizzare: JBoss e Tomcat come application server, JasperReport e BIRT come motori di report, Jpivot e Mondrian come motori OLAP, Weka per il data mining, Talend Open Studio per il supporto ETL, OpenLaszlo come visualizzatore di dashboard. Il progetto SpagoBI è ambizioso e molto articolato; non nasce come prodotto completo messo a disposizione della comunità di interesse, anche se rende disponibili alcune funzionalità utente, ma come soluzione progettuale da sviluppare e consolidare insieme ad essa. Per questo ogni componente è rilasciata con licenza GNU LGPL, così da permetterne la condivisione, lo sviluppo e l estensione Architettura di SpagoBI SpagoBI presenta una struttura modulare; un nuovo progetto può richiedere il coinvolgimento di alcuni moduli soltanto, con la garanzia che eventuali estensioni saranno facilmente realizzabili dato che la piattaforma integra i vari moduli in una visione globale. In figura 4.1 è introdotta l architettura di SpagoBI. Il livello di integrazione è legato alla interazione delle applicazioni con portali generici, che possono essere specifici per la Business Intelligence o per l intera azienda, e permette dunque la navigazione e l utilizzo dei servizi offerti. Il livello delle applicazioni BI costituisce il nucleo analitico della piattaforma e gestisce la navigazione, attivazione e gestione dei parametri dei vari motori BI, che producono i documenti analitici a partire dai dati e

83 4.2. SPAGOBI 73 Figura 4.1: Architettura di SpagoBI metadati estratti dalle sorgenti. SpagoBI fornisce supporto per le funzionalità di amministrazione dell intera piattaforma, sia degli utenti che degli oggetti. Spago è un J2EE Framework realizzato da Engineering che permette lo sviluppo di applicazioni Web, l integrazione di infrastrutture e la pubblicazione di servizi su differenti canali. Spago BI eredita da Spago alcune caratteristiche, adattandole al proprio contesto: gestisce dunque oggetti specifici della Business Intelligence ( oggetti BI ) e supporta l utente di Business nella loro gestione, controllo, certificazione e distribuzione. Ogni oggetto BI è distribuito all utente finale mediante portlet (JSR 168), in modo tale che sia i portlet che gli oggetti siano gestiti e incapsulati nel portale scelto per la specifica soluzione aziendale, anche qualora dovesse trattarsi di un prodotto commerciale. Questi oggetti sono report, analisi OLAP, modelli di Data Mining, ciascuno con un proprio motore di esecuzione, e Spago- BI ne gestisce i cicli di produzione e validazione, la navigazione, selezione, attivazione dei parametri e il versionamento. SpagoBI eredita da Spago l aderenza al pattern architetturale MVC. Ricordiamo che il pattern Model-View-Controller (MVC), fondamentale nello sviluppo di interfacce grafiche di sistemi software object-oriented, si basa sulla linea guida generale che l applicazione debba separare i componenti software che implementano il modello delle funzionalità di business (model),

84 74 CAPITOLO 4. OPEN SOURCE E SPAGOBI dai componenti che implementano la logica di presentazione (view) e di controllo che utilizzano tali funzionalità (controller). I due assunti di fondo che hanno guidato la progettazione di SpagoBI sono la possibilità di declinare il pattern architetturale MVC sulle tematiche implementative della Business Intelligence e la possibilità di portare in primo piano i metadati, affinché diventino il fondamento per la guida ed il controllo di tutta la piattaforma. Analizziamo come il pattern MVC si caratterizza secondo questi due semplici principi guida; in figura 4.2 sono evidenziati i tre moduli: Model, View e Controller; le frecce continue rappresentano invocazioni di metodi, quelle tratteggiate rappresentano eventi. Il modulo Model deve incapsulare la logica applicativa, che si delinea in questo caso come logica analitica. Gli oggetti BI vengono trattati come generici Componenti BI con una propria logica di controllo e con un motore di esecuzione specifico; governano la logica di business in quanto il business nel contesto di interesse è l analisi stessa. Un altra nota particolare riguarda il dominio dei dati, che si posiziona a livello di Data Warehouse e non di sistema operazionale. Infine nel dominio dei dati sono compresi anche i metadati per la gestione semantica dei primi e per l espressione della logica di controllo. Il livello View, che deve incapsulare la logica di presentazione, affronta le problematiche relative alle componenti di pubblicazione e distribuzione delle informazioni tipicamente caratterizzanti le applicazioni web; una particolarità aggiunta è il fatto di poter mantenere e richiedere documenti di validità storica. Trattandosi di logiche analitiche è ridotta la necessità di gestire input da parte dell utente. Infine il livello Controller assume nella Business Intelligence l onere del coordinamento e della navigazione all interno dei singoli componenti e tra componenti differenti. SpagoBI adatta l architettura di Spago al contesto di interesse, definendo tre livelli logici sui quali è strutturata l intera piattaforma (figura 4.3): il livello distribuzione, per la distribuzione dei modelli di informazione e analisi, il livello analitico, per la trasformazione dei dati grezzi in informazioni significative e il livello dati e metadati, per ricevere i dati e strutturarli per scopi analitici.

85 4.2. SPAGOBI 75 Figura 4.2: Approccio MVC per SpagoBI Gli scopi principali del livello Distribuzione sono di rendere utilizzabili i servizi BI e di permettere ad applicazioni esterne di interagire con essi. I portlet sono il primo strumento di accesso e permettono di costruire un interfaccia personalizzata in un nuovo portale di Business Intelligence, o in una parte di uno già esistente. Per l interazione con altre applicazioni aziendali sono previsti anche i Web Service, per l abilitazione dei processi analitici i messaggi JSM. I modelli e le strutture di tipo XML permettono infine una semplice trasmissione dell informazione e dei risultati. Il livello Analitico è il nodo centrale della piattaforma; coordina le attività analitiche, fornendo anche gli strumenti necessari a supportarle. Le componenti centrali (Componenti BI ) sono i moduli di Report, OLAP, Data Mining, Dashboard e Scorecard: ognuna di queste risponde ad una serie di funzionalità specifiche, ma la piattaforma le tratta secondo gli stessi principi architetturali, consentendone così un facile utilizzo ed un uso modulare. Il modulo di report permette la vista strutturata di informazioni, quello OLAP

86 76 CAPITOLO 4. OPEN SOURCE E SPAGOBI Figura 4.3: Architettura di SpagoBI nel dettaglio

87 4.2. SPAGOBI 77 permette l analisi dei dati secondo una logica di business; il modulo di Data Mining offre algoritmi e processi, come le reti neurali o gli alberi decisionali, per scoprire informazioni nascoste nei dati. Nel contesto del Management Performance SpagoBI fornisce strumenti per la creazione e visualizzazione di cruscotti, a partire dalla valutazione di indici di performance definiti. Alcune applicazioni di servizio supportano le componenti BI predisponendo l ambiente di lavoro nei suoi aspetti collaterali: gestione unificata dei parametri, definizione di filtri e domini, funzionalità di Query by Example, espressione di profili utente, strutturazione delle categorie per la classificazione dei documenti, archiviazione e ricerca dei documenti, approvazione e gestione del workflow. BIParameter gestisce i valori di input per l attivazione dei moduli analitici e regola la visibilità dei dati e il comportamento del sistema a seconda dei privilegi dell utente corrente. BIProfiling è responsabile della registrazione dei documenti analitici nel rispetto di standard definiti. BIFunctionality definisce e gestisce i servizi BI permettendone inoltre l organizzazione ad albero, il versionamento, la visibilità a seconda dei ruoli utente e la produzione dei documenti in accordo con le regole determinate da BIProfiling. BISearch è un motore di ricerca dei documenti, BIQbE una componente per l interrogazione visuale dei dati e BINotify uno strumento per notificare eventi. Il Controllore dei contesti ha la responsabilità di garantire il corretto coordinamento dell interazione sia fra le varie Componenti BI, sia fra questi ultimi e le applicazioni di servizio. Il livello Dati e Metadati si posiziona al livello del Data Warehouse e fornisce una meta-descrizione dei suoi aspetti tecnici, dei contenuti di business e delle informazioni relative ai processi. É anche fornito un repository di servizio al fine di supportare la gestione dei documenti e la descrizione degli oggetti. L interazione con le componenti BI può avvenire in maniera diretta o attraverso un livello semantico di interfaccia, che può essere generico o specifico di un particolare tool. La relazione con i sistemi sorgenti è gestita da un modulo ETL, che fornisce vari servizi quali l estrazione, la trasformazione e il caricamento dei dati. Infine, per gli utenti di amministrazione, sono

88 78 CAPITOLO 4. OPEN SOURCE E SPAGOBI previste diverse funzionalità per la configurazione ed il controllo dell intera piattaforma Il meta-modello di SpagoBI Da un punto di vista di flusso dei dati la struttura di SpagoBI è analizzabile individuando quattro livelli di astrazione che, partendo dalle sorgenti fisiche dei dati, ad esempio il Data Warehouse, arrivano a trattare l intera piattaforma come un insieme di funzionalità, quindi a delinearne le funzioni di gestione. Intenzione degli sviluppatori è dunque definire un meta-modello globale, composto a sua volta di un meta-modello per ogni livello di astrazione. La figura 4.4 illustra i quattro livelli, mappandoli alla realtà esecutiva dell applicazione e individuando i tipi di metadati adatti a realizzare le funzionalità necessarie. Le funzionalità che permettono all utente di connet- Figura 4.4: Livelli del meta-modello di SpagoBI tersi alla piattaforma e accedere ai documenti analitici sono caratteristiche

89 4.2. SPAGOBI 79 del livello SBI-L3, che offre una visione globale della piattaforma, fornendo anche la gestione della sicurezza. Una volta che l utente richiede un documento informativo il livello SBI-L2 si occupa di utilizzare le strutture analitiche di SpagoBI adatte a soddisfare il bisogno informativo espresso. Le strutture selezionate dovranno recuperare i dati dalle sorgenti, pertanto il livello SBI- L1 permette loro di riferirsi alle risorse fisiche, ad esempio le tabelle e le colonne relazionali. Infine il livello più basso, SBI-L0, esegue l interrogazione sulla risorsa, ad esempio il database relazionale. La figura 4.4 illustra anche i metadati che descrivono e supportano le attività dei vari livelli; a partire dalla loro individuazione è possibile costruire il meta-modello adatto a descriverli. Al livello SBI-L0 sono necessari metadati che descrivono fisicamente la risorsa sorgente, ad esempio il database o il Data Warehouse. Tali metadati, al livello SBI-L1, devono essere organizzati secondo una logica utilizzabile dalle strutture analitiche del livello successivo; ad esempio individuando concetti come fatti e dimensioni. Al livello SBI-L2 i metadati descrivono come il Data Warehouse viene utilizzato per la produzione dei documenti analitici, ad esempio report, OLAP, dashboard. Specificano inoltre come questi sono organizzati tra loro e quali operazioni di navigazione e modifica ammettano. Infine i metadati a livello SBI-M3 descrivono come la piattaforma di Spago- BI è utilizzata dagli utenti; riguardano pertanto le interfacce di navigazione e accesso, i ruoli degli utenti e le conseguenti visibilità di dati e applicazioni. L applicazione sviluppata come prototipo, descritta nel capitolo 5, tratta i metadati caratteristici dei primi due livelli, SBI-L0 e SBI-L1, in quanto si occupa di estrarre i metadati da un database relazionale ed organizzarli secondo una logica OLAP. Definiamo come modello analitico l insieme dei documenti analitici sviluppati sulla piattaforma e delle regole che descrivono come essi siano associati agli utenti in base al loro ruolo e alle loro capacità. Definiamo invece come modello comportamentale l insieme delle regole che gestiscono, sempre in funzione dei ruoli utente, la visibilità sui dati mostrati attraverso i documenti analitici e i parametri di validazione. Il modello comportamentale garantisce

90 80 CAPITOLO 4. OPEN SOURCE E SPAGOBI sicurezza e facilita la manutenzione del sistema, in quanto le regole relative a ogni concetto analitico sono codificate una sola volta e condivise da tutti i motori, indipendentemente dalla loro natura, open source o propietaria, e dal loro ruolo. E possibile dunque produrre nuovi documenti analitici e registrarli nella piattaforma riferendosi al modello comportamentale; per spiegare come questo agisce, immaginiamo che un utente si autentichi nella piattaforma e scelga un documento analitico da eseguire; il sistema legge la configurazione esecutiva del documento e produce una pagina per l input dei parametri in accordo con il ruolo dell utente; i valori di input sono dunque controllati e validati, sempre a seconda del ruolo, e viene prodotto il documento finale. La direzione che gli sviluppatori intendono intraprendere è l adozione di un meta-modello che consenta la descrizione astratta di tutte le aree analitiche. Poiché allo stato attuale SpagoBI non si avvale di un metamodello, sia il modello analitico che quello comportamentale attingono i dati e metadati direttamente dalle fonti. Per quanto concerne il primo i documenti analitici implementano al loro interno il livello dei metadati (ad esempio i tipi dei dati), le logiche multidimensionali ed eventuali valori di soglia sui dati; per quanto invece riguarda il secondo le regole di visibilità sui dati vengono ricavate inferendole direttamente dalle fonti dati. In figura 4.5 è illustrata tale situazione. L introduzione del meta-modello globale permetterebbe di definire una vista consistente ed omogenea sia delle entità che compongono il Data Warehouse che delle regole di visibilità del modello comportamentale, vista condivisa da tutti i motori analitici. Permetterebbe inoltre l interazione con sistemi esterni che espongono a loro volta una propria interfaccia di gestione. Il meta-modello progettato per SpagoBI si articola nei quattro livelli precedentemente illustrati, orientamento che ricorda la struttura in livelli dei package CWM. L adozione del meta-modello all interno dellarchitettura di SpagoBI avverrà in fasi successive, integrando man mano le componenti al meta-modello invece che alle fonti dati. Descriviamo dunque due possibili future fasi di integrazione progressiva in SpagoBI.

91 4.2. SPAGOBI 81 Figura 4.5: Assenza di meta-modello globale La prima fase consisterà nell introduzione dei livelli SBI-L0 e SBI-L1, che verranno inizialmente utilizzati soltanto dal motore QbE, mentre i restanti motori e il modello comportamentale continueranno a riferirsi direttamente alle fonti dati. QbE, acronimo di Query by Example, è un linguaggio per interrogare database relazionali che, a differenza dell SQL, fornisce un interfaccia grafica grazie alla quale l utente può scrivere query in modo visuale, senza la necessità di scrivere codice SQL. In questo contesto si rivela particolarmente vantaggiosa una mappatura mantenuta nel sistema, in quanto permette di effettuare interrogazioni complesse senza dover indicare le condizioni di join fra le varie entità del Data Warehouse. L integrazione con i livelli SBI-L0 /SBI-L1 permetterà di evitare la definizione di questa mappatura relazionale, attualmente generata mediante il reverse engineering di Hibernate. Sarà dunque necessario definire un successivo livello SBI-L2 che descriva le modalità mediante le quali il motore QbE interagisce con il meta-modello (figura 4.6). Una successiva fase prevederà l integrazione di tutti i motori analitici con il meta-modello e la relativa implementazione del livello SBI-L2. Ad esempio il motore OLAP Mondrian prevede uno schema XML che definisca la struttura del cubo a partire dalle entità relazionali che compongono il Data

92 82 CAPITOLO 4. OPEN SOURCE E SPAGOBI Figura 4.6: Livello SBI-L2 per QbE Warehouse, attualmente creato manualmente. Il livello SBI-L2 per il motore OLAP Mondrian avrà pertanto il compito di generare automaticamente tale schema XML a partire dal livello SBI-L1, che mantiene la vista multidimensionale del Data Warehouse condivisa da tutti i motori analitici. Il modello comportamentale dovrà quindi essere integrato col meta-modello; ad esempio sarà possibile definire diversi criteri di visibilità, in base ai ruoli degli utenti, direttamente sui livelli di una gerarchia definita su SBI-L1, invece che interagendo con le fonti dati (figura 4.7). L integrazione del metamodello è prevista nell ambito dello sviluppo della versione 2.0 di SpagoBI, che includerà la realizzazione dell ambiente di sviluppo della piattaforma (SpagoBI Studio), la quale permetterà di implementare, testare e rilasciare sia le componenti del modello comportamentale che i documenti analitici. La successiva integrazione del meta-modello all interno della piattaforma SpagoBI sarà accompagnata dallo sviluppo di funzionalità di SpagoBI Studio che permetteranno di effettuare implementazione, test e rilascio dei componenti con riferimento alle entità definite nel meta-modello

93 4.2. SPAGOBI 83 Figura 4.7: Un livello SBI-L2 per ogni componente stesso. Conclusioni Nel presente capitolo abbiamo illustrato il concetto di open source, soffermandoci anche sulla sua nascita ed evoluzione. E stato dunque presentato il progetto SpagoBI, evidenziandone in particolare la necessità di adottare un meta-modello. Nel capitolo 5 si illustra il prototipo realizzato che, come già spiegato, tratta i metadati dei livelli SBI-L0 e SBI-L1 ; se ne descrivono in particolare le funzionalità, le tecnologie utilizzate e i passi esecutivi.

94 84 CAPITOLO 4. OPEN SOURCE E SPAGOBI

95 Capitolo 5 Implementazione Si intende ora descrivere l implementazione del prototipo. Nel capitolo 4 abbiamo analizzato il contesto, ovvero la necessità per la piattaforma Spago- BI di Engineering di adottare un meta-modello, suddiviso in quattro livelli di astrazione. L implementazione riguarda i due livelli più bassi, denominati SBI-L0 e SBI-L1 ; i metadati relativi al primo descrivono una sorgente dati, nel caso del prototipo un database relazionale, e riguardano entità quali tabelle, colonne, chiavi. Questi sono organizzati, nel livello SBI-L1, secondo una logica multi-dimensionale, individuando pertanto concetti come fatti, dimensioni e misure. La sezione 5.1 introduce l Online Analytical Processing (OLAP) e i relativi concetti fondamentali. La sezione 5.2 illustra nel dettaglio le funzionalità dell applicazione sviluppata, a cui segue nella sezione 5.3 l elenco degli strumenti di sviluppo utilizzati. Infine la sezione 5.4 illustra come il meta-modello CWM è stato utilizzato per esprimere i metadati; è mostrato un esempio di esecuzione dell applicazione su un input semplice ma significativo. 5.1 OnLine Analytical Processing (OLAP) L Online Analytical Processing (OLAP) è una tecnica di analisi in cui i dati, provenienti da diverse sorgenti operazionali, sono consolidati ed esposti in un 85

96 86 CAPITOLO 5. IMPLEMENTAZIONE formato multi-dimensionale che permette agli analisti del business di accederli, esplorarli e modificarli in maniera intuitiva. I tool OLAP si propongono tipicamente di trasformare dati riguardanti il business nel business stesso. A seconda che i dati siano fisicamente memorizzati in un database relazionale o multi-dimensionale si parla rispettivamente di ROLAP e di MOLAP; le risorse dati rappresentabili dai package CWM Relational e Multidimensional dello strato Resource sono pertanto ottime candidate per essere il fondamento di tecniche di analisi OLAP. La mappatura di tali risorse a una modellazione logica OLAP e, viceversa, il tracciamento dei dati OLAP alle rispettive sorgenti fisiche è effettuato mediante il package Transformation. Forniamo dunque una breve descrizione dei principali concetti OLAP prima di analizzare come CWM è in grado di rappresentarli. Alla base della analisi vi è il modello dimensionale, il cui concetto fondante è quello di cubo OLAP, definibile anche come cubo multidimensionale o ipercubo, che consistente di fatti numerici chiamati misure organizzati in dimensioni. In figura 5.1 è mostrato un esempio di cubo che rappresenta le vendite di un negozio; esempi di misure potrebbero essere la quantità di merce venduta e il prezzo di un singolo pezzo. Il cubo è definito da tre dimensioni, che logicamente ne costituiscono i lati; sono rispettivamente la dimensione tempo, la dimensione geografia e la dimensione prodotto. Ciascuna di queste si sviluppa su determinati valori, detti anche membri; ad esempio nel caso della dimensione geografica i membri potrebbero essere tutti i comuni d Italia. Selezionando un membro per ogni dimensione identifico una cella del cubo contenente un valore per ogni misura: nel caso d esempio, si individuano le vendite di un dato prodotto effettuate in un certo periodo in una precisa zona. Il principale meccanismo OLAP che permette di ottimizzare la performance delle attività di analisi sono le aggregazioni, costruite cambiando la granularità di visualizzazione sulle dimensioni e aggregando di conseguenza i valori delle misure lungo esse, secondo la modalità di aggregazione specifica della misura. Le dimensioni infatti sono caratterizzate da gerarchie di livelli di aggregazione. Per fornire un esempio, una dimensione temporale avrà

97 5.2. FUNZIONALITÀ DEL PROTOTIPO 87 Figura 5.1: Esempio di cubo OLAP tipicamente i livelli giorno, mese e anno ; se considero come misura il numero di prodotti venduti, posso passare da una visualizzazione della informazione giornaliera a una mensile aggregando, quindi presumibilmente sommando, i valori su tutti i giorni del mese. Quando si sale di livello nella gerarchia, aumentando l astrazione, quindi aggregando i dati, si compie un operazione chiamata roll up; l operazione inversa si chiama drill down e risulta possibile fino al raggiungimento della granularità di memorizzazione dei dati, ovvero il massimo grado di dettaglio memorizzato. Se immaginiamo di aver inserito nella risorsa fisica i dati relativi alla quantità di merce venduta giornalmente non sarà possibile in alcun modo ottenere l informazione delle quantità vendute ogni ora, in quanto sarebbe necessario ripopolare la risorsa di nuovi dati. Tipicamente in un sistema OLAP le aggregazioni più richieste dalle attività di analisi sono pre-calcolate, in modo da ottimizzare i tempi di risposta. 5.2 Funzionalità del prototipo La creazione di modelli dimensionali a partire da realtà del dominio di business è spesso una soluzione al bisogno di metadati di tool OLAP e database

98 88 CAPITOLO 5. IMPLEMENTAZIONE multidimensionali; è necessario distinguere il modello OLAP, composto da entità logiche, dal modello fisico. Il primo è costituito da dimensioni, gerarchie, livelli e cubi, definizioni logiche che rappresentano come l utente finale vede il sistema da un punto di vista del business. Il secondo descrive la risorsa fisica, nel caso del prototipo un database relazionale che memorizza i dati su cui si intendono effettuare le analisi. E necessario definire dunque delle corrispondenze tra le entità logiche, che forniscono l astrazione del business, e quelle fisiche. Il prototipo sviluppato permette all utente di connettersi a un database relazionale, estrarne i metadati prescelti ed organizzarli secondo una logica dimensionale; il programma produce in output un file XML in cui sono rappresentati, come istanza del meta-modello CWM, il modello del database relazionale, il modello dello schema OLAP e le mappature tra essi. Il diagramma use-case in figura 5.2 mostra le funzionalità dell applicazione: Figura 5.2: Funzionalità del sistema 1. L utente seleziona i parametri di connessione ad un database relazionale (MySql, Oracle, PostgreSql o SqlServer).

99 5.2. FUNZIONALITÀ DEL PROTOTIPO seleziona un sottoinsieme delle tabelle del database selezionato 3. seleziona un sottoinsieme delle colonne appartenenti alle tabelle precedentemente scelte. 4. L utente definisce le dimensioni, per ciasuna: (a) definisce i livelli, per ciascuno dei quali: i. sceglie il nome ii. sceglie gli attributi tra le colonne precedentemente selezionate. Nel caso provengano da più di una tabella deve indicare le condizioni di join. iii. ridefinisce (opzionalmente) il nome degli attributi iv. sceglie l attributo o gli attributi chiave del livello. (b) definisce le gerarchie, per ciascuna: i. sceglie il nome ii. sceglie i livelli che la compongono tra quelli precedentemente definiti, specificandone l ordinamento. iii. definisce eventuali attributi della gerarchia mappandoli agli attributi dei livelli coinvolti nella gerarchia. iv. nomina un attributo chiave della gerarchia, che viene automaticamente mappato agli attributi chiave dei livelli coinvolti (c) definisce eventuali attributi della dimensione mappandoli agli attributi delle gerarchie coinvolte. (d) nomina la chiave della dimensione, che viene automaticamente mappata agli attributi chiave delle gerarchie coinvolte 5. L utente definisce i fatti, per ciascuno: (a) sceglie il nome (b) sceglie gli attributi tra le colonne precedentemente selezionate. Nel caso provengano da più di una tabella deve indicare le condizioni di join.

100 90 CAPITOLO 5. IMPLEMENTAZIONE (c) definisce la dimensionalità del cubo. Seleziona le dimensioni tra quelle precedentemente create e sceglie quale tra gli attributi del fatto sono le chiavi esterne verso esse. (d) fra gli attributi restanti seleziona quali sono misure. Per ciascuna specifica anche un eventuale modalità di aggregazione. Un singolo attributo può definire più misure, specificando diverse modalità di aggregazione. (e) definisce eventuali misure derivate, specificandone la formula, ove gli operandi sono le misure precedentemente definite. 6. Il programma crea e visualizza il file XML con il meta-modello CWM; l utente può associarvi il riferimento a un DTD per assicurarne la validazione. 7. L utente salva il file creato. Le entità del file XML creato rappresentano logicamente una istanza della classe CWM Package, che descrive i tipi utilizzati dal database, e una istanza della classe Model. Quest ultima contiene a sua volta la rappresentazione di una istanza della classe Catalog, che descrive i metadati del database relazionale (livello SBI-L0 ), una istanza della classe Schema del package OLAP, che descrive un modello multidimensionale (livello SBI-L1 ), e infine una istanza di DeploymentGroup che definisce le mappature tra il modello OLAP (logico) e quello relazionale (fisico). Si procede con una breve descrizione degli strumenti utilizzati per lo sviluppo. 5.3 Strumenti di sviluppo Si intende descrivere i principali strumenti di sviluppo utilizzati: Java 1.5 Java è un linguaggio di programmazione orientato agli oggetti, derivato dal C++ (quindi indirettamente dal C) e creato da James Gosling e altri in-

101 5.3. STRUMENTI DI SVILUPPO 91 gegneri di Sun Microsystems. Java fu annunciato ufficialmente il 23 maggio 1995 a SunWorld. La piattaforma di programmazione Java è fondata sul linguaggio stesso, sulla Java Virtual Machine (JVM) e sulle API. Intenzione degli sviluppatori era creare un linguaggio orientato agli oggetti, indipendente dalla piattaforma, contenente strumenti e librerie per il networking e che fornisse un supporto per l esecuzione del codice da sorgenti remote. Per l implementazione è stata utilizzata la versione 1.5, rilasciata nel JDBC JDBC è un middleware per database che consente l accesso alle basi di dati da qualsiasi programma scritto con il linguaggio di programmazione Java, indipendentemente dal tipo di DBMS utilizzato. È costituito da una API, raggruppata nel package java.sql, che serve ai client per connettersi a un database; fornisce inoltre metodi per interrogare e modificare i dati. L interfaccia databasemetadata permette di accedere ai metadati, mentre l interfaccia resultsetmetadata consente di estrarre i metadati che descrivono il risultato di una query SQL. Eclipse: Eclipse è un IDE (ambiente di sviluppo integrato) utilizzato per la produzione software di vario genere, in particolare per il linguaggio Java. La piattaforma di sviluppo è incentrata sull uso di plug-in, ovvero delle componenti software ideate per uno specifico scopo, ad esempio la generazione di diagrammi UML; tutta la piattaforma è un insieme di plug-in che chiunque può sviluppare e modificare. Nella versione base è possibile programmare in Java usufruendo di comode funzioni di aiuto quali il completamento automatico ( Code completion ), suggerimento dei tipi di parametri dei metodi, possibilità di accesso diretto a CVS e riscrittura automatica del codice ( Refactoring ) in caso di cambiamenti nelle classi.

102 92 CAPITOLO 5. IMPLEMENTAZIONE Java Metadata Interface (JMI) La specifica delle java Metadata Interface (JSR 40) permette l implementazione di una infrastruttura dinamica e indipendente dalla piattaforma sottostante per gestire la creazione, accesso, memorizzazione, ricerca e scambio di metadati. JMI definisce uno standard di interfacce Java verso le componenti di meta-modelli MOF, permettendo pertanto l accesso ai metadati, in quanto istanze dei meta-modelli. Rappresentano una maniera alternativa per generare interfacce verso CWM rispetto all utilizzo delle mappature MOF-IDL e IDL-JAVA, approccio che si presenta meno intuitivo. DBMS Procediamo ad una breve descrizione dei database management systems (DBMS), cioè sistemi di gestione di basi di dati, dai quali l applicazione può estrarre i metadati. La connessione JDBC permette di utilizzare la stessa interfaccia di accesso indipendentemente dal database sottostante; vi sono alcune differenze sintattiche da rispettare, specialmente con Oracle, tuttavia minime. MySql: un DBMS relazionale, composto da un client con interfaccia a caratteri e un server. Se ne è utilizzata la versione 5.1, rilasciata nel Oracle: fa parte dei cosiddetti RDBMS (Relational DataBase Management System) ovvero sistemi di database basati sul modello relazionale, che si è affermato come lo standard dei database dell ultimo decennio. SqlServer: Microsoft SQL Server è un database relazionale prodotto da Microsoft. Nelle prime versioni era utilizzato per basi di dati mediopiccole, ma negli ultimi cinque anni (a partire dalla versione 2000) è stato utilizzato anche per la gestione di basi dati di grandi dimensioni. PostgreSQL: un completo database relazionale ad oggetti con licenza libera stile (BSD).

103 5.4. ESECUZIONE DELL APPLICAZIONE Esecuzione dell applicazione CWM separa i concetti di modello logico e modello fisico di un sistema OLAP. Come già spiegato, il primo consiste di concetti OLAP puramente logici, come dimensioni, gerarchie, cubi e relativi attributi. Il secondo invece modella le strutture fisiche che realizzano le entità logiche; per questo motivo viene denominato deployment model, ovvero modello realizzativo. Un modello logico può essere concretizzato da più di un deployment model, magari relativi a strutture dati diversi, come un database relazionale o uno multi-dimensionale. Le mappature tra le entità logiche alle rispettive fisiche vengono realizzate mediante il package Transformation. L utente può dunque creare un modello logico consistente di dimensioni, gerarchie, livelli e cubi, definizioni che rappresentano come l utente finale vede il sistema da un punto di vista del business, e definire le corrispondenze con una realtà fisica sottostante. Si intendono descrivere nel dettaglio i passi esecutivi dell applicazione, visualizzati in figura 5.3. Innanzitutto vi è la connessione al database relazionale che diventerà la risorsa fisica da cui estrarre i dati per l analisi; se ne estraggono dunque i metadati relativi a tabelle, colonne, chiavi e indici. L utente definisce un modello di analisi OLAP, costituito dunque da dimensioni, fatti, gerarchie, livelli e misure; provvede dunque a mappare tali entità e i rispettivi attributi ai corrispettivi metadati appena estratti, relativi alla risorsa fisica. L applicazione provvede dunque alla creazione, a partire dai metadati estratti, di istanze dei meta-oggetti definiti dalle JMI/CWM; vengono rappresentate dunque istanze del meta-modello CWM riguardanti il modello relazionale, il modello OLAP e le relative corrispondenze. Tali istanze vengono quindi espresse in un file XML sfruttando le mappature definite dalla specifica XMI.

104 94 CAPITOLO 5. IMPLEMENTAZIONE Figura 5.3: Passi di esecuzione Estrazione dei metadati relazionali Il primo passo è l estrazione dei metadati relazionali dal database verso il quale si è effettuata la connessione. Ci sono diversi modi per accedere ai metadati di un database relazionale. Il linguaggio SQL mette a disposizione alcuni costrutti appositi; tale approccio ha il vantaggio di permettere l estrazione di qualsiasi tipo di informazione, presenta però due svantaggi: scrivere query SQL è tutt altro che semplice e i costrutti sono specifici per ogni vendor di database. L utilizzo delle JDBC presenta invece il fondamentale vantaggio che lo stesso codice può essere utilizzato con qualsiasi database che le supporta, con lo svantaggio che sono accessibili soltanto i metadati previsti dalle interfacce. Nella scelta dell approccio da utilizzare si è tenuto conto che lo scopo finale è esportare metadati condivisibili tramite CWM, pertanto è fondamentale che lo stesso tipo di metadati siano accessibili da tutti i tipi di database; JDBC si è pertanto rivelata la scelta ideale. L applicazione si connette dunque ad un database relazionale e ne es-

105 5.4. ESECUZIONE DELL APPLICAZIONE 95 Figura 5.4: Entità estratte trae i metadati relativi a tipi, tabelle, colonne, relazioni, chiavi ed indici: per ciascuna di queste entità estrae gli attributi principali. Il programma potrebbe essere esteso trattando anche i metadati relativi a viste e trigger, la cui estrazione è prevista dalle JDBC. La figura 5.4 evidenzia e contestualizza le entità esportate; le linee continue indicano una possessione, quelle tratteggiate una relazione. Il catalog e lo schema (in Oracle esiste solo il concetto di schema) sono le entità di più alto livello, che contengono le restanti. Lo schema di un database contiene tipi di dati primitivi, tipi definiti dall utente (UDT), tabelle e store procedure. Un tabella possiede colonne, chiavi primarie, chiavi esterne ed indici. Le chiavi e gli indici si relazionano alla colonna di riferimento e, nel caso delle chiavi esterne, alla chiave primaria con cui individuano una relazione tra tabelle. Le colonne sono caratterizzate da un tipo. Prima di illustrare come CWM modella le entità relazionali appena descritte, mediante il package relational, descriviamo come sia possibile istanziare meta-oggetti rappresentanti dei metadati estratti, mediante l utilizzo delle JMI mappate allo standard CWM.

106 96 CAPITOLO 5. IMPLEMENTAZIONE Creazione dei meta-oggetti Tra l estrazione dei metadati tramite JDBC e la loro esportazione in formato CWM/XML è necessario un passo intermedio, consistente nel creare degli oggetti Java che esprimano i metadati estratti come delle entità istanze di classi del meta-modello CWM. Come già illustrato nel capitolo 3, le Java Metadata Interface sono interfacce in grado di fornire accesso ai metadati descritti da meta-modelli MOF mediante la creazione di meta-oggetti; è pertanto possibile mapparle a CWM, con la conseguente possibilità di creare e manipolare meta-oggetti CWM, ovvero oggetti Java che rappresentano specifici meta-dati. Per ogni classe CWM le JMI definiscono due classi Java: una rappresenta il meta-oggetto instance dell entità e ne descrive pertanto gli attributi, l altra invece rappresenta i meta-oggetti classproxy, già descritti nel capitolo 3, che permettono la creazione di meta-oggetti instance e fungono da contenitori degli oggetti creati, permettendone anche l accesso. Le JMI definiscono anche una classe che rappresenta meta-oggetti Package, contenente un campo rappresentante del classproxy corrispondente alla classe di ogni meta-oggetto instance appartenente al package. L appendice A mostra le interfacce Java generate a partire da alcune classi del package Core. I meta-oggetti si pongono dunque come rappresentanti di istanze del meta-modello CWM; analizziamo dunque come le entità CWM siano in grado di rappresentare i domini di nostro interesse, ovvero il modello relazionale, dimensionale e le relative mappature. L isolamento dei package, una delle caratteristiche chiave del CWM, è evidenziata; è infatti sufficiente implementare i package specifici dei domini di interesse, ignorando i restanti: pertanto il package Relational per il modello relazionale, OLAP per il modello multidimensionale e Transformation per le mappature Il modello relazionale Il package Relational appartiene al livello Resource e definisce quali metadati relazionali possono essere scambiati tramite CWM, la loro struttura e

107 5.4. ESECUZIONE DELL APPLICAZIONE 97 semantica. La figura 5.5 mostra i package da cui Relational dipende, ovvero Core, Behavior e Instance del livello Object Model, DataTypes, KeysAndIndexes del livello Foundation. La figura 5.6 evidenzia invece il diagramma Figura 5.5: Package relazionale e dipendenze delle principali classi, che descrivono schemi di database relazionali aderenti allo standard SQL99, standard selezionato grazie alla sua diffusione e al fatto di essere indipendente da uno specifico vendor. Sebbene sufficiente per lo scambio di metadati relazionali, il meta-modello non è in grado di descrivere completamente uno schema di un prodotto commerciale; si noti infatti come supporti solo gli aspetti logici dello schema, come tabelle, colonne, viste; non sono supportati invece gli aspetti fisici, come l allocazione in file degli attributi, in quanto sono tipicamente specifici di ogni vendor e non sono informazioni che solitamente è utile condividere tra più applicazioni, specialmente quando lo scopo ultimo è integrare prodotti appartenenti a vendor differenti. Non ci inoltreremo nella descrizione delle singole classi del package in quanto le si ritiene di facile comprensione; si noti però come la classe Schema raccolga tutte le informazioni relative al database. Il package Relational, con le sue ventiquattro classi, è il più ampio tra quelli presenti in CWM; è pertanto evidente come anche i meta-modelli appartenenti agli altri package siano comprensibili e trattabili.

108 98 CAPITOLO 5. IMPLEMENTAZIONE Figura 5.6: Principali classi relazionali

109 5.4. ESECUZIONE DELL APPLICAZIONE 99 Esempio di modellazione di metadati relazionali Si intende offrire un esempio di come sia possibile modellare col meta-modello CWM i metadati di un contesto relazionale. Consideriamo il caso molto semplice descritto in figura 5.7, in cui è rappresentato il fatto che in una regione sono situati molti comuni. Le entità da modellare mediante il meta-modello Figura 5.7: Esempio di schema relazionale CWM sono pertanto le tabelle Regione e Comune, le relative colonne, le chiavi primarie applicate alle colonne id regione e id comune, la relazione tra le tabelle. La figura 5.8 mostra il modello CWM risultante. Le tabelle Comune e Regione sono rappresentate come oggetti istanza della classe Table, le colonne come istanze della classe Column, i vincoli di chiave primaria ed esterna come istanze rispettivamente delle classi PrimaryKey e ForeignKey. Gli oggetti della classe Column, derivata da Feature, appartengono a un oggetto della classe Table, che eredita da Classifier, mediante l associazione Classifier.feature, mostrata in figura 5.6 a pagina 98. Gli oggetti delle classi PrimaryKey e ForeignKey sono invece posseduti dalla tabella mediante la relazione elementownership ereditata dalle classi ModelElement e Namespace, padre di Table. Infine la classe ForeignKey si relaziona alla colonna e alla chiave primaria ereditando le associazioni della classe keyrelationship del package KeysAndIndexes, di cui è figlia Il modello OLAP La figura 5.9 mostra le classi principali del meta-modello OLAP di CWM, appartenente al package Analysis: illustriamo dunque come siano in grado di rappresentare un modello dimensionale. Uno schema, rappresentato dalla

110 100 CAPITOLO 5. IMPLEMENTAZIONE Figura 5.8: Modello istanza

111 5.4. ESECUZIONE DELL APPLICAZIONE 101 Figura 5.9: Il meta-modello OLAP

112 102 CAPITOLO 5. IMPLEMENTAZIONE classe Schema, contiene tutti gli elementi di un modello OLAP ed è composto da dimensioni e cubi, rappresentati rispettivamente dalle classi Dimension e Cube. Ogni dimensione è una collezione di membri che ne rappresentano i valori possibili; in quanto ereditata da Classifier può possedere degli attributi che possono essere utilizzati per individuare i singoli membri. Le classi MemberSelection e MemberSelectionGroup permettono di selezionare soltanto un sottoinsieme dei membri di una dimensione. Mediante le classi ValueBasedHierarchy o LevelBasedHierarchy, le dimensioni possono ordinare i propri membri in gerarchie organizzate rispettivamente per valore o definendo livelli gerarchici (esprimibili con la classe Level). Una dimensione CWM può contenere un numero illimitato di attributi, livelli e gerarchie. Le classi Dimension, Hierarchy e Level sono sottotipi di Classifier, pertanto possono possedere attributi in quanto ereditano l associazione classifierfeature; tale scelta progettuale permette all utente di mantenere una separazione dei costrutti tra i diversi livelli logici di dettaglio, ovvero tra cosa è esposto a livello dimensione, cosa a livello gerarchia e cosa a livello livello. Costrutti appartenenti a livelli logici differenti sono poi mappati tra loro mediante le strutture fornite dal package Transformation. Una gerarchia organizzata in livelli è inoltre composta di entità denominate HierarchyLevelAssociation, che definiscono l appartenenza di un determinato livello ad una precisa gerarchia, e permettono di specificare l ordinamento rispetto ai restanti livelli. La figura 5.10 riassume i diversi livelli logici rappresentabili dal meta-modello a cui possono essere aggregati i dati: dimensione, livello e gerarchia, associazione gerarchia-livello. Un cubo è una collezione di valori descritti da un medesimo insieme di dimensioni, ciascuna dei quali ne rappresenta concettualmente un lato; precisamente una cella del cubo contiene un valore per ogni misura contenuta, esprimibile mediante la classe Measure ereditata da Attribute. Le associazioni tra dimensioni e cubi sono rappresentati con la classe CubeDimensionAssociation. I cubi sono costruiti come insiemi di CubeRegion, strutture

113 5.4. ESECUZIONE DELL APPLICAZIONE 103 Figura 5.10: Livelli di dettaglio del modello logico che, rappresentando sottoinsiemi del cubo a cui si riferiscono, possono essere mappate al livello fisico. Le classi CubeDeployment e DimensionDeployment sono usate per mappare rispettivamente cubi e dimensioni alle risorse dati fisiche, ad esempio le entità del database relazionale. Esempio di modellazione OLAP Vediamo un esempio di come i metadati estratti da un database relazionale possono essere organizzati secondo una logica dimensionale ed espressi in CWM. Immaginiamo un organizzazione che venda diverse tipologie di prodotti a clienti provenienti da svariate nazioni; la capacità di effettuare analisi degli andamenti delle vendite nel tempo offrirebbe un vantaggio decisivo per la crescita economica. Immaginiamo si desiderino analizzare i profitti, in termini di quantità e preziosità della merce venduta: potrebbe essere utile riuscire a individuare i mesi, le regioni e le linee di prodotto che massimizzino o minimizzino le rendite, ad esempio per indirizzare eventuali campagne pubblicitarie; ne deduciamo che avremmo bisogno di una dimensione temporale, una legata a coordinate geografiche ed una alle linee di prodotto vendute. Descriviamo un semplice modello di database relazionale che costituisca il modello fisico sui cui mappare le entità OLAP che saranno successivamente definite. La figura 5.11 ne mostra la struttura mediante un diagramma entità-relazione; si tratta di uno star-schema, in cui una singola tabella dei fatti