VALUTAZIONE COMPARATIVA E CRITERI PER LA SCELTA DI STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE PER LA PUBBLICA AMMINISTRAZIONE DEL FVGTesi

UNIVERSITÀ DEGLI STUDI DI TRIESTE
Facoltà di Ingegneria
Corso di Laurea in Ingegneria informatica
VALUTAZIONE COMPARATIVA E CRITERI PER LA SCELTA DI
STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE PER
LA PUBBLICA AMMINISTRAZIONE DEL FVG
Relatore: Laureando:
Chiar.mo Prof. Fulvio Sbroiavacca Tomaž Ceh
Correlatore:
Dott. Gianluca Leani

INDICE
INDICE ..............................................................................................................................................3
INTRODUZIONE.................................................................................................................................4
1. BUSINESS INTELLIGENCE...............................................................................................................7
2. DATA WAREHOUSE DI RIFERIMENTO.........................................................................................10
3. ESIGENZE DELLA PUBBLICA AMMINISTRAZIONE REGIONALE IN TERMINI DI BUSINESS
INTELLIGENCE.................................................................................................................................15
4. OPEN SOURCE NELLA PUBBLICA AMMINISTRAZIONE BASI LEGALI..............................................17
5. STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE..............................................................21
6. VALUTAZIONE COMPARATIVA....................................................................................................60
7. CONCLUSIONI .............................................................................................................................66
RINGRAZIAMENTI...........................................................................................................................68
ACRONIMI......................................................................................................................................69
DEFINIZIONI....................................................................................................................................71
INDICE DELLE FIGURE......................................................................................................................73
INDICE DELLE TABELLE....................................................................................................................75
BIBLIOGRAFIA.................................................................................................................................76
3

INTRODUZIONE
I. Prefazione
Il progresso tecnologico ha permesso di raccogliere, elaborare e immagazzinare una
grande mole di dati in modo del tutto automatico. Tecnologie di comunicazione come
internet, hanno reso possibile la condivisione di questi dati sul piano globale ampliando
notevolmente gli orizzonti di business delle singole aziende.
Questa migrazione ha reso il mondo industrializzato e in particolar modo il mercato,
entità dinamiche, dove i dati devono essere disponibili in tempo reale e devono fornire un
quadro al quanto più reale della situazione ricercata. Questo è in netto contrasto rispetto
a quanto visto fino a pochi anni fa, dove i dati erano confinati a realtà prevalentemente
locali.
I dati come tali, non rappresentano un vantaggio concreto per le aziende, se non
opportunamente analizzati e trasformati in informazioni. L’analisi dei dati è dunque il
punto chiave di ogni azienda. Permette agli organi preposti di operare scelte strategiche
volte ad offrire prodotti innovativi e concorrenziali ai propri clienti, che si traduce in un
potenziale aumento dei ricavi.
Grazie al connubio delle tecnologie informatiche e tecniche economiche è stato possibile
creare appositi strumenti, detti di Business Intelligence, che permettono ai manager di
avere un’amplia visuale sull’andamento aziendale in qualunque istante e in qualunque
luogo. Sarebbe altrimenti alquanto difficoltoso per una sola persona monitorare tutti gli
indicatori.
Sino a pochi anni fa le soluzioni di Business intelligence erano strettamente legate al
modello commerciale. La situazione è notevolmente migliorata negli ultimi anni, con
l’introduzione in diverse aziende, del modello open source come modello di business.
Questo modello a dispetto di quello commerciale, permette una maggiore flessibilità da
parte del cliente oltre che proporre uno strumento del tutto gratuito.
La pubblica amministrazione del Friuli Venezia Giulia, attraverso la sua azienda
informatica, Insiel Spa, ha da tempo introdotto la Business Intelligence come strumento di
analisi ed elaborazione di dati a fini di monitoraggio e di supporto alle decisioni.
La soluzione adottata si basa sull’impiego del software Business Objects di SAP che,
essendo una soluzione commerciale, è soggetta a una licenza che ne vincola la
distribuzione, e ad a un canone annuo di manutenzione ed assistenza.
L’introduzione di strumenti di Business Intelligence a codice sorgente aperto porterebbe a
ripercussioni positive derivanti principalmente dalla possibilità di modificare, espandere e
personalizzare la soluzione in aderenza alle esigenze dell’Amministrazione Regionale.
4

II. Obiettivi
In questa tesi di laurea sono descritte le principali piattaforme open source per la
Business Intelligence (BI) con lo scopo di valutare la possibilità, per una realtà come quella
dell’Amministrazione Regionale del Friuli Venezia Giulia, di utilizzare tali strumenti per
l’analisi dei dati finalizzata al supporto alle decisioni.
L’analisi ha preso in esame quattro software, che sono stati individuati come i più credibili
candidati per sostituire o in alternativa affiancare lo strumento commerciale di business
intelligence attualmente usato dalla pubblica amministrazione Regionale.
Lo studio è stato condotto presso la Insiel Spa, che è la società in house della Regione
Friuli Venezia Giulia, che fornisce servizi informatici ai diversi enti della Regione, durante
un periodo di tirocinio.
III. Sintesi del lavoro
Il lavoro è suddiviso in sette capitoli con una serie di sottocapitoli.
Nel primo capitolo è fatta un’introduzione alla Business Intelligence dov’è descritta la
nascita del termine, le varie versioni e le tecnologie che utilizza.
Nel secondo capitolo viene descritta l’organizzazione del Data Warehouse Regionale.
Dopo una breve introduzione viene analizzata la struttura e l’architettura di base, la
suddivisione in Data Mart, ed infine le varie tecniche di analisi dati.
Nel terzo capitolo vengono analizzate le esigenze della pubblica amministrazione
Regionale in termini di Business Intelligenze a supporto delle funzioni operative,
statistiche e di governo degli uffici regionali.
Nel quarto capitolo vengono descritte le basi legali, con estratti di leggi, relativamente
all’introduzione di software open source nella pubblica amministrazione.
Nel quinto capitolo, che rappresenta il fulcro della tesi di laurea, vengono introdotti i
software open source di BI presi in esame, ed in particolare Eclipse BIRT, Pentaho
community, Jaspersoft community e SpagoBI. Vengono qui descritte le varie licenze con
cui sono distribuiti, le funzionalità proposte, il posizionamento sul mercato dei vari
produttori, proposto dalla Gartner Group e dalla Forrester. Per ciascuna piattaforma
viene effettuata un’introduzione dove vengono elencati i componenti principali della suite
di BI, seguita da una breve descrizione dell’architettura di base. Dopo l’introduzione segue
la descrizione puntuale delle diverse funzionalità, in termini di Reportistica, analisi OLAP e
Cruscotti. In ogni punto vengono descritti i vari strumenti utilizzati con le funzionalità
proposte.
Nel sesto capitolo vengono messi a confronto i software previamente analizzati, con la
descrizione delle tecniche e delle modalità di valutazione.
5

Nel settimo ed ultimo capitolo viene formulata una conclusione sul possibile software da
adottare o in alternativa da affiancare alla soluzione commerciale in uso
dall’Amministrazione Regionale. Nel capitolo viene inoltre illustrata una possibile
evoluzione di tali sistemi all’interno della pubblica amministrazione Regionale.
PAROLE CHIAVE: Business Intelligence, open source, pubblica amministrazione, analisi
dati, Data Warehouse, Eclipse BIRT, Jaspersoft Community Edition, SpagoBI, Pentaho
Community Edition.
6

1. BUSINESS INTELLIGENCE
1.1 Storia e panoramica generale
Nel 1958 il termine BI è stato usato per la prima volta dall’inventore e ricercatore Hans
Peter Luhn, mentre lavorava alla IBM. La definì come “L’abilità di cogliere le interrelazioni
dei fatti presentati in modo tale da orientare l'azione verso l’obiettivo desiderato”.1
Nel 1989 Howard Dresner, analista presso la Gartner Group, propose la BI come termine
generico per descrivere “Concetti e metodi per migliorare il processo decisionale con
l’utilizzo di sistemi di supporto basati sui fatti”. Il suo uso si diffuse solo verso la fine degli
anni ’90.
Al giorno d’oggi la BI viene usata per riferirsi a un insieme di processi aziendali tesi a
raccogliere e analizzare informazioni. Questo è possibile grazie ad appositi software che
analizzano i dati nei vari DW o DM.
Per Forrester Research la BI è un set di metodologie, processi, architetture e tecnologie
che trasforma dati grezzi in dati comprensibili e utili per scopi direzionali. Usando questa
definizione il BI include tecnologie per l’integrazione dei dati, la verifica della qualità dei
dati, il data warehousing, il master data management, l’analisi del testo e altri incorporati
nell’information management.
I vantaggi nell’uso del BI sono molteplici e possono essere sintetizzati nei seguenti punti:
• Riduzione nei tempi di raccolta delle informazioni rilevanti
• Impiego di strumenti per la raccolta e l’analisi di informazioni
• Una panoramica più dettagliata sulla situazione generale (tendenze clienti,
nuove opportunità ecc.)
Si può concludere che la BI permette alle aziende di rimanere concorrenziali, fornendo
informazioni aggiuntive, che permettono di impostare una strategia quanto più realistica.
1.2 Versioni
Nel tempo il BI ha subito evoluzioni, fino a raggiungere la versione tre. Di seguito vengono
illustrati i vari BI e le loro principali caratteristiche.
Nella prima versione del BI le informazioni vengono raccolte per scopi direzionali interni e
per il controllo di gestione. I dati vengono opportunamente elaborati e utilizzati per
supportare le decisioni di chi occupa ruoli direzionali. In secondo luogo le informazioni
1
The ability to apprehend the interrelationships of presented facts in such a way as to guide action towards a
desired goal
7

possono essere analizzate a differenti livelli di dettaglio e gerarchico per qualsiasi altra
funzionalità aziendale come il marketing o risorse umane.
La seconda versione è stata adottata dal 2000 in poi e prende il nome dal Web 2.0. Il
nuovo BI adotta strumenti che permettono una ricerca in tempo reale (che mancano nel
primo BI) ed è fortemente orientamento al Web. Le modifiche sono state rese possibili
grazie alla nascita dei SOA che permettono maggiore flessibilità nella gestione dei dati
nonché alla moltitudine di standard open source per lo scambio di dati, come ad esempio
il XBRL.
La nuova versione cerca di allontanarsi dal classico BI, che utilizza i DW interni, a quella
orientata al Web dove le informazioni sono molte e da fonti diverse.
La terza versione sta prendendo piede ed è orientata alla Collaborative decision making. I
software basati sul nuovo BI sono predisposti per estrarre informazioni dai social network
il che gli rende al passo con i tempi. Secondo i leader del settore il nuovo BI permetterà
un radicale allontanamento dalle vecchie versioni, che avevano un basso tasso di
adattamento alle continue evoluzioni del mercato, una limitata capacità di reporting e
cruscotti non sofisticati. I principale pregio della nuova versione è quello di poter
prendere in esame i singoli profili e confrontarli con i vari modelli per trovare i dati più
rilevanti e sfruttando il “lato sociale “ si possono promuovere iterazioni sociali con altri
soggetti e aziende.
Anche la flessibilità nella personalizzazione dei “cruscotti” ricopre un ruolo importante,
perché da all’utilizzatore la possibilità di scegliere quali dati privilegiare e quali porre in
secondo piano o eventualmente rimuovere.
Sintetizzando:
• BI 1.0 Strutturato in modo da fornire una presentazione dei dati e la
memorizzazione di quest’ultimi;
• BI 2.0 Permette l’acquisizione dei dati in tempo reale eh ha un orientamento al
Web. Introduce nuovi strumenti come il KPI e scheda di valutazione bilanciata;
• BI 3.0 Interagisce con i Social network e si discosta in modo radicale dalle
vecchie versioni. Permette una maggiore flessibilità nella personalizzazione dei
“cruscotti”.
1.3 Tecnologie
La BI per esistere ha bisogno delle seguenti tecnologie informatiche (figura 1):
• Data Warehouse – archivio informatico di un organizzazione volto alla raccolta,
l’immagazzinamento e l’elaborazione dei dati.
• Applicazioni BI – strumenti (commerciali o open source) in grado di analizzare le
informazioni e restituire report (oggetto di questa tesi).
8

