Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
UNIVERSITA DEGLI STUDI DI PARMA
FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI
Corso di Laurea in Informatica
Tesi di Laurea Triennale
Business Intelligence:un caso di studio nel settore
cosmetico
Candidato:
Federico Fontana
Relatore: Correlatore:
Prof. Giulio Destri Dott. Fabio Morsiani
Anno Accademico 2009/2010
iii
A Elena, che mi e stata vicino
durante questi anni di studio.
v
Ringraziamenti
Desidero innanzitutto ringraziare la mia famiglia, Anna, Daniele, Francesco e Veronica
per avermi sempre sostenuto durante il mio percorso di studio.
Ringrazio l’azienda Sinfo-One s.p.a. per avermi permesso di effettuare lo stage azien-
dale su cui si basa questo lavoro di tesi.
Un particolare ringraziamento al Dott. Fabio Morsiani che e stato il mio tutor aziendale
e grazie al quale ho conosciuto il mondo della Business Intelligence.
Desidero inoltre ringraziare Leonardo Barbato, Sara Cangini, Emanuele Marchesi, An-
drea Messetti, Sara Sacco e Antonio Viscomi per il supporto e la formazione aziendale.
Ringrazio il Prof. Giulio Destri per il tempo dedicatomi durante questi mesi di lavo-
ro e per i suggerimenti che ha saputo darmi.
Infine un grazie a tutti i pagliacci del dipartimento: Fede Ferretti, Fede Bacchi, Gan-
do, Leo, Matte, Marti, Paolo, Ali, Tocci, Ila, Jessica, Bea, Ponz e, perche no, anche il
Disa.
vii
Presentazione dell’azienda
Sinfo One S.p.A. nasce il 1◦ settembre 2007, dalla Divisione Industria di Sinfo Pragma
e si rivolge, in particolare, alle medie aziende italiane fornendo soluzioni ERP estese,
consulenza direzionale, organizzativa, di processo e tecnologica nonche servizi di system
integration.
Flessibilita, continui investimenti in ricerca e formazione e attenzione alle esigenze dei
clienti costituiscono le basi del suo progetto di sviluppo.
L’offerta ERP e basata sulla piattaforma proprietaria Si Fides e sulla piattaforma Oracle
JD Edwards Enterprise One che Sinfo One completa con il proprio verticale per il Food
& Beverage.
Sinfo One opera su tutto il territorio nazionale attraverso un team di oltre 100 profes-
sionisti con esperienze nei diversi settori di mercato e profonde competenze sui relativi
processi specifici.
Grazie alla specifica conoscenza della piattaforma Oracle JDEdwards ed alle competenze
ed esperienze dei propri team di professionisti e in grado di offrire soluzioni verticalizza-
te e integrate a Enterprise Content Managemet, Enterprise Performance Management e
Business Intelligence.
Sinfo One e Oracle
Sinfo One e Platinum Partner di Oracle e Oracle Accelerate Partner per il Food & Beve-
rage. Si e inoltre aggiudicata l’edizione 2010 degli Oracle Partner Specialization Awards
per la regione Europa, Medio Oriente e Africa. Un grande successo per l’azienda che ha
cosı superato la concorrenza di altre 87 societa provenienti da 22 Paesi, tutte candidate
alla conquista del riconoscimento.
viii
Esperienza e competenza
I professionisti Sinfo One hanno competenze estese e specializzate, sono attenti ai biso-
gni dei clienti e abituati a lavorare con obiettivi ambiziosi. Particolare attenzione, con
divisioni e laboratori di ricerca (Isi Lab) dedicati, e data a tematiche di ECM, EPM, BI
e SCM.
Sul fronte del Supply Chain Planning il team di esperti Sinfo One ha messo a punto
una metodologia proprietaria: Step (Sistemi Tecnologici di Pianificazione) che nasce da
know-how, esperienza, efficienza e selezione delle migliori tecnologie.
Sinfo One numeri
Sinfo One ha chiuso il 2010 con un fatturato di 9,5 milioni (nel 2009 il fatturato e stato
di 9 milioni di euro), risultato buono se si tiene conto della particolare situazione di crisi
che attraversa l’economia mondiale.
Il budget 2011 prevede un fatturato di 10,5 milioni e i dati dei primi mesi sono in linea
con il budget.
Sinfo One SPA: Via Benedetta 77/a - 43122 Parma - Tel. 0521.9371, Fax 0521.775824
[email protected] - www.sinfo-one.it
ix
Sommario
L’aumento esponenziale del volume dei dati operazionali ha reso il calcolatore l’unico sup-
porto adatto al processo decisionale, inoltre l’utilizzo massiccio di tecniche di analisi dei
dati aziendali ha reso il sistema informativo un elemento strategico per la realizzazione
del business. Per questi motivi il ruolo dell’informatica e passato da passivo strumento
per la registrazione delle operazioni, a fattore decisivo per l’individuazione di elementi
critici dell’organizzazione e di potenziali aree di business.
Il termine Business Intelligence (BI) venne introdotto nel 1989 da Howard Dresner, per
indicare un insieme di strumenti e procedure che consentono a un’azienda di trasformare i
propri dati di business in informazioni utili al processo decisionale, da rendere disponibili
alla persona giusta e nel formato idoneo. Le informazioni ottenute sono utilizzate dai
decisori aziendali (decision maker) per definire e supportare le strategie di business.
Lo strumento principe per la BI e stato fino a oggi il data warehouse (DW), al quale
vanno riconosciuti meriti come la capacita di gestire serie storiche dei dati o di effettuare
analisi multidimensionali, basandosi su un modello semplice e che puo essere facilmente
assimilato dai manager. Caratteristiche come queste hanno facilitato l’ampia diffusione
dei sistemi di data warehousing e hanno favorito la maturazione degli utenti che, una vol-
ta sfruttate appieno le sue potenzialita, cominciano a percepirne i limiti e di conseguenza
richiedono nuove soluzioni in grado di soddisfare l’accresciuta richiesta di informazioni.
In particolare sorge la necessita di soluzioni che consentano analisi su dati provenienti da
sorgenti informative eterogenee, con aggiornamenti piu rapidi rispetto a quelli del DW,
che difficilmente hanno una periodicita inferiore al giorno, e che consentano ai decion
maker la possibilita di “prevedere il futuro”.
Il data mining, le analisi what-if e le attivita di Business Performance Management
(BPM), sono alcune delle tecniche che vengono utilizzate per soddisfare i limiti che i
sistemi di data warehousing presentano.
La tecnologia Oracle BI 11g fornisce una gamma completa di soluzioni per la business
intelligence. Tuttavia nel caso di studio realizzato utilizzeremo le sole funzionalita di
analisi su dati provenienti da un data warehouse.
INDICE
1 I dati e l’azienda 1
1.1 Processi e catena del valore . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 La catena del valore di Porter . . . . . . . . . . . . . . . . . . . . 3
1.1.2 La piramide di Anthony . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 I principali tipi di sistemi usati nelle aziende . . . . . . . . . . . . . . . . 6
1.3 I DBMS ed il loro ruolo . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 DBMS transazionali (OLTP) . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 DBMS per l’analisi (OLAP) . . . . . . . . . . . . . . . . . . . . . 12
1.3.3 Perche e necessario distinguere . . . . . . . . . . . . . . . . . . . . 13
2 Introduzione alla Business Intelligence 15
2.1 Data warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Componenti di un data warehouse . . . . . . . . . . . . . . . . . . 18
2.1.2 Architetture per il data warehousing . . . . . . . . . . . . . . . . 20
2.1.3 Gli strumenti ETL . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Il modello multidimensionale . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Modellazione concettuale: il Dimensional Fact Model . . . . . . . 28
2.2.2 Modellazione logica . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2.1 I sistemi ROLAP . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2.2 I sistemi MOLAP . . . . . . . . . . . . . . . . . . . . . . 34
2.2.2.3 Slowly Changing Dimensions (SCD) . . . . . . . . . . . 35
xii INDICE
2.3 La Business Intelligence (BI) . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.1 Accedere al data warehouse . . . . . . . . . . . . . . . . . . . . . 40
2.3.2 Business Intelligence: oltre il data warehouse . . . . . . . . . . . . 44
2.3.2.1 Data Mining . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3.2.2 Analisi what-if . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.2.3 Business Performance Management (BPM) . . . . . . . 49
2.3.3 Ciclo delle analisi di Business Intelligence . . . . . . . . . . . . . . 50
3 La tecnologia Oracle BI 11g 53
3.1 Oracle e la business intelligence . . . . . . . . . . . . . . . . . . . . . . . 54
3.2 Architettura logica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3 Installazione del prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4 Componenti di front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.4.1 Analisi e reportistica . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.4.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4.3 Scorecard e Strategy Management . . . . . . . . . . . . . . . . . . 69
3.4.4 BI Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.4.5 Actionable Intelligence . . . . . . . . . . . . . . . . . . . . . . . . 70
3.4.6 BI Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.5 L’Administration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.6 Comparazione con gli altri competitor . . . . . . . . . . . . . . . . . . . . 75
3.6.1 Prodotti open source . . . . . . . . . . . . . . . . . . . . . . . . . 79
4 Il caso di studio: Realizzazione di una soluzione di Business Intelligence
per l’azienda Cadey 81
4.1 Presentazione dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2 Struttura data center Cadey . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3 Struttura del data mart vendite . . . . . . . . . . . . . . . . . . . . . . . 85
4.4 Costruzione dei metadati . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.4.1 Livello fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.4.2 Livello logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.4.3 Livello di presentazione . . . . . . . . . . . . . . . . . . . . . . . . 92
4.4.4 Validazione del repository . . . . . . . . . . . . . . . . . . . . . . 92
4.5 Costruzione della reportistica . . . . . . . . . . . . . . . . . . . . . . . . 93
Conclusioni 95
CAPITOLO 1
I dati e l’azienda
Un’azienda e una struttura sociale stabile e formale che trae risorse dall’ambiente e le
elabora per produrre un risultato. Il capitale e la forza lavoro sono i principali fattori di
produzione forniti dall’ambiente. L’azienda trasforma questi input in prodotti e servizi
tramite la funzione di produzione. I prodotti e i servizi vengono poi consumati dall’am-
biente.
Molte aziende operano in un contesto complesso ed in continua trasformazione: le nuove
opportunita che si vengono a creare devono essere valutate rapidamente con sempre mag-
gior frequenza per non rischiare di perdere la propria competitivita. In questo contesto,
le tecnologie dell’informazione e della comunicazione (ICT) stanno contribuendo a modi-
ficare il modo di lavorare e di vivere dell’azienda, attraverso nuove e sofisticate soluzioni
di elaborazione e trasmissione dell’informazione. La disponibilita, a costi sempre minori,
di tali soluzioni sta provocando significativi cambiamenti soprattutto per quelle attivita,
sempre piu numerose, che comportano gestione di informazione.
La costruzione dell’informazione ed il suo uso entro l’azienda, a partire da dati “grezzi”
di ingresso, puo avvenire attraverso quattro stadi successivi qui di seguito riportati:
• Dati: sono l’insieme di fatti, il risultato di una misurazione, la materia prima del-
l’informazione in relazione agli oggetti del mondo reale. Non possiedono significato
al di la della loro esistenza. Possono essere scoperti, ricercati, raccolti e prodotti.
2 I dati e l’azienda
• Informazione: l’informazione conferisce un significato ai dati, grazie al fatto che li
pone in una relazione reciproca e li organizza secondo dei modelli. Per trasformare i
dati in utili informazioni, un’impresa deve impegnare risorse per organizzare i dati
in categorie di comprensione, come rapporti relativi ai totali di vendita mensili,
giornalieri, regionali o per negozio.
• Conoscenza: la conoscenza e informazione rielaborata ed applicata. E un evento
cognitivo e persino fisiologico che ha luogo nella mente delle persone, ma allo stesso
tempo viene conservato in librerie e registrazioni, condiviso, ad esempio, per mezzo
di conferenze, e conservato dalle aziende sotto forma di processi gestionali codificati
e documentati e know-how dei dipendenti. La conoscenza presente nella mente dei
dipendenti e che non sia documentata prende il nome di conoscenza tacita, mentre
quella documentata viene definita conoscenza esplicita.
• Saggezza: la saggezza e l’esperienza collettiva ed individuale dell’applicazione della
conoscenza alla soluzione di problemi. Essa implica il dove, come e quando applicare
la conoscenza. Non e possibile creare la saggezza allo stesso modo di come vengono
creati i dati e le informazioni, e non e possibile condividerla con gli altri, come
invece avviene per la conoscenza.
Per l’impresa la conoscenza e un tipo di bene diverso, per esempio, dagli edifici o dai beni
finanziari; inoltre la conoscenza e un fenomeno complesso e il processo di gestione che
la riguarda ha molti aspetti. Possiamo inoltre riconoscere che il nucleo delle competenze
basate sulla conoscenza di un’impresa, ossia le due o tre cose che un’azienda fa meglio,
sono beni organizzativi fondamentali. Sapere come fare le cose in modo efficiente adot-
tando soluzioni che le altre organizzazioni non possono riprodurre e una fonte primaria
di profitto e di vantaggio competitivo che i concorrenti non possono facilmente acquistare
sul mercato.
La collaborazione e la comunicazione con professionisti ed esperti, la creazione di nuova
conoscenza, l’agevolazione dell’accesso alla conoscenza e l’uso di quest’ultima per miglio-
rare i processi gestionali e direzionali sono diventati elementi vitali per l’innovazione e la
sopravvivenza delle imprese [LL06].
1.1 Processi e catena del valore 3
1.1 Processi e catena del valore
Con il termine “processo” si fa riferimento a un insieme di attivita attraverso le quali
le risorse di un’impresa o, piu in generale, di un’organizzazione (individui e mezzi) rea-
lizzano la mission organizzativa trasformando input (materiali o immateriali) in output,
ossia in prodotti/servizi che trasferiscono valore al fruitore dei prodotti/servizi stessi. Il
concetto di valore e fondamentale, in quanto uno degli scopi fondamentali della model-
lazione tramite processi delle attivita aziendali e proprio un ausilio alla misurazione del
valore prodotto. In ciascun processo vengono tipicamente coinvolte competenze e unita
organizzative diverse che rispondono al responsabile del processo (process owner), figura
alla quale sono stati affidati la responsabilita e il coordinamento del processo stesso.
Figura 1.1: Rappresentazione di un processo aziendale
1.1.1 La catena del valore di Porter
In ogni organizzazione e possibile individuare alcuni processi fondamentali. La catena
del valore di Porter rappresenta una classificazione dei processi, modellizzando il funzio-
namento dell’intera azienda come una successione di processi. I processi sono suddivisi
in: [Des07]
4 I dati e l’azienda
• Buy side: come acquisti/approvvigionamenti, ossia processi il cui output proviene
dai fornitori;
• Inside: ossia aventi sia input sia output interni all’azienda, che possono essere ul-
teriormente suddivisi tra processi primari, che sono direttamente legati alla produ-
zione del valore del core business dell’azienda e processi ausiliari, che non generano
direttamente un valore, ma producono quei servizi senza i quali l’organizzazione
non potrebbe operare;
• Sell side: il cui output e rivolto direttamente ai clienti esterni dell’azienda.
1.1.2 La piramide di Anthony
La piramide di Anthony, illustrata in Figura 1.2 e una modalita di rappresentazione del-
l’organizzazione, introdotta con l’obiettivo specifico di classificare le attivita tipicamente
svolte nell’organizzazione stessa e identificare il ruolo dei sistemi informatici a supporto
di tali attivita e la progettazione del loro sviluppo. Nonostante l’inarrestabile e radicale
innovazione delle ICT questo modello ha sostanzialmente mantenuto intatta la validita
della sua formulazione originaria nel corso del tempo.
Il modello di Anthony, sviluppato nel 1965, distingue tre diverse tipologie di attivita,
ognuna delle quali interagisce con quella adiacente realizzando cicli di pianificazione e
controllo attraverso i quali verificare risultati e decidere azioni correttive. Tali attivita
sono: [PM05]
• Attivita strategiche: concorrono all’identificazione degli obiettivi primari dell’a-
zienda nei confronti del mercato e della concorrenza;
• Attivita tattiche: traducono gli obiettivi strategici in obiettivi economici, defi-
nendo le previsioni a medio termine e verificandone periodicamente l’attuazione;
• Attivita operative: attuano i piani definiti occupandosi dello svolgimento delle
attivita correnti.
1.1 Processi e catena del valore 5
Figura 1.2: Le attivita aziendali secondo Anthony
Una tale classificazione e dovuta al fatto che attivita appartenenti a ciascuna tipologia
possiedono caratteristiche comuni per quanto riguarda il fabbisogno informativo che ri-
chiedono per supportare in modo adeguato il loro svolgimento. I criteri per identificare
tali caratteristiche sono: [TRS03]
• Orizzonte temporale di riferimento: e l’intervallo di tempo che intercorre tra
due esecuzioni successive di una determinata attivita. Le attivita strategiche hanno
effetto nel “lungo termine”, mentre le attivita operative solitamente hanno effetto
immediato;
• Orientamento all’esterno: e l’entita dell’impatto che le attivita hanno al di fuori
dei confini dell’organizzazione. Le attivita strategiche hanno effetto sul contesto
competitivo in cui l’organizzazione opera, mentre le attivita operative sono confinate
nell’interno dell’organizzazione;
• Discrezionalita: e il grado di arbitrio con il quale si puo decidere come e quando
svolgere un’attivita. E massima a livello strategico e diminuisce progressivamente
nelle attivita di piu basso livello. Nelle attivita operative le procedure di esecuzione
sono il piu possibile precise;
6 I dati e l’azienda
• Ripetitivita: e la frequenza con cui un’attivita viene svolta. Un’alta ripetitivita
caratterizza le attivita operative;
• Prevedibilita: e correlata alla ripetitivita. E tipica delle attivita operative, poiche
producono risultati prevedibili a priori e la loro esecuzione e prevista a priori nei
tempi e nella modalita;
• Ruoli organizzativi coinvolti: Le attivita strategiche sono di competenza della
direzione aziendale. Le attivita di programmazione e controllo sono assegnate alle
direzioni funzionali o di divisione. Le attivita operative sono condotte dal personale
esecutivo.
In particolare questo ultimo criterio e alla base della scomposizione dell’organizzazione,
che secondo un approccio di tipo gerarchico puo essere rappresentata con la piramide
indicata.
1.2 I principali tipi di sistemi usati nelle aziende
Poiche in un’azienda esistono interessi, specializzazioni e livelli differenti, esistono anche
tipi di sistemi diversi. Non esiste un sistema in grado di fornire tutte le informazioni di
cui ha bisogno un’azienda.
Come abbiamo visto prima, secondo il modello di Anthony un’azienda puo essere scom-
posta in tre livelli, ad ognuno dei quali corrispondono differenti tipologie di attivita:
strategiche, tattiche ed operative. E inoltre possibile osservare un’ulteriore suddivisione
in aree funzionali, come per esempio vendite e marketing, produzione, gestione finanziaria
e contabilita e risorse umane. I sistemi informativi hanno lo scopo di servire questi diversi
interessi nell’azienda.
I sistemi informativi a supporto delle attivita strategiche aiutano i senior manager
ad affrontare i problemi strategici e a valutare le tendenze a lungo termine sia nell’azienda
sia nell’ambiente esterno. La loro principale preoccupazione e far corrispondere i cambia-
menti nell’ambiente esterno con le capacita organizzative dell’azienda. “Quali saranno i
tassi di occupazione tra cinque anni?”. “Quali saranno le tendenze dei costi in questo
campo a lungo termine e come si posizionera la nostra azienda?”. “Quali prodotti dovre-
mo produrre nei prossimi cinque anni?”.
1.2 I principali tipi di sistemi usati nelle aziende 7
I sistemi informativi a supporto dell’attivita manageriale favoriscono le attivita
di monitoraggio, di controllo, decisionali e amministrative dei middle manager. La prin-
cipale domanda a cui devono rispondere questi sistemi e: “Le cose funzionano bene?”. In
genere i sistemi a livello manageriale forniscono report periodici piuttosto che informa-
zioni istantanee sulle operazioni.
I sistemi informativi operativi supportano i manager per la registrazione delle atti-
vita elementari e delle transazioni che si svolgono nell’azienda. Lo scopo principale dei
sistemi a questo livello e quello di supportare le attivita di routine e registrare il flusso
delle transazioni all’interno dell’azienda.
Normalmente in un’azienda esistono sistemi informativi operativi, di supporto alle at-
tivita manageriali e di supporto alle attivita strategiche per ognuna delle aree funzionali
(alcuni esempi sono stati riportati sopra).
Per esempio la funzione vendite sara in generale dotata di:
• un sistema operativo per registrare i dati di vendita quotidiani e per elaborare gli
ordini;
• un sistema informativo di supporto all’attivita manageriale avra un sistema per
registrare i dati di vendita mensili suddivisi per area geografica e indicare i luoghi
in cui le vendite hanno superato o non hanno raggiunto i livelli previsti;
• un sistema informativo di supporto alle attivita strategiche che prevede le tendenze
di vendita nell’arco di cinque anni.
I principali tipi di sistemi informativi sono:
TPS (Transaction Processing System):
I sistemi di elaborazione delle transazioni sono i sistemi operativi di base che servono il
livello operativo dell’azienda. Un sistema di elaborazione delle transazioni e un sistema
computerizzato che svolge e registra le transazioni di routine necessarie quotidianamente
per condurre le attivita aziendali. Per esempio, puo trattarsi di sistemi per l’inserimento
di ordini, di prenotazione alberghiera, di calcolo degli stipendi, di archiviazione della do-
cumentazione relativa ai dipendenti e delle spedizioni.
I sistemi di elaborazione delle transazioni sono talvolta cosı importanti per un’azienda
8 I dati e l’azienda
che un guasto di qualche ora puo sancire la sua fine e talvolta anche di altre aziende ad es-
sa connesse. I TPS sono anche i principali produttori di informazioni per altri tipi sistemi.
MIS (Management Information System):
Il termine sistemi di gestione dell’informazione designa una specifica categoria di sistemi
informativi che servono le funzioni di livello manageriale. Generalmente adempiono a
questo compito offrendo ai manager report e spesso un accesso online alle prestazioni
correnti e ai dati storici dell’azienda. In genere questi sistemi sono orientati quasi esclu-
sivamente a eventi interni.
Il sistema di gestione delle informazioni normalmente risponde alle necessita dei manager
interessati a risultati settimanali, mensili e annuali, benche alcuni di essi consentano loro
di approfondire fino a vedere i dati su base giornaliera o persino oraria.
DSS (Decision Support System):
Anche i sistemi di supporto alle decisioni rispondono alle esigenze del livello manageriale
dell’azienda. Aiutano i manager a prendere decisioni che sono uniche, in rapido cam-
biamento e difficilmente specificate in anticipo. Questi sistemi riguardano problemi in
cui la procedura per arrivare ad una soluzione puo non essere nota completamente in
anticipo. Sebbene i sistemi di supporto alle decisioni usino le informazioni interne fornite
dai sistemi di elaborazione delle transazioni e dai sistemi di gestione delle informazioni,
spesso impiegano anche informazioni tratte da fonti esterne.
Per definizione i DSS hanno una maggiore potenza analitica rispetto agli altri sistemi.
Essi utilizzano vari modelli di analisi dei dati o condensano grandi quantita di dati in un
formato utile per prendere decisioni.
Sono sistemi progettati in modo che gli utenti possano lavorare direttamente sui dati;
questi sistemi sono costituiti da software di facile uso; sono interattivi e l’utente puo
cambiare le premesse, porre nuove domande e includere nuovi dati.
ESS (Executive Support System):
Sono sistemi informativi per il livello strategico. Per prendere le loro decisioni i senior
manager utilizzano sistemi di supporto direzionale. Essi riguardano decisioni non di
routine che richiedono giudizi, valutazioni e conoscenze approfondite, poiche non esiste
nessuna procedura standard per giungere a una soluzione.
1.2 I principali tipi di sistemi usati nelle aziende 9
I sistemi di supporto direzionale sono progettati per incorporare i dati legati a eventi
esterni, ma traggono anche informazioni dai MIS e dai DSS. Essi filtrano, comprimono,
estraggono ed individuano i dati critici, mettendo in luce quelli della massima importanza
per i senior manager.
Il sistema ESS utilizza software di grafica avanzato ed e in grado di presentare grafici e
dati provenienti da molte fonti.
La Figura 1.3 illustra il modo in cui i vari sistemi servono i vari livelli di un’azienda
e le relazioni tra di essi.
Figura 1.3: Relazioni tra i sistemi
I sistemi di elaborazione delle transazioni rappresentano la fonte principale dei dati per
gli altri sistemi, mentre i sistemi di supporto direzionale fondamentalmente ricevono i
dati dai sistemi di livello inferiore. E sostanzialmente vantaggioso avere una certa in-
tegrazione tra questi sistemi in modo che le informazioni possano fluire con facilita tra
le varie parti dell’azienda e offrire al management una visione delle prestazioni aziendali
che abbracci l’intera impresa. Ma l’integrazione costa. L’integrazione di tanti sistemi
differenti richiede molto tempo e impegno [LL06].
La Tabella 1.1 riassume le principali caratteristiche dei sistemi appena descritti.
10 I dati e l’azienda
Tipo di sistema Informazioni di input Elaborazioni svolte Informazioni di output Utenti
ESS Dati aggregati, esterni e
interni
Grafici, simulazioni; inte-
rattivita
Proiezioni; risposte alle in-
terrogazioni
Senior manager
DSS Bassi volumi di dati o grossi
database ottimizzati per l’a-
nalisi dei dati; modelli ana-
litici e strumenti di analisi
dei dati
Interattivita; simulazioni
analisi
Report speciali; analisi del-
le decisioni; risposte alle
interrogazioni
Professionisti; manager di
staff
MIS Riepilogo dei dati sulle tran-
sazioni, alti volumi di dati,
semplici modelli
Report di routine, model-
li semplici; analisi di basso
livello
Riepiloghi e report delle
eccezioni
Middle manager
TPS Transazioni; eventi Ordinamento, produ-
zione elenchi, unioni e
aggiornamenti
Report dettagliati, liste; rie-
piloghi
Personale operativo, super-
visori
Tabella 1.1: Caratteristiche dei diversi tipi di sistemi informativi.
1.3 I DBMS ed il loro ruolo
Nel primo capitolo abbiamo osservato quanto siano importanti i dati per un’azienda al
fine di produrre in successione informazione, conoscenza e saggezza.
L’attenzione ai dati ha caratterizzato le applicazioni dell’informatica fin dalle sue origini,
ma sistemi software specificamente dedicati alla gestione dei dati sono stati realizzati
solo a partire dalla fine degli anni Settanta. I DBMS (Data Base Management System)
rientrano in questi sistemi software; sono infatti in grado di gestire collezioni di dati che
siano grandi, condivise e persistenti, assicurando la loro affidabilita e privatezza. Come
ogni prodotto informatico, un DBMS deve essere efficiente ed efficace. Una base di dati
e una collezione di datigestita da un DBMS [ACPT06].
In un’azienda i vari tipi di sistemi utilizzano gli stessi dati ma con finalita e modalita
diverse. In base a questa osservazione, possiamo suddividere i sistemi in sistemi operazio-
nali o transazionali, ovvero sistemi a supporto di attivita operative e gestionali e sistemi
di analisi, ovvero sistemi a supporto delle attivita decisionali-strategici.
1.3.1 DBMS transazionali (OLTP)
Si definisce transazione un’unita logica di elaborazione, cioe una sequenza di operazioni
che hanno un effetto globale sul database, vista come un insieme atomico, che completa
con successo o fallisce, senza nessuna possibilita intermedia. Un sistema che mette a
disposizione un meccanismo per la definizione e l’esecuzione di transazioni viene detto
sistema transazionale. Il loro scopo principale e quello di supportare attivita routinarie
1.3 I DBMS ed il loro ruolo 11
e registrare il flusso delle transazioni entro l’azienda, al livello operativo; mentre il loro
componente principale sono i sistemi OLTP (On-Line Transaction Process), che svolgono
e registrano le transazioni di routine necessarie per le attivita quotidiane dell’azienda.
In un DBMS transazionale, tutto il codice che viene eseguito all’interno di una transazione
gode di proprieta particolari, le cosiddette proprieta acide delle transazioni: atomicita,
consistenza, isolamento e persistenza; il termine deriva dall’acronimo ACID (Atomicity,
Consistency, Isolation, Durability) [ACPT06].
• Atomicita: rappresenta il fatto che una transazione e un’unita indivisibile di esecu-
zione. Tutte le operazioni della sequenza terminano con successo (commit) oppure,
se anche una sola di esse fallisce, l’intera transazione viene abortita (abort); si
applica quindi un approccio “tutto o niente”;
• Consistenza: richiede che l’esecuzione della transazione non violi i vincoli di inte-
grita definita sulla base dati. Una transazione e una trasformazione corretta dello
stato del database, vale a dire, al termine di ogni transazione il database deve
trovarsi in uno stato consistente. Nel caso di un’eventuale violazione il sistema
interviene per annullare la transazione o per correggere la violazione del vincolo.
• Isolamento: richiede che l’esecuzione di una transazione sia indipendente dalla
contemporanea esecuzione di altre transazioni. In particolare si richiede che il risul-
tato dell’esecuzione concorrente di un insieme di transazioni sia analogo al risultato
che le stesse transazioni otterrebbero qualora ciascuna di esse fosse seguita da sola;
• Persistenza: richiede che l’effetto di una transazione che ha eseguito il commit
correttamente non venga piu perso. In pratica, una base di dati deve garantire che
nessun dato venga perso per nessun motivo.
Data la sua natura esecutiva, il sistema transazionale ha la tendenza a strutturare i flussi
e a standardizzare il contenuto informativo per minimizzare la possibilita di commette-
re errori e, nello stesso tempo, rendere le operazioni fluide e rapide. La sua struttura
e ottimizzata per sostenere l’attivita di un numero potenzialmente elevato di persone
che interagiscono puntualmente con la base dati in attivita di ricerca, di creazione e di
aggiornamento delle informazioni.
12 I dati e l’azienda
1.3.2 DBMS per l’analisi (OLAP)
Mentre i dati operazionali coprono un arco temporale di solito piuttosto limitato, poiche
la maggior parte delle transazioni coinvolge i dati piu recenti, i sistemi di analisi devono
permettere analisi che spazino sulla prospettiva di alcuni anni. Per questo motivo questi
ultimi sistemi devono essere aggiornati a intervalli regolari a partire dai dati operazionali
e sono in crescita continua. Volendo fare un paragone possiamo supporre che, a intervalli
regolari, venga scattata una fotografia istantanea dei dati operazionali. La progressione
delle fotografie scattate viene immagazzinata, generando un film che documenti la situa-
zione aziendale da un istante zero fino al tempo attuale.
I processi decisionali non sono standardizzabili ne riconducibili a procedure automatiz-
zate, perche sono influenzati dai modelli di realta che le persone utilizzano per effettuare
le scelte. I sistemi di analisi devono pertanto supportare il processo decisionale seguendo
i passaggi logici del decisore e dandogli la possibilita di avere visioni diversamente orga-
nizzate dai dati.
L’On-Line Analytical Processing (OLAP) e l’insieme dei sottosistemi informativi azien-
dali pensati per l’analisi interattiva dei dati, ottimizzati per garantire la massima effi-
cienza nell’elaborazione dei dati di sintesi e la massima flessibilita nelle interrogazioni.
Solitamente si basano su sistemi in sola lettura, o comunque articolati in modo tale da
privilegiare operazioni di lettura e di aggregazione dei dati, con strutture orientate agli
oggetti di analisi.
Il database per il processo di analisi ha le seguenti caratteristiche: [Des07]
• Entita denormalizzate;
• Disegno del database piu semplice (meno tabelle e meno associazioni) per una
comprensione piu facile da parte dell’utente;
• I dati memorizzati possono essere aggregati (riassuntivi);
• Le interrogazioni richiedono poche join;
• Ottimizzato per la consultazione di grandi moli di dati.
Dal momento che i sistemi di analisi, come gia detto, accedono ai dati quasi solamente
in sola lettura, le proprieta acide osservate precedentemente per i DBMS transazionali
possono essere tralasciate.
1.3 I DBMS ed il loro ruolo 13
1.3.3 Perche e necessario distinguere
L’elevata discrepanza tra le esigenze informative dei diversi livelli operativi e decisionali
aziendali impone, come abbiamo visto in precedenza, l’adozione di sistemi differenziati. I
sistemi informativi aziendali devono guidare sia l’attivita operativa che quella decisionale.
Fino a tempi recenti lo facevano tramite il solo sistema operazionale. Al crescere della
criticita del processo decisionale e della quantita di dati da elaborare, l’uso di un unico
sistema centralizzato come supporto sia operativo che informazionale ha manifestato nu-
merosi limiti.
In particolare, il sistema operazionale, strutturato sul concetto di transazione e di pro-
cesso, si e rilevato carente:
• Nella produzione di dati di sintesi, presentati tramite reportistica solitamente rigida,
modificabile solo con costi elevati;
• Nella possibilita di interrogare interattivamente la base dati, solitamente articolata
in modo complesso e accessibile ai soli addetti ai lavori:
• Nella disponibilita di dati fondamentali per il processo decisionale, ma non sempre
utilizzati o presenti a livello operativo;
• Nella velocita di risposta dal momento che la struttura dati e ottimizzata per il
supporto alle transazioni e non per l’elaborazione di informazioni di sintesi;
• Nella copertura temporale, solitamente ridotta per motivi di prestazioni e di oc-
cupazione di memoria di massa , che potrebbe rivelarsi insufficiente per condurre
analisi di tendenza sul medio/lungo periodo.
Uno schema delle differenze tra OLTP e OLAP , tra sistemi operazionali e sistemi di
analisi, e mostrato in Tabella 1.2 [PM05].
14 I dati e l’azienda
OLTP OLAP
Finalita Supporto all’operativita Supporto al processo decisio-
nale
Utenti Molti, livello operativo Pochi, livello direzionale
Dati Elementari, numerici e alfanu-
merici
Sintetici, solitamente numerici
Modalita di uti-
lizzo
Guidata, per processi e stati
successivi
Interrogazioni ad hoc
Quantita di da-
ti per operazione
elementare
Bassa: centinaia di record per
ogni transazione
Alta: milioni di record per ogni
query
Qualita In termini di integrita In termini di consistenza
Orientamento Per processo/applicazione Per soggetto
Frequenza di ag-
giornamento
Continua, tramite azioni Sporadica, tramite funzioni
esplicite
Copertura tem-
porale
Dati correnti Storica
Ottimizzazione Per accessi in lettura e scrittu-
ra su una porzione della base
di dati
Per accessi in sola lettura su
tutta la base di dati
Tabella 1.2: Differenze tra sistemi OLTP e sistemi OLAP.
CAPITOLO 2
Introduzione alla Business Intelligence
2.1 Data warehousing
Tra i sistemi di supporto alle decisioni, i sistemi di data warehousing sono probabilmente
quelli su cui negli ultimi anni si e maggiormente focalizzata l’attenzione sia nel mondo
accademico sia in quello industriale. E possibile definire in modo informale il data ware-
housing come segue:
Data warehousing: E una collezione di metodi, tecnologie e strumenti di ausilio
al cosiddetto “lavoratore della conoscenza” per condurre analisi dei dati finalizzate
all’attuazione di processi decisionali ed al miglioramento del patrimonio informativo.
Per capire a fondo il ruolo e l’utilita del data warehousing occorre analizzare le esi-
genze che ne hanno decretato la nascita. Kimball riassume efficacemente tali esigenze,
evidenziando le lamentele piu frequenti mosse dagli utenti.
“Abbiamo montagne di dati ma non possiamo accedervi!”. Questa frase esprime la fru-
strazione da parte di chi ha il ruolo e la competenza per decidere del futuro aziendale,
ma non possiede gli strumenti tecnici per ottenere, nella forma desiderata, i dati necessari.
16 Introduzione alla Business Intelligence
“Come e possibile che persone che svolgono lo stesso ruolo presentino risultati sostan-
zialmente diversi?”. In un contesto aziendale medio-grande sono tipicamente presenti
piu basi di dati, ciascuna relativa a una diversa area del business, spesso memorizzate
su piattaforme logico-fisiche differenti e non integrate dal punto di vista concettuale. I
risultati prodotti all’interno delle diverse aree saranno allora, molto probabilmente, in-
consistenti tra loro.
“Vogliamo selezionare, raggruppare e manipolare i dati in ogni modo possibile!”. Il pro-
cesso decisionale e difficilmente pianificabile a priori. L’utente finale vorrebbe disporre
di uno strumento sufficientemente amichevole e flessibile da consentirgli di condurre l’a-
nalisi in modo estemporaneo, lasciandosi guidare dalle informazioni via via ottenute per
decidere sul momento quali nuove correlazioni ricercare.
“Mostrami solo cio che e importante!”. Esaminare i dati al massimo livello di dettaglio e
non solo inutile per il processo decisionale, ma addirittura controproducente, perche non
consente di focalizzare l’attenzione sulle informazioni veramente significative.
“Tutti sanno che alcuni dati non sono corretti!”. Questo e un altro punto dolente. Una
percentuale non trascurabile dei dati transazionali e non corretta, o addirittura assente.
Evidentemente, basare il procedimento analitico su dati errati e incompleti non permette
di raggiungere risultati validi.
Da questo elenco di difficolta e problemi possiamo facilmente estrarre un elenco di parole
chiave che diventano fattori distintivi e requisiti indispensabili del processo di data ware-
housing, ossia del complesso di attivita che consentono di trasformare i dati operazionali
in conoscenza a supporto delle decisioni:
• Accessibilita a utenti con conoscenze limitate di informatica e strutture dati;
• Integrazione dei dati sulla base di un modello standard dell’impresa;
• Flessibilita di integrazione per trarre il massimo vantaggio dal patrimonio infor-
mativo esistente;
• Sintesi per permettere analisi mirate ed efficaci;
2.1 Data warehousing 17
• Rappresentazione multidimensionale per offrire all’utente una visione intuitiva
ed efficacemente manipolabile delle informazioni;
• Correttezza e completezza dei dati integrati.
Al centro del processo vi e il data warehouse, un contenitore di dati che diventa garante
dei requisiti esposti. Inmon ne diede una definizione nel 1996.
Data warehouse. Un Data Warehouse (DW) e una collezione di dati di supporto
per il processo decisionale che presenta le seguenti caratteristiche:
• E orientata ai soggetti di interesse;
• E integrata e consistente;
• E rappresentativa dell’evoluzione temporale e non volatile.
Il DW e orientato ai soggetti in quanto in quanto si incentra sui concetti di interesse
dell’azienda, quali clienti, i prodotti, le vendite, gli ordini. Viceversa, i database opera-
zionali sono organizzati intorno alle differenti applicazioni del dominio aziendale.
La condizione di integrita e consistenza e molto importante, in quanto il DW si appog-
gia a piu fonti di dati eterogenee: dati estratti dall’ambiente di produzione, e quindi
originariamente archiviati in basi di dati aziendali, o addirittura provenienti da sistemi
informativi esterni all’azienda. Di tutti questi dati il DW si impegna a restituire una
visione unificata. La costruzione di un sistema di data warehousing non comporta l’in-
serimento di nuove informazioni bensı la riorganizzazione di quelle esistenti, e implica
pertanto l’esistenza di un sistema informativo.
Infine nel data warehouse i dati non vengono mai rimossi ma solo aggiunti, questa carat-
teristica consente di avere a disposizione sia dati storici che recenti.
Un data warehouse puo essere consultato direttamente, ma anche essere usato come
sorgente per costruirne delle parziali repliche orientate verso specifiche aree dell’impresa.
Tali repliche vengono dette data mart.
18 Introduzione alla Business Intelligence
Data mart. Con il termine data mart si intende un sottoinsieme o un aggregazione
dei dati presenti nel DW primario, contenente l’insieme delle informazioni rilevanti
per una particolare area del business, una particolare divisione dell’azienda, una
particolare categoria di soggetti
2.1.1 Componenti di un data warehouse
Ora che abbiamo compreso gli obiettivi di un sistema di data warehousing, possiamo
osservare quali sono i componenti che ne fanno parte. Se ne possono individuare quattro
(Figura 2.1), ognuno dei quali ha le proprie funzionalita e il proprio ruolo all’interno del
sistema [KRT+07].
Figura 2.1: Componenti di un sistema di data warehousing
Sistemi Sorgente:
Sono costituiti dai sistemi gestionali e amministrativo-contabili di tipo tradizionale o ERP,
dai sistemi che interfacciano il mercato (sistemi di CRM), dai sistemi Web e da tutti gli
altri sistemi informativi di tipo operativo e/o transazionali [Pas04]. Devono essere visti
come parti esterne rispetto al sistema di data warehousing, poiche probabilmente si avra
poco o nessun controllo sul contenuto e la forma dei dati che essi contengono. Questi
sistemi solitamente mantengono pochi dati storici. Avere a disposizione un buon data
2.1 Data warehousing 19
warehouse solleva la gran parte della responsabilita di rappresentare il passato ai sistemi
sorgente.
Staging Area:
La staging area di un data warehouse e composta da due parti: un’area di memorizzazione
dei dati e un insieme di procedure comunemente dette extraction-transformation-loading
(ETL). Si colloca tra i sistemi sorgente e l’area di presentazione. Kimball paragona la
staging area alla cucina di un ristorante, nella quale gli ingredienti vengono trasformati
per un buon pasto. I dati operazionali vengono infatti trasformati e consegnati al data
warehouse in una forma appropriata per il loro consumo, ossia la loro elaborazione per
produrre informazioni utili all’azienda. Come per la cucina di un ristorante anche la
staging area sara accessibile solamente da professionisti qualificati e per tanto risultera
essere off-limits per gli utenti business. Inoltre non sara predisposta per servizi di in-
terrogazione e di presentazione, cosı come i clienti di un ristorante non sono invitati a
mangiare in cucina.
La presenza e l’utilizzo di questo componente dipende dall’architettura adottata per
realizzare il sistema di data warehousing, come verra esposto in seguito.
Area di presentazione:
L’area di presentazione e la parte dove i dati sono organizzati, conservati, e resi disponi-
bili per l’interrogazione diretta da parte di utenti, autori di report, e altre applicazioni
analitiche. Per la comunita imprenditoriale l’area di presentazione coincide con il data
warehouse, in quanto e tutto quello che possono vedere e toccare mediante gli apposi-
ti strumenti in loro possesso. E fortemente consigliabile che i dati vengano presentati,
memorizzati e siano accessibili in schema dimensionali (il modello multidimensionale e
descritto nel capitolo 4), in quanto risultano essere di piu facile uso per gli utenti di data
warehouse.
Strumenti di accesso ai dati:
E l’insieme degli strumenti di front-end che gli utenti business hanno a loro disposizione
per consultare l’area di presentazione. Possono essere semplici strumenti per eseguire
query ad hoc oppure strumenti che eseguono analisi piu complesse, come verra illustrato
20 Introduzione alla Business Intelligence
nel paragrafo 2.3.1. Tuttavia nell’80-90 per cento dei casi gli utenti utilizzano applicazioni
che forniscono automaticamente e ad intervalli di tempo prestabiliti informazioni strut-
turate in modo pressoche invariabile e che quindi non implicano la costruzione diretta
di query. In ogni caso questi strumenti dovranno possedere un motore di ottimizzazione
delle interrogazioni, a prescindere dal fatto che esse vengano o meno costruite dell’utente.
2.1.2 Architetture per il data warehousing
Come accennato nel paragrafo precedente la presenza e le modalita di utilizzo della staging
area definiscono l’architettura del sistema di data warehousing. La scelta dell’architettura
da utilizzare dipende delle esigenze e dal tipo dell’organizzazione entro la quale il progetto
dovra essere realizzato, tuttavia esistono caratteristiche irrinunciabili per un sistema di
data warehousing che possono essere cosı enunciate: [GR06]
• Separazione: l’elaborazione analitica e quella transazionale devono essere mantenute
il piu possibile separate;
• Scalabilita: l’architettura hardware e software deve poter essere facilmente ridimen-
sionata a fronte della crescita nel tempo dei volumi di dati da gestire ed elaborare
e del numero di utenti da soddisfare;
• Estendibilita: deve essere possibile accogliere nuove applicazioni e tecnologie senza
riprogettare integralmente il sistema;
• Sicurezza: il controllo sugli accessi e essenziale a causa della natura strategica dei
dati memorizzati;
• Amministrabilita: la complessita dell’attivita di amministrazione non deve risultare
eccessiva.
In seguito vengono presentati alcuni modelli architetturali.
Architettura a un livello
E un’architettura scarsamente utilizzata nella pratica. Ha come obiettivo quello di mi-
nimizzare la quantita di dati memorizzati eliminando le ridondanze. Come mostrato in
Figura 2.2 il data warehouse in questo caso e virtuale, poiche viene implementato come
una vista multidimensionale dei dati operazionali da un apposito middleware.
2.1 Data warehousing 21
Figura 2.2: Architettura ad un livello per un sistema di data warehousing
Una tale architettura presenta i seguenti punti deboli:
• Non rispetta il requisito di separazione dell’elaborazione analitica da quella transa-
zionale. Le interrogazioni di analisi vengono infatti ridirette sui dati operazionali
dopo essere state reinterpretate dal middleware, interferendo cosı con il normale
carico di lavoro transazionale;
• I requisiti di integrazione e correttezza dei dati possono essere soddisfatti, ma con
un’elevata complessita;
• E impossibile avere un livello di storicizzazione superiore a quello delle sorgenti.
Architettura a due livelli
Con questa architettura si riesce a soddisfare il requisito di separazione, come si evince
dalla Figura 2.3. Nonostante si articoli su quattro livelli distinti viene chiamata architet-
tura a due livelli per evidenziare la separazione tra le sorgenti e il data warehouse. I dati
che il data warehouse utilizzera sono contenuti in database aziendali relazionali o legacy,
oppure provenienti da sistemi informativi esterni all’azienda (livello delle sorgenti). Tali
dati saranno estratti, ripuliti per eliminare le inconsistenze e completare eventuali parti
22 Introduzione alla Business Intelligence
Figura 2.3: Architettura a due livelli per un sistema di data warehousing
mancanti, integrati per fondere sorgenti eterogenee secondo uno schema comune, me-
diante gli strumenti ETL accennati precedentemente ed approfonditi nel paragrafo 2.1.3
(livello di alimentazione). Le informazioni vengono raccolte nel data warehouse che potra
essere direttamente consultato o usato come sorgente per costruire data mart (livello del
warehouse). Accanto al DW, il contenitore dei metadati mantiene informazioni sulle sor-
genti, sui meccanismi di accesso, sulle procedure di pulitura e alimentazione, sugli utenti,
sugli schemi dei data mart ecc. Infine si potranno consultare in modo efficiente e flessi-
bile i dati integrati a fini di stesura di report, di analisi e di simulazione (livello di analisi).
Architettura a tre livelli
Al livello delle sorgenti e quello del data warehouse, viene aggiunto un terzo livello che
viene chiamato livello dei dati riconciliati. Questo livello materializza i dati operazionali
ottenuti a valle del processo di integrazione e ripulitura dei dati sorgente: quindi dati
integrati, consistenti, corretti, volatili, correnti e dettagliati. Il data warehouse non verra
quindi piu alimentato direttamente dalle sorgenti, ma dai dati riconciliati.
2.1 Data warehousing 23
Un vantaggio di questa architettura, mostrata in Figura 2.4, e che il livello dei dati ricon-
ciliati crea un modello di dati comune e di riferimento per l’intera azienda, introducendo
al contempo una separazione netta tra le problematiche legate all’estrazione e integrazio-
ne dei dati dalle sorgenti e quelle inerenti l’alimentazione del DW. Tuttavia presenta lo
svantaggio di introdurre un’ulteriore ridondanza rispetto ai dati operazionali sorgente.
Figura 2.4: Architettura a tre livelli per un sistema di data warehousing
24 Introduzione alla Business Intelligence
2.1.3 Gli strumenti ETL
Il ruolo degli strumenti di extraction-trasformation-loading e quello di alimentare una
sorgente dati singola, dettagliata, esauriente e di alta qualita che possa a sua volta ali-
mentare il data warehouse. Le procedure di popolamento del data warehouse possono
raggiungere elevati livelli di complessita, in relazione alle discrepanze esistenti tra le sor-
genti, al loro livello di correttezza e al livello di precisione rappresentativa nel tempo che
si desidera mantenere nel sistema informazionale. Sono caratterizzate da una sequenza di
fasi che dipende dalle politiche di aggiornamento che si e deciso di adottare, politiche che
prevedono azioni piu o meno articolate da parte delle procedure di popolamento. La com-
plessita di queste procedure e tale che sul mercato sono presenti diversi prodotti software
orientati specificamente al supporto delle fasi di estrazione, pulizia, trasformazione
e caricamento dei dati nel processo di alimentazione del data warehouse.
Occorre precisare che, nella letteratura, i confini tra pulitura e trasformazione sono spesso
sfumati dal punto di vista terminologico, per cui e spesso poco chiara l’attribuzione di
una specifica operazione all’uno o all’altro processo.
Estrazione
Le operazioni di estrazione sono eseguite all’atto dell’inizializzazione del livello riconciliato
per essere poi ripetute periodicamente, in base all’intervallo di aggiornamento stabilito
dal progettista, al fine di acquisire informazioni relative agli eventi verificatisi durante
la vita del sistema. I dati che andranno a popolare il data warehouse sono solo quelli
essenziali all’analisi e non tutti i dati ospitati sui sistemi di origine. Esistono due tipologie
di approcci all’estrazione:
• Estrazione statica: vengono trattati tutti i dati presenti nelle sorgenti operazionali.
E l’unica soluzione possibile all’atto dell’inizializzazione, ma puo essere impiegata
ogni qual volta la quantita ridotta dei dati lo permetta;
• Estrazione incrementale: con questo approccio vengono presi in considerazione i
soli dati prodotti o modificati dalle sorgenti nell’intervallo di tempo intercorso dal-
l’ultimo aggiornamento del data warehouse. Puo essere suddiviso ulteriormente
in immediato e ritardato. Nel primo caso ogni modifica ai dati viene registrata
immediatamente, mentre nel secondo caso posticipano tale operazione.
2.1 Data warehousing 25
L’estrazione incrementale generalmente si basa sui log mantenuti dal DBMS transaziona-
le. Inoltre l’estrazione puo anche essere guidata dalle sorgenti in quei casi in cui e possibile
ricevere, in modo asincrono, le notifiche delle modifiche dalle applicazioni operazionali.
Pulizia
Spesso i dati provenienti dalle sorgenti non sono di qualita adeguata agli standard richiesti
per il sistema informazionale. Devono quindi essere applicate analisi in grado di rilevare
e possibilmente correggere le situazioni che potrebbero essere critiche o condurre a errori.
Tra gli errori e le inconsistenze tipiche che rendono “sporchi” i dati segnaliamo: [GR06]
• Dati duplicati (per esempio, un cliente che compare piu volte nell’anagrafica);
• Inconsistenza tra valori logicamente associati (per esempio, tra i dati della persona
ed il suo codice fiscale);
• Dati mancanti (per esempio, la professione di un cliente);
• Uso non previsto di un campo (per esempio il campo destinato al codice fiscale
usato per memorizzare il numero di telefono d’ufficio);
• Valori impossibili o errati (per esempio, 30/02/2011);
• Valori inconsistenti per la stessa entita dovuti a differenti convenzioni (per esem-
pio, la nazione indicata mediante sigla piuttosto che con il nome completo) e
abbreviazioni (per esempio, ‘Piazza Garibaldi’ e ‘P.za Garibaldi’);
• Valori inconsistenti per la stessa entita dovuti a errori di battitura (per esempio,
‘Piazza Garibaldi’ e ‘Piazza Gribaldi’).
Per correggere errori di scrittura e riconoscere sinonimi vengono utilizzati degli appositi
dizionari, mentre per stabilire le corrette corrispondenze tra valori vengono applicate
regole proprie del dominio applicativo.
Trasformazione
Durante questa fase vengono eseguite le trasformazioni necessarie a conformare i dati delle
sorgenti alla struttura del data warehouse; in caso di architettura a tre livelli l’output di
questa fase e il livello dei dati riconciliati. La presenza di piu fonti eterogenee complica
26 Introduzione alla Business Intelligence
notevolmente questa fase, in quanto viene richiesta una complessa fase di integrazione.
Nella fase di trasformazione possono essere effettuate molte operazioni, tra cui:
• Conversione e normalizzazione: operano a livello di formato di memorizzazione e
di unita di misura per uniformare i dati;
• Matching : Stabilisce le corrispondenze tra campi equivalenti in sorgenti diverse;
• Selezione: riduce il numero di campi e di record rispetto alle sorgenti.
Negli strumenti ETL le attivita di pulitura e trasformazione sono spesso allacciate e
sovrapposte.
Caricamento
Al termine, si procede al caricamento vero e proprio dei dati sul data warehouse. Questa
procedura puo avvenire in due modalita.
Refresh. I dati vengono completamente riscritti all’interno del DW. Viene solitamente
utilizzata insieme all’estrazione statica durante la fase di inizializzazione.
Update. Vengono aggiunti al DW i soli cambiamenti verificatisi nelle sorgenti operaziona-
li. Questa tecnica viene solitamente utilizzata in abbinamento all’estrazione incrementale
al fine di ottenere un aggiornamento periodico del DW.
2.2 Il modello multidimensionale
La progettazione di data warehouse e data mart si basa su un paradigma di rappresenta-
zione multidimensionale dei dati, in grado di offrire un duplice vantaggio: sotto il profilo
funzionale, risulta efficace per garantire tempi di risposta rapidi a fronte di interrogazioni
complesse; sul piano logico, le dimensioni corrispondono in modo naturale ai criteri di
analisi utilizzati dai knowledge worker [Ver06].
Il modello multidimensionale si basa sul fatto che gli oggetti che influenzano il processo
decisionale sono fatti del mondo aziendale come ad esempio le vendite o le spedizioni. Le
occorrenze di un fatto vengono dette eventi : ogni singola vendita o spedizione effettuata
e un evento. Per ciascun fatto, interessano in particolare i valori di un insieme di misure
che descrivono quantitativamente gli eventi.
2.2 Il modello multidimensionale 27
La quantita degli eventi all’interno di una azienda e troppo elevata per poter analizzare
ogni singolo evento singolarmente. Per questo motivo per poterli agevolmente seleziona-
re e raggruppare (come vedremo nel capitolo 5) si immagina di collocarli in uno spazio
n-dimensionale, i cui assi vengono chiamati appunto dimensioni di analisi. Per esempio
nel caso in cui il fatto in questione siano le vendite, le dimensioni di analisi potrebbero
essere: i prodotti, i negozi e le date.
Il concetto di dimensione genera la metafora del cubo.
Cubo multidimensionale. Un cubo multidimensionale e incentrato su un fatto
di interesse per il processo decisionale. Esso rappresenta un insieme di eventi, de-
scritti quantitativamente da misure numeriche. Ogni asse del cubo rappresenta una
possibile dimensione di analisi.
Figura 2.5: Cubo multidimensionale che modella le vendite in una catena di negozi
Ovviamente se le dimensioni sono piu di tre, si tratta piu propriamente di un ipercu-
bo.
28 Introduzione alla Business Intelligence
Normalmente ciascuna dimensione e associata ad una gerarchia di livelli di aggregazione
che ne raggruppa i valori in diversi modi. I livelli che compaiono nella gerarchia vengono
detti attributi dimensionali
Figura 2.6: Una possibile gerarchia per la dimensione negozi
2.2.1 Modellazione concettuale: il Dimensional Fact Model
Un modello concettuale deve per definizione fornire una serie di strutture, dette costrutti,
atte a descrivere la realta di interesse in una maniera facile da comprendere e che pre-
scinde dai criteri di organizzazione dei dati nei calcolatori [ACPT06]. Il modello Entity/
Relationship e un modello concettuale molto diffuso nelle imprese per la progettazione e
documentazione di basi di dati relazionali.
Mentre e ormai universalmente riconosciuto che un data mart si appoggia su una vi-
sione multidimensionale dei dati, non c’e ancora accordo su come portare a termine la
progettazione concettuale a partire dai requisiti utente. Non esiste infatti un modello
concettuale adottato universalmente per la progettazione e documentazione di basi di
dati per il data warehousing. Il modello Entity/Relationship non risulta essere adatto a
tale scopo in quanto non e in grado di mettere correttamente in luce gli aspetti peculiari
2.2 Il modello multidimensionale 29
del modello multidimensionale, senza contare che risulterebbe poco economico dal punto
di vista grafico-notazionale.
Il Dimensional Fact Model (DFM), proposto da Golfarelli nel 1998, e un modello concet-
tuale specificamente concepito per fungere da supporto alla progettazione di data mart;
e essenzialmente di tipo grafico, e puo essere considerato come una specializzazione del
modello multidimensionale per applicazioni di data warehousing. La rappresentazione
concettuale generata dal DFM consiste in un insieme di schemi di fatto. Gli elementi di
base modellati dagli schemi di fatto sono i fatti, le misure, le dimensioni, le gerarchie e
gli attributi dimensionali. In questa sede non saranno trattati gli aspetti di modellazione
avanzata.
Nelle Figure 2.7 e 2.8 sono riportati lo schema di fatto e lo schema Entity/Relationship
relativi alle vendite.
Figura 2.7: Semplice schema di fatto delle vendite
Figura 2.8: Schema Entity/Relationship corrispondente allo schema di fatto di Figura 2.7
30 Introduzione alla Business Intelligence
Come si puo evincere dalla figura, un fatto e raffigurato da un rettangolo che ne riporta il
nome insieme ai nomi delle eventuali misure; le dimensioni sono rappresentati da piccoli
cerchi collegati al fatto tramite linee. E importante evidenziare come un fatto esprime
un’associazione molti-a-molti tra le dimensioni. Per tale motivo lo schema Entity/Re-
lationship corrispondente ad uno schema di fatto consiste in un’associazione n-aria tra
entita che modellano le dimensioni.
Le gerarchie vengono rappresentate da alberi direzionati i cui nodi sono attributi dimen-
sionali e i cui archi modellano associazioni molti-a-uno tra coppie di attribuiti dimensio-
nali. La Figura 2.9 ne fornisce una rappresentazione.
Figura 2.9: Schema di fatto delle vendite arricchito
Se si volesse tradurre questo schema di fatto nel corrispondente schema E/R si avrebbe
un’esplosione in termini grafico-notazionali, come gia si era accennato in precedenza.
Tutti gli attributi dimensionali all’interno di uno schema di fatto devono avere nomi
diversi tra loro. Nomi uguali possono essere differenziati qualificandoli con il nome di
un attributo dimensionale che li precede nella gerarchia (per esempio, citta negozio e
citta marca).
2.2 Il modello multidimensionale 31
2.2.2 Modellazione logica
Mentre per la fase di modellazione concettuale non ci si deve preoccupare delle scelte che
si dovranno fare durante la fase di modellazione logica, per quest’ultima non si puo dire
la stessa cosa. Sara infatti in questa fase che si dovra scegliere il DBMS da utilizzare
durante la progettazione fisica. I dati soggetti ad analisi possono essere rappresentati
secondo due modelli logici: quello relazionale, che da luogo ai cosiddetti sistemi ROLAP
(Relational OLAP), e quello multidimensionale, per il quale i sistemi utilizzati vengono
detti MOLAP (Multidimensional OLAP).
Esiste anche una terza soluzione, intermedia alle due appena menzionate ed e il cosiddetto
HOLAP (Hybrid OLAP).
2.2.2.1 I sistemi ROLAP
Adottare una soluzione di questo genere implica il dover modellare i concetti multidi-
mensionali osservati fin ora in elementi bidimensionali, ovvero le tabelle del modello
relazionale. Una tale operazione viene effettuata mediante il cosiddetto star schema
(Figura 2.10).
Figura 2.10: Star schema per le vendite
32 Introduzione alla Business Intelligence
Uno schema a stella e composto da:
• Un insieme di tabelle, chiamate tabelle delle dimensioni (dimension table). Cia-
scuna di queste tabelle e caratterizzata da una chiave primaria e da un insieme di
attributi che descrivono le dimensioni di analisi a diversi livelli di aggregazione;
• Una tabella chiamata tabella dei fatti (fact table) in cui sono presenti le chiavi di
tutte le tabelle delle dimensioni. La chiave primaria di questa tabella sara data
dall’insieme delle chiavi esterne delle dimension table. La tabella dei fatti contiene
inoltre un attributo per ogni misura.
La visione multidimensionale si ottiene eseguendo il join tra la fact table e le dimension
table.
La seguente query SQL fornisce la quantita e l’incasso totale delle vendite di surgelati
relative all’anno 2010 per la regione Emilia Romagna, raggruppata per responsabili.
1 SELECT DT2. r e sponsab i l e , SUM(FT. quant i ta ) , SUM(FT. i n ca s s o )
2 FROM Vendite FT, Prodotto DT1, Negozio DT2, Data DT3
3 WHERE FT. prodotto = DT1. prodotto ID AND
4 FT. negoz io = DT2. negoz io ID AND
5 FT. data = DT3. data ID AND
6 DT1. c a t e go r i a = ’ s u r g e l a t i ’ AND
7 DT2. r eg i one = ’ Emil ia Romagna ’ AND
8 DT3. anno = 2010
9 GROUP BY DT2. r e s pon s ab i l e
Si noti come le dimension table violino la terza forma normale, ovvero contengono at-
tributi che dipendono transitivamente da una chiave. Una tale situazione introduce una
ridondanza e per tanto richiede piu spazio per la memorizzazione dei dati, ma allo stesso
tempo richiede un minor numero di join per reperire le informazioni. Si potrebbe pero
essere interessati ad avere uno schema logico piu vicino agli enunciati della teoria relazio-
nale; lo snowflake schema (Figura 2.11) lo permette in quanto caratterizzato da una
parziale normalizzazione delle dimension table.
2.2 Il modello multidimensionale 33
Uno schema snowflake e ottenibile da uno schema a stella scomponendo una o piu dimen-
sion table in piu tabelle, in modo tale da eliminare alcune delle dipendenze funzionali
transitive in esse presenti. Le tabelle delle dimensioni le cui chiavi sono importate nella
fact table vengono dette primarie, mentre chiameremo secondarie le rimanenti.
In questo modo e possibile trovare il giusto compromesso tra spazio in memoria utilizzato
e numero di join da effettuare per ricavare l’informazione desiderata. Si noti come a ogni
passo di normalizzazione corrisponda un arco nello schema di fatto e una sotto-gerarchia
che invece verra memorizzata in una tabella a parte.
Affinche lo snowflaking sia efficace, tutti gli attributi del sottoalbero dell’attributo da cui
ha origine la normalizzazione devono essere spostati nella nuova relazione.
La scelta di mappare elementi del mondo multidimensionale nel modello relazionale po-
trebbe apparire una forzatura. Tuttavia una tale scelta e giustificata da un insieme di
motivazioni di varia natura, prima fra tutte la constatazione che il modello relazionale
e di fatto lo standard nel settore dei database. Inoltre, l’evoluzione subita dai DBMS
relazionali nell’arco degli anni della loro presenza sul mercato ne fa degli strumenti estre-
mamente raffinati ed ottimizzati.
Figura 2.11: Snowflake schema ottenuto mediante una parziale normalizzazione dello star
schema di Figura 2.10
34 Introduzione alla Business Intelligence
2.2.2.2 I sistemi MOLAP
Nell’approccio MOLAP il data warehouse memorizza i dati usando strutture intrinseca-
mente multidimensionali: i dati vengono fisicamente memorizzati in vettori e l’accesso e
di tipo posizionale. Il sistema alloca una cella per ogni possibile combinazione dei valori
delle dimensioni e l’accesso ad un fatto avviene in modo diretto, sulla base delle coordi-
nate fornite.
L’utilizzo di una tale soluzione rappresenta la soluzione naturale per un sistema di data
warehousing e puo fornire prestazioni ottimali, in quanto le operazioni di query multidi-
mensionale non devono essere simulate mediante complesse istruzioni SQL. Il principale
problema a cui pero e soggetta la soluzione MOLAP, e la sparsita dei dati, rappresentata
in Figura 2.12.
Figura 2.12: Rappresentazione del fenomeno di sparsita dei dati: in bianco le celle relative
ad eventi effettivamente accaduti
Mediamente in un cubo multidimensionale meno del 20% delle celle contiene effettivamen-
te delle informazioni, mentre le restanti celle risultano essere vuote poiche corrispondono
ad eventi non accaduti. La memorizzazione di celle non informative provoca uno spreco
dello spazio su disco.
Il fenomeno della sparsita dei dati viene affrontato partizionando il cubo n-dimensionale
in questione, in piu sottocubi n-dimensionali che vengono detti chunk. Si parla di chunk
densi, se la maggior parte delle celle contengono dati, chunk sparsi altrimenti [GR06].
Un tale approccio permette di operare su blocchi di dati di dimensione inferiore e che
quindi potranno essere caricati agevolmente in memoria.
2.2 Il modello multidimensionale 35
Figura 2.13: Suddivisione del cubo multidimensionale in chunk: in bianco i chunk densi
Si osserva pero che la memorizzazione diretta di chunk sparsi comporta un notevole spreco
di spazio dovuto alla rappresentazione delle celle che non contengono informazioni. Per
questo motivo i chunk sparsi vengono utilizzati mediante un indice che riporta l’offset
delle sole celle che contengono informazioni.
Oltre al problema relativo allo spreco di memoria, un altro fattore debilitante per la
diffusione dei sistemi MOLAP e costituito dalla mancanza di standard. I diversi strumenti
disponibili sul mercato sono accomunati dai soli principi di base (come puo essere la
gestione della sparsita), mentre non si e a conoscenza dei dettagli implementativi. Non
esiste infatti uno standard di interrogazione che svolga il ruolo che l’SQL svolge nei sistemi
relazionali.
2.2.2.3 Slowly Changing Dimensions (SCD)
Per quanto e stato detto fino ad ora si potrebbe pensare che l’unica componente dinamica
del modello multidimensionale siano i fatti e i relativi eventi che lo instanziano, portandoci
a pensare che le dimensioni, e di conseguenza le gerarchie, siano caratterizzate da una
natura statica. Cio non sempre e vero. Puo infatti capitare che la categoria di un prodotto
venga cambiata, oppure che un negozio venga spostato da un distretto all’altro, o ancora
che un cliente cambi agente. Kimball (1996) chiama questo fenomeno slowly changing
dimensions. Un tale fenomeno richiede modifiche, seppur minime, alle dimensioni ed e
da considerarsi come un evento straordinario legato alla manutenzione del data mart.
Per far fronte allo slowly changing dimensions, durante la fase di modellazione logica sara
possibile scegliere fra tre tipi di tecniche (piu una ibrida): [KRT+07]
36 Introduzione alla Business Intelligence
• Tipo 1 : Sovrascrittura (Overwrite). E una tecnica che prevede la semplice so-
vrascrittura di uno o piu attributi nelle dimensioni esistenti. Il vecchio valore andra
perso, per tanto e bene utilizzare questa metodologia quando non si ha interesse nel
memorizzare lo storico per l’attributo dimensionale in questione. Si supponga di
porsi nello scenario in cui una tale modifica debba essere effettuata su uno schema
a stella (ovvero uno scenario nel quale e stata adottata una soluzione ROLAP). Nel
momento in cui interverra una modifica a un valore di una tupla della dimension
table sara sufficiente sovrascrivere il vecchio valore con il nuovo. Come conseguenza
tutti i dati della fact table vengono associati al nuovo valore della dimension table.
• Tipo 2 : Creazione di una nuova riga (Create new row). E la tecnica stan-
dard per registrare la verita storica, ovvero consente di modificare le dimensioni in
modo che esse vengano poi associate correttamente ai fatti. Nell’esempio di uno
star schema gli eventi della fact table dovranno essere associati ai dati dimensionali
che erano validi quando si e verificato l’evento. Per realizzare questa tecnica ba-
stera aggiungere una nuova riga nella dimension table appropriata, senza andare ad
eliminare quella vecchia. Al vecchio record non sara piu possibile associare nessun
nuovo evento. Per il soddisfacimento di un tale vincolo e possibile aggiungere una
colonna contenente un flag che indichi la versione corrente, oppure assegnare ad
ogni versione una data di inizio ed una data di fine, la versione in cui la data di fine
non e stata settata sara quella corrente.
• Tipo 3 : Aggiunta di una nuova colonna (Add a new column). Questa
tecnica supporta variazioni degli attributi che avvengono in modo poco frequente.
Essa infatti dimostra una minor flessibilita ai cambiamenti rispetto la tecnica di
tipo 2. Mentre per quest’ultima ogni cambiamento richiedeva l’aggiunta di una
nuova riga, per la tecnica di tipo 3 e richiesta la valorizzazione di apposite colonne.
Il numero delle colonne a disposizione e stabilito in fase di progettazione e per tanto
il livello di storicizzazione risulta essere limitato. Tuttavia rende possibile riferirsi
ad un attributo che conterra sia il nuovo che il vecchio valore.
• Tecnica ibrida. Si basa sulla combinazione delle tecniche viste fino ad ora e
viene talvolta indicata come tecnica di tipo 6 (1+2+3 = 6). Per esempio, puo
essere impiegata per avere la gestione dello storico offerto dalle soluzioni di tipo
2, ma con la possibilita di raggiungere agevolmente il valore corrente dell’attributo
2.3 La Business Intelligence (BI) 37
partendo dai vecchi valori. Quest’ultima caratteristica puo essere ottenuta mediante
la tecnica di tipo 3 memorizzando per ogni vecchio valore anche il valore corrente
in un’apposita colonna.
Prima di affrontare la scelta della tecnica con la quale si desidera fronteggiare lo slowly
changing dimensions occorre precisare che l’adozione di gerarchie dinamiche implica un
sovraccosto in termini di spazio e puo comportare una forte riduzione delle prestazioni.
E quindi indispensabile valutare con attenzione i casi in cui impiegarle.
2.3 La Business Intelligence (BI)
L’aumento esponenziale del volume dei dati operazionali ha reso il calcolatore l’unico sup-
porto adatto al processo decisionale, inoltre l’utilizzo massiccio di tecniche di analisi dei
dati aziendali ha reso il sistema informativo un elemento strategico per la realizzazione
del business. Per questi motivi il ruolo dell’informatica e passato da passivo strumento
per la registrazione delle operazioni, a fattore decisivo per l’individuazione di elementi
critici dell’organizzazione e di potenziali aree di business.
Il termine Business Intelligence venne introdotto nel 1989 da Howard Dresner, per indi-
care un insieme di strumenti e procedure che consentono a un’azienda di trasformare i
propri dati di business in informazioni utili al processo decisionale, da rendere disponibili
alla persona giusta e nel formato idoneo. Le informazioni ottenute sono utilizzate dai
decisori aziendali (decision maker) per definire e supportare le strategie di business.
L’insieme delle applicazioni IT in un’azienda viene detto portafoglio applicativo (Fi-
gura 2.14) e puo essere diviso in tre segmenti principali:
• Portafoglio direzionale: e l’insieme delle applicazioni utilizzate dai manager
aziendali per analizzare lo stato dell’azienda e prendere le decisioni migliori nel
minor tempo possibile;
• Portafoglio operativo: comprende le applicazioni informatiche per i processi
primari dell’azienda;
• Portafoglio istituzionale: comprende le applicazioni informatiche per i processi
di supporto, quali amministrazione, gestione delle risorse umane, contabilita.
38 Introduzione alla Business Intelligence
Figura 2.14: Rappresentazione del portafoglio applicativo aziendale
Il portafoglio direzionale viene anche detto piattaforma per la Business Intelligence. Essa,
al fine di garantire ai manager analisi potenti e flessibili, deve possedere un’apposita
infrastruttura hardware e software di supporto composta da:
• Hardware dedicato;
• Infrastrutture di rete;
• DBMS;
• Software di back-end;
• Software di front-end.
Il ruolo chiave di una piattaforma di business intelligence e la trasformazione dei da-
ti aziendali in informazioni fruibili a diversi livelli di dettaglio e, quindi, in conoscenza.
La Figura 2.15 rappresenta quella che viene chiamata piramide della Business Intelligence.
Decisioni efficaci e tempestive:
L’abilita individuale e collettiva dei decision maker, che possiamo indicare con il termine
di knowledge worker, rappresenta uno dei principali fattori che influenzano le prestazioni
e la competitivita di un’organizzazione.
2.3 La Business Intelligence (BI) 39
Figura 2.15: Piramide della Business Intelligence: dai dati alla conoscenza
La maggior parte dei knowledge worker elabora le proprie decisioni utilizzando in modo
prevalente metodologie semplici e intuitive, che tengono conto di elementi quali esperienze
passate, conoscenza del contesto, informazioni disponibili. Questa attitudine determina
uno stile decisionale di indole statica, che trova difficolta ad adattarsi a condizioni mu-
tevoli determinate dai cambiamenti dell’ambiente economico. Nelle situazioni reali, i
processi decisionali risultano troppo complessi e dinamici per essere affrontati con effica-
cia mediante analisi intuitive, e richiedono invece un ordinamento piu rigoroso, basato su
metodologie analitiche e modelli matematici.
Un ambiente di business intelligence si propone di offrire ai knowledge worker strumenti
e metodologie che permettono di individuare decisioni efficaci e tempestive.
Decisioni efficaci. Se il decision maker dispone di informazioni e conoscenze piu attendi-
bili, ricavate sulla base di rigorose analisi quantitative, e in grado di formulare decisioni e
piani d’azione che consentono di realizzare con maggiore efficacia gli obiettivi prefissati.
In effetti, il ricorso a strumenti formali di indagine induce i decision maker a descrivere in
modo esplicito i criteri di valutazione delle scelte alternative e i meccanismi che regolano il
fenomeno analizzato. L’attivita di studio e di riflessione che ne scaturisce determina una
maggiore consapevolezza e una comprensione piu approfondita della logica che governa
il processo decisionale.
40 Introduzione alla Business Intelligence
Decisioni tempestive. Le imprese operano in contesti economici caratterizzati da un ele-
vato livello competitivo e da forte dinamicita. Di conseguenza, la capacita di reagire
in modo tempestivo alle azioni dei competitori e alle nuove condizioni di mercato rap-
presenta un fattore decisivo per determinare il successo di un’impresa o addirittura per
consentire la sua sopravvivenza.
Se il decision maker dispone di un ambiente di business intelligence in grado di faci-
litare il suo compito, ci possiamo attendere che la qualita del processo decisionale ne
tragga un complessivo beneficio [Ver06].
2.3.1 Accedere al data warehouse
Fino ad oggi lo strumento principe per la Business Intelligence e stato sicuramente il Data
Warehouse, le cui installazioni si stanno rapidamente consolidando, oltre che nelle grandi
aziende anche in quelle di media dimensione. In particolare possiamo elencare alcuni dei
meriti che sono riconosciuti al DW: [GR06]
• Consente di gestire serie storiche dei dati;
• Permette di effettuare analisi multidimensionali;
• Si basa su un modello semplice che puo essere facilmente assimilato dai manager;
• E alla base dei sistemi per il calcolo degli indicatori.
Nel capitolo 3 abbiamo accennato a strumenti di accesso ai dati come una componente
dei sistemi di data warehousing. Li avevamo definiti come degli strumenti di front-end che
gli utenti business hanno a loro disposizione per consultare l’area di presentazione, ovvero
il data warehouse. Di seguito presenteremo i due principali approcci all’interrogazione di
un DW da parte degli utenti finali: la reportistica e l’analisi multidimensionale.
Reportistica
E un approccio che permette agli utenti di accedere in modo tempestivo ai dati contenuti
nei DW e nei data mart. Solitamente l’accesso avviene a intervalli di tempo predefiniti
e le informazioni che si ricavano sono strutturate in modo invariabile. Proprio per que-
st’ultimo aspetto solitamente l’interrogazione viene definita a priori secondo quelle che
2.3 La Business Intelligence (BI) 41
sono le necessita dell’utente e successivamente integrata in un’applicazione. In questo
modo l’utilizzatore di tale applicazione potra eseguire l’interrogazione quando piu ne ha
bisogno sui dati correnti.
Un rapporto (o report) e scomponibile in due parti: interrogazione e presentazione. L’in-
terrogazione e la parte che andra a reperire i dati di interesse dal DW o data mart, mentre
la presentazione provvede a presentare i dati ottenuti in forma grafica o tabellare. La
validita di uno strumento di reportistica non e data solo dalla ricchezza nella presenta-
zione dei rapporti, ma anche dalla flessibilita dei meccanismi per la loro distribuzione.
Un rapporto infatti puo essere sia generato manualmente dall’utente che automaticamen-
te per una distribuzione periodica agli utenti interessati, per esempio mediante posta
elettronica.
Analisi multidimensionale
L’analisi multidimensionale e la piu nota modalita di reperimento di informazioni con-
tenute in un data warehouse. Si differenzia dalla reportistica statica proprio grazie alla
sua dinamicita, permette infatti di soddisfare quegli utenti le cui necessita di analisi non
sono ben note a priori. Mentre con gli strumenti di reportistica l’utente era limitato ad
un ruolo passivo, con gli strumenti di analisi multidimensionale l’utente svolge un ruolo
attivo durante tutta la sessione di analisi.
Facendo riferimento al concetto di cubo multidimensionale, trattato nel capitolo 4, de-
finiamo ora le operazioni che vengono utilizzate durante l’analisi multidimensionale, le
cosiddette operazioni OLAP. Come prima cosa osserviamo quegli operatori che permet-
tono di modellare la dimensione del cubo e quindi la quantita di dati che esso contiene.
E possibile individuare due categorie distinte.
Restrizione. La grandezza del cubo viene ridotta mediante l’imposizione di vincoli
sugli attributi dimensionali. Esistono sostanzialmente due operatori all’interno di questa
categoria:
• Slice: il cubo viene “tagliato a fettine”. La sua dimensionalita infatti viene ridotta
fissando un valore per una o piu delle dimensioni originarie. Per esempio, per le
vendite potrebbe essere richiesto di osservare le sole vendite dell’anno 2010, in questo
modo viene eliminata la dimensione tempo. Oppure si potrebbe voler osservare le
42 Introduzione alla Business Intelligence
sole vendite del negozio x relativamente al prodotto y, in tal caso ad essere eliminate
saranno la dimensione negozio e prodotto;
• Dice: il cubo viene “tagliato a cubetti”. Viene ridotto l’insieme dei dati attraverso
la formulazione di un criterio di selezione complesso. Tipicamente la dimensionalita
rimane invariata. Per esempio, per le vendite se si vuole visualizzare le sole vendite
tra il 2004 ed il 2010 per i soli prodotti che presentano un costo superiore ai 100 euro.
Si osserva che con l’imposizioni di tali vincoli la dimensionalita rimane invariata.
Figura 2.16: Operatori di slice-and-dice
Nella letteratura queste due operazioni vengono racchiuse nel termine slice-and-dice (let-
teralmente, tagliare a fettine e cubetti).
Aggregazione. L’aggregazione e un meccanismo di fondamentale importanza nelle basi
di dati multidimensionali. Si supponga di voler analizzare le vendite nel loro dettaglio
mensile, anziche a livello giornaliero; cio significa dover raggruppare, per ciascun prodot-
to e negozio tutte le celle relative ai giorni di uno stesso mese in un’unica macro-cella.
L’aggregazione puo essere operata contemporaneamente su piu dimensioni, ovvero si po-
trebbe decidere di aggregare le vendite per mese, tipo di prodotto e citta del negozio.
Anche in questo caso si possono individuare due operatori:
• Roll-up: talvolta indicato col termine drill-up, significa letteralmente arrotolare o
alzare. Con questa operazione si induce un aumento nell’aggregazione dei dati
eliminando un livello di dettaglio da una gerarchia. Puo essere utilizzata anche per
ridurre la dimensionalita del risultato, qualora tutti i dettagli di una certa gerarchia
vengano eliminati. Ad esempio, la rimozione della dimensione tempo conduce a
2.3 La Business Intelligence (BI) 43
consolidare le misure tramite la somma su tutti i periodi temporali presenti nel
cubo di dati;
• Drill-down: talvolta indicato con il termine roll-down, significa letteralmente trivel-
lare. E il duale dell’operatore roll-up, infatti esso diminuisce l’aggregazione dei dati
introducendo un ulteriore livello di dettaglio in una gerarchia. Per esempio, puo
essere utilizzato per passare dall’aggregazione per regione del cliente a quella, piu
fine, per citta del cliente. Come il roll-up permette di ridurre la dimensionalita, il
drill-down, essendo il suo duale, permette di aumentarla. Potremo infatti visualiz-
zare gli incassi annuali di ogni categoria di prodotto, aggiungendo le informazioni
sull’area geografica dei clienti.
Figura 2.17: Effetti degli operatori di roll-up e drill-down sul cubo multidimensionale
Aggregazione e restrizione possono essere combinate per permettere un processo di analisi
mirato con precisione alle esigenze dell’utente.
Come osservato in precedenza, le operazioni descritte sin ora permettono di alterare la
quantita di dati da analizzare secondo quelle che sono le specifiche dell’analisi. Esistono
tuttavia altre operazioni che possono essere usate per manipolare il cubo, e sono:
• Pivoting: talvolta chiamata rotazione, permette di ruotare gli assi scambiando tra
loro alcune dimensioni per ottenere una diversa vista sul cubo di dati;
• Drill-across: permette di stabilire un collegamento tra due o piu cubi correlati al
fine di compararne i dati;
• Drill-through: e disponibile solo in alcuni strumenti OLAP e consiste nel passaggio
dai dati aggregati multidimensionali del data warehouse ai dati operazionali presenti
nelle sorgenti o nel livello riconciliato.
44 Introduzione alla Business Intelligence
2.3.2 Business Intelligence: oltre il data warehouse
Nel precedente paragrafo abbiamo evidenziato le caratteristiche che hanno permesso il
successo del data warehouse come strumento per la business intelligence. Tuttavia la
sua ampia diffusione ha comportato una rapida maturazione degli utenti che, comprese
appieno le sue potenzialita, cominciano a percepirne i limiti. Alcuni di queste limitazioni
sono:
• I dati vengono aggiornati con una periodicita che difficilmente e inferiore alla
settimana/giorno.
• Quando vengono eseguite complesse interrogazioni, al di fuori del modello multidi-
mensionale, il DW risulta essere poco efficiente;
• Registra solo il passato e non offre scenari per la formulazione di previsioni.
L’utente necessita di tecniche di analisi piu potenti e non basate sul modello multidimen-
sionale, analisi che gli permettano di operare su dati provenienti da fonti eterogenee e
con aggiornamenti piu rapidi. Inoltre sorge la necessita di poter “predire il futuro”.
A tali scopi si propongono varie soluzioni: il data mining, un processo di esplorazione e
analisi di un insieme di dati, generalmente di grandi dimensioni, per individuare eventua-
li regolarita, estrarre conoscenza e ricavare regole ricorrenti significative; l’analisi what-if
che permette di formulare scenari di previsione basati su modelli di business e trend
aziendale; il business-performance-management (BPM), inteso come un framework per
il controllo della performance aziendale che permette di condividere la strategia scelta a
tutti i livelli dell’azienda. Il data mining e l’analisi what-if sono tecniche ben note nella
letteratura, ma che tuttavia, a causa della loro complessita, sono state quasi sempre igno-
rate in ambito aziendale, in favore del data warehousing, la cui complessita risulta essere
decisamente inferiore. Il BPM invece rappresenta una soluzione innovativa soprattutto
dal punto di vista tecnologico.
Al giorno d’oggi il panorama aziendale e da considerarsi pronto per utilizzare tecniche
all’avanguardia come quelle appena descritte.
2.3 La Business Intelligence (BI) 45
2.3.2.1 Data Mining
Le attivita di data mining costituiscono un processo di analisi di natura iterativa svolto su
voluminose basi di dati, con l’obiettivo di estrarre informazioni e conoscenze che risultino
accurate e potenzialmente utili ai knowledge worker nel corso dei processi decisionali.
Prendiamo in considerazione l’analisi multidimensionale e osserviamo come essa non per-
metta all’utente di individuare modelli significativi come sequenze ripetute, correlazioni
e associazioni tra i dati o raggruppamenti interessanti all’interno della grande mole di
dati che si vuole esaminare. I modelli appena citati sono solo alcuni esempi di quelli che
vengono chiamati pattern, ovvero una rappresentazione sintetica e ricca di semantica di
un insieme di dati (Rizzi, 2003). Il data mining raccoglie tutta una serie di metodologie
dell’intelligenza artificiale e del pattern recognition come per esempio algoritmi genetici,
logica fuzzy e reti neurali, con l’obiettivo di aiutare l’utente nel processo di estrazione
della conoscenza (knowledge discovery). Il processo di knowledge discovery, rappresentato
in Figura 2.18, e di tipo iterativo e prevede quattro fasi distinte: [GR06]
• Selezione: vengono selezionati i dati da sottoporre al processo. Essi possono
provenire da data base operazionale, dal data warehouse oppure da data stream
alimentati per esempio dalle macchine di produzione;
• Preparazione: i dati vengono ripuliti e trasformati nel formato richiesto dagli algo-
ritmi del passo successivo;
• Data mining : viene scelto ed eseguito l’algoritmo opportuno per generare i pattern;
• Valutazione: I pattern individuati vengono visualizzati ed esaminati. Se i risultati
non sono soddisfacenti si innesca una retroazione verso le fasi precedenti.
Vediamo ora alcune delle principali funzionalita di data mining ed i relativi pattern che
esse si prestano ad individuare.
Caratterizzazione. E un processo che si focalizza su un attributo target e opera su
di esso con svariate finalita. Puo infatti operare una caratterizzazione di tale attributo
osservando il valore che esso assume per tutti i record che appartengono ad una deter-
minata classe, oppure evidenziare la distribuzione dei valori che l’attributo assume per
i record appartenenti ad una medesima classe confrontandoli, per esempio, con quelli
46 Introduzione alla Business Intelligence
Figura 2.18: Il processo di knowledge discovery
di una classe diversa. E una tecnica molto semplice da realizzare e i risultati vengono
visualizzati all’utente in forma grafica.
Serie storiche. Talvolta l’attributo target e soggetto ad un’evoluzione temporale che
consiste in una sequenza dei valori che tale attributo assume. Le serie storiche sono una
funzionalita di data mining che studiano fenomeni caratterizzati da una dinamica tempo-
rale e si propongono di predire il valore della variabile target per uno o piu periodi futuri.
2.3 La Business Intelligence (BI) 47
Regole associative. Consentono di determinare le regole di implicazione logica presenti
nella base di dati, ovvero regole della forma:
X ⇒ Y
Se per esempio X e Y sono insiemi di prodotti , avremo che le transazioni che contengono
prodotti in X tendono a contenere anche quelli in Y. Ad ogni regola riscontrata vengono
attribuite due misure: il supporto e la confidenza. Con il supporto si indica la percen-
tuale delle transazioni che contengono sia X che Y, mentre la confidenza indica in che
percentuale le transazioni che contengono X contengono anche Y.
Le aziende della grande distribuzione ricorrono a regole di associazione per pianificare la
disposizione dei prodotti sugli scaffali o nei cataloghi
Clustering. Il termine cluster viene utilizzato per riferirsi ad un sottogruppo omogeneo
presente all’interno di una popolazione. Le tecniche di clustering svolgono operazioni
di segmentazione di una popolazione eterogenea. Solitamente e una tecnica che viene
utilizzata durante la fase preliminare di data mining, in quanto consente di individuare
categorie di dati tra loro omogenei, consentendo cosı alle successive attivita di mining di
focalizzarsi sul cluster in interesse.
Alberi decisionali. Vengono utilizzate per comprendere un determinato fenomeno,
permettono infatti di classificare, in ordine di importanza, le cause che portano al verifi-
carsi di un evento. In prossimita di ciascun nodo dell’albero viene effettuata una scelta,
solitamente attraverso il confronto di un attributo con una costante; gli archi che esco-
no dal nodo rappresentano l’esito del confronto. Le decisioni finali sono contenute nelle
foglie.
48 Introduzione alla Business Intelligence
2.3.2.2 Analisi what-if
Assumendo un particolare insieme di condizioni iniziali l’analisi what-if consente di for-
mulare alcuni scenari di previsione al fine di valutare il comportamento di un sistema
reale. E evidente come questo tipo di approccio superi quelli che sono i limiti delle ana-
lisi che si basano sulla semplice consultazione del data warehouse (ovvero reportistica ed
analisi multidimensionale, osservate nel paragrafo precedente).
Come prima cosa l’analista dovra riprodurre un modello che sia in grado di simulare il
sistema in esame, ovviamente maggiore sara l’accuratezza con il quale viene disegnato,
piu attendibili saranno i risultati che da esso si ricaveranno. In genere il modello viene
costruito mediante un processo iterativo, dove ad ogni passo viene verificato il suo com-
portamento confrontando i risultati in output con un insieme di dati di test. Le tecniche
di analisi what-if possono essere classificate in base al metodo utilizzato per la creazione
del modello. Esistono sostanzialmente due tipologie:
• Tecniche induttive: Sono le soluzioni piu semplici da realizzare in quanto vengono
osservati solo gli effetti del comportamento di un sistema, mentre le cause sono
completamente ignorate. La costruzione del modello fa riferimento al principio
descritto sinteticamente dalla seguente frase: “se fino ad ora e andata cosı, andra
cosı anche dopo!”. Le tecniche induttive si basano infatti sul comportamento che il
sistema ha avuto durante un certo intervallo temporale. Per questo motivo vengono
talvolta dette estensionali;
• Tecniche deduttive: I problemi osservati nell’approccio induttivo vengono superati
grazie ad una approfondita conoscenza delle regole che governano il sistema. Il
modello che verra generato sara caratterizzato da un insieme di rapporti del tipo
causa-effetto. I limiti di queste tecniche emergono nel caso in cui i rapporti prima
citati formino dei cicli di retroazione.
Solitamente, indipendentemente dalla tecnica scelta, la modellazione viene effettuata sui
dati del data warehouse, poiche esso rappresenta il principale serbatoio che memorizza le
serie storiche degli eventi verificatisi in azienda.
2.3 La Business Intelligence (BI) 49
2.3.2.3 Business Performance Management (BPM)
Fusione e acquisizioni, cambiamenti nei modelli di business, nuovi requisiti industriali e
mutamenti nelle aspettative dei clienti pongono un grande numero di problemi a livello
di processi che le aziende devono continuamente affrontare. La gestione dei processi bu-
siness consente alle aziende di gestire i cambiamenti incrementali dei processi che sono
richiesti simultaneamente in molte aree dell’azienda.
Business Performance Management (BPM). Insieme di attivita atte a mi-
surare le proprie prestazioni incoraggiando l’efficacia dei processi aziendali e l’uso
efficiente delle risorse umane, materiali ed economiche.
La misurazione delle prestazioni dei processi aziendali puo essere realizzata mediante
degli specifici indicatori detti Key Performance Indicator (KPI). Il punto di forza
dei KPI e quello di permettere ai manager di fissare delle regole che non si prestino a
equivoci o a interpretazioni personali, il che non accade quando si utilizzano allo stesso
tempo regole di comportamento e direttive aziendali.
Il BPM richiede che i valori degli indicatori siano continuamente aggiornati e resi di-
sponibili al momento giusto nella forma piu adatta a supportare le attivita decisionali.
Si differenzia dalla classica soluzione di data warehousing per le seguenti caratteristiche:
[GR06]
• Utenti : il BPM interessa sempre i decisori, ma a livello operativo e tattico anziche
strategico;
• Tempo di risposta: dal momento che le decisioni dei livelli tattico e operativo devono
avvenire con maggior frequenza rispetto a quelle del livello strategico, i sistemi di
BPM dovranno avere periodi di aggiornamento piu brevi rispetto a quelli del data
warehouse;
• Livello di dettaglio: poiche gli eventi di interesse dei BPM sono attivita ben speci-
fiche, il dettaglio delle informazioni che dovranno avere a disposizione e di conse-
guenza piu elevato rispetto a quello del data warehouse;
• Tempo di vita: a differenza del livello di dettaglio, il tempo di vita delle informazioni
per il BPM sara decisamente minore rispetto a quello che richiedono i sistemi di
50 Introduzione alla Business Intelligence
data warehousing. Questo perche gli utenti BPM sono interessati alle performance
attuali della propria attivita;
• Interfaccia utente: le informazioni verranno presentate all’utente sotto forma re-
port o tramite allarmi innescati automaticamente mediante il controllo di regole di
business.
Alla luce di quanto appena detto risulta evidente come DW e BPM siano profondamente
differenziati e allo stesso tempo complementari.
Si noti come BPM sia anche l’acronimo utilizzato per il business process management che
pero e inerente alle modalita di gestione aziendale per processi.
2.3.3 Ciclo delle analisi di Business Intelligence
Ciascuna analisi di business intelligence si sviluppa secondo modalita autonome che ri-
sentono del contesto, delle caratteristiche soggettive dei decision maker e degli strumenti
analitici disponibili. Tuttavia e possibile identificare un percorso ideale che caratterizza
l’evoluzione delle singole analisi di business intelligence, come rappresentato in Figura 2.19
[Ver06].
Figura 2.19: Fasi di un’analisi di business intelligence
Analisi. In questa fase si deve comprendere in maniera precisa il problema da affrontare,
un decision maker elabora un modello del fenomeno analizzato, selezionando i fattori che
risultano maggiormente rilevanti. La possibilita di esplorare secondo diverse viste logiche
i cubi di dati nel corso delle analisi multidimensionali, permette a un decision maker di
2.3 La Business Intelligence (BI) 51
modificare con flessibilita e tempestivita le sue ipotesi. Osserviamo quindi come le me-
todologie di business intelligence permettano di sviluppare rapidamente diversi percorsi
di analisi.
Comprensione. In un secondo momento il decision maker dovra approfondire ogni
caratteristica del problema rilevato durante la fase di analisi. In pratica si tratta di tra-
sformare le informazioni precedentemente identificate in conoscenza. Questo processo di
trasformazione puo avvenire mediante l’intuizione e l’esperienza del decision maker op-
pure tramite eventuali informazioni non strutturate in suo possesso.
Decisione. E la fase in cui le conoscenze vengono tradotte in decisioni e successivamente
in azioni. La business intelligence permette di svolgere le fasi di analisi e comprensione
in modo piu rapido e di conseguenza anche decisioni piu efficaci e tempestive.
Misura. Durante la fase di misura ci si preoccupa di misurare le prestazioni, basate
su metriche comprendenti non solo indicatori finanziari ma anche prestazionali relativi ai
diversi segmenti aziendali.
Le metodologie di business intelligence riducono i tempi del ciclo analisi-decisione-azione-
revisione, con un miglioramento della qualita dei processi decisionali.
CAPITOLO 3
La tecnologia Oracle BI 11g
Introduzione al mondo Oracle
La Oracle Corporation e una multinazionale americana specializzata nello sviluppo e
commercializzazione di sistemi hardware e prodotti software enterprise. Ha sede in Cali-
fornia, nella Silicon Valley.
Venne fondata nel 1977 da Larry Ellison, Bob Miner e Ed Oates con il nome “Software
Development Laboratories” (SDL). Due anni dopo, nel 1979, la societa venne rinominata
“Relational Software Inc.”. Negli anni Ottanta, in seguito al successo del progetto Oracle,
un database commissionato dalla CIA, la societa assunse il suo nome attuale.
Presente in oltre 145 paesi nel mondo, Oracle Corporation oggi produce, sviluppa, com-
mercializza e offre servizi legati all’infrastruttura tecnologica, alle business applications e
ai sistemi hardware.
Dal gennaio 2005 con l’acquisizione di PeopleSoft, e quindi della piattaforma ERP JD
Edwards, Oracle ha lanciato la sua strategia di acquisizioni che fino ad ora l’ha portata
ad acquisire quasi 60 aziende e a raggiungere numerosi primati. In particolare, People-
soft ha assicurato la leadership nelle applicazioni per la gestione delle Risorse Umane,
Siebel Systems in area CRM, Hyperion in ambito Enterprise Performance Management
e Business Intelligence; mentre BEA Systems ha assicurato dei primati in alcune aree
54 La tecnologia Oracle BI 11g
del Middleware. Con Sun Microsystems, Oracle ha esteso la propria proposta anche ai
sistemi operativi e ai sistemi hardware oltre a diventare proprietario di Java.
Nel nostro Paese, Oracle e presente dal 1993 con sedi principali a Milano e Roma e con
filiali a Torino, Padova, Bologna e Vercelli.
Oracle in Italia opera al fianco di circa 900 Business Partner e dedica loro uno specifico
programma, denominato Oracle PartnerNetwork (OPN) Specialized, a garanzia di un
supporto continuativo ed efficiente [Oraa].
3.1 Oracle e la business intelligence
In questa sezione sono riportati gli aspetti del pensiero Oracle riguardo alla costruzione
di un business case per la business intelligence [Ora09].
Business case. E la collezione di (buoni) motivi per dare il via ad un progetto.
Il business case tipico per la BI e quello di aiutare a prendere decisioni migliori, tut-
tavia avere le giuste informazioni e solo una parte del processo decisionale. I benefici
dell’avere una soluzione di BI si realizzano quando si implementa una decisione e non
dal processo decisionale in se. Una soluzione di BI, aiuta a migliorare le funzionalita di:
reportistica, analisi e previsioni (in ordine dalla meno importante alla piu importante).
Ogni business case inizia con una comprensione del livello di ambizione che l’azienda
sceglie di avere. Esistono tre differenti livelli di ambizione:
• Efficienza: Concentrarsi sul miglioramento dell’efficienza aiuta gli utenti a lavorare
meglio nell’ambito delle mansioni che gia svolgono;
• Efficacia: Curare l’aspetto dell’efficacia del business aiuta l’organizzazione ad
operare le scelte giuste;
• Cambiamento: Consente di avere la possibilita di fare nuove cose.
I diversi incarichi che le persone ricoprono in azienda portano ciascuno ad avere una
prospettiva diversa del medesimo problema. Si noti, infatti, che i responsabili IT foca-
lizzeranno la loro attenzione sull’efficienza, mentre i dirigenti aziendali sono interessati a
gestire il cambiamento.
3.1 Oracle e la business intelligence 55
Un business case per la business intelligence e disegnato su cinque distinti livelli:
• Dati ed infrastruttura;
• Strumenti di BI ed applicazioni di gestione delle prestazioni;
• Uso, governance e BICC (BI Competency Center, coordina la gestione delle infor-
mazioni);
• Processi gestionali ed operativi;
• Strategia di business.
I vari livelli si “appoggiano” uno all’altro. E quindi necessario coinvolgere tutti i livelli in
modo da creare un link diretto tra i requisiti di business del cliente e le varie componenti
che costituiscono la struttura operativa che supporta i suddetti requisiti.
I livelli di ambizione possono essere combinati con quelli appena descritti generando la
Tabella 3.1, nelle celle sono riportati degli esempi di attivita che devono essere affrontate
durante la realizzazione del business case.
Standardizzazione degli strumenti di BI
Riportiamo al lettore i risultati di due ricerche relative all’impiego delle tecnologie di
business intelligence all’interno delle aziende:
• il 40% delle organizzazioni utilizzano ancora dai 3 ai 5 strumenti di BI, ed oltre il
20% almeno 6 o piu strumenti di BI (Forrester Research, 2008);
• le aziende che hanno implementato una soluzione di BI usando gli strumenti di un
unico fornitore software sono aumentate dal 24% del 2005 al 42% del 2007. Dal
sondaggio del 2007 e anche emerso che le aziende che hanno classificato la propria
soluzione BI come “di successo” implementavano un sistema realizzato utilizzando
gli strumenti di un unico fornitore software.
La Figura 3.1 illustra la situazione appena descritta
56 La tecnologia Oracle BI 11g
Efficienza Efficacia Cambiamento
Strategia di Eccellenza Eccellenza Nuovi modelli
business operativa gestionale di business
Processi Riduzione dei Creazione di un’ Nuovi processi di
costi, maggiori
prestazioni, piu
qualita
organizzazione
che sia moderna,
agile ed allineata
business, integrazione
della catena per la
crezione del valore
Uso e governance Il BICC Il BICC crea BICC esteso,
supporta gli stru-
menti usati
e condivide cono-
scenza all’interno
dell’organizzazio-
ne
creazione e condivisio-
ne della conoscenza al-
l’interno di tutta la
catena della creazione
del valore
Strumenti di BI e
applicazioni di ge-
stione delle presta-
zioni
Standardizzazione
degli strumenti
Aggiunta di nuo-
ve funzionalita
Converge con la ge-
stione dei processi di
business, le applica-
zioni business ed il
middleware
Dati ed infrastrut-
tura
Concentrarsi sul
TCO
Fare il punto sul-
la flessibilita
Implementazione
di un’architettura
orientata ai servizi
(SOA)
Tabella 3.1: Matrice business case per la BI.
3.1 Oracle e la business intelligence 57
Figura 3.1: Standardizzazione degli strumenti e successo della BI
La proposta Oracle, per quanto riguarda gli strumenti di business intelligence, e data
dalla suite Oracle Business Intelligence Foundation. Essa e composta da Oracle Business
Intelligence Enterprise Edition, Oracle BI Publisher, Oracle Essbase, Oracle Scorecard e
Strategy Management e Oracle Essbase Analytics Link (EAL) [Ora11a].
Il componente di maggior rilievo e senza dubbio la suite Oracle Business Intelligence En-
terprise Edition (da ora in poi piu semplicemente OBIEE), giunta alla versione 11.1.1.3.0,
rilasciata il 13 agosto 2010. La Figura 3.2 fornisce una panoramica della sua architettura.
Figura 3.2: Architettura di OBIEE 11g
58 La tecnologia Oracle BI 11g
La suite OBIEE 11g, e completamente integrata con il Fusion Middleware di Oracle.
Questo, dal punto di vista architetturale, si traduce principalmente con l’adozione di
Oracle Web Logic Application Server come piattaforma per tutti i servizi JEE della
suite, a cui si affiancano i servizi C++ e J2SE ereditati dalla precedente release.
3.2 Architettura logica
L’architettura logica del sistema Oracle Business Intelligence e composta da un unico in-
sieme integrato di componenti gestibili, detto dominio BI (BI domain). Tali componenti
possono risiedere su di un unico host oppure essere separati in piu host per ragioni di
performance, disponibilita e sicurezza.
Figura 3.3: Architettura logica di OBIEE 11g su un singolo host
3.2 Architettura logica 59
Un dominio BI e composto da: componenti Java, componenti di sistema e da un insieme
di altri componenti tra cui repository dei metadati e presentation catalog [Orad].
Componenti Java
Vengono distribuiti come applicazioni JEE per servizi SOAP, HTTP ed altre forme di
richiesta. Nell’architettura mostrata in Figura 3.3 possiamo notare la presenza di due
contenitori JEE: l’Administration Server ed il Managed Server.
L’Administration Server contiene i componenti Java necessari per l’amministrazione
del sistema. Tali componenti sono:
• JMX MBeans: provvede a schematizzare gli accessi per la gestione del dominio BI;
• Fusion Middleware Control: e l’interfaccia utente di amministrazione usata per
gestire il dominio BI;
• WebLogic Server Administration Console: e l’interfaccia utente di amministrazione
per la gestione avanzata di WebLogic, componenti JEE e sicurezza.
Figura 3.4: Architettura logica di OBIEE 11g su piu host
60 La tecnologia Oracle BI 11g
Il Managed Server fornisce l’ambiente di run-time per servizi Java-based e applicazioni
interne al sistema. Un dominio di BI puo possedere piu Managed Server che possono
essere distribuiti su uno o piu host. I componenti Java gestiti sono:
• Action Services: fornisce i servizi Web dedicati che vengono richiesti dall’Action
Framework (descritto nel paragrafo 3.4.5) e che consentono all’amministratore di
configurare manualmente quali directory del servizio Web possono essere sfogliate
dagli utenti quando questi eseguono una determinata azione;
• SOA Services: fornisce servizi Web dedicati per gli oggetti nel presentation catalog
per invocare analisi, agenti e condizioni;
• BI Office: provvede all’integrazione tra OBIEE ed i prodotti Microsoft Office;
• Real-Time Decisions (RTD): fornisce soluzioni software enterprise di analisi che
permettono alle aziende di prendere le migliori decisioni in tempo reale;
• BI Plugin: e un’applicazione JEE che ha il compito di instradare le richieste SOAP
e HTTP ai Presentation Services (che saranno descritti in seguito);
• BI Publisher: fornisce una soluzione di reportistica per la creazione, gestione e
distribuzione di report “pixel perfect” a dipendenti, clienti e fornitori;
• Security Services: fornisce servizi Web dedicati che consentono l’integrazione del BI
Server (che descriveremo in seguito) con la piattaforma di sicurezza Oracle Fusion
Middleware.
Sia l’Administration che il Managed Server vengono eseguiti su Java virtual machine
dedicate.
Infine il Node Manager fornisce servizi per la gestione dei processi per l’Administration
ed il Managed Server. Esso infatti permette di avviare, arrestare e riavviare le loro istanze
in remoto.
Componenti di sistema
I componenti di sistema forniscono i servizi base (C++ o J2SE) per poter eseguire OBIEE,
e sono:
3.2 Architettura logica 61
• BI Server: fornisce le funzionalita di query ed accesso ai dati che sono il cuore di
OBIEE;
• Presentation Services: forniscono il framework e l’interfaccia per la presentazione
dei dati di business intelligence. E loro compito gestire il Presentation Catalog (che
sara trattato successivamente);
• Scheduler: permette di schedulare la consegna di analisi agli utenti in momenti
specifici. BI Publisher possiede uno scheduler proprio;
• JavaHost: offre servizi che permettono al Presentation Server di supportare com-
ponenti come i task dello Scheduler, BI Publisher e la generazione dei grafici;
• Cluster Controller: ha il compito di distribuire le richieste al BI Server ed assicurare
che il carico di lavoro di tali richieste siano bilanciate su tutti i BI Server nel dominio
BI.
L’OPMN (Oracle Process Manager and Notification server) ha il compito di gestire i
componenti appena descritti.
Repository dei metadati
Il repository dei metadati e un file con estensione rpd dalle dimensioni solitamente com-
prese tra 0.5MB e 2MB. Ha il compito di memorizzare i metadati di cui necessita il BI
Server per trasformare una query logica, ovvero una interrogazione che viene costruita
dall’utente che non e a conoscenza della struttura delle sorgenti, nella relativa query fisica
da eseguire sui dati sorgente. Un repository e suddiviso in tre livelli, come mostrato in
Figura 3.5: [Orac]
• Livello fisico: definisce gli oggetti e le loro relazioni, necessarie al BI Server per
costruire le query native sui dati fisici. Puo essere creato importando tabelle, cubi
e flat file dalle fonti dati. Il livello fisico ha il compito di separare il comportamento
logico delle applicazioni dal modello fisico, dando quindi la possibilita di unire piu
fonti dati fisiche in un unico oggetto logico. Una separazione di questo tipo assicura
una elevata portabilita;
62 La tecnologia Oracle BI 11g
Figura 3.5: Traduzione di una query logica nella relativa query fisica attraverso i 3 livelli
del repository
• Livello logico: definisce il modello business dei dati e la mappatura con gli schemi
fisici. In questo livello si determina il comportamento analitico percepito dagli utenti
e viene definito l’insieme degli oggetti e delle relazioni a disposizione dell’utente;
• Livello di presentazione: fornisce un modo sicuro e personalizzato per rappresen-
tare il modello business. Nel livello di presentazione vengono create le cosiddette
subject area che permettono di suddividere il modello business in piu parti.
Il repository dei metadati viene gestito dall’Administration Tool, un’applicazione Win-
dows appartenente alla suite dei client tools, trattata nel paragrafo 3.5
Come accennato in precedenza, il BI server si serve del repository per trasformare le query
logiche nelle query native che saranno poi eseguite sui dati sorgente. La Figura 3.6 mo-
stra come il BI Server interagisce con le query dei client, le sorgenti dati, l’Administration
Tool e il repository.
Presentation Catalog
Ha il compito di memorizzare in una struttura di directory gli oggetti creati dagli utenti.
Tali oggetti possono essere: analisi, dashboard, filtri, prompt, ecc. Ogni qual volta un
utente salva un oggetto come quelli appena indicati, esso verra automaticamente memo-
rizzato all’interno del Presentation Catalog.
3.3 Installazione del prodotto 63
Figura 3.6: Architettura del BI Server
Come per il repository esiste un’applicazione anche per la gestione del Presentation
Catalog ed e il Catalog Manager.
3.3 Installazione del prodotto
Requisiti di sistema
OBIEE 11g offre senza dubbio un’architettura piu scalabile e strumenti di gestione piu
maturi rispetto la release precedente. Per contro, la complessita di gestione e superiore
e sono richieste maggiori risorse di sistema. I requisiti di sistema consigliati da Oracle
sono: [Ora11b]
• Spazio su disco: 20GB o piu;
• Memoria RAM: 4GB o piu;
• Spazio temporaneo: 950MB o piu;
• Spazio di swap: 3GB o piu;
• CPU: dual-core Pentium, 1.5GHz o maggiore.
64 La tecnologia Oracle BI 11g
DBMS supportati:
• Oracle 10.2.0.4+ , 11.1.0.7+, 11.2.0.1+;
• IBM DB2 9.1+, 9.5+, 9.7+;
• MS SQL Server 2005, 2008;
• Teradata 12, 13.
Sistemi operativi supportati: [Orae]
• Oracle/Red Hat Enterprise Linux 4 (Update 7+), 5 (Update 3+);
• SUSE Linux Enterprise Server 10 (SP1+), 11;
• Windows 2003 SP2/R2+;
• Windows Server 2008 SP1+;
• Windows Server 2008 R2.
Installazione
Il pacchetto di installazione di Oracle Business Intelligence, include i seguenti prodotti:
[Orab]
• OBIEE 11g (Answers, Dashboards, Delivers, Repository Administration Tool, Of-
fice e Oracle Business Intelligence Publisher);
• Oracle Business Intelligence Publisher;
• Oracle Real-Time Decisions.
E possibile installare uno, due o tutti e tre i prodotti che condivideranno la stessa
struttura Oracle Fusion Middleware all’interno del medesimo dominio WebLogic. Una
tipica installazione di Oracle BI prevede una Fusion Middleware home e le seguenti
sottodirectory:
• wlserver 10.3 : e la home del WebLogic server e contiene: i componenti Java, un
Administration Server e uno o piu Managed Server;
3.3 Installazione del prodotto 65
• user projects : contiene i domini dei prodotti, inclusi uno o piu domini BI;
• Oracle BI1 : contiene i file binari (in sola lettura) propri di Oracle Business Intelli-
gence.
Figura 3.7: Tipica struttura delle directory di Oracle BI
Sono inoltre previste tre modalita di installazione:
• Simple Install : l’installazione verra eseguita con i settaggi di default, su un singolo
computer e nel minor numero di passi;
• Enterprise Install : permette di effettuare una installazione enterprise distribuita.
La configurazione non e quella di default, sara possibile infatti specificare impo-
stazioni come: percorsi delle directory, nomi degli host, numeri di porta e molto
altro;
• Software Only : con questa modalita di installazione vengono installati i soli file
binari, la configurazione dovra per tanto essere eseguita separatamente. Per sistemi
a 64-bit costituisce l’unica modalita di installazione possibile.
Non esiste un’unica procedura di installazione. Essa dipende dal sistema operativo (Win-
dows o Linux) e dalla sua architettura (32 o 64 bit). Cio che le accomuna e la necessita di
creare uno schema su un database mediante l’utility RCU (Repository Creation Utlity).
Per installazioni su macchine a 64 bit o macchine Linux non e prevista l’installazione
dei client tools, in quanto questi ultimi sono disponibili solo per macchine Windows 32-
bit. E tuttavia possibile scaricare ed installare i soli client tools, facendoli poi collegare
66 La tecnologia Oracle BI 11g
in remoto con il server sul quale e installato OBIEE.
Per i sistemi a 64 bit e inoltre richiesto che l’installazione della JDK e di WebLogic
venga fatta separatamente prima di procedere all’installazione, che avverra in modalita
“Software Only”.
3.4 Componenti di front-end
OBIEE 11g fornisce una suite completamente integrata di prodotti complementari per
fornire una gamma completa di funzionalita di analisi.
I Presentation Services forniscono l’interfaccia utente che viene utilizzata per la visualiz-
zazione dei dati provenienti dal BI Server. Tramite questa interfaccia gli utenti possono
accedere agli strumenti di front end che verranno descritti di seguito [Ora11a].
3.4.1 Analisi e reportistica
OBIEE 11g mette a disposizione dell’utente un ambiente web per la creazione di analisi,
reportistica e query ad-hoc. Questo ambiente era conosciuto nella precedente versione con
il nome di “BI Answers”, in OBIEE 11g si parlera di “BI Analysis and Reporting”.
Le funzionalita messe a disposizione dell’utente sono:
• Indipendenza dai dati sorgente: gli utenti interagiscono con una vista logica delle
informazioni, che maschera completamente la complessita della struttura dei dati
sorgente. Inoltre non e richiesto che gli utenti siano a conoscenza di come le regole
business sono calcolate. Esse infatti vengono definite nel repository (come descritto
precedentemente);
• Condivisione online delle analisi: una volta salvata la propria analisi, l’utente po-
tra condividerla online pubblicandola all’interno di una Dashborad (trattate nel
paragrafo 3.4.2);
• Salvataggio delle analisi: misure, attributi descrittivi, filtri, pattern di ordinamento,
grafici e viste in tabelle pivot possono essere aggiunte, eliminate e modificate in ogni
momento. Al termine delle modifiche, la nuova analisi puo essere salvata e condivisa
con un gruppo di utenti;
3.4 Componenti di front-end 67
• Potenti analisi ad-hoc: poiche il processo analitico e spesso iterativo, non vengono
imposti vincoli sull’ordine con il quale l’analisi viene costruita. Infatti, per esempio,
la selezione delle misure, l’aggiunta o la modifica di filtri, l’aggiunta o la rimozione
di colonne e la possibilita di visualizzare il risultato, sono attivita che possono essere
effettuate in un qualsiasi momento ed ordine durante la costruzione delle analisi;
• Personalizzazione: le informazioni a cui accedono gli utenti vengono filtrate e
personalizzate automaticamente in base all’identita e al ruolo dell’utente stesso.
Una sessione di analisi in OBIEE 11g comincia con la selezione della subject area, per
esempio le vendite. Successivamente vengono mostrati all’utente tutti gli oggetti business
che avra a disposizione per costruire l’analisi. Una volta terminato, il BI Analysis and
Reporting genera la relativa query in SQL logico e la invia al BI Server che provvede a
convertirla nella equivalente query fisica.
La Figura 3.8 mostra l’interfaccia messa a disposizione dell’utente per la creazione delle
analisi. A sinistra possiamo notare la subject area, mentre al centro la visualizzazione
del risultato.
Figura 3.8: Costruzione di un’analisi con BI Analysis and Reporting
Una caratteristica fondamentale che un’analisi deve possedere e la chiarezza del risultato.
OBIEE 11g offre svariate modalita di visualizzazione tra cui grafici e diagrammi, tabelle
pivot, viste geospaziali, ecc.
68 La tecnologia Oracle BI 11g
3.4.2 Dashboard
Una dashboard (o cruscotto) e una collezione di oggetti che, raccolti per aree tematiche,
mostrano un certo quadro della situazione. La maggior parte di tali oggetti vengono
creati mediante BI Analysis and Reporting. Le dashboard hanno il compito di facilitare
l’accesso degli utenti ad analisi costruite in precedenza e offrono le seguenti funzionalita:
• Potenza di analisi: le dashboard costituiscono un potente ambiente per l’analisi
interattiva dei dati, in quanto permettono la loro navigazione;
• Condivisione online delle informazioni: la possibilita di pubblicare online le dash-
board costituisce un fondamentale metodo per la condivisione delle informazioni;
• Personalizzazione: ogni cruscotto puo essere personalizzato in modo tale da vi-
sualizzare automaticamente i dati in base all’identita e al ruolo dell’utente che li
richiede;
• Filtraggio dati: possono essere visualizzate analisi prefiltrate da valori di default o
immessi manualmente dagli utenti;
• Condivisione offline delle informazioni: le dashboard possono essere salvate e di-
stribuite per un utilizzo di tipo offline come report o Briefing Book (decritti nel
paragrafo 3.4.6). Inoltre il contenuto di un cruscotto puo essere scaricato in file
Excel o PowerPoint;
• Salvataggio personalizzazioni: gli utenti possono modificare analisi, filtri, layout,
ecc. e salvare le modifiche sia per uso personale che condiviso;
• Personalizzazione dello stile: Il look and feel delle dashboard puo essere modificato
utilizzando i Cascading Style Sheet (CSS).
Gli utenti interagiscono con le dashboard filtrando i dati mediante l’inserimento di valori
in un prompt, eseguendo operazioni di drill-down per accedere a informazioni piu detta-
gliate, modificando l’ordinamento delle colonne, ecc.
La creazione dei cruscotti, molto spesso, avviene per mano degli utenti stessi senza nessun
coinvolgimento di specialisti IT.
La Figura 3.9 mostra un esempio di dashboard.
3.4 Componenti di front-end 69
Figura 3.9: Un esempio di dashboard interattiva
3.4.3 Scorecard e Strategy Management
Oracle Scorecard e Strategy Management estende la suite Oracle BI con funzionalita de-
stinate a comunicare gli obiettivi strategici in tutta l’organizzazione e il monitoraggio dei
loro progressi nel tempo. Permette di stabilire obiettivi specifici, definire le modalita per
misurare il loro successo, e comunicare informazioni a tutta l’organizzazione. I dipendenti
possono quindi capire il loro impatto sul raggiungimento del successo e allineare le loro
azioni di conseguenza.
Figura 3.10: Un esempio di scorecard
70 La tecnologia Oracle BI 11g
3.4.4 BI Publisher
BI Publisher viene utilizzato per la realizzazione di report statici con personalizzazione
avanzata del layout grafico (“pixel perfect”). Permette inoltre, l’estrazione di dati da piu
sorgenti e la loro pubblicazione in svariati formati, consentendo di pianificare la consegna
dei report alle destinazioni.
Gli utenti finali possono creare facilmente il layout grafico utilizzando strumenti desktop
familiari come Microsoft Word, Microsoft Excel o Adobe Acrobat, oppure mediante un
nuovo strumento WYSIWYG di layout designer utilizzabile direttamente nel browser, il
BI Publisher Layout Editor. Gli sviluppatori invece, possono scegliere di utilizzare Adobe
Flex Builder o un qualsiasi IDE XML.
Figura 3.11: Costruzione di un report pixel perfect mediante BI Publisher Layout Editor
3.4.5 Actionable Intelligence
OBIEE 11g estende le funzionalita di reporting tradizionali appena descritte, offrendo la
possibilita di:
3.4 Componenti di front-end 71
• rilevare il verificarsi di determinate condizioni e di inviare degli alert agli utenti
interessati;
• avviare direttamente processi esterni.
Queste funzionalita vengono offerte rispettivamente dal BI Delivers e dall’Action Fra-
mework che saranno brevemente descritti di seguito.
BI Delivers
BI Delivers, attraverso la creazione di Agenti, offre la possibilita di monitorare proattiva-
mente le informazioni di business, allertare gli utenti tramite mail, dashboard e dispositivi
mobili come telefoni cellulari e permette di prendere decisioni rapide in funzione degli alert
che sono stati ricevuti.
Gli agenti possono essere concatenati, ovvero possono scambiarsi informazioni tra loro.
Essi vengono creati mediante un’apposita interfaccia, mostrata in Figura 3.12, nella quale
l’utente puo specificare le opzioni di consegna degli alert, definire profili, programmare
l’esecuzione automatica di un report e molto altro ancora.
Figura 3.12: Creazione di un agente tramite BI Delivers
72 La tecnologia Oracle BI 11g
Action Framework
E una particolare funzione altamente innovativa che agisce da collegamento fra l’analisi
e l’azione dando agli utenti la possibilita di attivare un processo di business o un Web
service direttamente dal proprio cruscotto.
3.4.6 BI Mobile
Sempre piu frequentemente gli utenti manifestano il desiderio di avere a disposizione o
di poter reperire le informazioni business anche quando non sono in ufficio. OBIEE offre
tre possibili soluzioni a questo problema.
Briefing Books
Un Briefing Book e un documento che cattura il contenuto di una dashboard e ne consen-
te la visualizzazione in modalita disconnessa, da parte di chiunque disponga del software
Briefing Book reader. Offrono un metodo per creare istantanee delle dashboard, visua-
lizzarle offline, o condividerle con gli altri e ne possiedono lo stesso “look and feel”. I
Briefing Book forniscono anche un metodo per archiviare le informazioni di una dash-
board poiche possono essere salvati localmente sul PC di un utente. I Briefing Book
personalizzati possono essere distribuiti automaticamente (via e-mail) tramite Oracle BI
Delivers a gruppi di utenti.
BI Mobile
Le aziende richiedono che le informazioni possano essere reperibili in qualsiasi momento.
I dispositivi mobili svolgono un ruolo chiave in questo contesto, per tanto OBIEE offre
la possibilita di accedere a tutti i contenuti delle dashboard tramite dispositivi mobili.
Si noti come un tale approccio renda ancora piu efficace il ruolo giocato dagli agenti che
hanno il compito di inviare gli alert.
Plug-in Office
L’Add-In di Microsoft Office integra le informazioni di Business Intelligence provenienti
dal BI Server, BI Analysis and Reporting, dashboards e BI Publisher con l’ambiente
di Microsoft Office. Questo permette di incorporare dati aziendali aggiornatissimi nei
3.5 L’Administration Tool 73
documenti di Microsoft Word, Excel e PowerPoint. Gli utenti possono quindi condividere
questi documenti sul Web per attuare un processo decisionale veramente collaborativo.
3.5 L’Administration Tool
E uno strumento facente parte dei client tool che permette di operare con efficienza sui
metadati contenuti nel repository. La Figura 3.13 mostra l’interfaccia dell’Administration
Tool; si noti la netta separazione dei tre livelli del repository.
Figura 3.13: Suddivisione dei tre livelli del repository nell’Administration Tool
L’Administration Tool aiuta gli amministratori a preparare le formule (per esempio una
percentuale rispetto a un totale) e ne assicura la correttezza, oppure consente di creare
centinaia di misure di confronto per le serie temporali (per esempio, vendite dell’anno
precedente, percentuale di modifica rispetto all’anno precedente, rapporto di vendita
rispetto all’anno precedente, e cosı via) in pochi secondi. Funzionalita sofisticate di
gestione del progetto permettono inoltre a piu amministratori di operare simultaneamente
sui repository dei metadati.
Ecco alcune delle principali funzionalita offerte dall’Administration Tool:
• Gestione delle modifiche: fornisce numerosi servizi per facilitare la gestione delle
modifiche. Per esempio, un wizard di rinomina semplifica il cambiamento dei nomi
74 La tecnologia Oracle BI 11g
di piu oggetti simultaneamente, la sostituzione di testo, la modifica di maiuscole/-
minuscole e l’aggiunta di prefissi o suffissi. Questo, a sua volta, semplifica il trasci-
namento e il rilascio di colonne fisiche nel livello della modellazione e mappatura
business e consente di attribuire loro nomi logici piu leggibili e significativi;
• Amministrazione dei metadati: per semplificare le operazioni con i repository di
grandi dimensioni, il tool di amministrazione permette all’amministratore di strut-
turare e organizzare i metadati, per esempio utilizzando cartelle, per organizzare gli
oggetti. L’amministratore puo inserire tutte le tabelle dimensionali in una singola
cartella e tutte le gerarchie in una cartella differente o, alternativamente, inserire
una tabella dimensionale e le gerarchie correlate nella stessa cartella e utilizzare
icone grafiche per contrassegnare gli oggetti per finalita specifiche;
• Dipendenza e analisi degli impatti: una utility consente all’amministratore di cer-
care nei metadati oggetti per tipo, pur filtrando le proprieta e le relazioni con gli
altri oggetti. Per esempio, un amministratore puo trovare tutte le colonne logiche
che dipendono da una specifica tabella o colonna fisica per determinare quali ogget-
ti di business vengano influenzati dall’eventuale eliminazione dal database di una
specifica colonna fisica;
• Esportazione/importazione: il tool di amministrazione offre funzionalita di espor-
tazione e importazione dei metadati per spostare i sistemi dagli ambienti di staging
a quelli di produzione e per esportare i metadati su file a scopo di documentazione.
Una utility di documentazione del repository genera un elenco di colonne di pre-
sentazione, colonne del modello di business loro corrispondenti, formule e sorgenti
fisiche mappate;
• Collaborazione multi-utente per l’amministrazione: l’Administration Tool puo esse-
re utilizzato sia in modalita offline che online. Le modifiche online hanno effetto
immediatamente, senza dover riavviare il server. La modalita offline permette a
diversi amministratori di operare modifiche in modo concomitante su uno stesso
repository di metadati. Quando gli oggetti sono selezionati per la modifica, questi e
gli oggetti da cui dipendono sono disponibili agli altri amministratori esclusivamente
in formato di sola lettura;
3.6 Comparazione con gli altri competitor 75
• Amministrazione degli utenti: il tool di amministrazione offre inoltre un modo per
visualizzare (e terminare) le sessioni utente correnti; per vedere le variabili utilizzate
in ciascuna sessione; per elencare le voci cache disponibili per area tematica, utente,
o tabella fisica; per riferire sulla storia recente dell’uso della cache.
3.6 Comparazione con gli altri competitor
In questo paragrafo osserviamo le caratteristiche dei prodotti dei principali vendor di
software per la business intelligence, caratteristiche che devono essere considerate dalle
organizzazioni che vogliono adottare soluzioni di business intelligence che soddisfino le
loro richieste.
Riportiamo ora alcune considerazioni fatte da Gartner, una delle piu importanti aziende
di analisi del mercato IT. La Figura 3.14 mostra il Magic Quadrant pubblicato da Gartner
nel gennaio 2011 [Gar11].
Figura 3.14: Quadrante magico di Gartner relativo alle piattaforme di Business
Intelligence del mese di gennaio 2011
76 La tecnologia Oracle BI 11g
I criteri di valutazione adottati dal Magic Quadrant sono: la completezza di visione
e la capacita di esecuzione. Chi eccelle in entrambe fa parte dei leader. Chi ha
buona completezza di visione ma non ha una solida capacita di esecuzione fa parte dei
visionari. Chi ha buona capacita di esecuzione ma ha una visione incompleta fa parte
degli sfidanti, mentre, per concludere, chi ha una visione incompleta e al tempo stesso
ha scarsa capacita di esecuzione viene definito come player di nicchia.
Osserviamo ora le caratteristiche dei maggiori vendor di prodotti per la business intelli-
gence.
Oracle
Pro: la piattaforma OBIEE e considerata lo standard di riferimento per la BI nella mag-
gior parte delle aziende che la utilizzano. Inoltre permette un alto livello di integrazione
con le applicazioni aziendali e con l’infrastruttura informativa e supporta un elevato nu-
mero di utenti contemporaneamente.
Contro: la release 11g ha avuto un ciclo di sviluppo e rilascio relativamente lungo. Le
funzionalita di data mining ed analisi what-if vengono offerte come parte di Oracle da-
tabase e del prodotto Oracle Real-Time Decision, entrambi i quali sono separati dalla
piattaforma OBIEE.
Microstrategy
Pro: Microstrategy ha costruito la sua piattaforma da zero ed e specializzata nelle imple-
mentazioni di BI che girano su grandi data warehouse. E stata una dei primi produttori
ad investire pesantemente in applicazioni BI per dispositivi mobili. Fornisce un eccellen-
te supporto del prodotto che consente agli amministratori di risolvere in breve tempo i
problemi riscontrati. Si pone al primo posto per livello di integrazione dei componenti
della piattaforma.
Contro: nonostante l’ambiente di sviluppo Microstrategy sia uno dei piu potenti e fles-
sibili, presenta una ripida curva di apprendimento. La creazione di dashboard e re-
port ad-hoc non e particolarmente user-frendly per gli utenti business. Inoltre, i clienti
Microstrategy indicano come limitazione piu grande il costo del software.
3.6 Comparazione con gli altri competitor 77
Microsoft
Pro: Microsoft ha sempre investito nella costruzione e miglioramento delle sue funzio-
nalita di BI in tre dei suoi prodotti: Microsoft Office, Microsoft SQL Server e Microsoft
SharePoint, al fine di aumentare il loro valore. I costi delle licenze sono tra i piu bassi e
la possibilita di poter utilizzare funzionalita di business intelligence integrate in prodotti
gia presenti nelle aziende, conferisce ai prodotti Microsoft il piu alto grado di “capacita
di esecuzione” tra tutti i prodotti di BI presenti sul mercato.
Contro: la scelta di offrire funzionalita di BI in una soluzione multi prodotto, soprattut-
to considerando che tali prodotti svolgono anche funzionalita non-BI, presenta per certi
versi una limitazione rispetto alle soluzioni di altri vendor, che integrano tutte (o quasi
tutte) le funzionalita di business intelligence all’interno di un unico prodotto. Un’altra
limitazione e data dalla scarsa disponibilita di strumenti orientati agli utenti business,
facendo dei prodotti Microsoft BI delle soluzioni destinate agli sviluppatori. Infine, non
esiste un unico livello per i metadati e le funzionalita offerte per la loro modellazione sono
molto limitate.
SAP
Pro: la combinazione di SAP e Business Object rappresenta la piattaforma piu installata
in assoluto. Il volume di dati e di utenti dei clienti SAP sono tra i maggiori sul mercato
(quasi il doppio della media). Le sue funzionalita di reporting e di costruzione di query
ad-hoc vengono definite dai suoi clienti come i maggiori punti di forza del prodotto. La
piattaforma SAP/BO viene completata nelle aree della collaborazione e nel supporto alle
decisioni dai prodotti: StreamWork, Text-Analysis ed altri prodotti di gestione dell’in-
formazione con integrazione dei dati.
Contro: tra le piu frequenti lamentele mosse dai clienti fanno parte le basse performance
e l’alto livello di difficolta delle implementazioni. L’esperienza dei clienti e la qualita del
software e del supporto tecnico sono tra i piu bassi rilevati nel sondaggio Gartner.
IBM
Pro: IBM detiene la leadership per quanto riguarda la “completezza di visione”. Il pro-
dotto offerto per la business intelligence da IBM e IBM Cognos che offre la possibilita di
effettuare sia analisi statiche sia di tipo predittivo. In particolare, quest’ultima tipologia
78 La tecnologia Oracle BI 11g
di analisi costituisce uno dei maggiori punti di forza del prodotto.
Contro: Uno dei maggiori punti deboli del prodotto IBM e dato dalle performance, an-
che se la versione 10.1 di IBM Cognos dispone di funzionalita specifiche per affrontare
problemi di performance. La scarsa diffusione del prodotto puo essere ricercata nella
elevata difficolta dell’implementazione dei progetti di business intelligence e dalla scarsa
usabilita del prodotto stesso. Infine, i costi elevati delle licenze (ben sopra alla media)
costituiscono un ulteriore motivo di angoscia per i clienti.
In cinque anni, il mercato delle piattaforme software di Business Intelligence ha subi-
to notevoli trasformazioni, sopratutto per il susseguirsi di importanti acquisizioni. Di
seguito vengono messe a confronto due istantanee con le posizioni occupate dai principali
player sul quadrante magico.
Figura 3.15: Confronto delle posizioni occupate dai maggiori vendor di piattaforme di
Business Intelligence nel quadrante magico di Gartner nel 2006 e nel 2011
3.6 Comparazione con gli altri competitor 79
Nel 2006 i due principali leader del mercato erano Business Objects e Cognos. A
distanza di 5 anni il quadrante dei leader si e decisamente affollato. Le strategie che hanno
contraddistinto l’evoluzione del mercato sono riconducibili a due modelli fondamentali:
• l’acquisizione/fusione di piu realta per potenziare e completare l’offerta;
• l’investimento interno finalizzato a sviluppare la propria vision che sia in grado di
contraddistinguere la propria offerta rispetto ai competitor.
Oracle ha seguito la prima strategia e, in virtu dell’anticipo con cui ha effettuato le sue
mosse sul mercato, e quella che, avendo avuto il tempo necessario per realizzare un’offerta
completa, ha meglio capitalizzato gli investimenti in termini di posizionamento.
3.6.1 Prodotti open source
Un numero crescente di organizzazioni si dimostra sempre piu attratto dalle promesse del
software open source. Sono soluzioni ricche di funzionalita che possono ridurre il costo
totale di proprieta dell’infrastruttura IT. Software come Linux, OpenOffice, MySQL e
Firefox sono considerate soluzioni mainstream e vengono ampiamente adottate. Osser-
viamo ora, se anche le soluzioni open source di business intelligence sono abbastanza
mature per poter essere utilizzate dalle aziende.
Non si deve guardare molto lontano per avere la prova della maturita raggiunta dalla BI
open source. Unionfidi, un’importante istituzione finanziaria italiana attiva nel credito a
piccole e medie aziende, ha sostituito tutte le soluzioni BI esistenti, comprese quelle di
reporting, con una suite BI open source a partire dal 2006. Un altro esempio e quello del
ministero della Sanita che ha scelto una suite open source per sviluppare un nuovo sistema
di supporto decisionale. Molte organizzazioni, sia pubbliche sia private, stanno attual-
mente implementando soluzioni BI open source che rispondono al nome di JasperSoft,
Pentaho o SpagoBI, suite che rendono disponibile un ampio spettro di funzionalita,
dall’ETL a funzioni ad-hoc di analisi e reporting. Spago BI ha inoltre il vantaggio di
essere un prodotto italiano, sviluppato e supportato da Engineering, un grande system
integrator nazionale.
Tuttavia e bene sottolineare che sia JasperSoft che Pentaho offrono versioni Community
e Professional. Mentre le prime sono completamente open source, le versioni Professional
includono invece componenti aggiuntivi closed source.
80 La tecnologia Oracle BI 11g
Nonostante le tecnologie open source per la business intelligence non siano direttamen-
te confrontabili con le suite proprietarie (le piu importanti descritte precedentemente) e
bene riportare un concetto fondamentale che Gartner ha espresso nel seguente modo:
“mentre i vendor tradizionali possono ancora vantare una posizione di preminen-
za nell’offerta tecnologica complessiva, l’adozione dell’open source aumenta perche
considerata sufficientemente valida”
ETL open source
Anche nel campo dell’ETL il mondo open source offre una vasta gamma di prodotti.
Kettle, per esempio, e un tool ETL facente parte della suite BI di Pentaho. E poi Talend
(utilizzato all’interno di JasperSoft dove viene chiamato JasperETL), Jitterbit, Snaplo-
gic, CloverETL. Non saranno comparabili a quelli offerti dai “megavendor”, ma vengono
ritenuti sufficientemente validi per il loro basso costo e le adeguate funzionalita. Possono
pertanto essere un’alternativa al software proprietario.
La caratteristica che consente di implementare con successo un progetto BI fa comunque
riferimento alle prestazioni. In molte implementazioni di BI open source si e spesso scelto
di utilizzare MySQL, che puo essere considerato un buon DBMS transazionale, ma che
rivela tutte le sue limitazioni quando impiegato per la costruzione di data warehouse e
data mart a livello enterprise. Per questo motivo alcuni vendor open source hanno svi-
luppato soluzioni di database, basate su MySql, ma che prevedono un motore di storage
completamente differente, adatto a supportare carichi di lavoro BI di tipo enterprise. Na-
turalmente la scelta di un database analitico open source non si limita a soluzioni basate
su MySql.
L’importanza della query performance non deve essere sottovalutata durante la scelta del
DBMS analitico. Le soluzioni Oracle e SQL Server, grazie anche alle loro tecniche di in-
dicizzazione e compressione, si collocano tra le migliori per quanto riguarda le prestazioni
per le attivita di query.
CAPITOLO 4
Il caso di studio: Realizzazione di una
soluzione di Business Intelligence per
l’azienda Cadey
4.1 Presentazione dell’azienda
Cadey s.r.l nasce nel 1959 ed e tra le aziende leader nel panorama della cosmetica italiana.
Ha sede a Piacenza e conta 54 dipendenti con un fatturato di 38,8 milioni.
Cadey si vuole affermare come il marchio italiano di riferimento per la cura della persona,
in grado di offrire ai consumatori prodotti innovativi dall’ottimo rapporto qualita prezzo
presenti in tutti i canali distributivi: ipermercati, supermercati e profumerie.
Famiglie di prodotti
• Solari, marchio Bilboa (prodotti di punta dell’azienda).
• Creme per il corpo, marchio Cambia Pelle e Staminaline.
82Il caso di studio: Realizzazione di una soluzione di Business Intelligence per
l’azienda Cadey
• Depilazione, marchio Depilsoap.
• Cura capelli, marchio Bilba e Luminose.
Tipologia di clienti
• Canale GDO.
• Negozi specializzati casa toilette.
• Grossisti.
• Normal trade.
Struttura organizzativa
Figura 4.1: Struttura commerciale dell’azienda Cadey s.r.l.
4.2 Struttura data center Cadey 83
Figura 4.2: Organigramma dell’azienda Cadey s.r.l.
4.2 Struttura data center Cadey
La soluzione tecnologica adottata dall’azienda Cadey che andremo ad illustrare, e stata
scelta poiche in grado di:
• fornire una solida piattaforma iniziale che potra crescere nel tempo senza disperdere
gli investimenti di partenza;
• fornire una soluzione in grado di fornire continuita d’esercizio anche a seguito di
crash di alcune componenti.
Elemento centrale della soluzione proposta e la soluzione di virtualizzazione su piattafor-
ma VMware implementata in questa fase su due nodi.
VMware vSphereTM elimina la proliferazione dei server eseguendo le applicazioni all’in-
terno di macchine virtuali installate su un numero inferiore di server e con un utilizzo
84Il caso di studio: Realizzazione di una soluzione di Business Intelligence per
l’azienda Cadey
piu efficiente delle risorse di rete e storage. Le organizzazioni che utilizzano una tale
soluzione possono conseguire rapporti di consolidamento per singolo server elevatissimi,
grazie a straordinarie funzionalita di gestione della memoria e ottimizzazione dinamica.
La complessita di gestione dell’hardware viene ridotta mediante la virtualizzazione totale
di server, storage e hardware di rete.
VMware vSphereTM aiuta quindi a realizzare una solida infrastruttura protetta, che ga-
rantisce la continuita aziendale anche in presenza di guasti hardware o di indisponibilita
del data center. Grazie a queste sue funzionalita, la scelta di Cadey e stata VMware
vSphere Standard. Essa rappresenta una soluzione di fascia entry-level per il consolida-
mento applicativo di base, allo scopo di ridurre sensibilmente i costi hardware, accelerando
nel contempo la distribuzione delle applicazioni.
Configurazione hardware
Server:
nodi VMware N◦2 PRIMERGY RX300 S6. Caratteristiche tecniche:
• doppio processore quad core;
• 16GB di RAM;
• scheda fibre channel;
• N◦2 hard disk 146GB SAS.
Storage:
Controller a 2 canali FC 4GB - N◦4 hard disk da 450GB SAS 15k (3 hard disk raid 5 +
1 hard disk spare)
Soluzione e strategia di backup:
Sono previsti due livelli di backup, il primo su disco mentre il secondo su nastro.
Sul server e presente l’unita nastro LTO3 per l’esecuzione del secondo livello di copia.
4.3 Struttura del data mart vendite 85
4.3 Struttura del data mart vendite
La soluzione di business intelligence che l’azienda Cadey ha deciso di adottare, consiste
nella suite Oracle Business Intelligence fondata su un Enterprise Data Warehouse realiz-
zato su database Oracle 11g.
Il processo ETL per la costruzione del data warehouse non rientra nelle attivita da me
svolte presso il cliente durante l’esperienza di tirocinio. Tuttavia propongo la struttura
del data mart relativo alle vendite sul quale si basano le attivita di sviluppo del progetto
da me affrontato.
Figura 4.3: Schema concettuale del data mart delle vendite
Nelle prossime sezioni vengono descritti i passi che consentono di presentare i dati all’in-
terno del data mart all’utente finale, in una forma a lui comprensibile.
86Il caso di studio: Realizzazione di una soluzione di Business Intelligence per
l’azienda Cadey
4.4 Costruzione dei metadati
Il repository dei metadati, come anticipato nella sezione 3.2, e un file che ha il compito di
memorizzare i metadati necessari al BI Server per trasformare una query logica, ovvero
una interrogazione che viene costruita dall’utente che non e a conoscenza della struttura
delle sorgenti, nella relativa query fisica da eseguire sui dati sorgente.
Lo strumento che Oracle BI mette a disposizione degli sviluppatori per la costruzione
dei metadati e l’Administration Tool. Con esso e possibile mappare i dati presenti nelle
sorgenti fisiche nei dati di presentazione, utilizzabili dall’utente finale, passando per tre
livelli distinti: livello fisico, livello logico e livello di presentazione.
Di seguito vengono descritte le tre fasi, prendendo come riferimento il repository dei
metadati utilizzato dall’azienda Cadey. Essendo le dimensioni del progetto troppo elevate
per poterle esaminare in modo esaustivo, ho deciso di prendere in esame solo una fact
table e una dimension table ed osservare il passaggio dei dati dalle sorgenti fisiche, fino
alla loro visualizzazione in report utilizzabili dagli utenti business.
4.4.1 Livello fisico
La costruzione di questo livello inizia con l’importazione delle tabelle che andranno a
costituire le sorgenti. Tali sorgenti possono essere eterogenee, tuttavia in questo caso
proverranno dal medesimo data mart. La Figura 4.4 mostra il livello fisico costruito nel
nostro caso di studio.
Il database e l’oggetto collocato piu in alto nel livello fisico e definisce la sorgente dati
alla quale il BI Server dovra inviare le query. Il connection pool definisce le modalita
di collegamento al database, mentre lo schema contiene le tabelle e le colonne dello
schema fisico.
Le tabelle importate sono le seguenti:
• F SPED: fact table relativa alle vendite;
• L CLI: dimension table relativa ai clienti, sulla quale viene eseguita una parziale nor-
malizzazione con le tabelle L GEO NAZIONE, L GEO REGIONE e L GEO PROVINCIA
che contengono rispettivamente i dati relativi alla nazione, regione e provincia del
cliente;
4.4 Costruzione dei metadati 87
• L CLI NAZIONE, L CLI REGIONE e L CLI PROVINCIA: alias per le tabelle
L GEO NAZIONE, L GEO REGIONE e L GEO PROVINCIA rispettivamente.
Verranno utilizzate per riferisi alle tabelle appena elencate.
Figura 4.4: Rappresentazione del livello fisico nell’Administration Tool
Definizione dei vincoli di integrita referenziale
Una volta importate le tabelle, occorre definire i vincoli di foreign key. Nel nostro caso
saranno:
F SPED.DOC CLI DM ID = L CLI.CLI ID
L CLI.CLI PROVINCIA ID = L CLI PROVINCIA.PROVINCIA ID
L CLI PROVINCIA.REGIONE ID = L CLI REGIONE.REGIONE ID
L CLI REGIONE.NAZIONE ID = L CLI NAZIONE.NAZIONE ID
88Il caso di studio: Realizzazione di una soluzione di Business Intelligence per
l’azienda Cadey
Figura 4.5: Rappresentazione dei vincoli di integrita referenziale delle tabelle del livello
fisico
Figura 4.6: Diagramma completo del livello fisico relativo alle vendite
4.4 Costruzione dei metadati 89
4.4.2 Livello logico
E il livello dove gli schemi fisici vengono semplificati e riorganizzati per formare le basi
della vista che l’utente avra dei dati.
La costruzione del livello logico inizia con l’importazione degli oggetti dal livello fisico e
con la definizione delle relazioni tra di essi (Figura 4.7). Infatti, solo grazie a quest’ultimo
passaggio si riescono a definire i ruoli degli oggetti stessi, ovvero quali sono le fact table
e quali le dimension table.
Figura 4.7: Rappresentazione del livello logico e della relazione che lega la dimension
table “ClienteDim” con la fact table “Spedito - Vendite”
Per ogni tabella del livello logico, le source table identificano le relative tabelle sor-
genti nel livello fisico. Si noti che per la dimension table ClienteDim compare la so-
la tabella L CLI come sorgente, mentre vengono omesse le tabelle L CLI NAZIONE,
L CLI REGIONE e L CLI PROVINCIA. Questo perche e possibile mappare una source
table su piu tabelle fisiche, a patto che siano in relazione tra loro nel modello fisico.
90Il caso di studio: Realizzazione di una soluzione di Business Intelligence per
l’azienda Cadey
Per ognuna delle misure e possibile definire una regola di aggregazione. In questo mo-
do si definisce il comportamento che tale misura dovra avere ogni qualvolta si desidera
cambiare il livello di dettaglio con il quale analizzare i dati. Nel nostro caso ogni misura
possiede come regola di aggregazione la somma.
Creazione di nuove colonne nel livello logico
All’interno del livello logico e possibile creare nuove colonne, utilizzando colonne gia
presenti all’interno di una formula. Possono essere utilizzate:
• Colonne logiche: vengono utilizzate colonne appartenenti al livello logico. La regola
di aggregazione della colonna creata viene automaticamente individuata sulla base
delle regole di aggregazione delle colonne logiche utilizzate nella formula;
• Colonne fisiche: vengono utilizzate colonne appartenenti al livello fisico. In questo
caso la regola di aggregazione deve essere specificata manualmente, in quanto le
colonne utilizzate nella formula non ne possiedono una.
La differenza tra le due metodologie risiede nell’ordine con il quale le aggregazioni vengono
eseguite. Nel primo caso infatti saranno effettuate a livello di colonna, mentre nel secondo
a livello di riga.
Creazione delle gerarchie
La creazione di una gerarchia conferisce una organizzazione gerarchica alle colonne logiche
appartenenti ad una dimension table. In questo modo si possono definire i percorsi di
drill-down che l’utente potra effettuare durante la fase di analisi. La struttura di una
gerarchia e gestibile dal solo livello logico. La Figura 4.8 mostra la gerarchia utilizzata
nel nostro caso di studio.
L’introduzione di una gerarchia permette di definire:
• Level-based measures: Sono misure che vengono calcolate ad uno specifico livello
di aggregazione e che per tanto non vengono influenzate dai drill-down su altri livelli;
• Share measures: Sono misure che vengono calcolate facendo il rapporto tra le
normali misure e misure level-based. Vengono utilizzate per calcolare le percentuali.
4.4 Costruzione dei metadati 91
Figura 4.8: Gerarchia relativa alla dimension table ClienteDim
Figura 4.9: Diagramma completo del livello logico relativo alle vendite
92Il caso di studio: Realizzazione di una soluzione di Business Intelligence per
l’azienda Cadey
4.4.3 Livello di presentazione
Rappresenta la vista che ha l’utente dei dati. Ha il compito di semplificare il livello logi-
co. Nel livello di presentazione e infatti possibile nascondere determinate colonne oppure
riorganizzare i dati in cataloghi o cartelle separate. La Figura 4.10 fornisce una rappre-
sentazione del livello di presentazione.
Figura 4.10: Rappresentazione del livello di presentazione nell’Administration Tool
Le presentation table possono essere utilizzate per riorganizzare i dati. Esse possono
contenere colonne logiche provenienti da piu tabelle logiche e risultano essere indipendenti
da queste ultime.
La definizione delle subject area permette, come vedremo piu avanti, la suddivisione in
piu ambiti di analisi negli strumenti di front end.
4.4.4 Validazione del repository
Una volta terminata la costruzione dei tre livelli occorre validare il repository appena
creato. Per essere considerato valido, un repository deve possedere i seguenti requisiti:
4.5 Costruzione della reportistica 93
• Tutte le colonne logiche sono mappate direttamente o indirettamente su una o piu
colonne fisiche;
• Tutte le dimension table del livello logico hanno una chiave logica;
• Tutte le tabelle logiche sono in logical join con almeno un’altra tabella logica;
• Devono essere presenti almeno due tabelle logiche: una fact table ed una dimension
table. Eventualmente possono entrambe essere mappate sulla medesima tabella
fisica.
• Non ci devono essere cicli nelle relazioni definite nel modello logico;
• Esiste almeno una subject area per ogni modello business (si noti che nell’esempio
trattato e presente un solo modello business, quello delle vendite).
Una volta validato il repository e possibile caricarlo all’interno del BI Server attraverso
l’Enterprise Manager.
4.5 Costruzione della reportistica
Mentre la costruzione dei metadati e un compito strettamente riservato agli sviluppatori,
la costruzione della reportistica puo essere fatta anche dagli utenti business.
Oracle BI mette infatti a disposizione una semplice GUI (Figura 4.11) per la creazione
di report e dashboard.
Figura 4.11: Costruzione di un report tramite “Oracle BI Analysis and Reporting”
94Il caso di studio: Realizzazione di una soluzione di Business Intelligence per
l’azienda Cadey
Nella parte sinistra e collocata la subject area. In essa si possono reperire gli oggetti
necessari alla costruzione del report. OBIEE 11g permette la costruzione di analisi con-
tenenti oggetti provenienti da piu subject area.
Nella parte destra, invece, e possibile modellare il report modificando l’ordine e le pro-
prieta delle colonne (in alto), oppure definire opportuni filtri (in basso).
Di seguito una dashboard e un report di tipo grafico, relativi alle vendite analizzate
per famiglia dell’articolo.
Figura 4.12: Dashboard relativa alle vendite analizzate per famiglia dell’articolo
Figura 4.13: Report grafico che descrive la situazione mostrata nella dashboard di
Figura 4.12
4.5 Costruzione della reportistica 95
Conclusioni
La struttura di questo lavoro di tesi rappresenta il percorso seguito durante i mesi di
tirocinio.
Le prime settimane sono state infatti dedicate ad attivita di studio individuale e a corsi
di formazione, che mi hanno portato ad acquisire le nozioni di base dei sistemi di data
warehousing e business intelligence. I primi due capitoli riassumono il percorso formativo
intrapreso.
La seconda parte del tirocinio e stata dedicata allo studio della tecnologia Oracle BI 11g,
al fine di apprendere le caratteristiche tecniche del prodotto, descritte nel terzo capitolo,
e le metodologie di sviluppo di un progetto di business intelligence.
Quindi, solamente dopo aver seguito un percorso di formazione adeguato, sono stato
coinvolto nello sviluppo di una soluzione di business intelligence presso l’azienda Cadey
s.r.l di Piacenza. Durante questa esperienza ho potuto partecipare alle seguenti attivita:
• Installazione della piattaforma di business intelligence;
• Costruzione dei metadati, ovvero il processo di mappatura dei dati fisici del data
mart delle vendite nei dati di presentazione utilizzabili dall’utente;
• Costruzione della reportistica, report e dashboard, in base alle esigenze mostrate
dal cliente.
Il quarto capitolo descrive come sono state affrontate alcune di queste attivita.
L’esperienza di tirocinio mi ha permesso di maturare sotto l’aspetto professionale e di
acquisire conoscenze che considero di fondamentale importanza per il mio futuro.
ELENCO DELLE FIGURE
1.1 Rappresentazione di un processo aziendale . . . . . . . . . . . . . . . . . 3
1.2 Le attivita aziendali secondo Anthony . . . . . . . . . . . . . . . . . . . . 5
1.3 Relazioni tra i sistemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Componenti di un sistema di data warehousing . . . . . . . . . . . . . . 18
2.2 Architettura ad un livello per un sistema di data warehousing . . . . . . 21
2.3 Architettura a due livelli per un sistema di data warehousing . . . . . . . 22
2.4 Architettura a tre livelli per un sistema di data warehousing . . . . . . . 23
2.5 Cubo multidimensionale che modella le vendite in una catena di negozi . 27
2.6 Una possibile gerarchia per la dimensione negozi . . . . . . . . . . . . . . 28
2.7 Semplice schema di fatto delle vendite . . . . . . . . . . . . . . . . . . . 29
2.8 Schema Entity/Relationship delle vendite . . . . . . . . . . . . . . . . . . 29
2.9 Schema di fatto delle vendite arricchito . . . . . . . . . . . . . . . . . . . 30
2.10 Star schema per le vendite . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.11 Snowflake schema per le vendite . . . . . . . . . . . . . . . . . . . . . . . 33
2.12 Rappresentazione del fenomeno di sparsita dei dati . . . . . . . . . . . . 34
2.13 Suddivisione del cubo multidimensionale in chunk . . . . . . . . . . . . . 35
2.14 Rappresentazione del portafoglio applicativo aziendale . . . . . . . . . . . 38
2.15 Piramide della Business Intelligence . . . . . . . . . . . . . . . . . . . . . 39
2.16 Operatori di slice-and-dice . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.17 Operatori di roll-up e drill-down . . . . . . . . . . . . . . . . . . . . . . . 43
98 ELENCO DELLE FIGURE
2.18 Il processo di knowledge discovery . . . . . . . . . . . . . . . . . . . . . . 46
2.19 Fasi di un’analisi di business intelligence . . . . . . . . . . . . . . . . . . 50
3.1 Standardizzazione degli strumenti e successo della BI . . . . . . . . . . . 57
3.2 Architettura di OBIEE 11g . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3 Architettura logica di OBIEE 11g su un singolo host . . . . . . . . . . . 58
3.4 Architettura logica di OBIEE 11g su piu host . . . . . . . . . . . . . . . 59
3.5 Traduzione di una query logica nella relativa query fisica attraverso i 3
livelli del repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6 Architettura del BI Server . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.7 Tipica struttura delle directory di Oracle BI . . . . . . . . . . . . . . . . 65
3.8 Costruzione di un’analisi con BI Analysis and Reporting . . . . . . . . . 67
3.9 Un esempio di dashboard interattiva . . . . . . . . . . . . . . . . . . . . 69
3.10 Un esempio di scorecard . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.11 Costruzione di un report pixel perfect mediante BI Publisher Layout Editor 70
3.12 Creazione di un agente tramite BI Delivers . . . . . . . . . . . . . . . . . 71
3.13 Suddivisione dei tre livelli del repository nell’Administration Tool . . . . 73
3.14 Quadrante magico di Gartner relativo alle piattaforme di Business Intelli-
gence del mese di gennaio 2011 . . . . . . . . . . . . . . . . . . . . . . . 75
3.15 Confronto delle posizioni occupate dai maggiori vendor di piattaforme di
Business Intelligence nel quadrante magico di Gartner nel 2006 e nel 2011 78
4.1 Struttura commerciale dell’azienda Cadey s.r.l. . . . . . . . . . . . . . . . 82
4.2 Organigramma dell’azienda Cadey s.r.l. . . . . . . . . . . . . . . . . . . . 83
4.3 Schema concettuale del data mart delle vendite . . . . . . . . . . . . . . 85
4.4 Rappresentazione del livello fisico nell’Administration Tool . . . . . . . . 87
4.5 Rappresentazione dei vincoli di integrita referenziale delle tabelle del livello
fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.6 Diagramma completo del livello fisico relativo alle vendite . . . . . . . . . 88
4.7 Rappresentazione del livello logico nell’Administration Tool . . . . . . . . 89
4.8 Rappresentazione di una gerarchia nell’Administration Tool . . . . . . . 91
4.9 Diagramma completo del livello logico relativo alle vendite . . . . . . . . 91
4.10 Rappresentazione del livello di presentazione nell’Administration Tool . . 92
4.11 Costruzione di un report tramite “Oracle BI Analysis and Reporting” . . 93
ELENCO DELLE FIGURE 99
4.12 Dashboard relativa alle vendite analizzate per famiglia dell’articolo . . . . 94
4.13 Un esempio di report grafico . . . . . . . . . . . . . . . . . . . . . . . . . 94
ELENCO DELLE TABELLE
1.1 Caratteristiche dei diversi tipi di sistemi informativi. . . . . . . . . . . . 10
1.2 Differenze tra sistemi OLTP e sistemi OLAP. . . . . . . . . . . . . . . . . 14
3.1 Matrice business case per la BI. . . . . . . . . . . . . . . . . . . . . . . . 56
BIBLIOGRAFIA
[ACPT06] Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, and Riccardo Torlone. Basi
di dati - modelli e linguaggi di interrogazione. McGraw-Hill, second edition,
2006.
[Des07] Giulio Destri. Introduzione ai sistemi informativi aziendali. Monte Universita
Parma, 2007.
[Gar11] Gartner. Magic quadrant for business intelligence platform, January 2011.
[GR06] Matteo Golfarelli and Stefano Rizzi. Data Warehouse - teoria e pratica della
progettazione. McGraw-Hill, second edition, 2006.
[KRT+07] Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy, and Bob
Becker. The Datas Warehouse Lifecycle Toolkit. Wiley Publishing, second
edition, 2007.
[LL06] Kenneth Laudon and Jane Laudon. Management dei sistemi informativi.
Pearson Prentice Hall, second edition, 2006.
[Oraa] Oracle. Company profile. http://www.oracle.com/global/it/corporate/
company_profile.html.
[Orab] Oracle. Oracle business intelligence enterprise edition 11g - installation guide.
[Orac] Oracle. Oracle business intelligence enterprise edition 11g - metadata
repository builder’s guide.
104 BIBLIOGRAFIA
[Orad] Oracle. Oracle business intelligence enterprise edition 11g - system
administrator’s guide.
[Orae] Oracle. Oracle fusion middleware 11g - certification matrix.
http://www.oracle.com/technetwork/middleware/downloads/
fmw-11gr1certmatrix.xls.
[Ora09] Oracle. Building a better business case for business intelligence, 2009.
[Ora11a] Oracle. Oracle business intelligence foundation suite - technical overview.
http://www.oracle.com/us/obiee-11g-technical-overview-078853.
pdf, January 2011.
[Ora11b] Oracle. Oracle fusion middleware 11g - system requirements and specifications,
January 2011.
[Pas04] Paolo Pasini. I sistemi informativi direzionali - le tecnologie dell’informazione
a supporto dei processi manageriali d’azienda. Egea, 2004.
[PM05] Maurizio Pighin and Anna Marzona. Sistemi informativi aziendali - struttura
e applicazioni. Pearson Prentice Hall, 2005.
[TRS03] Marco Tagliavini, Aurelio Ravarini, and Donatella Sciuto. Sistemi per la
gestione dell’informazione. Apogeo, 2003.
[Ver06] Carlo Vercellis. Business Intelligence - modelli matematici e sistemi per le
decisioni. McGraw-Hill, 2006.