Universit degli Studi di Salerno Facolt di Scienze Matematiche Fisiche e Naturali

Corso di Basi di Dati II

Progettazione e Realizzazione di un Data Mart: un caso di studio

Vincenzo Presutto MATR:05210/00739

Premessa ............................................................................................................ 3 1 2 Dominio applicativo ....................................................................................... 3 Analisi e riconciliazione delle fonti dati .......................................................... 4
2.1 Ricognizione degli schemi .............................................................................................. 4

2.1.1 2.1.2
2.2 2.3

Ricognizione schema DB Nautica ....................................................... 5 Ricognizione schema DB CheckUp ..................................................... 6

Normalizzazione degli schemi ........................................................................................ 7 Integrazione .................................................................................................................. 7

2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 3

Preintegrazione .................................................................................. 7 Comparazione degli schemi ................................................................ 7 Allineamento degli schemi .................................................................. 8 Fusione e ristrutturazione degli schemi .............................................. 9 Definizione delle corrispondenze ........................................................ 9

Progettazione concettuale............................................................................ 11
3.1 3.2 3.3 3.4 3.5 Definizione dei fatti ..................................................................................................... 11 Costruzione dellalbero degli attributi........................................................................... 11 Potatura ed innesto ..................................................................................................... 12 Definizione delle dimensioni e delle misure .................................................................. 12 Creazione dello schema di fatto ................................................................................... 12

Progettazione logica .................................................................................... 13

4.1 SQL star schema ........................................................................................................ 14

5 6 7

Progettazione dellalimentazione .................................................................. 15 Creazione cubo multidimensionale e query MDX ......................................... 23 Navigazione cubo multidimensionale Mondrian con JPivot .......................... 29
7.1 7.2 7.3 7.4 7.5 Query MDX ................................................................................................................. 29 Vista aggregata del cubo con JPivot ............................................................................. 30 Il navigatore olap ........................................................................................................ 31 Costo testing per anni rispetto a tutti i tecnici e manutenzioni ..................................... 32 Costo testing per tecnici rispetto a tutti gli anni e manutenzioni ................................... 33

Bibliografia e sitografia...................................................................................... 34

Premessa
Lo scopo del lavoro che seguir quello di realizzare e progettare un data mart esclusivamente per scopi didattici. Per questo motivo non saranno sviluppate nel dettaglio tutte le 7 fasi di progettazione di un data mart. In particolare, si enfatizzeranno solo alcune fasi quali lanalisi e riconciliazione delle fonti dei dati, progettazione concettuale, progettazione logica ed infine la progettazione dellalimentazione. La progettazione dellalimentazione insieme allanalisi dei dati verr realizzata attraverso lutilizzo di Pentaho BI che una piattaforma di business intelligence che integra al proprio interno strumenti software come Kettle e Mondrian, ma anche altri, in grado di fornire funzionalit appropriate in tal senso. In particolare Kettle un componente di Pentaho BI responsabile del processo di Estrazione, Trasformazione e Caricamento dei dati, bench pu anche essere usato per altri scopi. Mondrian OLAP server, invece, insieme a JPivot , che una interaccia grafica via web, fornisce un motore di analisi dei dati multidimensionali.

1 Dominio applicativo
Lazienda interessata alla realizzazione del data mart la NauticaSun S.p.A. che si occupa principalmente di vendite e manutenzione di piccole e medie imbarcazioni. Lazienda ha una capillarit su tutto il territorio italiano ed composta da pi filiali dislocate per lo pi in localit marittime. In particolare, ogni filiale offre diversi servizi ed composta da tre reparti: amministrativo, esposizione ed officina. Il reparto amministrativo costituito da due uffici che si occupano di faccende che riguardano la contabilit della relativa filiale, invece il reparto di esposizione non altro che un grosso salone di circa 1000 metri quadri che funge da concessionaria dove vengono esposte le imbarcazioni da presentare ai clienti che sono interessati allacquisto. Infine il reparto officina si occupa di riparazioni delle imbarcazioni sia vendute dalla stessa azienda che da altre aziende. Comunque, la sede principale della NauticaSun S.p.A. non offre nessun tipo di servizio di esposizione e riparazioni ma composta solo da uffici amministrativi e contabili dellintera azienda.

