Data la necessità di manipolazione degli schema graph, che sono basati su rappresentazioni di grafi orientati ciclici o aciclici, l'architettura alla base del prototipo deve necessariamente prevedere una interfaccia grafica per l'interazione del progettista del data warehouse e dell'utente finale che dovrà interrogarne il contenuto. In fase di progettazione si è optato per un applicativo unico, che permetta sia la modellazione dei grafi, sia il loro utilizzo ai fini delle interrogazioni ROLAP. Il prototipo lavorerà sui meta-dati delle history delle versioni degli schemi, appoggiandosi ad un dbms server. Pur trattandosi di un prototipo, uno dei requisiti che ci siamo posti in fase di progettazione è stata la ricerca della maggiore indipendenza dalle possibili architetture di sistema, affinché questo si potesse ben integrare con il numero maggiore di implementazioni già esistenti.
La figura 5.1 mostra un diagramma UML dei casi d'uso del progettista di data warehouse. Come abbiamo già visto nel capitolo precedente, l'operazione iniziale del progettista sarà quella di creare una history ed una versione iniziale. Attraverso una serie di operazioni di modifica alla versione corrente verranno aggiunte o eliminate delle dipendenze funzionali (
), oppure inseriti o cancellati degli attributi (
). La serie di operazioni elementari di modifica andrà a comporre una transazione, che il progettista deciderà di applicare una volta terminata questa fase. L'applicazione di una transazione di modifiche farà scattare la richiesta di aumento, ed al progettista verrà richiesto se arricchire con le informazioni appena aggiunte le versioni precedenti a quella attuale. Nel caso il progettista decida di eseguire l'aumento, per ogni operazione elementare deve essere gestito il controllo o la migrazione dei dati corrispondenti. Come ultimo caso d'uso del progettista, bisogna anche considerare la cancellazione di una versione, che può avvenire in caso di inutilità o di estrema obsolescenza di uno schema.
La figura 5.2 mostra invece il diagramma UML dei casi d'uso dell'utente, che utilizzerà il sistema solamente per la visualizzazione degli schema graph e per l'interrogazione del data warehouse sulla base delle versioni. L'esecuzione di una query ROLAP inizia con la selezione del contesto della formulazione della query, individuando una specifica versione oppure un periodo temporale. L'utente dovrà selezionare le misure i cui risultati dovranno essere mostrati e le proprietà desiderate, eventualmente con clausole di proiezione per restringere il campo della selezione. Una volta eseguita la query potrà vederne i risultati e procedere con nuove interrogazioni.
La figura 5.3 mostra un tipico esempio dell'utilizzo di questo prototipo, i cui componenti sono distribuiti all'interno di una LAN o WAN. L'applicazione DWers può risiedere nei pc client del progettista e degli utenti, indipendentemente dal sistema operativo utilizzato, i meta-dati possono essere salvati in locale oppure messi a disposizione attraverso un repository rsync, ftp o SMB, mentre il dbms server fornirà i dati estensionali necessari per le interrogazioni. Nell'esempio è presente anche una architettura di firewalling, per incrementare il livello di sicurezza dei dati contenuti nel DBMS. In fase di progettazione e modellazione del data warehouse, non sarà necessario avere a disposizione la connessione con il DBMS server. L'analisi dell'architettura di rete a supporto del sistema di gestione del versioning esula dal contesto di questo lavoro di tesi, quindi daremo una serie di assunti ed ignoreremo le problematiche di sicurezza e di connettività:
La figura 5.4 mostra chiaramente attraverso un diagramma UML dei componenti la distribuzione e le connessioni tra i diversi elementi che compongono l'architettura. In fase di implementazione del prototipo sono state fatte delle scelte architetturali e sono state individuate alcune componenti software che abbiamo deciso di utilizzare per la realizzazione di DWers. Dati i requisiti di indipendenza dall'architettura dei client e la necessità di utilizzare dei driver standard per la connessione con il database relazionale, la scelta del linguaggio di programmazione è ricaduta immediatamente su Java. Per quanto riguarda il formato dei meta-dati, è stato scelto il linguaggio XML, data la sua estrema flessibilità e potenzialità di manipolazione ed interrogazione, come vedremo nella sezione successiva di questo capitolo. Per la realizzazione sono state utilizzate inoltre queste componenti software, già disponibili sotto licenza libera in rete:
In seguito vedremo alcuni degli aspetti progettuali relativi a queste componenti, ma prima è necessario approfondire le necessità di elaborazione riguardanti i meta-dati relativi alle history delle versioni per il data warehouse, punto di partenza della progettazione del prototipo.