• Data Mining – tecniche e metodologie volte all’estrazione dell’informazione
(modelli, tendenze, strutture) da grandi quantità di dati usando tecniche
computazionali derivate dalla statistica e dal pattern recognition.
Figura 1. Principali tecnologie informatiche alla base del BI
Oltre alle tecnologie appena citate bisogna considerare anche le tecnologie di
comunicazione (es. internet) in quanto consentono la distribuzione di informazioni su
larga scala nonché la consultazione degli archivi de-localizzati.
Questo porta ad enormi vantaggi, sia nella quantità di dati disponibili (raccolti in un unico
DW) che l’accessibilità di informazioni da qualunque posto (es. utilizzando uno
smartphone).
DATA WAREHOUSE
REGIONALE
Data Mart
Meta dati
Data mining
Applicazioni di
Business
Intelligence
9

2. DATA WAREHOUSE DI RIFERIMENTO
2.1 Panoramica generale
Il DW può essere definito come un archivio informatico (contenente una grande quantità
di dati) di un’organizzazione, che raccoglie dati da diverse fonti, trasformandoli in un
formato consistente ed omogeneo. I primi studi sul DW furono condotti alla fine degli
anni ’80, ma non fu prima della nascita degli OLAP che questi ebbero una massiccia
diffusione. Gli strumenti OLAP permettono l’analisi di una grande quantità di dati in tempi
ragionevoli.
Il DW di riferimento è creato usando Data Mart (figura 2) raggruppati per specifici settori
ed alimentati a partire dalle basi dati dei diversi sistemi informativi locali.
Figura 2. Data Warehouse Regionale
Ogni base dati è considerata un patrimonio di informazione e l’utilizzo di DM, dà la
possibilità di avere un’informazione standardizzata e omogenea, sulla quale si possono
effettuare interrogazioni incrociate.
Un architettura di tipo DW permette di:
• Raccogliere in un unico punto centralizzato le informazioni disponibili nei diversi
archivi gestionali degli enti locali..
• Standardizzare le modalità e gli strumenti di interrogazione ed analisi dei dati.
Allo scopo di:
• Migliorare la condivisione dei dati.
• Velocizzare le varie operazioni
10
Area 1
Data Mart 1.2
Dimensioni
condivise
Dimensioni
condivise
Area 2
Data Mart 1.3
Data Mart 1.1
Data Mart 2.2
Data Mart 2.3
Data Mart 2.1
Dimensioni
condivise

• Uniformare i dati
2.2 Architettura
Possiamo suddividere l’architettura (figura 3) usata nel DW, che è stato preso come
riferimento in due livelli, quello di back-end (figura 4) e di front-end (figura 5).
D A T A W A R E H O U S E
R E G I O N A L E
S I S T E M A
A L I M E N T A Z I O N E
E T L
D a t a b a s e
g e s t i o n a l i
M a i n
F r a m e
D a t a M a r t
M e t a d a t i
0
20
40
60
80
100
120
140
1s t Qtr 2nd Qtr 3rd Qtr 4th Qtr
W est
East
North
S I S T E M A
B A C K E N D
S I S T E M A
F R O N T E N D
C o n s u l t a z io n e
D a t a W a r e h o u s e
I n d i c a t o r i
S t a t is t ic i
F o n t i d a t i s o r g e n t e
A n a li s i e
R e p o r t is t i c a
Figura 3. Architettura Regionale
Livello back-end
Prevede l’impiego di software di mercato per l’aggiornamento delle informazioni del DW
a supporto delle fasi di:
• data profiling - la fase in cui viene analizzato il database di origine per trovare la
struttura, il contenuto, i rapporti e le regole di derivazione dei dati. Si procede
con il recupero di tutti i dati (minimizzando la quantità di dati da spostare) e poi
a cadenze regolari, si spostano solo le variazioni che sono state apportate ai
database originari.
• data quality - la fase anche detta “cleaning” prevede la raccolta di dati estratti,
in apposite aree di “staging” dove vengono sottoposti a controllo di qualità, il
quale prevede di unificare i dati provenienti da sistemi diversi e di verificare
anomalie nei dati che hanno lo stesso contenuto.
• ETL - la fase prevede l’estrazione dei dati di origine, la trasformazione attraverso
regole prestabilite (operazioni di riorganizzazione, aggregazione,
disaggregazione) e l’aggiornamento del DM di destinazione.
• gestione repository metadati – la fase consiste nella gestione della
configurazione degli ambienti da cui provengono i dati di aggiornamento in
seguito a nuovi rilasci o attività di manutenzione.
11

R E G I O N A L E
D I R E Z I O N E 2
D a t i s o r g e n t e
D I R E Z I O N E 1
D a t i s o r g e n t e
S I S T E M A
A L I M E N T A Z I O N E
E T L
A L T R E F O N T I D A T I
E S T E R N E
D a t a b a s e
g e s t i o n a l i
M a i n
F r a m e
M e t a d a t i
D I R E Z I O N E
G E N E R A L E
Figura 4. Livello back-end
Livello front-end
Prevede l’impiego di software di BI per la consultazione e l’analisi delle informazioni nei
DM allo scopo di dare risposta all’esigenza di:
• un’informazione statistica specifica e tempestiva.
• supporto alle decisioni – per la definizione di strategie, verifica dello stato di
attuazione dei risultati, valutazione dei benefici ottenuti e dei risultati
conseguiti.
• diritti d’accesso personalizzati - per ciascun utente sono stabiliti i gradi di
accesso alle informazioni secondo competenze e ruoli.
2.3 Organizzazione in Data Mart
Un DM è un sottoinsieme (logico o fisico) di un DW, che raccoglie informazioni
specializzate di un settore o area. Il DM si alimenta a partire dalle informazioni contenute
nel DW, ed è posto “a valle“ di quest’ultimo. I pregi di utilizzare il DM sono molteplici:
• Migliori prestazioni nei tempi di risposta all’utente finale e minor carico di rete
• Strutturazione dati ottimizzata per la ricerca e l’analisi (OLAP)
• Indipendenza degli utenti (mobilità, indipendenza da altre unita
dell’organizzazioni)
12

I dati possono essere strutturati in diversi modi. Nel DM di riferimento è stata scelta la
struttura a cubo multidimensionale che utilizza lo schema a stella (o star schema) che
prevede una tavola centrale, detta FACT_TABLE o tabella fatti, che ha collegamenti
multipli con altre tabelle, dette DIMENSION_TABLE, ovvero tabelle delle dimensioni. La
fact table è una tabella che contiene molti record (con chiavi primarie) ed è l’unica ad
avere collegamenti con altri record contenuti nelle dimension table. Le dimension table
sono cosi chiamate perché in esse sono contenute un insieme di parametri che
“influenzano” il dato vero e proprio.
Sintetizzando nella FACT_TABLE sono elencati i principali elementi su cui sarà costruita
l'interrogazione (di tipo OLAP) mentre nelle DIMENSION_TABLE sono specificati come
saranno aggregati i dati.
Questo schema presenta il vantaggio di dare una rappresentazione grafica del processo,
oltre a permettere con molta facilità di mettere in relazione le informazioni di diversi DM
(figura 6).
Figura 5. Esempio data mart con strutturazione dati in schema a stella.
13

Come si può vedere dalla figura 6 un area (es. Tavolare FVG ) può contenere più di un DM
(es. Tavolare statistica o Conservazione Sostitutiva FVG Anomalie) che sono collegati tra
loro da record univoci contenuti nelle rispettive dimension table.
2.4 Tecniche di analisi
La metodologia usata per l’analisi è di tipo OLAP. Questa metodologia coniata nel 1994 da
E.F. Codd & associates, consente di analizzare ed esplorare una grande quantità di dati (da
varie prospettive) da parte di utenti le cui necessità non sono facilmente identificabili a
priori. I report prodotti con questa metodologia si chiamano report multidimensionali o
meglio conosciuti come cubi (es. vendite x prodotto x zona x giorno). La
multidimensionalità dei report consente agli utenti di visualizzare:
• Viste in dettaglio – l’utente si sceglie le combinazioni più attinenti per il
raggiungimento del suo scopo (es. vendite x zona.)
• Viste riassuntive (statistiche) – visualizzano un dato in un arco temporale ben
definito (es. totale vendite in un anno.)
La visualizzazione è possibile attraverso il software web InfoView di BO che mette a
disposizione oltre a strumenti per la ricerca anche strumenti per lo scarico di documenti
(in formato es. MS Excel). Inoltre il software appena citato permette la predisposizione di
“cruscotti” preconfezionati, costituiti da statistiche (tabelle e grafici), che si differenziano
per ogni area della Regione e della Sanità.
R E G I O N A L E
D a t a M a r t
M e t a d a t i
S I S T E M A
F R O N T E N D
0
20
40
60
80
100
120
140
1st Qtr 2nd Qtr 3rd Qtr 4th Qtr
West
East
North
A n a l i s i e
R e p o r t i s t i c a
D i r e z i o n e 1
0
20
40
60
80
100
120
140
1 st Qtr 2nd Qtr 3rd Qtr 4 th Qtr
We st
Eas t
North
A n a l i s i e
R e p o r t i s t i c a
C o n s u l t a z i o n e
I n d i c a t o r i S t a t i s t i c i
D i r e z i o n e 2
D i r e z i o n e
G e n e r a l e
S u p e r v i s i o n e e
P i a n i f i c a z i o n e
S t r a t e g i c a
I n d i c a t o r i S t a t i s t i c i
S e r v i z i o S t a t i s t i c a
I n d ic a t o r i S t a t is t ic i
Figura 6. Livello front-end
14

3. ESIGENZE DELLA PUBBLICA AMMINISTRAZIONE
REGIONALE IN TERMINI DI BUSINESS INTELLIGENCE
Nel corso degli anni la PA Regionale si è evoluta grazie al progresso tecnologico, che ha
permesso l’automazione delle attività di ufficio e dei procedimenti amministrativi, che prima
erano svolti manualmente o erano parzialmente automatizzati. Questo ha portato alla
riduzione dei tempi di espletamento delle pratiche e la semplificazione delle attività
ripetitive.
Una delle prime esigenze in termini di business intelligence fu l’esigenza per “analisi ed
interrogazioni di tipo operativo”, legate perlopiù alle necessità dei funzionari regionali di
disporre di elenchi, di stampe di dettaglio, a supporto delle attività di gestione nelle varie
fasi del procedimento amministrativo.
Queste venivano soddisfatte con stampe e report realizzati ad hoc all’interno dei diversi
gestionali, utilizzando i linguaggi di programmazione del singolo gestionale, e quindi
risultavano scarsamente riutilizzabili, non modificabili o personalizzabili da parte dell’utente.
Il tutto si traduceva in tempi di attesa, per apportare modifiche o migliorie, che dovevano
essere fatte da personale qualificato e specializzato.
A queste “prime” seguono quasi subito le esigenze statistiche, con il fine di fornire supporto
alle scelte del governo, mediante la rappresentazione del quadro della situazione socio-
economica del territorio, e della sua evoluzione nel tempo a seguito degli interventi
effettuati.
Quest’ultime venivano soddisfatte mediate elaborazioni attraverso strumenti di produttività
individuale (MS Excel, MS Access), in cui venivano raccolti i file di dati forniti all’occorrenza
dalle varie strutture regionali.
Con l’introduzione del DW nella realtà Regionale la BI è cambiata radicalmente. La
standardizzazione dei dati, la disponibilità di quest’ultimi in un unico punto centralizzato,
l’introduzione di un unico strumento standard di BI, hanno permesso di rispondere alle
esigenze legate al controllo di gestione e direzionale, attraverso strumenti di monitoraggio
finalizzati all’ottimizzazione dei processi, al controllo dei costi, all’interno della P.A.
Tutte le esigenze appena elencate sono soddisfatte con l’uso di:
• reportistica autonoma da parte dell’utente, quindi con la possibilità di:
o accedere in maniera autonoma e semplice ai contenuti informativi della
base dati;
o accesso controllato ai dati – accesso limitato solo ai dati di competenza
dell’utente interessato.
15