2 Analisi e riconciliazione delle fonti dati

Lattivit di analisi riconciliazioni delle fonti dei dati, in generale, una fase molto complessa perch il pi delle volte le fonti dei dati da analizzare, ed a partire dalle quali viene sviluppato il data mart, risultano eterogenee. In particolare, la NauticaSun dispone di un sistema informativo molto grande ma lanalisi delle fonti dei dati viene eseguita solo su particolari porzioni del sistema informativo aziendale, che sono di interesse alla realizzazione del data mart. Quindi, vengono presi in considerazioni solo quelle parti del sistema informativo che si occupa di gestire informazione che riguardano la manutenzione ed i test(check-up) di verifica a seguito di una riparazione o una vendita.

2.1 Ricognizione degli schemi

Il sistema informativo di NauticaSun gestito attraverso un sistema AS/400 su cui sono presenti diversi data base relazionali ma vengono presi in considerazione solo due: il primo che chiameremo DB CheckUp che gestisce informazioni riguardanti i test delle imbarcazioni a seguito di una riparazione o vendita; il secondo, DB Nautica, gestisce informazioni generali circa le attivit eseguite in una data filiale. In particolare, esiste un data base CheckUp per ogni singola filiale le quali ad ogni riparazione effettuata devono registrare e memorizzare nel database le informazioni circa lesito dei test di una certa imbarcazione. Inoltre, presente un data base CheckUp utilizzato dalla filiale principale che mantiene informazioni circa tutti i test eseguiti da tutte le filiali. Invece, il data base Nautica utilizzato solo dalla filiale principale raccoglie informazioni circa le concessionarie affiliate con le relative officine, le vendite e le manutenzioni. I dettagli relativi alle informazioni presenti del database Nautica sono mantenuti in altri database gestiti dalle relative filiali. Per cui ogni filiale avr un database relativo alle vendite, un database relativo alla officina e manutenzione, e cosi via. Comunque, i due database presi in considerazione, DB CheckUp e DB Nautica, anche essendo omogenei, risultano scarsamente integrati e presentano sovrapposizioni e conflitti.

2.1.1

Ricognizione schema DB Nautica

Di seguito viene illustrato lo schema DB Nautica per il quale stata svolta una attenta analisi da cui non emersa nessuna particolare inconsistenza o errori.
codice cantiere Nome cantiere indirizzo codice manutenzione nome tecnico Modello imbarcazione pezzo ricambio

Tipo guasto

CANTIERE
(1,1)

(1,n)

compie

(1,1)

MANUTENZIONI
(1,n)

ha seguite da

nome P. Iva

citt

numero dipendenti codice verifica nome verifica

punteggio nome tecnico (1,1) anno

(1,n)

costo (1,n)

CONCESSIONARIA

emette
data

VERIFICA
(1,1)

modello imbarcazione

nome concessionaria

codice vendita nome venditore (1,1)

data

VENDITE

(1,n)

include

2.1.2

Ricognizione schema DB CheckUp

Di seguito viene illustrato lo schema DB CheckUp per il quale stata svolta una attenta analisi da cui non emersa nessuna particolare inconsistenza o errori.

Nome officina Id officina indirizzo

OFFICINA

(1,N)

LAVORA PER

data

Codice test

punteggio nome costo Codice fiscale

cognome nome (1,1) qualifica salario

anno

TEST
(1,N)

(1,1)

ESEGUE
(1,N)

TECNICO
(1,N)

ESPERTO EFFETTUA
Codice modello lunghezza (1,N) (1,N) (1,N)

MODELLO

stazza

IMBARCAZIONE

(1,1)

