Business Intelligence: un caso di studio nel settore

Transcription

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 aziendale 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, Andrea 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 lavoro e per i suggerimenti che ha saputo darmi.
Infine un grazie a tutti i pagliacci del dipartimento: Fede Ferretti, Fede Bacchi, Gando, 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 professionisti 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 verticalizzate 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 & Beverage. 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 bisogni 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
info@sinfo-one.it - www.sinfo-one.it
ix
Sommario
L’aumento esponenziale del volume dei dati operazionali ha reso il calcolatore l’unico supporto 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 volta 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
2.1
2.2
15
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
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
Ciclo delle analisi di Business Intelligence . . . . . . . . . . . . . .
50
2.3.3
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
79
Prodotti open source . . . . . . . . . . . . . . . . . . . . . . . . .
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
Costruzione della reportistica . . . . . . . . . . . . . . . . . . . . . . . .
93
4.5
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’ambiente.
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 maggior frequenza per non rischiare di perdere la propria competitività. In questo contesto,
le tecnologie dell’informazione e della comunicazione (ICT) stanno contribuendo a modificare 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 dell’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
• 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 adottando 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 migliorare 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
1.1
3
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) realizzano 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 modellazione 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 funzionamento dell’intera azienda come una successione di processi. I processi sono suddivisi
in: [Des07]
4
• 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 ulteriormente suddivisi tra processi primari, che sono direttamente legati alla produzione 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 dell’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’azienda nei confronti del mercato e della concorrenza;
• Attività tattiche: traducono gli obiettivi strategici in obiettivi economici, definendo 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 richiedono 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
• 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 scomposta 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 cambiamenti 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 dovremo 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 principale domanda a cui devono rispondere questi sistemi è: “Le cose funzionano bene?”. In
genere i sistemi a livello manageriale forniscono report periodici piuttosto che informazioni istantanee sulle operazioni.
I sistemi informativi operativi supportano i manager per la registrazione delle attività 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 attività 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 documentazione relativa ai dipendenti e delle spedizioni.
I sistemi di elaborazione delle transazioni sono talvolta cosı̀ importanti per un’azienda
8
che un guasto di qualche ora può sancire la sua fine e talvolta anche di altre aziende ad essa 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 esclusivamente 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 cambiamento 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 integrazione 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
Tipo di sistema
Informazioni di input
Elaborazioni svolte
Informazioni di output
Utenti
ESS
Dati aggregati, esterni e
Grafici, simulazioni; inte-
Proiezioni; risposte alle in-
Senior manager
interni
rattività
terrogazioni
Bassi volumi di dati o grossi
Interattività;
database ottimizzati per l’a-
analisi
DSS
simulazioni
nalisi dei dati; modelli ana-
Report speciali; analisi del-
Professionisti; manager di
le decisioni; risposte alle
staff
interrogazioni
litici e strumenti di analisi
dei dati
MIS
TPS
Riepilogo dei dati sulle tran-
Report di routine, model-
Riepiloghi e report delle
sazioni, alti volumi di dati,
li semplici; analisi di basso
eccezioni
semplici modelli
livello
Transazioni; eventi
Ordinamento,
zione
elenchi,
produunioni
e
Middle manager
Report dettagliati, liste; rie-
Personale operativo, super-
piloghi
visori
aggiornamenti
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 operazionali 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 esecuzione. 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 integrità 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 risultato 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 commettere 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
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 situazione aziendale da un istante zero fino al tempo attuale.
I processi decisionali non sono standardizzabili né riconducibili a procedure automatizzate, 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 organizzate dai dati.
L’On-Line Analytical Processing (OLAP) è l’insieme dei sottosistemi informativi aziendali pensati per l’analisi interattiva dei dati, ottimizzati per garantire la massima efficienza 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
1.3.3
13
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 numerosi limiti.
In particolare, il sistema operazionale, strutturato sul concetto di transazione e di processo, 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 occupazione 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
Finalità
OLTP
OLAP
Supporto all’operatività
Supporto al processo decisionale
Utenti
Molti, livello operativo
Pochi, livello direzionale
Dati
Elementari, numerici e alfanu-
Sintetici, solitamente numerici
merici
Modalità di uti-
Guidata, per processi e stati
Interrogazioni ad hoc
lizzo
successivi
Quantità di da-
Bassa: centinaia di record per
Alta: milioni di record per ogni
ti per operazione
ogni transazione
query
Qualità
In termini di integrità
In termini di consistenza
Orientamento
Per processo/applicazione
Per soggetto
Frequenza di ag-
Continua, tramite azioni
Sporadica,
elementare
giornamento
Copertura tem-
tramite funzioni
esplicite
Dati correnti
Storica
Per accessi in lettura e scrittu-
Per accessi in sola lettura su
ra su una porzione della base
tutta la base di dati
porale
Ottimizzazione
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 warehousing 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 esigenze 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 frustrazione 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
“Come è possibile che persone che svolgono lo stesso ruolo presentino risultati sostanzialmente 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, inconsistenti tra loro.
“Vogliamo selezionare, raggruppare e manipolare i dati in ogni modo possibile! ”. Il processo decisionale è difficilmente pianificabile a priori. L’utente finale vorrebbe disporre
di uno strumento sufficientemente amichevole e flessibile da consentirgli di condurre l’analisi 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 warehousing, 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 informativo 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 operazionali sono organizzati intorno alle differenti applicazioni del dominio aziendale.
La condizione di integrità e consistenza è molto importante, in quanto il DW si appoggia 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’inserimento 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 caratteristica 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
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
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 interrogazione 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 disponibili 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 appositi 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
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 strutturate 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 ridimensionata 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 minimizzare 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.
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 transazionale. 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 architettura 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
Figura 2.3: Architettura a due livelli per un sistema di data warehousing
mancanti, integrati per fondere sorgenti eterogenee secondo uno schema comune, mediante 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 sorgenti, 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 flessibile 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.
23
Un vantaggio di questa architettura, mostrata in Figura 2.4, è che il livello dei dati riconciliati 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 integrazione 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
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 alimentare il data warehouse. Le procedure di popolamento del data warehouse possono
raggiungere elevati livelli di complessità, in relazione alle discrepanze esistenti tra le sorgenti, 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 complessità 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 dall’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.
25
L’estrazione incrementale generalmente si basa sui log mantenuti dal DBMS transazionale. 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 esempio, 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
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 operazionali. 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 rappresentazione 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 selezionare 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, descritti 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 ipercubo.
28
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 prescinde 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 visione 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
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 concettuale 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
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/Relationship 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 dimensionali e i cui archi modellano associazioni molti-a-uno tra coppie di attribuiti dimensionali. 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.2
31
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 multidimensionali 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
Uno schema a stella è composto da:
• Un insieme di tabelle, chiamate tabelle delle dimensioni (dimension table). Ciascuna 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 s p o n s a b i l e , SUM(FT . q u a n t i t a ) , SUM(FT . i n c a s s o )
2
FROM Vendite FT, Pr od ott o DT1, Negozio DT2, Data DT3
3
WHERE FT . p r o d o t t o = DT1 . p r o d o t t o I D AND
4
FT . n e g o z i o = DT2 . n e g o z i o I D AND
5
FT . data = DT3 . data ID AND
6
DT1 . c a t e g o r i a = ’ s u r g e l a t i ’ AND
7
DT2 . r e g i o n e = ’ E m i l i a Romagna ’ AND
8
DT3 . anno = 2010
9
GROUP BY DT2 . r e s p o n s a b i l e
Si noti come le dimension table violino la terza forma normale, ovvero contengono attributi 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 relazionale; lo snowflake schema (Figura 2.11) lo permette in quanto caratterizzato da una
parziale normalizzazione delle dimension table.
33
Uno schema snowflake è ottenibile da uno schema a stella scomponendo una o più dimension 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 potrebbe 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 estremamente raffinati ed ottimizzati.
Figura 2.11: Snowflake schema ottenuto mediante una parziale normalizzazione dello star
schema di Figura 2.10
34
2.2.2.2
I sistemi MOLAP
Nell’approccio MOLAP il data warehouse memorizza i dati usando strutture intrinsecamente 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 coordinate 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 multidimensionale 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 effettivamente 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.
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
• Tipo 1 : Sovrascrittura (Overwrite). È una tecnica che prevede la semplice sovrascrittura 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 standard 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 basterà 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 supporto 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 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.
L’insieme delle applicazioni IT in un’azienda viene detto portafoglio applicativo (Figura 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
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 dati 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.
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 mutevoli determinate dai cambiamenti dell’ambiente economico. Nelle situazioni reali, i
processi decisionali risultano troppo complessi e dinamici per essere affrontati con efficacia 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̀ attendibili, 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
Decisioni tempestive. Le imprese operano in contesti economici caratterizzati da un elevato 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 rappresenta 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 facilitare 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 quest’ultimo aspetto solitamente l’interrogazione viene definita a priori secondo quelle che
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’interrogazione 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 presentazione dei rapporti, ma anche dalla flessibilità dei meccanismi per la loro distribuzione.
Un rapporto infatti può essere sia generato manualmente dall’utente che automaticamente 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 contenute 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, definiamo ora le operazioni che vengono utilizzate durante l’analisi multidimensionale, le
cosiddette operazioni OLAP. Come prima cosa osserviamo quegli operatori che permettono 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
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 (letteralmente, 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 prodotto 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 potrebbe 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
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 trivellare. 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 visualizzare 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
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 multidimensionale, 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 multidimensionale, 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 eventuali 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 ignorate 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.2.1
45
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 permetta 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 algoritmi 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 determinata 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
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 temporale e si propongono di predire il valore della variabile target per uno o più periodi futuri.
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 percentuale 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 verificarsi 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 escono dal nodo rappresentano l’esito del confronto. Le decisioni finali sono contenute nelle
foglie.
48
2.3.2.2
Analisi what-if
Assumendo un particolare insieme di condizioni iniziali l’analisi what-if consente di formulare 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 analisi 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 comportamento 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.2.3
49
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 business 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 misurare 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 disponibili 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 specifiche, il dettaglio delle informazioni che dovranno avere a disposizione è di conseguenza 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
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 report 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 risentono 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
51
modificare con flessibilità e tempestività le sue ipotesi. Osserviamo quindi come le metodologie 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 trasformare le informazioni precedentemente identificate in conoscenza. Questo processo di
trasformazione può avvenire mediante l’intuizione e l’esperienza del decision maker oppure 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-azionerevisione, 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 California, 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, commercializza 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, Peoplesoft 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
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, tuttavia 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 focalizzeranno 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 informazioni);
• 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
Efficienza
Efficacia
Cambiamento
Strategia di
Eccellenza
Eccellenza
Nuovi modelli
business
operativa
gestionale
di business
Processi
Riduzione dei
Creazione di un’
Nuovi processi di
costi,
organizzazione
business, integrazione
che sia moderna,
della catena per la
qualità
agile ed allineata
crezione del valore
Il BICC
Il BICC crea
BICC esteso,
supporta gli stru-
e condivide cono-
creazione e condivisio-
menti usati
scenza all’interno
ne della conoscenza al-
dell’organizzazio-
l’interno di tutta la
ne
catena della creazione
maggiori
prestazioni,
Uso e governance
più
del valore
Strumenti di BI e
Standardizzazione Aggiunta di nuo-
Converge con la ge-
applicazioni di ge-
degli strumenti
stione dei processi di
ve funzionalità
stione delle presta-
business, le applica-
zioni
zioni business ed il
middleware
Dati ed infrastrut-
Concentrarsi sul
Fare il punto sul-
Implementazione
tura
TCO
la flessibilità
di
un’architettura
orientata
(SOA)
Tabella 3.1: Matrice business case per la BI.
ai
servizi
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 Enterprise 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 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 insieme 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
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 componenti 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 comprese 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
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 rappresentare 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 Windows 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 mostra 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 memorizzato 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
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, Office 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 Intelligence.
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 impostazioni 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 (Windows 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 32bit. È tuttavia possibile scaricare ed installare i soli client tools, facendoli poi collegare
66
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 visualizzazione 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 potrà 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
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 dashboard costituisce un fondamentale metodo per la condivisione delle informazioni;
• Personalizzazione: ogni cruscotto può essere personalizzato in modo tale da visualizzare 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 distribuite 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̀ dettagliate, 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.
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̀ destinate 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
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:
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 Framework che saranno brevemente descritti di seguito.
BI Delivers
BI Delivers, attraverso la creazione di Agenti, offre la possibilità di monitorare proattivamente 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
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 consente la visualizzazione in modalità disconnessa, da parte di chiunque disponga del software
Briefing Book reader. Offrono un metodo per creare istantanee delle dashboard, visualizzarle 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 dashboard 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
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 trascinamento 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 strutturare 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 cercare 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 oggetti di business vengano influenzati dall’eventuale eliminazione dal database di una
specifica colonna fisica;
• Esportazione/importazione: il tool di amministrazione offre funzionalità di esportazione 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 presentazione, colonne del modello di business loro corrispondenti, formule e sorgenti
fisiche mappate;
• Collaborazione multi-utente per l’amministrazione: l’Administration Tool può essere 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
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 intelligence.
Oracle
Pro: la piattaforma OBIEE è considerata lo standard di riferimento per la BI nella maggior 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 numero 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 database 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 implementazioni 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 eccellente 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 flessibili, presenta una ripida curva di apprendimento. La creazione di dashboard e report ad-hoc non è particolarmente user-frendly per gli utenti business. Inoltre, i clienti
Microstrategy indicano come limitazione più grande il costo del software.
77
Microsoft
Pro: Microsoft ha sempre investito nella costruzione e miglioramento delle sue funzionalità 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, soprattutto 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’informazione 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 prodotto 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
di analisi costituisce uno dei maggiori punti di forza del prodotto.
Contro: Uno dei maggiori punti deboli del prodotto IBM è dato dalle performance, anche 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 subito 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
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. Osserviamo 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 attualmente 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
Nonostante le tecnologie open source per la business intelligence non siano direttamente 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 preminenza 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, Snaplogic, 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 sviluppato 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. Naturalmente 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 indicizzazione 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.
Il caso di studio: Realizzazione di una soluzione di Business Intelligence per
82
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 piattaforma VMware implementata in questa fase su due nodi.
VMware vSphereTM elimina la proliferazione dei server eseguendo le applicazioni all’interno di macchine virtuali installate su un numero inferiore di server e con un utilizzo
84
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 garantisce 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 consolidamento 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
4.3
85
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 realizzato 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’interno del data mart all’utente finale, in una forma a lui comprensibile.
86
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 normalizzazione 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
88
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.2
89
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 sorgenti nel livello fisico. Si noti che per la dimension table ClienteDim compare la sola 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.
90
l’azienda Cadey
Per ognuna delle misure è possibile definire una regola di aggregazione. In questo modo 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.
Figura 4.8: Gerarchia relativa alla dimension table ClienteDim
Figura 4.9: Diagramma completo del livello logico relativo alle vendite
91
92
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 logico. 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 rappresentazione 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”
94
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 contenenti oggetti provenienti da più subject area.
Nella parte destra, invece, è possibile modellare il report modificando l’ordine e le proprietà 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 Intelligence 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
[Orad]
BIBLIOGRAFIA
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.

Business Intelligence: un caso di studio nel settore

Transcription

Similar documents

Company Profile

Oracle Database Security

Konsep Sistem Informasi

Documento PDF - Università degli Studi di Padova

Untitled - Florida Federation

Diagnostica psicologica 8

buletin 2 2012_compress - Jabatan Kimia Malaysia

from sicurezzaterrorismosocieta.it

Sicurezza, Terrorismo e Società