o possibilità di personalizzare i report con funzionalità di calcolo,
formattazione dei risultati, ecc.
• OLAP, analisi dei dati, mediante “navigazione” libera e non pre-configurata sugli
stessi, allo scopo di analizzare e descrivere un determinato fenomeno, ma anche
esplorare i fattori che lo determinano. Questo permette di:
o accedere ai contenuti informativi della base dati in maniera individuale e
del tutto autonoma.
o poter incrociare le informazioni disponibili in maniera atipica.
o predisporre di operazioni di Drill-down, Slicing, ecc.
• cruscotti / dashboard: rappresentazioni pre-confezionate messe a disposizione
degli utenti, con il fine di avere una rappresentazione grafica e in tempo reale
dei settori interessati.
Questi requisiti sono attualmente soddisfatti utilizzando il software SAP Business Objects,
che mette a disposizione in un unico strumento (Web Intelligence):
• le funzionalità per la predisposizione di reportistica di media complessità;
• le funzionalità di analisi di tipo OLAP.
Tale soluzione è accessibile attraverso un browser web.
SAP Business Objects permette di definire modelli di business (“universi BO”) che
rappresentano la collezione di oggetti (dimensioni e misure) disponibili per l’analisi,
mappando quindi in maniera trasparente per l’utente finale la complessità del database, e
non richiedendo all’utente la conoscenza di linguaggi d’interrogazione (sql o mdx).
Per quanto riguarda la predisposizione di cruscotti, SAP fornisce un ulteriore software
acquistabile separatamente, XCelsius, che permette la creazione di dashboard interattivi
in ambiente Flash.
Tale software è integrato con Web Intelligence per quanto riguarda l’alimentazione
dinamica dei dati dei cruscotti, tuttavia la definizione di tale integrazione risulta
macchinosa.
16

4. OPEN SOURCE NELLA PUBBLICA AMMINISTRAZIONE BASI
LEGALI
La definizione di “open source” è stata introdotta ufficialmente nel sistema giuridico italiano
nel giugno 2002 con la pubblicazione del documento “Linee guida del Governo per lo
sviluppo della Società dell’Informazione nella legislatura” da parte dell’allora Ministro per
l’Innovazione e le Tecnologie on. Stanca. Un estratto dal documento: “Si diffonderanno gli
standard aperti e i software open source, cioè i software liberi, la cui proprietà non sia di un
singolo fornitore ma governati da una licenza d’uso che ne garantisce la possibilità di libero
utilizzo, scambio, studio e modificabilità.”
Il documento appena citato contiene un intero paragrafo dedicato all’open source: “Va fatta
un’approfondita valutazione, in linea con quanto sta facendo l’Unione Europea, sulla
strategia open source per la pubblica amministrazione. I prodotti open source (per
caratteristiche intrinseche derivanti dalle stesse modalità di sviluppo e di evoluzione)
determinano vantaggi in termini di: - contenimento dei prezzi - trasparenza (e quindi
sicurezza) - non dipendenza da un singolo fornitore - elevata riusabilità - accessibilità per le
piccole realtà di sviluppo (economie locali) In qualità di semplice utilizzatore, la pubblica
amministrazione può quindi immediatamente rivolgersi al mercato dei prodotti open source
per ridurre in modo consistente e rapido i costi di acquisizione e gestione di molte
applicazioni software. Questo è vero per le piattaforme per servizi web, per gli ambienti
operativi dai personal computer ai sistemi centrali, a molti strumenti di produttività
individuale. Inoltre, in qualità di catalizzatore, per la dimensione della domanda che
rappresenta e per la possibilità di aggregare e supportare piccole realtà di sviluppo e
ricerca, creando la necessaria massa critica, la pubblica amministrazione può avvantaggiarsi
del modello open source in vari modi, tra i quali lo sviluppo di infrastrutture software
per la connettività multicanale, lo sviluppo di piattaforme di
interoperabilità, di soluzioni specifiche per la pubblica amministrazione e di piattaforme
strategiche per il Paese (ad esempio quelle di e-learning ed e-Health) “.
Nei mesi seguenti fu istituita la commissione per “l’indagine conoscitiva sul software a
codice sorgente aperto nella Pubblica amministrazione “, un estratto: “...a tale fenomeno
si collegano tematiche sociali, quali il tema della circolazione del sapere, delle libertà di
divulgazione scientifica dei risultati della ricerca ed il dibattito sulle questioni connesse con
la tutela del diritto d'autore. Inoltre, la diffusione dell'informatica presso i cittadini è
talmente estesa che qualunque intervento nella pubblica amministrazione, relativo alla
circolazione di documenti o dati con i cittadini, ha implicazioni diffuse; in particolare, il tema
dei formati aperti è destinato ad avere un impatto sul rapporto fra pubblica
amministrazione e cittadini, stimolando la cultura della condivisione”. Ne consegue che alle
pubbliche amministrazioni è stato imposto di non vietare e di non penalizzare l'utilizzo di
pacchetti open source. Il criterio della scelta doveva essere fatto esclusivamente sulla base
economica (value for money).
La prima ricaduta legislativa ci fu nel 2003 con la direttiva Stanca (Sviluppo ed utilizzazione
dei programmi informatici da parte delle pubbliche amministrazioni) che fu la base per il D.
Lgs. 82/05 (Codice dell'amministrazione digitale). Nella direttiva si legge che le pubbliche
17

amministrazioni, nella predisposizione o nell'acquisizione dei programmi informatici,
devono privilegiare le soluzioni che presentano le seguenti caratteristiche:
• soluzioni informatiche che, basandosi su formati dei dati e interfacce aperte e
standard, assicurino l'interoperabilità e la cooperazione applicativa tra i diversi
sistemi informatici della pubblica amministrazione, salvo che ricorrano peculiari ed
eccezionali esigenze di sicurezza e segreto;
• soluzioni informatiche che, in assenza di specifiche ragioni contrarie, rendano i
sistemi informatici non dipendenti da un unico fornitore o da un'unica tecnologia
proprietaria; la dipendenza e' valutata tenendo conto dell'intera soluzione;
• soluzioni informatiche che, con il preventivo assenso del C.N.I.P.A ed in assenza di
specifiche ragioni contrarie, garantiscano la disponibilità del codice sorgente per
ispezione e tracciabilità da parte delle pubbliche amministrazioni, ferma la non
modificabilità del codice, fatti salvi i diritti di proprietà intellettuale del fornitore e
fermo l'obbligo dell'amministrazione di garantire segretezza o riservatezza;
• programmi informatici che esportino dati e documenti in più formati, di cui
almeno uno di tipo aperto.
La direttiva inoltre dava la possibilità alla PA di scegliere programmi creati ad-hoc e
riutilizzare quest’ultimi in altre amministrazioni e di utilizzare programmi dotati di licenze
d’uso o open source.
Seguirono altri interventi legislativi come il D. Lgs. del 7 marzo 2005, n. 82, art. 68, comma 1,
lettera D “Codice dell'amministrazione digitale” e la sua modifica e integrazione con il D.
Lgs. n. 159 del 4 aprile 2006, “Disposizioni integrative e correttive al decreto legislativo n. 82
del 7 marzo 2005, recante codice dell'amministrazione digitale”.
Con la Legge n. 296, art. 1, comma 892-895 del 27 dicembre 2006, “Disposizioni per la
formazione del bilancio annuale e pluriennale dello Stato “, legge finanziaria 2007 era stato
istituiva un Fondo di 30 milioni di Euro per il triennio 2007-2010 al fine di sostenere la
realizzazione di progetti per la società dell'informazione, dando priorità ai progetti che
utilizzano e/o sviluppano applicazioni software a codice aperto.
Il D. Lgs. n. 177 del 1 dicembre 2009 il C.N.I.P.A è stato trasformato in DigitPA. I suoi compiti
sono quelli di consulenza e di proposta, l’emanazione di standard e regole, la creazione di
guide tecniche, la valutazione, il monitoraggio è il coordinamento ed infine la gestione dei
progetti di innovazione.
Di recente, grazie al governo Monti, con il decreto “Salva Italiai
” è stata introdotta nell’ art.
29-bis la parziale modifica dell’art. 68 comma 1 del D. Lgs. n. 82 del 7 marzo 2005 (“codice
dell'amministrazione digitale”) che impone alle pubbliche amministrazioni, nel caso di
acquisizione di programmi informatici, di fare una valutazione comparativa di tipo tecnico
ed economico tra le varie soluzioni presenti sul mercato, ovvero anche quelli di tipo open
source. Tuttavia questa modifica non imponeva alle pubbliche amministrazioni di scegliere
la soluzione open source nel caso risulti equivalente a una commerciale.
18

Questa “mancanza” è stata colmata grazie alla recente legge n. 134 del 7 agosto 2012
Conversione in legge, con modificazioni del D.L. n. 82 del 22 giugno 2012 recante misure
urgenti per la crescita del paese che prevede la modifica del D. Lgs. del 7 marzo 2005, n. 82,
art. 68, comma 1, lettera D “Codice dell'amministrazione digitale” sostituendolo con:
1. Le pubbliche amministrazioni acquisiscono programmi informatici o parti di essi a seguito
di una valutazione comparativa di tipo tecnico ed economico tra le seguenti soluzioni
disponibili sul mercato:
a) software sviluppato per conto della pubblica amministrazione
b) riutilizzo di software o parti di esso sviluppati per conto della pubblica amministrazione
c) software libero o a codice sorgente aperto
d) software combinazione delle precedenti soluzioni. Solo quando la valutazione
comparativa di tipo tecnico ed economico dimostri l'impossibilita' di accedere a soluzioni
open source o già sviluppate all'interno della pubblica amministrazione ad un prezzo
inferiore, e' consentita l'acquisizione di programmi informatici di tipo proprietario
mediante ricorso a licenza d'uso. La valutazione di cui al presente comma e' effettuata
secondo le modalità e i criteri definiti dall'Agenzia per l'Italia Digitale, che, a richiesta di
soggetti interessati, esprime altresì parere circa il loro rispetto.
Si può concludere che la nuova normativa privilegia l’open source e considera il ricorso a
software proprietario solo nel caso non ci siano soluzioni alternative a codice sorgente
aperto o libero.
Nell’ambito dell’Unione Europea sono state varate specifiche, per la promozione e
diffusione del codice open source, sia per il settore privato, che quello pubblico. Dal 2005
fino al 2010 era attivo il progetto IDABC ovvero interoperabilità dei servizi europei di
governo elettronico nei confronti delle pubbliche amministrazioni.
Questo progetto aveva lo scopo di promuovere l’integrazione delle procedure operative tra
stati membri, nonché di incoraggiare e sostenere la fornitura di servizi transfrontalieri del
settore pubblico ai cittadini e alle imprese in Europa utilizzando le opportunità offerte dalle
tecnologie dell'informazione e della comunicazione. Nel 2010 e stato sostituito dall’ISA,
l’acronimo sta per “intercambio di dati fra le Amministrazioni”. Questo progetto adotta un
approccio più pratico nel supportare le varie amministrazioni e facilita le comunicazioni fra
di esse.
Il progetto ha una durata di 6 anni (fino alla fine del 2015) ed avrà a disposizione un budget
complessivo di 164 milioni per intervenire sul:
• Quadro generale di supporto all'interoperabilità (policies, strategie, specifiche,
metodologie, linee guida ed altri documenti, pubblicazioni ed approcci.)
19

• Strumenti di uso generale, riutilizzabili (sistemi di dimostrazione, reference,
piattaforme condivise e di collaborazione, componenti comuni e simili elementi
condivisibili per le esigenze degli utenti, a prescindere dal campo di applicazione)
• Servizi di uso comune (applicazioni operative ed infrastrutture di natura generica
per andare incontro alle richieste degli utenti, a prescindere dal campo di
applicazione.)
• Analisi dal punto di vista delle ICT, per l'implementazione di una nuova legislazione
Comunitaria su questi aspetti.
La Commissione Europea ha già stanziato i fondi per il 2013 e nel 2010 sono stati stanziati
ulteriori 26 milioni di euro per il supporto alla cooperazione applicativa nel settore pubblico
degli Stati europei.
A fronte di tali considerazioni si può concludere che esiste una base legale per l’introduzione
del software open source nella pubblica amministrazione. Nello specifico la legislazione
italiana impone ai vari enti di valutare anche le soluzioni open source nel caso di
acquisizione di nuovo software e di ricorrere a software proprietario solamente nel caso non
ci siano equivalenti soluzioni a codice sorgente aperto
20

5. STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE
5.1 INTRODUZIONE
Gartner Group definisce la business intelligence come una piattaforma software
(commerciale o open source) che offre una serie di funzionalità che possono essere
suddivise in tre grandi categorie:
• Integrazione (integration)
• Consegna di informazioni (information delivery)
• Analisi di informazioni (information analysis)
La maggior parte dei progetti di business intelligence si concentrano sul secondo punto
ovvero la consegna di informazioni. C’è tuttavia un crescente interesse per l’analisi di
informazioni, allo scopo di trovare nuove “conoscenze” ed implementarle.
Come già accennato la consegna delle informazioni costituisce il componente chiave di
ogni software di business intelligence (commerciale e open source). Di seguito vengono
illustrate alcune delle principali funzionalità che fanno parte di questa categoria:
• Reporting – report cartacei o elettronici contenenti informazioni riassuntive
(tabelle, grafici, ecc.)
• Cruscotti (dashboard) – sono una serie di report grafici (es. semafori, torte) che
permettono una visualizzazione semplificata per l’utente finale.
• Ricerche ad hoc (ad-hoc query) – possibilità di ricerche dettagliate (da remoto o
locale)
• Modelli KPI –sono modelli che permettono di monitorare l’andamento di un
processo aziendale.
• Analisi OLAP – analisi da prospettive diverse, fatte su database
multidimensionali
Software che offrono queste funzionalità si dividono in due categorie: commerciali (a
pagamento) e open source (gratuiti).
I software commerciali (che non vengono trattati) si distinguono da quelli open source,
per una più ricca dotazione di funzionalità e sono soggetti a licenze d’uso commerciali,
che hanno di solito una durata annua e danno diritto ad aggiornamenti, supporto e
manutenzione.
L’open source o “sorgente libera” indica un software, che è soggetto a una licenza d’uso
pubblica e può essere pertanto liberamente modificato e distribuito. L’uso di tale
21

software è molto radicato nella “parte bassa” dell’infrastruttura IT (es. sistemi operativi o
applicazioni server) mentre stenta a imporsi nella “parte alta” (es. office productivity).
Come già accennato questi software sono distribuiti sotto una licenza pubblica che può
essere di diverso tipo, a seconda dei vincoli in merito alla distribuzione,
commercializzazione e modifica.
La più popolare è la GNU GPL che permette la redistribuzione e la modifica del software
con il vicoli imposti dalla GPL stessa (testo della GPL allegato al software e corredato di
codice sorgente) e garantisce il copyleft, che non permette la ridistribuzione del software
sotto altra licenza.
Gli strumenti open source per la business intelligence sono tecnologie business
intelligence e applicazioni per lo sviluppo di componenti che sono soggette a licenza
d’uso libera.
Queste strumenti hanno (seguono) le stesse specifiche (per quanto riguarda la business
intelligence) delle loro controparti commerciali.
I loro produttori generano guadagno attraverso la sottoscrizione di contratti di supporto o
rilasciando sul mercato due versioni, una con funzionalità limitate (open source) e una
commerciale che genera guadagno.
Le prime soluzioni di questo tipo hanno fatto la loro comparsa sul mercato agli inizi del
2000, generando interesse, solamente qualche anno più tardi (con la maturazione dei vari
progetti e l’introduzione di nuovi).
In particolare, nel settore pubblico, sta nascendo un interesse sempre maggiore per
questo tipo di soluzioni in quanto permetterebbero di ovviare al problema degli alti costi
per le licenze di software commerciale. Anche le piccole-medie imprese si stanno
orientando verso questo tipo di soluzioni, per lo stesso motivo della PA, per non utilizzare
software proprietario e soggetto a licenze commerciali.
Nelle grandi aziende a frenare l’adozione di strumenti open source è la necessità di avere
personale con conoscenze addizionali per implementare le funzionalità dei business
intelligence commerciali (in merito a sicurezza, scalabilità ecc.).
C’è tuttavia da sottolineare che l’adozione di software di questo tipo comporta un
significante dispendio di risorse (per eventuali aggiornamenti o modifiche) che le grandi
aziende possono in parte ovviare, grazie all’utilizzo di personale interno.
I vantaggi nell’adottare software open source possono essere sintetizzati in tre punti:
• CAPEX – un fattore non trascurabile è la gratuità del software e un grosso
incentivo, ma bisogna considerare che ci possono essere costi per il supporto
(forniti direttamente dal produttore di quest’ultimo o da aziende di terze parti)
o costi per assumere personale più qualificato.
22

• Flessibilità del supporto - permette di decidere se sottoscrivere un contratto di
supporto con un'unica azienda (per l’assistenza e l’aggiornamento) o scegliersi
aziende differenti per l’assistenza e per l’aggiornamento o in alternativa usare
questi fondi per assumere personale che si occuperà di queste mansioni.
• Ampie opzioni di integrazione - i software open source permettono un ampia
personalizzazione e integrazione nei vari sistemi con alcune limitazioni
dipendenti dalle varie licenze d’uso.
Si può concludere che l’adozione di software open source può essere un vantaggio per le
grandi aziende che vogliono costruire piattaforme fatte ad-hoc e per le piccole e medie
imprese che non hanno particolari necessità di business intelligence.
La Gartner Group nell’articolo “Gartner Magic Quadrant for business intelligence
platforms “ propone una panoramica, sul posizionamento dei vari produttori di soluzioni
per il business intelligence (figura 7). I vari produttori sono disposti in quattro quadranti
(I quadrante “condottieri”, II quadrante “sfidanti”, III quadrante “giocatori di nicchia”, IV
quadrante “visionari”), con un ulteriore suddivisione sul piano orizzontale, “completezza
di visione” (crescente verso destra) e su quello verticale, l’abilità di eseguire (crescente
verso l’alto).
Figura 7. Posizionamento dei vari produttori di software BI
I principali produttori di OSS BI sono Pentaho, Jaspersoft, fondazione Eclipse (in
collaborazione con Actuate) e Engineering Ingegneria informatica SPA (non è inserita).
Engineering Ingegneria informatica SPA con il suo prodotto SpagoBI è stata omessa,
perché secondo la Gartner Group non ha raggiunto un sufficiente livello di penetrazione
del mercato (market awareness) come gli altri sviluppatori. Anche la Fondazione Eclipse è
stata omessa, perché la Gartner Group ha considerato solo la soluzione commerciale
proposta da Actuate, che integra gli stessi strumenti di base della soluzione proposta da
Eclipse, ma più completa e ricca di funzionalità aggiuntive. Come si può vedere gli altri
23

produttori sono “confinati” nel III quadrante (niche players) questo vuol dire, che sono
ancora in una fase di maturazione e poco diffusi.
La Forrester nella sua pubblicazione: Forrester Wave: Open source Business intelligence
(BI), Q3 2010 ha scelto di analizzare solamente i principali produttori e le loro soluzioni
open source (figura 8).
Figura 8. Posizionamento dei vari produttori di OSS per BI secondo la Forrester
L’unica eccezione è la Actuate BIRT che è principalmente una soluzione commerciale.
Tutti i produttori/prodotti sono rappresentati in un unico quadrante. Il piano orizzontale
rappresenta la strategia, che è crescente verso destra, mentre il piano verticale
rappresenta l’offerta attuale, che è crescente verso l’alto. C’è un’ulteriore suddivisione in
scaglioni, che dividono i produttori in quattro grandi categorie (risky bets, contenders,
strong performers e leader) a seconda del loro ruolo nel mercato. La Actuate con BIRT
guida il gruppo essendo posizionata nello scaglione Leaders e avendo una forte strategia,
nonché una più che buona offerta di funzionalità. Segue SpagoBI che si posiziona nello
scaglione Strong Performers, come anche Pentaho Community e Eclipse BIRT,
quest’ultimo in particolare sta sul confine tra Strong Performers e Contenders. C’è
tuttavia da sottolineare che Eclipse BIRT si discosta dalle altre soluzioni dello stesso
segmento per una migliore strategia, frutto della collaborazione con Actuate. L’unico a
posizionarsi nello scaglione Contenders è Jaspersoft con la sua versione Community.
Nella seguente Tabella 1 sono visualizzati i quattro produttori, con i rispettivi prodotti e le
versioni che saranno presentate nelle seguenti pagine. Nella sopracitata tabella è stato
inserito anche Modrian in quanto rappresenta un’eccezione, ovvero è usato da tutti i
software analizzati per la configurazione di analisi OLAP, come vedremo in seguito.
24

PRODUTTORI PRODOTTO VERSIONE
Eclipse Eclipse BIRT 3.7.2
BIRT Viewer 3.7.2
Jaspersoft
Jaspersoft Community (Server,
iReport Designer)
4.5
Jaspersoft Studio 1.0.9
Jaspersoft Workbench 1.0
Pentaho
Pentaho Community (Server) 3.7.0
Pentaho Report Designer 3.8.2
Pentaho Design Studio 3.7.0
Engineering ingegneria
informatica
SpagoBI (Server, Studio, Meta, SDK) 3.4
Mondrian Mondrian Schema Workbench 3.4.1
Tabella 1. Tabella riassuntiva dei vari produttori, con i vari prodotti e versioni
25

5.2 ECLIPSE BIRT
5.2.1 Introduzione alla piattaforma
Nel 2004 la Actuate un azienda informatica, approccio la Eclipse Foundation con l’intento
di creare un set di strumenti open source per il BI. Il progetto fu chiamato Eclipse BIRT
(Business Intelligence Reporting Tools). La Actuate scelse questo percorso perché si rese
conto che doveva ringiovanire la propria offerta è uno dei punti chiave era l’open source.
Nel corso degli anni divenne un partner strategico all’interno della fondazione e partecipa
attivamente allo sviluppo del progetto. Grazie a questa collaborazione nacque uno
strumento molto professionale, che viene integrato in diversi progetti di BI come si vedrà
in seguito.
Al giorno d’oggi BIRT è il più diffuso strumento di BI e reporting, con milioni di download
(figura 9) e l’invidiabile cifra di 750.000
sviluppatori. BIRT è distribuito sotto la
licenza EPL, una licenza sostitutiva alla
CPL, che permette l’uso, la modifica, la
copia e distribuzione del lavoro
originale o delle versioni modificate.
La Actuate propone una sua versione a
pagamento, la ActuateOne che si
differenzia dalla soluzione open con
l’offerta di un set più completo di
funzionalità.
Figura 9. Numero di download (in milioni) per anno
5.2.2 Architettura
La versione open source di BIRT è costituita da due componenti principali:
• Birt Reports – componente per la creazione di report
• Runtime engine – componente per la generazione di report che può essere
distribuito in qualsiasi ambiente Java.
Il BIRT Reports può funzionare sia come Eclipse RCP o come plug-in integrato in Eclipse
IDE, mentre il report engine può essere distribuito in qualsiasi server Servlet o J2EE
Application Server basati su JBoss, Tomcat o Websphere. Nella figura 10 è mostrata
l’architettura di Eclipse BIRT.
L’architettura di BIRT e molto flessibile e estendibile. La connettività alle sorgenti dati è
possibile grazie a ODA, un framework creato dalla stessa Eclipse, che permette l’accesso
ai dati sorgenti standard e personalizzati, ovvero permette di connettersi a sorgenti
fisiche quali JDBC RDBMS, Web Service, Flat Files o Java Beans, e trattarle come un set
logico di risultati.
26

La trasformazione dei dati avviene parzialmente sui DB sorgente e consiste
nell’ordinamento, nel filtraggio e raggruppamento di dati, allo scopo di soddisfare le
esigenze dello specifico utente. Nel caso di “flat files” o “java objects” la trasformazione è
eseguita per intero da BIRT.
Sono disponibili una serie di servizi per creare una Logica di Business in quanto i dati del
mondo reale sono raramente strutturati in modo da essere utilizzati direttamente in un
report senza modifiche.
Figura 10. Architettura BIRT
La presentazione dei dati all’utente finale è possibile in tre modalità:
• Tramite le API – BIRT mette a disposizione tre API che sono: Design Engine API
(DE API), Report Engine API (RE API) e Chart Engine API (CE API.)
• In un’applicazione JAVA EE (es. Report Viewer)
• Con lo Scripting tramite Rhino all’interno dei modelli di report
Designer Engine API permette di esplorare o modificare i report o in alternativa l’utente
può crearsi uno strumento di progettazione di report. Se invocata all’interno dello script
BIRT, permette di modificare il report attualmente in esecuzione.
Report Engine API è usata per eseguire i report direttamente dal codice Java o per creare
un’applicazione web di front-end per BIRT.
Chart Engine API è usato per creare e renderizzare i grafici al di fuori di BIRT.
Report viewer può essere utilizzato in vari modi; come applicazione stand alone,
richiamata attraverso la libreria di tag di BIRT, come plug-in in una applicazione RCP
esistente o infine come applicazione web personalizzabile. Se utilizzata come
un’applicazione AJAX basata su Java EE aggiunge alcune interessanti funzionalità come il
27