APPARTIENE
pescaggio

nome imbarcazione

Matricola imbarcazione

2.2 Normalizzazione degli schemi

Per quanto riguarda lattivit di normalizzazione degli schemi il lavoro risulta abbastanza semplificato perche gli schemi analizzati nella fase di ricognizione risultano corretti, privi di errori e modellano in modo soddisfacente il dominio applicativo. Per cui non c nulla da correggere e modificare.

2.3 Integrazione
Il processo di integrazione suddiviso in pi fasi il cui obbiettivo creare uno schema riconciliato globale risolvendo i problemi evidenziati nella precendente fase.

2.3.1

Preintegrazione

La fase di integrazione consiste di una ulteriore analisi mirata a definire la politica di integrazione. In questo caso si decide di non eliminare porzione degli schemi sorgenti per cui vengono integrati cosi come sono. La strategia di integrazione adottata , per forza, quella binaria.

2.3.2

Comparazione degli schemi

Questa fase consiste in una vera propria analisi comparativa degli schemi sorgenti mirata a individuare eventuali conflitti o correlazioni dei concetti espressi negli stessi schemi. I tipi di conflitti che possono essere evidenziati ricadono nelle seguenti quattro categorie: Conflitti di eterogeneit: dalla analisi comparativa degli schemi non sorgono conflitti di eterogeneit in quanto essi essendo modellati con lo stesso formalismo grafico non presentano discrepanze causate da diversi poteri espressivi. Conflitti sui nomi: CANTIERE: nello schema DB Nautica il nome di una entit, nello schema DB CheckUp viene usato il nome officina come sinonimo per indicare lo stesso concetto tramite l entit OFFICINA. Nello schema riconciliato si utilizza il nome officina. Lo stesso ed identico discorso vale per gli attributi id cantiere e nome cantiere dellentit CANTIERE.

VERIFICA: nello schema DB Nautica il nome di una entit, nello schema DB CheckUp viene usato il nome test come sinonimo per indicare lo stesso concetto tramite l entit TEST. Nello schema riconciliato si utilizza il nome test. Lo stesso ed identico discorso vale per lattributo codice verifica dellentit VERIFICA. Conflitti semantici: i due schemi non presentano conflitti semantici in quanto modellano con lo stesso livello di dettaglio ed astrazione. Conflitti strutturali: TECNICO: nello schema DB CheckUp rappresenta il nome di una entit mentre nello schema DB Nautica il nome di un attributo della entit MANUTENZIONI. Nello schema riconciliato globale si sceglie di rimanere tale concetto come entit TECNICO. MODELLO: nello schema DB CheckUp rappresenta il nome di una entit mentre nello schema DB Nautica il nome di un attributo della entit MANUTENZIONI. Nello schema riconciliato globale si sceglie di rimanere tale concetto come entit MODELLO. Propriet inter schema: la relazione LAVORA PER tra lentit TECNICO ed OFFICINA stata rimossa e non compare nello schema riconciliato perche non ritenuta necessaria. Invece, stata creata una nuova relazione EFFETTUATA DA tra le entit TECNICO e MANUTENZIONI. Infine, stata creata la relazione DI tra le entit VENDITA e IMBARCAZIONE. Eliminazione delle ridondanze: nello schema DB Nautica lattributo nome concessionaria dell entit VENDITE del tutto ridondante perche il concetto di concessionaria espresso dalla entit CONCESSIONARIA in relazione con VENDITE. Nello schema riconciliato viene eliminato tale attributo.

2.3.3

Allineamento degli schemi

Lobbiettivo di questa fase quello di risolvere i conflitti evidenziati o trovati al passo immediatamente precedente a questo attraverso delle primitive di trasformazione applicate agli schemi locali o quello riconciliato. Comunque, nel nostro caso, abbiamo anticipato questa fase includendo tutto nella fase precedente evidenziando ma anche risolvendo i conflitti, discutendo

delle soluzioni applicate per la risoluzione dei conflitti mediante delle trasformazioni direttamente allo schema riconciliato. Quindi per maggiori dettagli leggere il paragrafo precedente.

2.3.4

Fusione e ristrutturazione degli schemi

La fusione degli schemi DB Nautica e DB CheckUp avvenuta attraverso la sovrapposizione o fusione dei concetti espressi mediante le entit OFFICINA E TEST collegando i restanti concetti provenienti dagli schemi di partenza. Lo schema riconciliato illustrato alla pagina successiva.

2.3.5

Definizione delle corrispondenze

Loutput della fase di analisi e riconciliazione delle fonti oltre ad essere lo schema riconciliato costituito anche dalle corrispondenze tra gli elementi di questultimo e quelli degli schemi locali. In generale, quello che si fa per stabilire una corrispondenza tra i due livelli definire i concetti dello schema globale in termini dei concetti degli schemi locali. Questo approccio conosciuto come GAV ovvero Global As View il quale pi precisamente prevede che ad ogni concetto dello schema globale associata una vista il cui significato definito in base ai concetti rappresentati negli schemi locali.

Nome officina Id officina indirizzo

codice manutenzione

tipo guasto

pezzo ricambio

OFFICINA

(1,N)

compie

(1,1)

MANUTENZIONE

(1,N)

effettuata da

(1,1)

(1,N)
codice fiscale nome tecnico cognome

ha
P. Iva nome concessionaria

citt numero dipendenti

seguite da
punteggio

(1,N) (1,N)
TECNICO

qualifica

(1,N)
CONCESSIONARIA

data

codice test

salario durata nome test

(1,N)

(1,N)
include

(1,1)

(1,1)
TEST

(1,1)

esegue

(1,N)
emette
codice vendite data

esperto
lunghezza nome modello codice modello stazza

costo

nome venditore

effettua

(1,1)
VENDITE

(1,N) (1,N)
matricola imbarcazione nome imbarcazione

MODELLO

pescaggio

(1,1)

(1,N)

(1,N)
di

(1,1)

IMBARCAZIONI

(1,1)

appartiene a

3 Progettazione concettuale
La progettazione concettuale consiste nella creazione degli schemi di fatto, a partire dallo schema riconciliato, per quei fatti che sono di interesse al processo decisionale della azienda. In particolare la tecnica per la progettazione concettuale di un data mart consiste di pi passi che descriveremo di seguito.

3.1 Definizione dei fatti

La progettazione concettuale inizia proprio con la scelta dei fatti a partire da una entit dello schema riconciliato oppure una relazione. In questultimo caso sarebbe necessario il processo di reificazione. Comunque il fatto scelto in questo caso TESTING che corrisponde alla entit TEST dello schema riconciliato.

3.2 Costruzione dellalbero degli attributi

Lalbero degli attributi una albero gerarchico che viene costruito a partire dallo schema riconciliato e una entit F designata come fatto. Lalbero costruito deve soddisfare i seguenti requisiti. Ogni vertice corrisponde ad un attributo dello schema riconciliato, la radice corrisponde alla chiave primaria della entit F identificata come fatto e infine per ogni vertice v dellalbero lattributo corrispondente determina funzionalmente tutti gli attributi corrispondenti ai vertici discendenti di v. Lalbero degli attributi dello schema riconciliato, nel nostro caso, il seguente:
pezzo ricambio nome officina indirizzo citt P. Iva Concessionaria ria id officina tipo guasto nome test punteggio data nome venditore matricola imbarcazione anno cognome lunghezza qualifica salario costo data stazza pescaggio nome modello codice modello nome imbarcazione

nome concessionaria

numero dipendenti

codice manutenzione

codice test

codice vendite

nome tecnico

codice fiscale

3.3 Potatura ed innesto

A seguito di innesti e potature lalbero degli attributi modificato il seguente:

punteggio

nome Concessionaria ria

nome officina

tipo guasto

codice test