sommario, la possibilità di esportare i report in differenti formati, permette le stampe lato
server o client, nonché la paginazione dei report.
5.2.3 Reportistica
La gestione e la creazione di report è fatta attraverso il programma BIRT Reports che si
basa sulla nota piattaforma open source Eclipse IDE è fornisce agli sviluppatori un set di
base per la visualizzazione e la creazione di report, nonché strumenti e tecniche più
avanzate per accedere ai dati della sorgente dati, trasformarli, applicare la logica di
business e una volta che i dati sono stati filtrati e formattati presentare i risultati agli
utenti sotto forma di report.
• La versione analizzata propone le seguenti funzionalità:
• Una vasta gamma di strumenti di progettazione e disegno
• La personalizzazione dei dati
• Programmabilità
• La flessibilità nella presentazione dei dati
• La possibilità del riutilizzo di componenti e librerie
• La facilità nell’integrazione in altri progetti
BIRT Reports è un tool di sviluppo molto intuitivo, che però richiede utenti esperti in
quanto mette a disposizione parecchie funzionalità che possono confondere un utente
medio. Con la creazione di un nuovo progetto l’utente deve scegliere l’area (figura 11),
ovvero la dimensione di uno spazio dove verranno messi gli elementi che popoleranno il
report. Questi elementi sono presenti in un apposita finestra e vanno dalla semplice
tabella a elementi più complessi come i grafici. Con la tecnica Drag & Drop, ovvero
selezionando con il mouse l’elemento desiderato è possibile trascinarlo nella posizione
desiderata all’interno dell’area, che si ha a disposizione.
I report cosi creati vengono salvati nel formato .rptdesign, un formato della Actuate
Corporation.
Lo strumento appena descritto permette anche il debugging, che controlla eventuali
errori e genera un anteprima del report.
28

Figura 11. Schermata principale di BIRT
Come accennato in precedenza Eclipse BIRT mette a disposizione sia la creazione di
connessioni con le sorgenti dati preesistenti (Data source), sia la possibilità di crearne
nuove (Data Set). I dati possono pertanto provenire da varie fonti come i database, servizi
web, Java e ogni altro tipo di dato scelto dall’utente, avendo previamente creato la UI e la
runtime, utilizzando il framework ODA.
BIRT permette anche di creare una logica di business in quanto raramente i dati del
mondo reale sono strutturati esattamente come si desidera. Questo è fatto utilizzando
script, precisamente Javascript che è messo a disposizione da BIRT.
I report completi possono essere visualizzati internamente in BIRT Report Designer o
attraverso una soluzione esterna come BIRT Viewer.
5.2.4 Cruscotti
La versione open source a differenza di quella proposta da Actuate (BIRT 360) non
propone nessun specifico strumento per la creazione e visualizzazione di cruscotti in un
portale web.
29

5.2.5 Analisi OLAP
Dalla versione 2.2 in poi, BIRT supporta l’analisi OLAP in forma di cross-tabulation (tabelle
incrociate). L’analisi OLAP consiste dapprima nella creazione di un cubo
multidimensionale con Report Designer e in seguito, usare il cubo appena creato come
sorgente dati per i report a tabelle incrociate.
La procedura è notevolmente semplificata dalla presenza di un wizard che guida l’utente
nelle varie fasi di compilazione dei form. Come nel caso dei report è richiesta, da parte
dell’utente, una conoscenza avanzata dell’informatica, in particolare dei cubi
multidimensionali.
Come visto in precedenza Report Designer permette di testare i report, ed eventualmente
esportarli. Come per i report anche le analisi OLAP (che non sono altro che report che
usano cubi multidimensionali come sorgenti dati) possono essere visualizzate in due
modi:
• All’interno di Report Designer
• Grazie a BIRT Viewer
Il procedimento e analogo a quello descritto per i report. Di seguito è mostrato un
esempio di analisi OLAP fatta con BIRT e visualizzata in BIRT Viewer (figura 12).
Figura 12. Esempio di analisi OLAP in BIRT Report Viewer
30

5.2.6 Supporto e altro
Essendo Eclipse, una piattaforma molto usata, il supporto è molto buono. Esiste
un’apposita pagina wikiii
, che illustra il funzionamento di BIRT e propone un’area FAQ e
Tutorials, dove è possibile trovare le risposte alle domande più frequenti oltre, che ad un
apposito tutorial in formato PDF e flash.
Bisogna segnalare anche la presenza di un apposito topic sul forumiii
di Eclipse, dove gli
utenti possono risolvere eventuali problemi e chiedere informazioni.
31

5.3 JASPERSOFT COMMUNITY
Nel 2001 Teodor Danciu comincio a sviluppare un motore e una libreria di report basati su
Java, che culmino nella creazione della libreria JasperReports Library. Nello stesso periodo
Gulio Tuffoli creo uno strumento di progettazione grafica dei report (Jaspersoft iReport
Designer) per JasperReports. Nel 2004 i due sviluppatori si unirono a una compagnia
statunitense per fondare la Jaspersoft. Ai sopracitati strumenti si aggiunse JasperReports
Server, uno strumento di reporting basato su server.
Nel 2005 venne proposta una versione open source con supporto commerciale
(Jaspersoft 1.0). Il codice era distribuito sotto la licenza copyleft JasperReport License, che
in seguito fu commutata in LGPL. Nel corso degli anni l’offerta fu ampliata con Jaspersoft
OLAP uno strumento di analisi multidimensionale e con Jaspersoft ETL uno strumento di
estrazione, trasformazione e caricamento dei dati in DW i DM.
Al giorno d’oggi la Jaspersoft propone sia versioni commerciali (Express, Professional,
Enterprise) che una versione open source (Community). Le versioni commerciali integrano
tutti gli strumenti in un unica suite mentre nella versione open source questi sono
disponibili singolarmente. Oltre ad essere disponibili singolarmente, gli strumenti
propongono solo funzionalità di base (come il reporting, l’analisi OLAP o il supporto per
dispositivi mobili) e non integrano per es. analisi in-memory, widget, mappe o cruscotti.
Riassumendo la Jaspersoft propone i seguenti strumenti:
• JasperReports Server
• JasperReports Library
• Jaspersoft iReports
• JasperSoft OLAP
• Jaspersoft ETL
• Jaspersoft Studio
JasperReports Server è il componente fondamentale dell’intero pacchetto e permette di
gestire i documenti analitici (importandoli, catalogandoli e mandandoli in esecuzione) i
permessi di accesso, permette la pianificazione delle operazioni e permette di gestire i
database sorgenti (DW e DM). La versione Community o open source ha molte limitazioni
tra le quali si segnala l’impossibilità di implementare cruscotti.
A JasperReports Server si accede attraverso un browser web (Firefox, Internet Explorer,
Crome o altri) avendo previamente avviato un Application server che supporti la
tecnologia JSP come Apache Tomcat (che è incluso nel package) o JBoss.
32

Nella pagina iniziale vengono chiesti username e password, che vengono previamente
creati dall’amministratore del sistema. L’amministratore del sistema ha a disposizione uno
strumento di gestione delle credenziali (direttamente nel browser). Per l’autenticazione e
l’autorizzazione JasperReport Server fa largo uso di Spring e sub-progetti come Acegi
Security.
Dopo aver inserito le credenziali l’utente viene reindirizzato alla home page dove ha la
possibilità di:
• esplorare il database - che gli viene messo a disposizione;
• vedere i report – che possono essere modificati, pianificati, cancellati o eseguiti;
• vedere le viste OLAP – che possono essere eseguite;
• eseguire una ricerca – con l’apposito motore di ricerca.
5.4.2 Architettura
L’architettura di Jaspersoft si può suddividere in tre livelli:
• livello dei dati;
• livello analitico;
• livello di presentazione.
Il livello dei dati come si può vedere dalla figura 13 è costituito da tutti i database
sorgenti (RDBMS, POJO, EJB ecc.) che andranno ad alimentare la piattaforma (Server) e/o
i vari componenti (es. JasperReports).Con l’apposito motore ETL presente nello strumento
JaspersoftETL è possibile filtrare, riordinare e omogeneizzare i dati in un DW, DM o ODS,
cosi da avere un'unica base dati, da cui attingere le informazioni.
Sopra il livello dati si trova il livello analitico, che rappresenta il livello più importante
dell’intera suite. In questo livello si trovano tutte le principali componenti, come ad es.
JasperReports Server. Bisogna segnalare che i dati analitici non sono creati all’interno
della piattaforma, ma sono sviluppati con strumenti esterni come ad es. Jasper Report
Designer e vengono successivamente caricati all’interno della piattaforma per essere
eseguiti. Durante questa fase viene creata una connessione con la sorgente dati (indicata
dall’utente) che sarà passata al rispettivo motore, che produrrà il documento analitico.
L’ultimo livello è dato dal livello di presentazione che è incaricato di presentare
graficamente i vari documenti analitici.
33

Figura 13. Architettura di Jaspersoft divisa per livelli.
5.3.3 Reportistica
Jaspersoft mette a disposizione due strumenti per la creazione e modifica di report:
Jasper iReports e JasperStudio (figura 14). Il primo è stato realizzato da Jaspersoft, mentre
il secondo si basa sulla piattaforma Eclipse, che è stata analizzata pocanzi.
I report sono modelli, utilizzati dal motore JasperReports per fornire all’utente un
contenuto dinamico, pronto per essere visualizzato sullo schermo o nel web ed
eventualmente essere stampato.
I report vengono salvati in un formato speciale, che è l’unico accettato da Jaspersoft. Il
formato con estensione *.jrxml è una variante XML sviluppata dalla Jaspersoft e definita
in un file DTD che è allegato al software. Un file XML può essere convertito in JRXML
apportando le seguenti modifiche al codice:
<?xml version="1.0"?>
<!DOCTYPE jasperReport
PUBLIC "-//JasperReports//DTD Report Design//EN"
"http://jasperreports.sourceforge.net/dtds/jasperreport.dtd">
<jasperReport name="name_of_the_report" ... >
...
</jasperReport>
34

Avere un formato proprietario rende il report non condivisibile con altri motori o
strumenti di reportistica, il che ne limita la diffusione.
Di seguito viene visto iReports in quanto Jaspersoft Studio ha le identiche funzionalità di
Eclipse Report Designer, viste nel precedente capitolo.
iReport a differenza di Jaspersoft Studio è fornito in allegato a Jaspersoft Server, una cosa
non di poco conto se si pensa che l’utente ha da subito a disposizione uno strumento per
la creazione di un report.
Jasper iReports e basato sulla piattaforma Netbeans e rappresenta a mio avviso un ottimo
strumento per la creazione e modifica di report. Consente infatti di realizzare report
professionali, con contenuti e layout anche complessi e sofisticati, ma proprio per tali
motivi lo strumento risulta di difficile utilizzo da parte dell’utente finale, in quanto
l’interfaccia è complessa è richiede una conoscenza informatica di tipo avanzato.
Tra le tante funzionalità proposte bisogna segnalare una funzione, che permette di
esportare il report appena creato in diversi formati (pdf, html, xml, txt ecc.) con la
possibilità di compilarlo in modo da proteggere il codice.
L’esecuzione di un report è possibile passando un file Jasper e una sorgente dati a
JasperReport. Jaspersoft supporta molte sorgenti dati in particolare un file Jasper può
essere riempito con query SQL, file XML, CVS, query HQL ecc. Se la fonte dati non è tra
quelle supportate, l’utente ha la possibilità di crearsi una sorgente personalizzata.
Figura 14. Schermata iniziale di iReports
35