anno citt costo nome tecnico

3.4 Definizione delle dimensioni e delle misure

Le dimensioni scelte sono durata, data e codice manutenzione. In particolare la dimensione durata verr arricchita con una gerarchia di attributi dimensionali minuti, ore, giorni; mentre la dimensione data verr arricchita con gli attributi dimensionali settimana, mese trimestre, anno e infine verr arricchita la dimensione codice manutenzione con lattributo dimensionale regione. Per quanto riguarda le misure esse sono costo test e punteggio massimo.

3.5 Creazione dello schema di fatto

Lo schema di fatto risultante per il fatto TESTING il seguente:

tecnico

nome concessionaria ria

nome officina

tipo guasto

TESTING Costo Punteggio

anno

citt

4 Progettazione logica
La progettazione logica, in generale, prevede di costruire uno schema a stella a partire dagli schemi di fatto creati nella progettazione concettuale. In particolare uno schema a stella composto da: Un insieme di relazioni DT1,..,DTn, chiamate dimension table, ciascuna corrispondente ad una dimensione. Ogni DTi caratterizzata da una chiave primaria e da un insieme di attributi che descrivono le dimensioni di analisi a diversi livelli di aggregazione. Una relazione FT, chiamata fact table, che importa le chiavi di tutte le dimension table. La chiave primaria di FT data dallinsieme delle chiavi esterne dalle dimension table. FT contiene un attributo per ogni misura. Nel nostro caso lo schema a stella per il fatto TESTING il seguente:

dim_manutenzione
manutenzione_id tipo guasto nome officina nome concessionaria citt

dim_tecnico
tecnico_id nometecnico

dim_durata
anno_id

fact_TESTING
tecnico_id anno_id manutenzione_id costo testing punteggio

anno

Non viene effettuata nessuna snowflakeizzazione dello schema a stella ma rimane cosi come .

4.1 SQL star schema

DROP DATABASE IF EXISTS DW_simpleTesting_2; CREATE DATABASE DW_simpleTesting_2; USE DW_simpleTesting_2; -- TECNICO dimension CREATE TABLE dim_TECNICO ( tecnico_id BIGINT NOT NULL PRIMARY KEY, nome_tecnico VARCHAR(255), codice_tecnico BIGINT NOT NULL ); CREATE UNIQUE INDEX idx_dim_TECNICO_pk ON dim_TECNICO ( tecnico_id ); CREATE INDEX idx_dim_TECNICO_lookup ON dim_TECNICO ( nome_tecnico ); -- ANNO dimension CREATE TABLE dim_ANNO ( anno_id BIGINT NOT NULL PRIMARY KEY, anno VARCHAR(255), cod_test BIGINT ); CREATE UNIQUE INDEX idx_dim_ANNO_pk ON dim_ANNO ( anno_id ); CREATE INDEX idx_dim_ANNO_lookup ON dim_ ANNO ( durata ); -- MANUTENZIONE dimension CREATE TABLE dim_MANUTENZIONE ( manutenzione_id BIGINT NOT NULL PRIMARY KEY, tipo_guasto VARCHAR(255), nome_officina VARCHAR(255), nome_concessionaria VARCHAR(255), citta VARCHAR(255), cod_officina BIGINT, cod_concessionaria BIGINT, cod_manuten BIGINT ); CREATE UNIQUE INDEX idx_dim_MANUTENZIONE_pk ON dim_MANUTENZIONE ( manutenzione_id ); CREATE INDEX idx_dim_MANUTENZIONE_lookup ON dim_MANUTENZIONE ( nome_officina );

-- fact table CREATE TABLE fact_TESTING ( fact_id BIGINT NOT NULL PRIMARY KEY, anno_id BIGINT, tecnico_id BIGINT, manutenzione_id BIGINT, costo_testing BIGINT, punteggio BIGINT );

5 Progettazione dellalimentazione
Il processo di alimentazione del data warehouse TESTING pu avvenire sia direttamente dalle sorgenti operazionali e sia dal livello riconciliato che come sappiamo consiste di una fusione delle sorgenti operazionali, per dirla molto brevemente, con particolari aggiustamenti. In particolare in questo caso di studio dellazienda NauticaSun il datawarehouse TESTING stato alimentato proprio a partire dal livello riconciliato. Comunque, nel processo di alimentazione di un datawarehouse giocano un ruolo fondamentale i cos detti strumenti ETL(Extraction Transformation Loading) i quali consistono di 4 processi distinti, ovvero: extraction, transformation, cleaning e
loading.

Tutto ci stato fatto usando il tool automatico Pentaho Data Integration meglio conosciuto come Kettle che un componente della Suite PentahoBI server. Una procedura ETL in Kettle un file XML prodotto dalleditor grafico Spoon e mandato in esecuzione con Pan, nel caso di trasformazioni sottoforma di file xml .ktr o da repository, oppure con Kitchen, nel caso di job sottoforma di file .kjb o da repository. Per cui quello che abbiamo fatto estrarre i dati di interesse dal database riconciliato e caricarli nel datawarehouse tramite kettke e tale processo illustrato nella figura della pagina seguente:

In pratica il processo di alimentazione tramite kettle consistito di una sola trasformazione(non intesa come operazione di ETL ma come procedura di kettle) con una serie di Step ed Hop. Loperazione fondamentale fatta in questo processo di alimentazione stata quella di Lookup/update tramite luso degli Step Combination LookUp/Update e Update, come si pu notare dallimmagine. Pi in particolare lintero processo stato eseguito a partire da una estrazione dei dati dalla sorgente operazionale attraverso il passo chiamato Table Input. Tramite tale passo abbiamo proprio materialmente prelevato i dati dalla sorgente, ovviamente siamo andati a prendere solo quelli che ci interessavano per il popolamento del datawarehouse attraverso una serie di Join tra le relazioni(tabelle ) presenti nella sorgente dati. Tutto ci quanto avvenuto in tale passo e che abbiamo appena descritto mostrato nella figura seguente:

Naturalmente lestrazione dei dati sorgente stata possibile perch kettle consente di effettuare connessioni a database esistenti in un modo molto semplice fornendogli alcuni parametri per la connessione. Comunque il database usato in questo caso MySql. Fatto ci, una volta prelevati i dati, il passo successivo stato quello di andare a inserire tali dati nel datawarehosuse attraverso lutilizzo dei passi di LookUp e Update, collegati tra loro tramite degli Hop che sono una rappresentazione grafica del flusso dei dati che viaggia attraverso i passi collegati mediante loro. Un generico passo di Combination Lookup/udate raffigurato di seguito

In pratica la configurazione di questo passo consiste di fornire il data base destinazione dei dati nel campo Connessioni, la tabella( dimensione ) destinazione, il campo chiave per effettuare il lookup ed infine il nome della chiave surrogata nella riga campo della chiave tecnica. In pratica, se non esiste una combinazione di lookup nella tabella destinazione lo scopo di questo passo generare una nuova chiave surrogata e inserire una riga con il campo chiave e quello della chiave surrogata. Fatto ci, una volta completato il passo di lookup, bisogna aggiornare i restanti campi della tabella destinazione e lo si fa attraverso il passo di Update che raffigurato di seguito:

Come al solito nel campo connessione mettiamo il nome del database a cui volgiamo connetterci, nel campo tabella destinazione il nome della dimensione che deve essere aggiornata, ed infine gli forniamo anche la chiave surrogata per il lookup del valore e il nome del o dei campi da aggiornare. Attraverso questo processo di utilizzo di una serie di passi di lookup ed update siamo andati a popolare le dimensioni adesso ci rimane da popolare la tabella dei fatti e lo facciamo attraverso il passo Table Output il quale non fa altro che ricevere lo stream di dati provenienti dai passi precedenti e andare a scriverlo nella tabella dei fatti. Ovviamente questo avviene configurando opportunamente tale passo e ci mostrato nella figura successiva:

Solito procedimento, indicare nome database e tabella destinazione nelle apposite label ed infine quali sono i campi da riempire nella tabella destinazione. Questultimo passo mostrato nella figura alla pagina successva:

Di seguito sono raffigurate delle immagini che mostrano una preview dei dati prelevati dalla sorgente tramite il passo Table Input e loutput dei dati nella tabella dei fatti, ovviamente nella tabella dei fatti verranno inseriti solo quei valori dei campi che sono stati specificati nel passo. Per concludere, la cosa bella di kettle che ogni processo creato con un tool grafico dove possiamo specificare cosa fare e come farlo senza scrivere codice, ma semplicemente con degli strumenti grafici.

6 Creazione cubo multidimensionale e query MDX

A questo punto una volta che abbiamo memorizzato il cubo in un database, a valle del processo di ETL, bisogna avere degli strumenti che ci permettono di poter interrogare tale cubo per elaborare i dati ed estrarre informazioni. A tale scopo ci viene in aiuto Mondrian. Mondrian e' un motore OLAP scritto in Java, esegue query scritte nel linguaggio MDX (MultiDimensional eXpressions: una specie di SQL per cubi OLAP), legge dati da un database relazionale, e presenta i risultati in formato multidimensionale attraverso un API. Quindi, per essere precisi, Mondrian e' un ROLAP (Relational) poich si basa su una base dati relazionale per ricavare i dati senza necessit di un preprocessing iniziale. In particolare, Mondrian Schema Workbench una interfaccia grafica che permette di creare e testare schemi di cubi OLAP Mondrian. Il motore Mondrian usa questi schemi di cubi per interpretare le query MDX e tradurle in SQL queries per recuperare dati da un RDBMS, per cui in pratica, processa richieste MDX con gli schemi ROLAP. Questi file di schemi sono XML metadati che sono creati e strutturati in un modo specifico. Per cui comunque la prima cosa da fare avviare il tool grafico schema workbench tramite un file .bat. Una volta avviato il programma bisogna creare una nuova connessione ad un database fornendo i parametri corretti e poi naturalmente connettersi. Tale procedimento raffigurato alla pagina successiva. E provvisto delle seguenti funzionalit: Editordi schemi integrato con il data source sottostante Testing delle query MDX Caricamento della struttura del database sottostante.

Una volta creata la connessione andiamo nella barra dei menu in altro e visitiamo il menu a tendina file, clicchiamo new schema e ci compare la interfaccia

grafica attraverso cui possiamo con una facilit estrema editare e creare il cubo graficamente, specificando quindi il fatto, le dimensioni e le misure. Alla pagina successiva mostrata una immagine di questo procedimento.

Di seguito, alla pagina successiva, possiamo vedere anche il file XML associato allo schema del cubo:

Per questioni di leggibilit riportiamo il file XML alla pagina successiva mostrandolo con pi chiarezza