5.3.4 Cruscotti
Nella versione community questa funzionalità non è disponibile, mentre nelle versioni
commerciali (Professional e Business) è supportata. Tuttavia esiste il modo di integrare i
cruscotti, vedendoli come sub-report. Non esistendoci alcuna documentazione ufficiale, si
è scelto di non procedere con l’approfondimento dell’argomento. Si consiglia agli utenti
che ricercano questa funzionalità di orientarsi su altri prodotti.
5.3.5 Analisi OLAP
L’analisi OLAP è fatta dallo strumento Jaspersoft OLAP, un estensione di JasperReports
Server che utilizza database RDBMS esistenti per fare analisi. Questo strumento utilizza
due motori open source, Mondrian e JPivot. Il primo è usato per collegarsi al database,
interrogarlo usando MDX e restituire risultati, mentre il secondo permette di interfacciarsi
con l’OLAP senza conoscere la struttura MDX e visualizzare i risultati su una pagina web.
Per eseguire analisi OLAP bisogna innanzitutto configurare Jaspersoft OLAP nel database.
Per prima cosa l’utente deve creare uno schema Mondrian, cioè un file XML che definisce
le relazioni nel proprio database, ovvero i metadati che verranno usati nel processo OLAP.
A questo proposito è usato un tool desktop, Jaspersoft OLAP Workbench (scaricabile a
parte), che permette all’utente di creare e testare uno schema. Lo strumento si presenta
con una grafica molto spartana, ma implementa al suo interno tutte le funzioni per creare
un nuovo cubo o inserire una query MDX. La difficoltà maggiore rappresenta la query
MDX, basata sul linguaggio di programmazione MDX, che è stato concepito
specificamente per l’interrogazione e la manipolazione di dati salvati in cubi OLAP.
L’utente all’apertura del tool deve configurare il collegamento con il database sorgente
sul quale verrà basato lo schema, inserendo il driver JDBC, l’url, la username e la
password.
Per testare lo schema si interroga lo stesso con query DMX. Dopo aver ovviato ad
eventuali errori, lo schema va importato in JasperReport Server tramite l’interfaccia
utente.
L’utente può in alternativa utilizzare lo strumento ufficiale di Mondrian, Mondrian
schema Workbench per creare e modificare uno schema.
36

Figura 15. Esempio di analisi OLAP fatta in Jaspersoft Server.
Jaspersoft mette a disposizione un apposita paginaiv
dov’è possibile trovare tutte le
informazioni necessarie ad utilizzare i vari strumenti. Si segnala la presenza di un blog e
una bacheca dove sono presenti le news e numerosi articoli riguardanti Jaspersoft BI.
Da non sottovalutare anche la presenza di un forum dove ogni utente può chiedere
approfondimenti o eventualmente risolvere problemi che riscontra nell’utilizzo dei vari
strumenti.
La manualistica è a mio avviso molto buona e le varie funzionalità sono spiegate
dettagliatamente. Come curiosità si segnala l’uso di un progetto open source, dal nome
Acegi, per la sicurezza. Acegi e un sub-progetto di Spring, basato sul linguaggio di
programmazione Java ed è pertanto multipiattaforma il che lo rende molto versatile. Si
rimandano gli interessati che desiderano ulteriori informazioni a visitare il sitov
di Spring
Security.
37

5.4 PENTAHO COMMUNITY
Nel 2004 la Pentaho, un azienda che ha sede a Orlando, Florida USA, cominciò con lo
sviluppo dell’omonima suite, la Pentaho BI suite. L’azienda propone sia versioni
commerciali (Basic, Professional, Enterprise) che una versione open source. La Pentaho
genera guadagno con il modello delle sottoscrizioni (annue), che danno diritto ad
aggiornamenti regolari, al supporto tecnico e ad altri servizi professionali (la quantità di
servizi varia da versione a versione).
Le versioni commerciali sono anche le più ricche, per quanto riguarda le funzionalità
offerte e sono distribuite sotto licenze commerciali, mentre la versione open source è
distribuita sotto la licenza MPL. Questa licenza è considerata come una debole copyleft
ovvero il codice sorgente copiato o modificato sotto la licenza MPL deve rimanere sotto
MPL.
La Pentaho BI suite è il fulcro del progetto e comprende applicativi per la creazione di
cruscotti e report, ricerche OLAP e ETL ed il data mining. Di seguito sono elencati gli
applicativi che sono resi disponibili da Pentaho:
• Pentaho Server
• Pentaho Report Designer
• Pentaho Metadata
• Pentaho Design Studio
• Data Integration
• Schema Workbench
La visualizzazione e gestione delle varie funzionalità avviene attraverso un ambiente web,
con l’uso di tecnologia JSP su un Server Java come Tomcat o JBoss. L’utente può accedere
facilmente alle varie opzioni attraverso un comune browser web (Firefox, Internet
Explorer ecc.)
Oltre alla modalità appena descritta esiste anche la modalità “portale”, che usa le Portlet
JSR-168 (che però non verrà vista in quanto è vincolata all’utilizzo di JBoss, l’unico a
supportare lo standard JSR-168).
5.4.2 Architettura
L’architettura di Pentaho Bi (figura 16) si può sintetizzare in tre livelli:
• Dei dati e metadati
38

• Il server J2EE
• Livello della presentazione
Il livello dei dati e metadati si occupa fondamentalmente di fornire, grazie a strumenti
ELT, le fonti dati che saranno successivamente analizzate dalle varie applicazioni. Come si
può notare Pentaho si appoggia via JDBC ai più diffusi database relazionali in quanto non
dispone di un proprio database per la persistenza. Tutti i documenti analitici vengono
salvati nel Solution Repository.
Il fulcro della suite è rappresentato dal server J2EE, che integra al suo interno specifici
motori dedicati alla creazione, all’esecuzione e alla navigazione dei componenti nonché
funzionalità di Auditing e la gestione della sicurezza attraverso il Single-Sign-On.
Il fulcro del Server è la Solution Engine che grazie alla sua posizione centrale, tra il
“mondo esterno”, composto da Web Client Servizi e System Monitoring e le componenti
interne, gli permette di gestire le richieste delle prime per instradarle negli appositi
componenti dove saranno eseguite. Le solution possono essere descritte come una
collezione di documenti ovvero un raggruppamento logico di Action Sequence e le risorse
di cui hanno bisogno. La relazione è mantenuta grazie al Solution Repository. Le Action
Sequenze, sono documenti XML che definiscono il più piccolo compito che può essere
eseguito dalla Solution engine. Vengono eseguite da un motore molto leggero che
definisce l’ordine con cui verranno eseguiti i vari componenti all’interno della piattaforma
Pentaho BI. Sono particolarmente usate per definire azioni lineari e leggere come i
reporting o il bursting.
Pentaho mette a disposizione un apposito tool, chiamato Design Studio, che è basato sulla
piattaforma open source Eclipse. Questo tool fornisce una raccolta di editor e vari moduli
per la creazione ed il test di documenti Action Sequenze in un ambiente grafico. Le Action
Sequenze vengono create con estensione “.xaction”.
39

Figura 16. Architettura Pentaho
Come già specificato Pentaho BI, è raggiungibile da un qualunque browser web avendo
previamente inizializzato il Server Tomcat o JBoss. Nella pagina principale vengono chiesti
username e password (che sono previamente creati dall’amministratore del sistema e
gestiti interamente online). La figura 17 mostra un esempio di una possibile schermata di
Pentaho. Come si può vedere l’ambiente e molto curato e si ha una distribuzione logica
dei principali comandi (es. salva, apri ecc. ) oltre ad una apposita finestra dov’è possibile
esplorare i database o i report che sono stati creati con appositi tool esterni (come
vedremo in seguito).
40

Figura 17. Esempio di una pagina di analisi in Pentaho.
5.4.3 Reportistica
Pentaho mette a disposizione uno strumento indipendente, Pentaho Report Designer e
uno interno per la creazione e gestione di report. Inoltre con Pentaho Design Studio è
possibile creare e testare documenti Action Sequenze. Tutti e tre gli strumenti utilizzano il
plugin JFree Reports, con la peculiarità che nell’application server è integrato sotto forma
di motore.
I report con i due strumenti possono utilizzare le classiche sorgenti dati ( database
relazionali, Pentaho metadata, XML data source ) o l’utente si può creare strutture
personalizzate, che pero richiedono una buona conoscenza del linguaggio di
programmazione Java.
Di seguito vengono presentati i sopracitati strumenti.
JFreeReports
E’ il motore integrato nel Pentaho Server che rende subito disponibile all’utente, senza la
necessità di ricercare strumenti appositi, la creazione di report. Questo è indubbiamente
un vantaggio non indifferente, poiché permette all’utente di costruirsi un report di base
all’interno di Pentaho Server ed in seguito modificarlo o ampliarlo utilizzando strumenti
appositi come Pentaho Design Studio o Pentaho Report Designer.
41

Figura 18. Schermata iniziale con le varie opzioni
Pentaho Report Designer
Report Designer è un tool di sviluppo di report ed è distribuito sotto la licenza LGPL.
All’apertura del programma appare una finestra dov’è possibile selezionare il “wizard” o
un report vuoto.
Il wizard o procedura guidata è particolarmente utile per utenti che hanno poca
dimestichezza con questo tipo strumenti o ad utenti che hanno necessità di creare report
semplici e veloci. Il wizard permette con semplicità di creare una struttura base e di
scegliere le fonti di informazione (database) da cui prelevare i dati necessari a popolare le
varie tabelle o grafici. Bisogna tuttavia segnalare, che al di fuori della struttura base il
popolamento dei report con strutture più complesse può risultare difficoltoso per utenti
che non hanno esperienze nell’uso di tali strumenti.
Il tool e strutturato come altri programmi classici, ovvero nella parte superiore troviamo i
classico menu a scorrimento (File, Modifica, Visualizza ecc.) seguito, un po’ più sotto da
icone che rappresentano collegamenti alle funzioni più usate (taglia, salva, annulla). In
questo riquadro è presente anche il collegamento ad un’interessante funzione; RUN che
permette di visualizzare il report appena creato in vari formati come il HTML, PDF, Excel.
Nel centro è stato posizionato il “piano di lavoro “ dove è possibile trascinare gli elementi
presenti sulla parte destra quali testo, elementi grafici (elissi, linee ecc.) o grafici (es.
torte).
Nella parte destra sono presenti due finestre: in alto è visualizzata la struttura del report e
i database disponibili, nella parte inferiore è visualizzato lo stile e gli attributi
dell’elemento selezionato.
42

Figura 19. Esempio di report creato con il wizard
E’ possibile aggiungere un’altra finestra “messaggi” che segnala all’utente eventuali errori
o avvisi (warnings).
I report vengono salvati nel formato *.prpt, un formato creato da Pentaho.
Bisogna segnalare la mancanza di un editor per la predisposizione di Action Sequenze, che
verrà visto in Pentaho Design Studio. Tuttavia bisogna ribadire che Pentaho Report
Designer si presenta come un buono strumento che mette a disposizione tutte gli
elementi per creare un report.
Pentaho Design Studio
Design Studio è un tool di sviluppo basato sulla piattaforma open source Eclipse. Questo
tool fornisce una raccolta di editor e vari moduli per la creazione ed il test di documenti
Action Sequenze e JFree reports in un ambiente grafico.
Design studio è nato per la creazione e gestione di file all’interno della piattaforma
Pentaho. A questo proposito sono disponibili all’utente diversi editor uno per ogni tipo di
file. Con l’Action sequenze editor e possibile definire attività che sono svolte all’interno
43

della piattaforma BI, più precisamente viene creato un documento Action sequenze XML,
che permette di gestire attività come la generazione di report o le query di database.
Come abbiamo già visto nel capitolo, questo tool è particolarmente famigliare ai
programmatori web, che sono abituati a utilizzare CSS, per la parte grafica e un linguaggio
simile a Javascript per la generazione di valori dinamici.
Figura 20. Esempio di una Xaction
5.4.4 Cruscotti
Pentaho community mette a disposizione sostanzialmente due modi per la creazione di
cruscotti:
• Usando la libreria Jfree Charts che mette a disposizione i classici formati come
le linee, barre e torte.
• Community Dashboard frame work/editor – editor grafico che utilizza il
framework CDE.
Nel primo caso è richiesta una notevole conoscenza di vari linguaggi di programmazione
(in particolare Javascript e XML) in quanto bisogna costruirsi una pagina JSP da zero.
Questo procedimento è poco usato, da quando è disponibile un apposito framework
(CDF) che è stato integrato nella piattaforma Pentaho. Il primo procedimento verrà
44

omesso da ulteriori approfondimenti in quanto si ritiene essere limitato ad utenti abili nei
linguaggi di programmazione prima indicati e che hanno tempo a disposizione per
dedicarsi al progetto.
Community Dashboard Frameworkvi
(CDF) è un progetto open source sviluppato dalla
Webdetailsvii
, cosi come Community Dashboard Editorviii
(CDE). Il primo fornisce le
“funzionalità “ mentre il secondo mette a disposizione una “veste grafica “ per la
creazione, modifica e visualizzazione dei cruscotti.
In Pentaho è integrato solamente il CDF, il CDE deve essere scaricato dalla pagina di
Webdetails e i file scompattati devono essere posizionati nella cartella principale di
Pentaho. Cosi facendo al prossimo avvio di Pentaho Server sarà possibile usare il CDE che
mette a disposizione tre elementi per la creazione di un cruscotto:
• Layout – è sostanzialmente l’aspetto che avrà il cruscotto
• Components – componenti grafici che faranno parte del cruscotto (lancette,
torte, semafori
• Data sources – sorgente dati da cui attingere informazioni che saranno
visualizzate nei componenti
I sopracitati elementi si trovano in un apposito menu (figura 21). Nel Layout l’utente cura
la parte grafica del cruscotto, aggiungendo, spostando o eliminando i differenti elementi
messi a disposizione (righe, colonne, spazi, blocchi HTML e immagini).
Ogni elemento è ulteriormente personalizzabile grazie ad un apposita finestra che
permette di scegliere le proprietà come ad esempio il colore.
I Components o componenti sono gli elementi fondamentali di un cruscotto e si possono
ulteriormente suddividere in tre categorie:
• Elementi visuali – sono i componenti che vengono visualizzati nel cruscotto
(tabelle, caselle di testo, grafici (a torta a barre ecc.), selettori (bottoni radio),
viste OLAP, report).
• Parametri- rappresentano i valori che sono condivisi tra i componenti (es.
executeAtStart Flag che indica se il componente deve essere eseguito quando il
cruscotto è caricato.)
• Scripts – sono parti di codice in Java Script che permettono di personalizzare il
look and feel o il comportamento di altri componenti.
Data sources o sorgenti dati sono la parte di CDE che gestisce la fonte dei dati che
saranno visualizzati nei cruscotti. Queste possono essere di vario tipo:
• Mondrian
45

• Database (classici)
• Pentaho metadata
• File XML
• Scripting – codice inserito dall’utente che permette di definire database ad-hoc
(es. tabelle)
• Kettle – permette di prelevare i dati da altre fonti, come i fogli Excel.
La definizione della sorgente dati e fatta come per il Layout e i Componenti direttamente
nel browser. L’utente dovrà specificare quale database sarà usato e in che formato sono i
dati. A seconda della scelta dei database le proprietà disponibili variano, ma ci sono
cinque punti chiave che sono sempre presenti:
• Nome sorgente dati – nome univoco per ogni sorgente dati
• Nome JNDI o parametri JDBC – specificano il host, nome utente ecc.
• Query - è la parte dove l’utente inserisce la query (SQL, MDX) a seconda della
sorgente dati
• Configurazione colonna – permette di rinominare le colonne restituite dalla
query o crearne nuove
• Opzioni di output - permette di riordinare o mantenere un sottoinsieme delle
colonne restituite dalla query.
Figura 21. Schermata principale di Community Dashboard Editor
Per creare un cruscotto in Pentaho bastano pochi passi, per prima cosa bisogna accedere
al server Pentaho e aprire il CDE, nominare il cruscotto e salvarlo. Il seguente passo è
46

quello di selezionare il layout e la sorgente dati. I procedimenti sono molto intuitivi e
logici.
Segue la scelta e la configurazione dei componenti che saranno inseriti nel cruscotto.
L’ultimo passo è quello di visualizzare un’anteprima del cruscotto e se non soddisfa le
esigenze dello sviluppatore basta ripetere i procedimenti sopraindicati e apportare le
modifiche desiderate.
5.4.5 Analisi OLAP
L’analisi OLAP è fatta attraverso due motori Mondrian e JPivot, entrambi integrati
all’interno di Pentaho Server. Il motore Mondrian viene usato per la creazione di un
database multidimensionale e per l’interrogazione di quest’ultimo e JPivot per la
visualizzazione di risultati in una pagina web.
L’utente deve per prima cosa scaricare Workbench schema, fornito separatamente alla
suite. Il passo successivo è quello di creare un cubo multidimensionale del database e la
query MDX con la quale si interrogherà il sopracitato cubo. La creazione del cubo risulta
facile, una sfida maggiore rappresenta la query, che necessita di una buona conoscenze
del linguaggio MDX da parte dell’utente.
Un esempio della query MDX è mostrata di seguito:
SELECT
NON EMPTY {[Measures].[Quantity]} ON COLUMNS,
NON EMPTY
{([Markets].[All Markets], [Customers].[All Customers],
[Product].[All Products], [Time].[All Years],
[Order Status].[All Status Types])} ON ROWS
FROM [SteelWheelsSales]
Dopo aver finito di creare lo schema, lo si deve importare in Pentaho Server. A questo
proposito è fornita un’apposita procedura guidata che facilita notevolmente il lavoro
dell’utente.
All’utente non resta che accedere al server e creare una nuova Analysis View, scegliendo il
cubo multidimensionale e lo schema, che sono stati previamente importati. Il motore
Modrian estrarrà i dati e il motore JPivot li visualizzerà sullo schermo. A questo punto
l’utente può personalizzare l’analisi OLAP scegliendo le righe e colonne da visualizzare e
raggruppando o mettendo condizioni sulle dimensioni di analisi.
Bisogna segnalare che JPivot non è più mantenuto è potrebbe scomparire dalle prossime
versioni di Pentaho.
47

Figura 22. Esempio di una analisi OLAP
Gli utenti alle prime armi hanno a disposizione un ampia manualistica e diversi tutorial
nonché un apposito forumix
dove poter chiedere eventuali delucidazioni. Essendo Pentaho
una delle più popolari suite open source di business intelligence il supporto globale e
molto buono.
Una peculiarità di Pentaho e di mettere a disposizione un apposito strumento per la
descrizione e salvataggio dei processi ETL utilizzando metadati. Pentaho Metadata Editor
permette la creazione di meta modelli e matadati con i quali è possibile mappare la
struttura fisica di un database e convertirlo in un modello logico orientato al business
(business model).
A titolo di curiosità si segnala la disponibilità da parte di Pentaho, di un editor, Open
Formula, che permette all’utente di inserire formule nelle caselle di testo, di data ecc.
Inoltre bisogna segnalare anche la presenza di un apposito motore, Weka, per il Data
Mining.
48

5.5 SPAGOBI
La suite è stata sviluppata ed è gestita da un’azienda italiana, la Engineering Ingegneria
Informatica SPA, un azienda costituita nel 1980, che ha sedi in diverse città italiane. La
Engineering Ingegneria Informatica SPA si occupa della realizzazione di software per
diversi settori come quello assicurativo, bancario e finanziario.
SpagoBi è l’unico software open source che mette a disposizione una suite completa di BI,
offrendo la possibilità di visualizzare Report, eseguire analisi di tipo OLAP, predisporre
cruscotti e KPI ed utilizzare tecniche di Data Mining per cercare informazioni nascoste. Per
garantire tutte queste funzionalità, in SpagoBI sono stati integrati diversi motori di
posizionamento, di ricerca, analisi e gestione documenti. Alcuni di questi motori, come il
motore di posizionamento, sono stati sviluppati internamente in Engineering Ingegneria
Informatica mentre la maggior parte è sviluppata da altre aziende come la Talend per
L’ETL, Eclipse e Jaspersoft per il Reporting o Weka per il Data Mining.
La suite è pertanto distribuita sotto la licenza GNU LGPL, che permette la libera modifica,
distribuzione e l’uso per fini commerciali.
5.5.1 Architettura
La Engineering Ingegneria Informatica ha scelto un approccio modulare per la creazione
della suite. Sviluppando il software in moduli si ha maggiore flessibilità nella modifica e
implementazione di nuovi componenti (moduli).
L’architettura di SpagoBI si compone di quattro moduli:
• SpagoBI Server
• SpagoBi Studio
• SpagoBI Meta
• SpagoBI SDK
SpagoBI Server è il fulcro della suite. Comprende le principali funzionalità di analisi dei
dati. Si compone di due modelli, quello Analitico e quello Comportamentale, oltre a
strumenti di amministrazione e servizi trasversali (figura 23).
SpagoBI Server è accessibile attraverso tutti i principali browser Web, avendo
previamente inizializzato il Server Apache Tomcat (incluso nel pacchetto di installazione) o
un server simile (es. jBoss). La suite è gestibile interamente nel browser in quanto è stata
pensata come un “portale”.
Nella pagina iniziale all’utente viene chiesto di inserire le credenziali d’accesso (username
e password), che sono state previamente create dall’amministratore del sistema.
49

L’amministratore può decidere di creare vari livelli di accesso ognuno con specifici
privilegi (tutte le operazioni sono fatte dal Web).
Dopo aver effettuato l’accesso l’utente viene reindirizzato alla home page dove sono
presenti diversi menu (in base alle autorizzazioni che gli sono state concesse
dall’amministratore) che gli permettono una vasta scelta di strumenti per il:
• Reporting – l’utente ha a disposizione diversi motori (Jaspersoft Report engine,
BIRT engine, accessibility engine e BO engine) che gli permettono di visualizzare
le informazioni a lui interessanti in vari formati (grafici o non) come ad es.
tabelle, liste, torte e ne permettono l’esportazione in vari formati (HTML, PDF).
• Analisi OLAP - utilizza tre motori Jpivot Mondrian, Jpalo/Mondrian e JPXMLA
per l’analisi multidimensionale dei dati. Rispetto ai report strutturati, questo
tipo di analisi permette agli utenti di avere un maggior grado di libertà e
flessibilità.
• Grafici (chart) e Location intelligence - Permettono all’utente di predisporre
istogrammi, semafori e grafici di vario tipo e consentono di rappresentare
graficamente i dati archiviati nei DW (con mappe statiche o interagendo con
sistemi georeferenziali.)
• Cruscotti interattivi (cockpits) - sono a disposizione due motori Composed
Document e In-Memory che rendono possibile la visualizzazione in un unica
finestra di più documenti, collegati tra loro.
• Interrogazione libera dei dati (Driven data selection ) - utilizza due motori Smart
Filter, QbE, quest’ultimo in particolare, viene usato per l’interrogazione dei dati
e l’estrazione in un formato adatto all’utente finale (es. foglio di lavoro).
50

Figura 23. Architettura SpagoBI
Tutti i motori analitici sono legati al modello comportamentale che li gestisce in
automatico. Il modello comportamentale permette di regolare in base al ruolo dell’utente
la visibilità dei documenti e dei dati. I principali vantaggi di avere un tale legame sta nella
riduzione dei documenti da sviluppare e mantenere e il rispetto delle regole di visibilità
nel tempo, indipendentemente dai motori o dai documenti che si vanno ad aggiungere.
Strumenti di Amministrazione e servizi trasversali
Servono agli amministratori, sviluppatori e persone dedicate ai test per supportare il loro
lavoro. Questi strumenti (es. gestione credenziali o gestione sorgenti dati) sono tutti
presenti nella pagina principale di SpagoBI Server. Questo dà la possibilità di una gestione
“grafica” che facilita il lavoro degli amministratori di sistema (non hanno bisogno di
inserire righe di codice).
I servizi trasversali sono i generici servizi offerti all’utente come il motore di ricerca, il
servizio di invio mail o il visualizzatore di notifiche.
SpagoBI SDK è lo strumento utilizzato da SpagoBI Studio per supportare le varie fasi di
progettazione, installazione e test, nonché il caricamento e scaricamento di documenti
presenti all’interno di SpagoBI Server (figura 24). SpagoBI SDK mette a disposizione
attraverso il Web Service una serie di servizi, che sono fruibili attraverso un portale
esterno.
• Catalogo mappe (map catalogue)– elenco delle mappe presenti in SpagoBI
• Motori (engine) – elenco dei motori presenti sul server
51

• Data Set – elenco dei data set con i relativi metadati
• Documenti analitici – elenco di tutti i documenti analitici (con le relative
proprietà), con la possibilità di eseguirli
• Sorgente dati (data source) – elenco delle connessioni ai database differenti
L’integrazione dei documenti all’interno di un portale esterno avviene attraverso:
• la libreria Java Script – che crea un HTML iFrame, dal quale potranno essere
consultati i vari documenti;
• un TagLib – che può essere integrato in un JSP e grazie all’iFrame sarà possibile
visualizzare i documenti.
Figura 24. Integrazione dei vari moduli
5.5.2 Reportistica
La creazione e modifica di report è possibile grazie a due strumenti: SpagoBI Studio e
SpagoBI Meta .
Il primo è basato su Eclipse ed è stato creato per fornire agli sviluppatori strumenti per la
modifica e progettazione dei vari documenti analitici.
Attraverso il modulo SpagoBI SDK è possibile comunicare direttamente con SpagoBI
Server al fine di supportare le varie fasi di progettazione, installazione e test su server.
Gli sviluppatori hanno anche la possibilità di accedere ai documenti presenti sul server e
se necessario modificarli in locale.
Come già visto nel capitolo 4.2.2, SpagoBI Studio figura 25 è un ambiente di sviluppo
basato su Eclipse, creato principalmente per la modifica o creazione di documenti analitici
o documenti composti. Tali documenti possono essere creati anche da utenti che non
hanno conoscenze tecniche. Con la creazione di un nuovo documento, si deve per prima
cosa definire la struttura (es. l’area che avrà il documento) e poi con un semplice click del
mouse si spostano gli elementi desiderati (griglie, liste, tabelle, grafici ecc.) in quest’area.
52

Si ottiene cosi un documento composto, che ingloba al suo interno più elementi anche
differenti tra loro.
Figura 25. Esempio di creazione di un report con SpagoBI Studio
SpagoBI Meta è il modulo che permette di definire l’interfaccia per l’accesso ai dati che
sarà a disposizione dell’utente finale all’interno di SpagoBI e degli altri moduli di analisi.
Attraverso tale modulo è quindi possibile definire oggetti base ed oggetti complessi a
partire dal database del Data Mart, in modo che l’interrogazione di tali oggetti da parte
dell’utente sia trasparente rispetto alla struttura fisica delle tavole del database ed alle
loro relazioni.
La procedura di importazione dei report e uguale per entrambi i strumenti e prevede la
compilazione di un apposito form, specificando il template (costituito usando uno dei due
strumenti) e la sorgente dati da cui si alimenterà, oltre che ad informazioni generiche
come il nome del report ecc. Al lancio del report il Web service di SpagoBI creerà una
connessione con la sorgente dati e la passerà al motore di competenza, per farlo eseguire.
5.5.3 Cruscotti
SpagoBI distingue due tipi di cruscotti:
53

• semplici - rappresentazione di un solo documento con dati in tempo reale
• interattivi – rappresentazione che combina di più documenti (con relazioni in
comune) in un'unica schermata
I componenti principali di un cruscotto (semplice o interattivo) sono i grafici. La loro
manipolazione è affidata a un motore interno a SpagoBi, mentre la visualizzazione è
affidata a una libreria open source JFreeChart che abbiamo già incontrato nel capitolo
4.4.3.
I grafici possono essere di vario tipo: a bolle, scatola, lancetta, gruppo, oltre ai classici
barra, linea e torta.
I cruscotti interattivi sono, a differenza di quelli semplici, gestiti dal motore SpagoBI
composite document, che permette di visualizzare in un'unica pagina più documenti
(mappe, report, grafici), al fine di rendere disponibile al’utente più informazioni in
un'unica schermata.
La procedura per la creazione di un cruscotto è fatta interamente online. Per prima cosa
l’utente deve impostare il motore che sarà utilizzato, segue la definizione di un dataset, la
creazione di un nuovo documento di tipo cruscotto ed infine l’esecuzione di quest’ultimo.
Il motore predisposto per la gestione dei cruscotti è SpagoBI Dashboard, che supporta i
seguenti widget:
• rotate
• table
• line trend
Il motore viene definito in un apposito form con l’inserimento di vari parametri tra i quali
si segnala il nome e l’etichetta che avrà il cruscotto. Segue la creazione di un dataset
(sempre con un apposito form), dove viene inserita una query, che permetterà di
recuperare i dati, dalla sorgente definita dall’utente.
All’utente non resta che creare un template xml per i widget e creare un nuovo
documento, associando il motore, il dataset e il template appena creati. Al lancio del
cruscotto i dati vengono prelevati a intervalli regolari in modo da assicurare la
“freschezza” di quest’ultimi.
Va precisato che la creazione e mantenimento dei cruscotti e risultata semplice e
intuitiva, l’unico problema potrebbe rappresentare la definizione della query e la
definizione del template dei widget.
Di seguito nella figura 26 viene proposto un esempio di un cruscotto dinamico.
54

Figura 26. Esempio di cruscotti interattivi
5.5.4 Analisi OLAP
SpagoBI integra al suo interno tre motori per la gestione dell’analisi OLAP,
JPivot/Mondrian, JPalo/Mondrian, JPivot/XMLA Server (ad es. MS Analysis Services).
L’analisi OLAP è analoga a quella nel capitolo 5.4.5 ovvero la parte che gestisce i database
e fatta da Mondrian, (usandolo in combinazione con JPivot o JPalo) oppure con XMLA
Server (solamente per JPivot). Vediamo il caso in cui si utilizza il motore Mondrian per
relazionarsi con il database; per prima cosa bisogna definire un schema Mondrian
utilizzando l’apposito tool Mondrian schema workbench (scaricabile a parte dalla pagina
principale di Mondrian) o in alternativa scriverlo a mano.
Dopo aver creato lo schema bisogna posizionarlo fisicamente nella cartella OLAP di
SpagoBI. La posizione della cartella è definita come risorsa JNDI nell’application server (in
Tomcat si trova in conf/server.xml). Lo schema deve essere copiato in engine-config.xml,
nel blocco SCHEMAS come mostrato di seguito:
<SCHEMAS>
<SCHEMA catalogUri="/Olap/FoodMart.xml" name="FoodMart" />
<SCHEMA catalogUri="/Olap/SbiMonitor.xml" name="SpagoMonitor" />
</SCHEMAS>
Dopo aver fatto ciò bisogna riavviare il server e creare un nuovo documento OLAP. Grazie
a un apposito strumento è possibile creare il template (figura 27), che specificherà quale
cubo usare è la query MDX che dovrà essere eseguita sul cubo selezionato. Si può notare
che durante la definizione del “documento” si può impostare il file come crittabile, che
critta il documento permettendo un’ulteriore protezione dei dati.
Dalla versione 2.6 in poi SpagoBI permette, con il motore SpagoBIJPivotEngine, di definire
i diritti di accesso alle analisi OLAP. Questo è fatto attraverso l’aggiunta di attributi nel file
schema .xml. Durante la creazione del template, bisogna specificare quale profilo o
gruppo di utenti può utilizzare il documento.
55

Dopo aver definito anche quest’ultimo parametro all’utente non resta che eseguire il
documento appena creato (figura 28).
Figura 27. Schermata per la creazione di un template.
Figura 28. Esempio di un analisi OLAP con JPivot
56

Vediamo ora l’accoppiata JPalo/Mondrian. Come già detto in precedenza Palo Pivot è
integrato nella suite di SpagoBI e interagisce con Mondrian server (anch’esso integrato
nella suite) tramite una connessione XMLA.
Come nel caso JPivot/Mondrian si deve per prima cosa mettere mano al codice
configurando Mondrian per fargli usare la sorgente dati come se fosse una risorsa JDNI (si
possono definire più di una risorsa dati) in server.xml. Bisogna inoltre configurarle anche
nel file context.xml nella cartella SpagoBIJPaloEngine/META-INF/. Nello specifico bisogna
indicare nel tag DataSourceInfo la corretta risorsa JDNI, che dovrà essere usata. Gli altri
tag (più importanti) sono i seguenti:
• jpalo.admin.user=[jpalo_username]
• jpalo.admin.password=[jpalo_password]
• jpalo.mondrian.connection.url=[mondrian_host]:[mondrian_port]
• jpalo.mondrian.connection.service=SpagoBIJPaloEngine/xmla
• jpalo.mondrian.connection.name=[name_of_mondrian_connection]
Il prossimo passo è quello di posizionare lo schema Mondrian, creato con l’apposito tool
Mondrian Schema Workbench nella cartella delle risorse di SpagoBI.
Per la gestione del documento, bisogna come già visto per JPivot configurare un template
e specificare i seguenti dati:
• Document type : On-line analytical processing
• Url : [protocol]://[host]:
[port]/SpagoBIJPaloEngine/com.tensegrity.wpalo.SpagoBIJPaloEngine/JPaloEngi
neStartServlet
• Driver : it.eng.spagobi.engines.drivers.jpalo.JPaloDriver
All’utente non resta che definire il cubo (da cui attingere i dati) e definire le varie viste. La
figura 29 mostra un esempio di una analisi fatta utilizzando JPalo.
57

Figura 29. Esempio di analisi OLAP fatta con JPalo
Nella pagina iniziale di SpagoBI si trova un FAQ con 48 domande e risposte (molto
esaurienti) che danno un’idea sulla suite SpagoBI.
In un apposita pagina wikix
sono disponibili le descrizioni dei singoli strumenti. La
manualistica a supporto dell’utente e scaricabile nell’apposita pagina di download.
Tra le curiosità si segnala una demo online, ovvero un simulatore Java che riproduce il
server SpagoBI e permette a chiunque di farsi un idea delle funzionalità messe a
disposizione da SpagoBI. Una scelta molto interessante, anche se l’utente può compiere
azioni limitate, per attirare nuovi potenziali clienti della piattaforma.
Come funzionalità aggiuntiva SpagoBI integra al suo interno un motore GIS/GEO, che
permette di collocare i dati su una mappa cartografica come si può vedere dalla figura 30.
Figura 30. Esempio di una mappa in SpagoBI
58

Come segnalato in precedenza SpagoBi mette a disposizione un apposito strumento,
SpagoBI Meta, incaricato della gestione ed interrogazione dei metadati. Questi possono
essere di due tipi:
• Business – permettono all’utente di conoscere al meglio i dati che sta
consultando
• Tecnici – permettono all’amministratore di monitorare la provenienza dei dati,
effettuare analisi e generare documentazione automatica.
Il modulo offre anche funzionalità aggiuntive come lo strumento a supporto della fase di
reverse engineering della base dati (per definire oggetti base e oggetti complessi) o
l’ampliamento e l’arricchimento della base di conoscenza dei metadati presenti in
SpagoBI Server (per permettere l’interrogazione attraverso strumenti come l’OLAP o
QbE).
59

6. VALUTAZIONE COMPARATIVA
La valutazione delle varie soluzioni risulta molto complessa a fronte delle differenze
architetturali adottate nei singoli software e nell’offerta di servizi proposti.
Si è pertanto scelto di scegliere un approccio di tipo grafico-descrittivo, che consiste nell’uso
di tabelle per evidenziare i punti di forza e le debolezze di ogni prodotto, e una parte
descrittiva che ne riassuma le caratteristiche.
In particolare, la metodologia adottata consiste nella valutazione di tipo semplice,
utilizzando congiunzioni SI-NO per indicare la disponibilità della funzionalità, o la presenza di
una determinata caratteristica.
Il tutto è riassunto in una tabella conclusiva, che è in forma numerica, per meglio
evidenziare la quantità di funzionalità messe a disposizione da ogni singolo software.
Gli aspetti considerati per tale valutazione derivano dalle esigenze della pubblica
amministrazione in termini di:
• Reportistica
• Analisi OLAP
• Cruscotti
• Esigenze di carattere generale, quali gestione della sicurezza, interfaccia web, ecc.
Vediamo ora di considerare le varie funzionalità nel dettaglio cominciando dalla reportistica.
REPORTISTICA
Funzionalità BIRT JASPERSOFT PENTAHO SPAGOBI
STUMENTO DI
REPORTING
IMPLEMENTATO NEL
WEB SERVER
NO NO SI SI
STRUMENTO DI
REPORTING
INDIPENDENTE
SI SI SI SI
REPORT SEMPLICI SI SI SI SI
REPORT COMPLESSI SI SI SI SI
60

VALUTAZIONE COMPARATIVA E CRITERI PER LA SCELTA DI STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE PER LA PUBBLICA AMMINISTRAZIONE DEL FVGTesi

VALUTAZIONE COMPARATIVA E CRITERI PER LA SCELTA DI STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE PER LA PUBBLICA AMMINISTRAZIONE DEL FVGTesi

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a VALUTAZIONE COMPARATIVA E CRITERI PER LA SCELTA DI STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE PER LA PUBBLICA AMMINISTRAZIONE DEL FVGTesi

Semelhante a VALUTAZIONE COMPARATIVA E CRITERI PER LA SCELTA DI STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE PER LA PUBBLICA AMMINISTRAZIONE DEL FVGTesi (20)

VALUTAZIONE COMPARATIVA E CRITERI PER LA SCELTA DI STRUMENTI OPEN SOURCE DI BUSINESS INTELLIGENCE PER LA PUBBLICA AMMINISTRAZIONE DEL FVGTesi