<Schema name="New Schema1"> <Dimension type="StandardDimension" highCardinality="false" name="dim_durata" description="tramite questa dimensione si analizzano i test effettuati alle imbarcazioni a secondo della durata impiegata "> <Hierarchy name="dim_anno" hasAll="true"> <Table name="dim_anno"> </Table> <Level name="dim_anno" table="dim_anno" column=" anno " nameColumn=" anno " type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never"> </Level> </Hierarchy> </Dimension> <Dimension type="StandardDimension" highCardinality="false" name="dim_tecnico" description="permette di analizzare i test effettuati rispetto ai tecnici meccanici che l&#39;hanno effettuato"> <Hierarchy name="dim_tecnico" hasAll="true"> <Table name="dim_tecnico"> </Table> <Level name="dim_tecnico" table="dim_tecnico" column="nome_tecnico" nameColumn="nome_tecnico" type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never"> </Level> </Hierarchy> </Dimension> <Dimension type="StandardDimension" highCardinality="false" name="dim_manutenzione" description="permette di effettuare analisi dei test rispetto alla loro causa dovuta a guasti delle imbarcazioni "> <Hierarchy name="Hierarchy " hasAll="true"> <Table name="dim_manutenzione"> </Table> <Level name="tipo_guasto" table="dim_manutenzione" column="tipo_guasto" nameColumn="tipo_guasto" type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never"> </Level> <Level name="nome_officina" table="dim_manutenzione" column="nome_officina" nameColumn="nome_officina" type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never"> </Level> <Level name="nome_concessionaria" table="dim_manutenzione" column="nome_concessionaria" nameColumn="nome_concessionaria" type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never"> </Level> <Level name="citta" table="dim_manutenzione" column="citta" nameColumn="citta" type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never"> </Level> </Hierarchy> </Dimension> <Cube name="testing" description="si vogliono analizzare i dati rispetto all&#39;andamento dei test effettuati ad imbarcazioni a seguito di una manutenzione o riparazione per un guasto" cache="true" enabled="true"> <Table name="fact_testing"> </Table> <DimensionUsage source="dim_anno " name="dim_anno " foreignKey=" anno_id" highCardinality="false"> </DimensionUsage> <DimensionUsage source="dim_tecnico" name="dim_tecnico" foreignKey="tecnico_id" highCardinality="false"> </DimensionUsage> <DimensionUsage source="dim_manutenzione" name="dim_manutenzione" foreignKey="manutenzione_id" highCardinality="false">

</DimensionUsage> <Measure name="costo_testing" column="costo_testing" datatype="Integer" aggregator="avg" description="descrive il costo che ci &#232; voluto per effettuare il test su una certa imbarcazione" visible="true"> </Measure> <Measure name="punteggio_massimo" column="punteggio_massimo" datatype="Integer" aggregator="avg" visible="true"> </Measure> </Cube> </Schema>

Come detto in precedenza schema workbench oltre a definire un cubo multidimensionale Mondrian permette anche di definire e testare le query MDX usando ovviamente il motore mondrian per processarle. Un esempio di creazione e testing di query MDX mostrato nella figura seguente:

Comunque, la sintassi generale delle query MDX la seguente: SELECT<membercollection> ON COLUMNS, <member collection> ON ROWS FROM <cubename> WHERE<conditions>

7 Navigazione cubo multidimensionale Mondrian con JPivot

In questa fase mostreremo come possibile visualizzare e navigare il cubo multidimensionale Mondiran attraverso JPivot. In pratica, JPivot interroga Mondrian con query MDX, permettendo navigazioni OLAP come slice e dice, drill down e roll up. JPivot usa Mondrian come OLAP Server. Di seguito mostreremo graficamente la navigazione del cubo mediante questi operatori.

7.1 Query MDX

Cliccando sul tasto MDX possibile editare query MDX con JPivot:

7.2 Vista aggregata del cubo con JPivot

Di seguito una vista aggregata del cubo mediante JPivot

Alla pagina successiva sar mostrato il navigatore OLAP che possibile ottenerlo semplicemente cliccando sul tasto su cui e disegnato il cubo.

7.3 Il navigatore olap

JPivot navigator un componente JPivot che permette di effettuare le seguenti operazioni: Filtrare i dati visibili sulla tabella di pivot Slice e dice E possibile anche selezionare e deselezionare campi visibili sulla tabella di pivot.

7.4 Costo testing per anni rispetto a tutti i tecnici e manutenzioni

7.5 Costo testing per tecnici rispetto a tutti gli anni e manutenzioni

Bibliografia e sitografia

M. Golfarelli , S. Rizzi, (2006) Data Warehouse Teoria e pratica di progettazione McGraw-Hill Dispense Professore http://mondrian.pentaho.com/documentation http://www.pentaho.com http://etl-tools.info/en/pentaho/jpivot-navigator.htm