Business Intelligence: un caso di studio nel settore cosmetico · 2017-01-05 · Il termine...

UNIVERSITA DEGLI STUDI DI PARMA

FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI

Corso di Laurea in Informatica

Tesi di Laurea Triennale

Business Intelligence:un caso di studio nel settore

cosmetico

Candidato:

Federico Fontana

Relatore: Correlatore:

Prof. Giulio Destri Dott. Fabio Morsiani

Anno Accademico 2009/2010

iii

A Elena, che mi e stata vicino

durante questi anni di studio.

v

Ringraziamenti

Desidero innanzitutto ringraziare la mia famiglia, Anna, Daniele, Francesco e Veronica

per avermi sempre sostenuto durante il mio percorso di studio.

Ringrazio l’azienda Sinfo-One s.p.a. per avermi permesso di effettuare lo stage azien-

dale su cui si basa questo lavoro di tesi.

Un particolare ringraziamento al Dott. Fabio Morsiani che e stato il mio tutor aziendale

e grazie al quale ho conosciuto il mondo della Business Intelligence.

Desidero inoltre ringraziare Leonardo Barbato, Sara Cangini, Emanuele Marchesi, An-

drea Messetti, Sara Sacco e Antonio Viscomi per il supporto e la formazione aziendale.

Ringrazio il Prof. Giulio Destri per il tempo dedicatomi durante questi mesi di lavo-

ro e per i suggerimenti che ha saputo darmi.

Infine un grazie a tutti i pagliacci del dipartimento: Fede Ferretti, Fede Bacchi, Gan-

do, Leo, Matte, Marti, Paolo, Ali, Tocci, Ila, Jessica, Bea, Ponz e, perche no, anche il

Disa.

vii

Presentazione dell’azienda

Sinfo One S.p.A. nasce il 1◦ settembre 2007, dalla Divisione Industria di Sinfo Pragma

e si rivolge, in particolare, alle medie aziende italiane fornendo soluzioni ERP estese,

consulenza direzionale, organizzativa, di processo e tecnologica nonche servizi di system

integration.

Flessibilita, continui investimenti in ricerca e formazione e attenzione alle esigenze dei

clienti costituiscono le basi del suo progetto di sviluppo.

L’offerta ERP e basata sulla piattaforma proprietaria Si Fides e sulla piattaforma Oracle

JD Edwards Enterprise One che Sinfo One completa con il proprio verticale per il Food

& Beverage.

Sinfo One opera su tutto il territorio nazionale attraverso un team di oltre 100 profes-

sionisti con esperienze nei diversi settori di mercato e profonde competenze sui relativi

processi specifici.

Grazie alla specifica conoscenza della piattaforma Oracle JDEdwards ed alle competenze

ed esperienze dei propri team di professionisti e in grado di offrire soluzioni verticalizza-

te e integrate a Enterprise Content Managemet, Enterprise Performance Management e

Business Intelligence.

Sinfo One e Oracle

Sinfo One e Platinum Partner di Oracle e Oracle Accelerate Partner per il Food & Beve-

rage. Si e inoltre aggiudicata l’edizione 2010 degli Oracle Partner Specialization Awards

per la regione Europa, Medio Oriente e Africa. Un grande successo per l’azienda che ha

cosı superato la concorrenza di altre 87 societa provenienti da 22 Paesi, tutte candidate

alla conquista del riconoscimento.

viii

Esperienza e competenza

I professionisti Sinfo One hanno competenze estese e specializzate, sono attenti ai biso-

gni dei clienti e abituati a lavorare con obiettivi ambiziosi. Particolare attenzione, con

divisioni e laboratori di ricerca (Isi Lab) dedicati, e data a tematiche di ECM, EPM, BI

e SCM.

Sul fronte del Supply Chain Planning il team di esperti Sinfo One ha messo a punto

una metodologia proprietaria: Step (Sistemi Tecnologici di Pianificazione) che nasce da

know-how, esperienza, efficienza e selezione delle migliori tecnologie.

Sinfo One numeri

Sinfo One ha chiuso il 2010 con un fatturato di 9,5 milioni (nel 2009 il fatturato e stato

di 9 milioni di euro), risultato buono se si tiene conto della particolare situazione di crisi

che attraversa l’economia mondiale.

Il budget 2011 prevede un fatturato di 10,5 milioni e i dati dei primi mesi sono in linea

con il budget.

Sinfo One SPA: Via Benedetta 77/a - 43122 Parma - Tel. 0521.9371, Fax 0521.775824

[email protected] - www.sinfo-one.it

ix

Sommario

L’aumento esponenziale del volume dei dati operazionali ha reso il calcolatore l’unico sup-

porto adatto al processo decisionale, inoltre l’utilizzo massiccio di tecniche di analisi dei

dati aziendali ha reso il sistema informativo un elemento strategico per la realizzazione

del business. Per questi motivi il ruolo dell’informatica e passato da passivo strumento

per la registrazione delle operazioni, a fattore decisivo per l’individuazione di elementi

critici dell’organizzazione e di potenziali aree di business.

Il termine Business Intelligence (BI) venne introdotto nel 1989 da Howard Dresner, per

indicare un insieme di strumenti e procedure che consentono a un’azienda di trasformare i

propri dati di business in informazioni utili al processo decisionale, da rendere disponibili

alla persona giusta e nel formato idoneo. Le informazioni ottenute sono utilizzate dai

decisori aziendali (decision maker) per definire e supportare le strategie di business.

Lo strumento principe per la BI e stato fino a oggi il data warehouse (DW), al quale

vanno riconosciuti meriti come la capacita di gestire serie storiche dei dati o di effettuare

analisi multidimensionali, basandosi su un modello semplice e che puo essere facilmente

assimilato dai manager. Caratteristiche come queste hanno facilitato l’ampia diffusione

dei sistemi di data warehousing e hanno favorito la maturazione degli utenti che, una vol-

ta sfruttate appieno le sue potenzialita, cominciano a percepirne i limiti e di conseguenza

richiedono nuove soluzioni in grado di soddisfare l’accresciuta richiesta di informazioni.

In particolare sorge la necessita di soluzioni che consentano analisi su dati provenienti da

sorgenti informative eterogenee, con aggiornamenti piu rapidi rispetto a quelli del DW,

che difficilmente hanno una periodicita inferiore al giorno, e che consentano ai decion

maker la possibilita di “prevedere il futuro”.

Il data mining, le analisi what-if e le attivita di Business Performance Management

(BPM), sono alcune delle tecniche che vengono utilizzate per soddisfare i limiti che i

sistemi di data warehousing presentano.

La tecnologia Oracle BI 11g fornisce una gamma completa di soluzioni per la business

intelligence. Tuttavia nel caso di studio realizzato utilizzeremo le sole funzionalita di

analisi su dati provenienti da un data warehouse.

INDICE

1 I dati e l’azienda 1

1.1 Processi e catena del valore . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 La catena del valore di Porter . . . . . . . . . . . . . . . . . . . . 3

1.1.2 La piramide di Anthony . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 I principali tipi di sistemi usati nelle aziende . . . . . . . . . . . . . . . . 6

1.3 I DBMS ed il loro ruolo . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 DBMS transazionali (OLTP) . . . . . . . . . . . . . . . . . . . . . 10

1.3.2 DBMS per l’analisi (OLAP) . . . . . . . . . . . . . . . . . . . . . 12

1.3.3 Perche e necessario distinguere . . . . . . . . . . . . . . . . . . . . 13

2 Introduzione alla Business Intelligence 15

2.1 Data warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Componenti di un data warehouse . . . . . . . . . . . . . . . . . . 18

2.1.2 Architetture per il data warehousing . . . . . . . . . . . . . . . . 20

2.1.3 Gli strumenti ETL . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Il modello multidimensionale . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.1 Modellazione concettuale: il Dimensional Fact Model . . . . . . . 28

2.2.2 Modellazione logica . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.2.1 I sistemi ROLAP . . . . . . . . . . . . . . . . . . . . . . 31

2.2.2.2 I sistemi MOLAP . . . . . . . . . . . . . . . . . . . . . . 34

2.2.2.3 Slowly Changing Dimensions (SCD) . . . . . . . . . . . 35

xii INDICE

2.3 La Business Intelligence (BI) . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3.1 Accedere al data warehouse . . . . . . . . . . . . . . . . . . . . . 40

2.3.2 Business Intelligence: oltre il data warehouse . . . . . . . . . . . . 44

2.3.2.1 Data Mining . . . . . . . . . . . . . . . . . . . . . . . . 45

2.3.2.2 Analisi what-if . . . . . . . . . . . . . . . . . . . . . . . 48

2.3.2.3 Business Performance Management (BPM) . . . . . . . 49

2.3.3 Ciclo delle analisi di Business Intelligence . . . . . . . . . . . . . . 50

3 La tecnologia Oracle BI 11g 53

3.1 Oracle e la business intelligence . . . . . . . . . . . . . . . . . . . . . . . 54

3.2 Architettura logica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.3 Installazione del prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.4 Componenti di front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.4.1 Analisi e reportistica . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.4.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.4.3 Scorecard e Strategy Management . . . . . . . . . . . . . . . . . . 69

3.4.4 BI Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.4.5 Actionable Intelligence . . . . . . . . . . . . . . . . . . . . . . . . 70

3.4.6 BI Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.5 L’Administration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.6 Comparazione con gli altri competitor . . . . . . . . . . . . . . . . . . . . 75

3.6.1 Prodotti open source . . . . . . . . . . . . . . . . . . . . . . . . . 79

4 Il caso di studio: Realizzazione di una soluzione di Business Intelligence

per l’azienda Cadey 81

4.1 Presentazione dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.2 Struttura data center Cadey . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.3 Struttura del data mart vendite . . . . . . . . . . . . . . . . . . . . . . . 85

4.4 Costruzione dei metadati . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.4.1 Livello fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.4.2 Livello logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.4.3 Livello di presentazione . . . . . . . . . . . . . . . . . . . . . . . . 92

4.4.4 Validazione del repository . . . . . . . . . . . . . . . . . . . . . . 92

4.5 Costruzione della reportistica . . . . . . . . . . . . . . . . . . . . . . . . 93

Conclusioni 95

CAPITOLO 1

I dati e l’azienda

Un’azienda e una struttura sociale stabile e formale che trae risorse dall’ambiente e le

elabora per produrre un risultato. Il capitale e la forza lavoro sono i principali fattori di

produzione forniti dall’ambiente. L’azienda trasforma questi input in prodotti e servizi

tramite la funzione di produzione. I prodotti e i servizi vengono poi consumati dall’am-

biente.

Molte aziende operano in un contesto complesso ed in continua trasformazione: le nuove

opportunita che si vengono a creare devono essere valutate rapidamente con sempre mag-

gior frequenza per non rischiare di perdere la propria competitivita. In questo contesto,

le tecnologie dell’informazione e della comunicazione (ICT) stanno contribuendo a modi-

ficare il modo di lavorare e di vivere dell’azienda, attraverso nuove e sofisticate soluzioni

di elaborazione e trasmissione dell’informazione. La disponibilita, a costi sempre minori,

di tali soluzioni sta provocando significativi cambiamenti soprattutto per quelle attivita,

sempre piu numerose, che comportano gestione di informazione.

La costruzione dell’informazione ed il suo uso entro l’azienda, a partire da dati “grezzi”

di ingresso, puo avvenire attraverso quattro stadi successivi qui di seguito riportati:

• Dati: sono l’insieme di fatti, il risultato di una misurazione, la materia prima del-

l’informazione in relazione agli oggetti del mondo reale. Non possiedono significato

al di la della loro esistenza. Possono essere scoperti, ricercati, raccolti e prodotti.

2 I dati e l’azienda

• Informazione: l’informazione conferisce un significato ai dati, grazie al fatto che li

pone in una relazione reciproca e li organizza secondo dei modelli. Per trasformare i

dati in utili informazioni, un’impresa deve impegnare risorse per organizzare i dati

in categorie di comprensione, come rapporti relativi ai totali di vendita mensili,

giornalieri, regionali o per negozio.

• Conoscenza: la conoscenza e informazione rielaborata ed applicata. E un evento

cognitivo e persino fisiologico che ha luogo nella mente delle persone, ma allo stesso

tempo viene conservato in librerie e registrazioni, condiviso, ad esempio, per mezzo

di conferenze, e conservato dalle aziende sotto forma di processi gestionali codificati

e documentati e know-how dei dipendenti. La conoscenza presente nella mente dei

dipendenti e che non sia documentata prende il nome di conoscenza tacita, mentre

quella documentata viene definita conoscenza esplicita.

• Saggezza: la saggezza e l’esperienza collettiva ed individuale dell’applicazione della

conoscenza alla soluzione di problemi. Essa implica il dove, come e quando applicare

la conoscenza. Non e possibile creare la saggezza allo stesso modo di come vengono

creati i dati e le informazioni, e non e possibile condividerla con gli altri, come

invece avviene per la conoscenza.

Per l’impresa la conoscenza e un tipo di bene diverso, per esempio, dagli edifici o dai beni

finanziari; inoltre la conoscenza e un fenomeno complesso e il processo di gestione che

la riguarda ha molti aspetti. Possiamo inoltre riconoscere che il nucleo delle competenze

basate sulla conoscenza di un’impresa, ossia le due o tre cose che un’azienda fa meglio,

sono beni organizzativi fondamentali. Sapere come fare le cose in modo efficiente adot-

tando soluzioni che le altre organizzazioni non possono riprodurre e una fonte primaria

di profitto e di vantaggio competitivo che i concorrenti non possono facilmente acquistare

sul mercato.

La collaborazione e la comunicazione con professionisti ed esperti, la creazione di nuova

conoscenza, l’agevolazione dell’accesso alla conoscenza e l’uso di quest’ultima per miglio-

rare i processi gestionali e direzionali sono diventati elementi vitali per l’innovazione e la

sopravvivenza delle imprese [LL06].

1.1 Processi e catena del valore 3

1.1 Processi e catena del valore

Con il termine “processo” si fa riferimento a un insieme di attivita attraverso le quali

le risorse di un’impresa o, piu in generale, di un’organizzazione (individui e mezzi) rea-

lizzano la mission organizzativa trasformando input (materiali o immateriali) in output,

ossia in prodotti/servizi che trasferiscono valore al fruitore dei prodotti/servizi stessi. Il

concetto di valore e fondamentale, in quanto uno degli scopi fondamentali della model-

lazione tramite processi delle attivita aziendali e proprio un ausilio alla misurazione del

valore prodotto. In ciascun processo vengono tipicamente coinvolte competenze e unita

organizzative diverse che rispondono al responsabile del processo (process owner), figura

alla quale sono stati affidati la responsabilita e il coordinamento del processo stesso.

Figura 1.1: Rappresentazione di un processo aziendale

1.1.1 La catena del valore di Porter

In ogni organizzazione e possibile individuare alcuni processi fondamentali. La catena

del valore di Porter rappresenta una classificazione dei processi, modellizzando il funzio-

namento dell’intera azienda come una successione di processi. I processi sono suddivisi

in: [Des07]


• Buy side: come acquisti/approvvigionamenti, ossia processi il cui output proviene

dai fornitori;

• Inside: ossia aventi sia input sia output interni all’azienda, che possono essere ul-

teriormente suddivisi tra processi primari, che sono direttamente legati alla produ-

zione del valore del core business dell’azienda e processi ausiliari, che non generano

direttamente un valore, ma producono quei servizi senza i quali l’organizzazione

non potrebbe operare;

• Sell side: il cui output e rivolto direttamente ai clienti esterni dell’azienda.

1.1.2 La piramide di Anthony

La piramide di Anthony, illustrata in Figura 1.2 e una modalita di rappresentazione del-

l’organizzazione, introdotta con l’obiettivo specifico di classificare le attivita tipicamente

svolte nell’organizzazione stessa e identificare il ruolo dei sistemi informatici a supporto

di tali attivita e la progettazione del loro sviluppo. Nonostante l’inarrestabile e radicale

innovazione delle ICT questo modello ha sostanzialmente mantenuto intatta la validita

della sua formulazione originaria nel corso del tempo.

Il modello di Anthony, sviluppato nel 1965, distingue tre diverse tipologie di attivita,

ognuna delle quali interagisce con quella adiacente realizzando cicli di pianificazione e

controllo attraverso i quali verificare risultati e decidere azioni correttive. Tali attivita

sono: [PM05]

• Attivita strategiche: concorrono all’identificazione degli obiettivi primari dell’a-

zienda nei confronti del mercato e della concorrenza;

• Attivita tattiche: traducono gli obiettivi strategici in obiettivi economici, defi-

nendo le previsioni a medio termine e verificandone periodicamente l’attuazione;

• Attivita operative: attuano i piani definiti occupandosi dello svolgimento delle

attivita correnti.

1.1 Processi e catena del valore 5

Figura 1.2: Le attivita aziendali secondo Anthony

Una tale classificazione e dovuta al fatto che attivita appartenenti a ciascuna tipologia

possiedono caratteristiche comuni per quanto riguarda il fabbisogno informativo che ri-

chiedono per supportare in modo adeguato il loro svolgimento. I criteri per identificare

tali caratteristiche sono: [TRS03]

• Orizzonte temporale di riferimento: e l’intervallo di tempo che intercorre tra

due esecuzioni successive di una determinata attivita. Le attivita strategiche hanno

effetto nel “lungo termine”, mentre le attivita operative solitamente hanno effetto

immediato;

• Orientamento all’esterno: e l’entita dell’impatto che le attivita hanno al di fuori

dei confini dell’organizzazione. Le attivita strategiche hanno effetto sul contesto

competitivo in cui l’organizzazione opera, mentre le attivita operative sono confinate

nell’interno dell’organizzazione;

• Discrezionalita: e il grado di arbitrio con il quale si puo decidere come e quando

svolgere un’attivita. E massima a livello strategico e diminuisce progressivamente

nelle attivita di piu basso livello. Nelle attivita operative le procedure di esecuzione

sono il piu possibile precise;


• Ripetitivita: e la frequenza con cui un’attivita viene svolta. Un’alta ripetitivita

caratterizza le attivita operative;

• Prevedibilita: e correlata alla ripetitivita. E tipica delle attivita operative, poiche

producono risultati prevedibili a priori e la loro esecuzione e prevista a priori nei

tempi e nella modalita;

• Ruoli organizzativi coinvolti: Le attivita strategiche sono di competenza della

direzione aziendale. Le attivita di programmazione e controllo sono assegnate alle

direzioni funzionali o di divisione. Le attivita operative sono condotte dal personale

esecutivo.

In particolare questo ultimo criterio e alla base della scomposizione dell’organizzazione,

che secondo un approccio di tipo gerarchico puo essere rappresentata con la piramide

indicata.

1.2 I principali tipi di sistemi usati nelle aziende

Poiche in un’azienda esistono interessi, specializzazioni e livelli differenti, esistono anche

tipi di sistemi diversi. Non esiste un sistema in grado di fornire tutte le informazioni di

cui ha bisogno un’azienda.

Come abbiamo visto prima, secondo il modello di Anthony un’azienda puo essere scom-

posta in tre livelli, ad ognuno dei quali corrispondono differenti tipologie di attivita:

strategiche, tattiche ed operative. E inoltre possibile osservare un’ulteriore suddivisione

in aree funzionali, come per esempio vendite e marketing, produzione, gestione finanziaria

e contabilita e risorse umane. I sistemi informativi hanno lo scopo di servire questi diversi

interessi nell’azienda.

I sistemi informativi a supporto delle attivita strategiche aiutano i senior manager

ad affrontare i problemi strategici e a valutare le tendenze a lungo termine sia nell’azienda

sia nell’ambiente esterno. La loro principale preoccupazione e far corrispondere i cambia-

menti nell’ambiente esterno con le capacita organizzative dell’azienda. “Quali saranno i

tassi di occupazione tra cinque anni?”. “Quali saranno le tendenze dei costi in questo

campo a lungo termine e come si posizionera la nostra azienda?”. “Quali prodotti dovre-

mo produrre nei prossimi cinque anni?”.

1.2 I principali tipi di sistemi usati nelle aziende 7

I sistemi informativi a supporto dell’attivita manageriale favoriscono le attivita

di monitoraggio, di controllo, decisionali e amministrative dei middle manager. La prin-

cipale domanda a cui devono rispondere questi sistemi e: “Le cose funzionano bene?”. In

genere i sistemi a livello manageriale forniscono report periodici piuttosto che informa-

zioni istantanee sulle operazioni.

I sistemi informativi operativi supportano i manager per la registrazione delle atti-

vita elementari e delle transazioni che si svolgono nell’azienda. Lo scopo principale dei

sistemi a questo livello e quello di supportare le attivita di routine e registrare il flusso

delle transazioni all’interno dell’azienda.

Normalmente in un’azienda esistono sistemi informativi operativi, di supporto alle at-

tivita manageriali e di supporto alle attivita strategiche per ognuna delle aree funzionali

(alcuni esempi sono stati riportati sopra).

Per esempio la funzione vendite sara in generale dotata di:

• un sistema operativo per registrare i dati di vendita quotidiani e per elaborare gli

ordini;

• un sistema informativo di supporto all’attivita manageriale avra un sistema per

registrare i dati di vendita mensili suddivisi per area geografica e indicare i luoghi

in cui le vendite hanno superato o non hanno raggiunto i livelli previsti;

• un sistema informativo di supporto alle attivita strategiche che prevede le tendenze

di vendita nell’arco di cinque anni.

I principali tipi di sistemi informativi sono:

TPS (Transaction Processing System):

I sistemi di elaborazione delle transazioni sono i sistemi operativi di base che servono il

livello operativo dell’azienda. Un sistema di elaborazione delle transazioni e un sistema

computerizzato che svolge e registra le transazioni di routine necessarie quotidianamente

per condurre le attivita aziendali. Per esempio, puo trattarsi di sistemi per l’inserimento

di ordini, di prenotazione alberghiera, di calcolo degli stipendi, di archiviazione della do-

cumentazione relativa ai dipendenti e delle spedizioni.

I sistemi di elaborazione delle transazioni sono talvolta cosı importanti per un’azienda


che un guasto di qualche ora puo sancire la sua fine e talvolta anche di altre aziende ad es-

sa connesse. I TPS sono anche i principali produttori di informazioni per altri tipi sistemi.

MIS (Management Information System):

Il termine sistemi di gestione dell’informazione designa una specifica categoria di sistemi

informativi che servono le funzioni di livello manageriale. Generalmente adempiono a

questo compito offrendo ai manager report e spesso un accesso online alle prestazioni

correnti e ai dati storici dell’azienda. In genere questi sistemi sono orientati quasi esclu-

sivamente a eventi interni.

Il sistema di gestione delle informazioni normalmente risponde alle necessita dei manager

interessati a risultati settimanali, mensili e annuali, benche alcuni di essi consentano loro

di approfondire fino a vedere i dati su base giornaliera o persino oraria.

DSS (Decision Support System):

Anche i sistemi di supporto alle decisioni rispondono alle esigenze del livello manageriale

dell’azienda. Aiutano i manager a prendere decisioni che sono uniche, in rapido cam-

biamento e difficilmente specificate in anticipo. Questi sistemi riguardano problemi in

cui la procedura per arrivare ad una soluzione puo non essere nota completamente in

anticipo. Sebbene i sistemi di supporto alle decisioni usino le informazioni interne fornite

dai sistemi di elaborazione delle transazioni e dai sistemi di gestione delle informazioni,

spesso impiegano anche informazioni tratte da fonti esterne.

Per definizione i DSS hanno una maggiore potenza analitica rispetto agli altri sistemi.

Essi utilizzano vari modelli di analisi dei dati o condensano grandi quantita di dati in un

formato utile per prendere decisioni.

Sono sistemi progettati in modo che gli utenti possano lavorare direttamente sui dati;

questi sistemi sono costituiti da software di facile uso; sono interattivi e l’utente puo

cambiare le premesse, porre nuove domande e includere nuovi dati.

ESS (Executive Support System):

Sono sistemi informativi per il livello strategico. Per prendere le loro decisioni i senior

manager utilizzano sistemi di supporto direzionale. Essi riguardano decisioni non di

routine che richiedono giudizi, valutazioni e conoscenze approfondite, poiche non esiste

nessuna procedura standard per giungere a una soluzione.

1.2 I principali tipi di sistemi usati nelle aziende 9

I sistemi di supporto direzionale sono progettati per incorporare i dati legati a eventi

esterni, ma traggono anche informazioni dai MIS e dai DSS. Essi filtrano, comprimono,

estraggono ed individuano i dati critici, mettendo in luce quelli della massima importanza

per i senior manager.

Il sistema ESS utilizza software di grafica avanzato ed e in grado di presentare grafici e

dati provenienti da molte fonti.

La Figura 1.3 illustra il modo in cui i vari sistemi servono i vari livelli di un’azienda

e le relazioni tra di essi.

Figura 1.3: Relazioni tra i sistemi

I sistemi di elaborazione delle transazioni rappresentano la fonte principale dei dati per

gli altri sistemi, mentre i sistemi di supporto direzionale fondamentalmente ricevono i

dati dai sistemi di livello inferiore. E sostanzialmente vantaggioso avere una certa in-

tegrazione tra questi sistemi in modo che le informazioni possano fluire con facilita tra

le varie parti dell’azienda e offrire al management una visione delle prestazioni aziendali

che abbracci l’intera impresa. Ma l’integrazione costa. L’integrazione di tanti sistemi

differenti richiede molto tempo e impegno [LL06].

La Tabella 1.1 riassume le principali caratteristiche dei sistemi appena descritti.


Tipo di sistema Informazioni di input Elaborazioni svolte Informazioni di output Utenti

ESS Dati aggregati, esterni e

interni

Grafici, simulazioni; inte-

rattivita

Proiezioni; risposte alle in-

terrogazioni

Senior manager

DSS Bassi volumi di dati o grossi

database ottimizzati per l’a-

nalisi dei dati; modelli ana-

litici e strumenti di analisi

dei dati

Interattivita; simulazioni

analisi

Report speciali; analisi del-

le decisioni; risposte alle

interrogazioni

Professionisti; manager di

staff

MIS Riepilogo dei dati sulle tran-

sazioni, alti volumi di dati,

semplici modelli

Report di routine, model-

li semplici; analisi di basso

livello

Riepiloghi e report delle

eccezioni

Middle manager

TPS Transazioni; eventi Ordinamento, produ-

zione elenchi, unioni e

aggiornamenti

Report dettagliati, liste; rie-

piloghi

Personale operativo, super-

visori

Tabella 1.1: Caratteristiche dei diversi tipi di sistemi informativi.

1.3 I DBMS ed il loro ruolo

Nel primo capitolo abbiamo osservato quanto siano importanti i dati per un’azienda al

fine di produrre in successione informazione, conoscenza e saggezza.

L’attenzione ai dati ha caratterizzato le applicazioni dell’informatica fin dalle sue origini,

ma sistemi software specificamente dedicati alla gestione dei dati sono stati realizzati

solo a partire dalla fine degli anni Settanta. I DBMS (Data Base Management System)

rientrano in questi sistemi software; sono infatti in grado di gestire collezioni di dati che

siano grandi, condivise e persistenti, assicurando la loro affidabilita e privatezza. Come

ogni prodotto informatico, un DBMS deve essere efficiente ed efficace. Una base di dati

e una collezione di datigestita da un DBMS [ACPT06].

In un’azienda i vari tipi di sistemi utilizzano gli stessi dati ma con finalita e modalita

diverse. In base a questa osservazione, possiamo suddividere i sistemi in sistemi operazio-

nali o transazionali, ovvero sistemi a supporto di attivita operative e gestionali e sistemi

di analisi, ovvero sistemi a supporto delle attivita decisionali-strategici.

1.3.1 DBMS transazionali (OLTP)

Si definisce transazione un’unita logica di elaborazione, cioe una sequenza di operazioni

che hanno un effetto globale sul database, vista come un insieme atomico, che completa

con successo o fallisce, senza nessuna possibilita intermedia. Un sistema che mette a

disposizione un meccanismo per la definizione e l’esecuzione di transazioni viene detto

sistema transazionale. Il loro scopo principale e quello di supportare attivita routinarie

1.3 I DBMS ed il loro ruolo 11

e registrare il flusso delle transazioni entro l’azienda, al livello operativo; mentre il loro

componente principale sono i sistemi OLTP (On-Line Transaction Process), che svolgono

e registrano le transazioni di routine necessarie per le attivita quotidiane dell’azienda.

In un DBMS transazionale, tutto il codice che viene eseguito all’interno di una transazione

gode di proprieta particolari, le cosiddette proprieta acide delle transazioni: atomicita,

consistenza, isolamento e persistenza; il termine deriva dall’acronimo ACID (Atomicity,

Consistency, Isolation, Durability) [ACPT06].

• Atomicita: rappresenta il fatto che una transazione e un’unita indivisibile di esecu-

zione. Tutte le operazioni della sequenza terminano con successo (commit) oppure,

se anche una sola di esse fallisce, l’intera transazione viene abortita (abort); si

applica quindi un approccio “tutto o niente”;

• Consistenza: richiede che l’esecuzione della transazione non violi i vincoli di inte-

grita definita sulla base dati. Una transazione e una trasformazione corretta dello

stato del database, vale a dire, al termine di ogni transazione il database deve

trovarsi in uno stato consistente. Nel caso di un’eventuale violazione il sistema

interviene per annullare la transazione o per correggere la violazione del vincolo.

• Isolamento: richiede che l’esecuzione di una transazione sia indipendente dalla

contemporanea esecuzione di altre transazioni. In particolare si richiede che il risul-

tato dell’esecuzione concorrente di un insieme di transazioni sia analogo al risultato

che le stesse transazioni otterrebbero qualora ciascuna di esse fosse seguita da sola;

• Persistenza: richiede che l’effetto di una transazione che ha eseguito il commit

correttamente non venga piu perso. In pratica, una base di dati deve garantire che

nessun dato venga perso per nessun motivo.

Data la sua natura esecutiva, il sistema transazionale ha la tendenza a strutturare i flussi

e a standardizzare il contenuto informativo per minimizzare la possibilita di commette-

re errori e, nello stesso tempo, rendere le operazioni fluide e rapide. La sua struttura

e ottimizzata per sostenere l’attivita di un numero potenzialmente elevato di persone

che interagiscono puntualmente con la base dati in attivita di ricerca, di creazione e di

aggiornamento delle informazioni.


1.3.2 DBMS per l’analisi (OLAP)

Mentre i dati operazionali coprono un arco temporale di solito piuttosto limitato, poiche

la maggior parte delle transazioni coinvolge i dati piu recenti, i sistemi di analisi devono

permettere analisi che spazino sulla prospettiva di alcuni anni. Per questo motivo questi

ultimi sistemi devono essere aggiornati a intervalli regolari a partire dai dati operazionali

e sono in crescita continua. Volendo fare un paragone possiamo supporre che, a intervalli

regolari, venga scattata una fotografia istantanea dei dati operazionali. La progressione

delle fotografie scattate viene immagazzinata, generando un film che documenti la situa-

zione aziendale da un istante zero fino al tempo attuale.

I processi decisionali non sono standardizzabili ne riconducibili a procedure automatiz-

zate, perche sono influenzati dai modelli di realta che le persone utilizzano per effettuare

le scelte. I sistemi di analisi devono pertanto supportare il processo decisionale seguendo

i passaggi logici del decisore e dandogli la possibilita di avere visioni diversamente orga-

nizzate dai dati.

L’On-Line Analytical Processing (OLAP) e l’insieme dei sottosistemi informativi azien-

dali pensati per l’analisi interattiva dei dati, ottimizzati per garantire la massima effi-

cienza nell’elaborazione dei dati di sintesi e la massima flessibilita nelle interrogazioni.

Solitamente si basano su sistemi in sola lettura, o comunque articolati in modo tale da

privilegiare operazioni di lettura e di aggregazione dei dati, con strutture orientate agli

oggetti di analisi.

Il database per il processo di analisi ha le seguenti caratteristiche: [Des07]

• Entita denormalizzate;

• Disegno del database piu semplice (meno tabelle e meno associazioni) per una

comprensione piu facile da parte dell’utente;

• I dati memorizzati possono essere aggregati (riassuntivi);

• Le interrogazioni richiedono poche join;

• Ottimizzato per la consultazione di grandi moli di dati.

Dal momento che i sistemi di analisi, come gia detto, accedono ai dati quasi solamente

in sola lettura, le proprieta acide osservate precedentemente per i DBMS transazionali

possono essere tralasciate.

1.3 I DBMS ed il loro ruolo 13

1.3.3 Perche e necessario distinguere

L’elevata discrepanza tra le esigenze informative dei diversi livelli operativi e decisionali

aziendali impone, come abbiamo visto in precedenza, l’adozione di sistemi differenziati. I

sistemi informativi aziendali devono guidare sia l’attivita operativa che quella decisionale.

Fino a tempi recenti lo facevano tramite il solo sistema operazionale. Al crescere della

criticita del processo decisionale e della quantita di dati da elaborare, l’uso di un unico

sistema centralizzato come supporto sia operativo che informazionale ha manifestato nu-

merosi limiti.

In particolare, il sistema operazionale, strutturato sul concetto di transazione e di pro-

cesso, si e rilevato carente:

• Nella produzione di dati di sintesi, presentati tramite reportistica solitamente rigida,

modificabile solo con costi elevati;

• Nella possibilita di interrogare interattivamente la base dati, solitamente articolata

in modo complesso e accessibile ai soli addetti ai lavori:

• Nella disponibilita di dati fondamentali per il processo decisionale, ma non sempre

utilizzati o presenti a livello operativo;

• Nella velocita di risposta dal momento che la struttura dati e ottimizzata per il

supporto alle transazioni e non per l’elaborazione di informazioni di sintesi;

• Nella copertura temporale, solitamente ridotta per motivi di prestazioni e di oc-

cupazione di memoria di massa , che potrebbe rivelarsi insufficiente per condurre

analisi di tendenza sul medio/lungo periodo.

Uno schema delle differenze tra OLTP e OLAP , tra sistemi operazionali e sistemi di

analisi, e mostrato in Tabella 1.2 [PM05].


OLTP OLAP

Finalita Supporto all’operativita Supporto al processo decisio-

nale

Utenti Molti, livello operativo Pochi, livello direzionale

Dati Elementari, numerici e alfanu-

merici

Sintetici, solitamente numerici

Modalita di uti-

lizzo

Guidata, per processi e stati

successivi

Interrogazioni ad hoc

Quantita di da-

ti per operazione

elementare

Bassa: centinaia di record per

ogni transazione

Alta: milioni di record per ogni

query

Qualita In termini di integrita In termini di consistenza

Orientamento Per processo/applicazione Per soggetto

Frequenza di ag-

giornamento

Continua, tramite azioni Sporadica, tramite funzioni

esplicite

Copertura tem-

porale

Dati correnti Storica

Ottimizzazione Per accessi in lettura e scrittu-

ra su una porzione della base

di dati

Per accessi in sola lettura su

tutta la base di dati

Tabella 1.2: Differenze tra sistemi OLTP e sistemi OLAP.

CAPITOLO 2

Introduzione alla Business Intelligence

2.1 Data warehousing

Tra i sistemi di supporto alle decisioni, i sistemi di data warehousing sono probabilmente

quelli su cui negli ultimi anni si e maggiormente focalizzata l’attenzione sia nel mondo

accademico sia in quello industriale. E possibile definire in modo informale il data ware-

housing come segue:

Data warehousing: E una collezione di metodi, tecnologie e strumenti di ausilio

al cosiddetto “lavoratore della conoscenza” per condurre analisi dei dati finalizzate

all’attuazione di processi decisionali ed al miglioramento del patrimonio informativo.

Per capire a fondo il ruolo e l’utilita del data warehousing occorre analizzare le esi-

genze che ne hanno decretato la nascita. Kimball riassume efficacemente tali esigenze,

evidenziando le lamentele piu frequenti mosse dagli utenti.

“Abbiamo montagne di dati ma non possiamo accedervi!”. Questa frase esprime la fru-

strazione da parte di chi ha il ruolo e la competenza per decidere del futuro aziendale,

ma non possiede gli strumenti tecnici per ottenere, nella forma desiderata, i dati necessari.

16 Introduzione alla Business Intelligence

“Come e possibile che persone che svolgono lo stesso ruolo presentino risultati sostan-

zialmente diversi?”. In un contesto aziendale medio-grande sono tipicamente presenti

piu basi di dati, ciascuna relativa a una diversa area del business, spesso memorizzate

su piattaforme logico-fisiche differenti e non integrate dal punto di vista concettuale. I

risultati prodotti all’interno delle diverse aree saranno allora, molto probabilmente, in-

consistenti tra loro.

“Vogliamo selezionare, raggruppare e manipolare i dati in ogni modo possibile!”. Il pro-

cesso decisionale e difficilmente pianificabile a priori. L’utente finale vorrebbe disporre

di uno strumento sufficientemente amichevole e flessibile da consentirgli di condurre l’a-

nalisi in modo estemporaneo, lasciandosi guidare dalle informazioni via via ottenute per

decidere sul momento quali nuove correlazioni ricercare.

“Mostrami solo cio che e importante!”. Esaminare i dati al massimo livello di dettaglio e

non solo inutile per il processo decisionale, ma addirittura controproducente, perche non

consente di focalizzare l’attenzione sulle informazioni veramente significative.

“Tutti sanno che alcuni dati non sono corretti!”. Questo e un altro punto dolente. Una

percentuale non trascurabile dei dati transazionali e non corretta, o addirittura assente.

Evidentemente, basare il procedimento analitico su dati errati e incompleti non permette

di raggiungere risultati validi.

Da questo elenco di difficolta e problemi possiamo facilmente estrarre un elenco di parole

chiave che diventano fattori distintivi e requisiti indispensabili del processo di data ware-

housing, ossia del complesso di attivita che consentono di trasformare i dati operazionali

in conoscenza a supporto delle decisioni:

• Accessibilita a utenti con conoscenze limitate di informatica e strutture dati;

• Integrazione dei dati sulla base di un modello standard dell’impresa;

• Flessibilita di integrazione per trarre il massimo vantaggio dal patrimonio infor-

mativo esistente;

• Sintesi per permettere analisi mirate ed efficaci;

2.1 Data warehousing 17

• Rappresentazione multidimensionale per offrire all’utente una visione intuitiva

ed efficacemente manipolabile delle informazioni;

• Correttezza e completezza dei dati integrati.

Al centro del processo vi e il data warehouse, un contenitore di dati che diventa garante

dei requisiti esposti. Inmon ne diede una definizione nel 1996.

Data warehouse. Un Data Warehouse (DW) e una collezione di dati di supporto

per il processo decisionale che presenta le seguenti caratteristiche:

• E orientata ai soggetti di interesse;

• E integrata e consistente;

• E rappresentativa dell’evoluzione temporale e non volatile.

Il DW e orientato ai soggetti in quanto in quanto si incentra sui concetti di interesse

dell’azienda, quali clienti, i prodotti, le vendite, gli ordini. Viceversa, i database opera-

zionali sono organizzati intorno alle differenti applicazioni del dominio aziendale.

La condizione di integrita e consistenza e molto importante, in quanto il DW si appog-

gia a piu fonti di dati eterogenee: dati estratti dall’ambiente di produzione, e quindi

originariamente archiviati in basi di dati aziendali, o addirittura provenienti da sistemi

informativi esterni all’azienda. Di tutti questi dati il DW si impegna a restituire una

visione unificata. La costruzione di un sistema di data warehousing non comporta l’in-

serimento di nuove informazioni bensı la riorganizzazione di quelle esistenti, e implica

pertanto l’esistenza di un sistema informativo.

Infine nel data warehouse i dati non vengono mai rimossi ma solo aggiunti, questa carat-

teristica consente di avere a disposizione sia dati storici che recenti.

Un data warehouse puo essere consultato direttamente, ma anche essere usato come

sorgente per costruirne delle parziali repliche orientate verso specifiche aree dell’impresa.

Tali repliche vengono dette data mart.


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


warehouse solleva la gran parte della responsabilita di rappresentare il passato ai sistemi

sorgente.

Staging Area:

La staging area di un data warehouse e composta da due parti: un’area di memorizzazione

dei dati e un insieme di procedure comunemente dette extraction-transformation-loading

(ETL). Si colloca tra i sistemi sorgente e l’area di presentazione. Kimball paragona la

staging area alla cucina di un ristorante, nella quale gli ingredienti vengono trasformati

per un buon pasto. I dati operazionali vengono infatti trasformati e consegnati al data

warehouse in una forma appropriata per il loro consumo, ossia la loro elaborazione per

produrre informazioni utili all’azienda. Come per la cucina di un ristorante anche la

staging area sara accessibile solamente da professionisti qualificati e per tanto risultera

essere off-limits per gli utenti business. Inoltre non sara predisposta per servizi di in-

terrogazione e di presentazione, cosı come i clienti di un ristorante non sono invitati a

mangiare in cucina.

La presenza e l’utilizzo di questo componente dipende dall’architettura adottata per

realizzare il sistema di data warehousing, come verra esposto in seguito.

Area di presentazione:

L’area di presentazione e la parte dove i dati sono organizzati, conservati, e resi disponi-

bili per l’interrogazione diretta da parte di utenti, autori di report, e altre applicazioni

analitiche. Per la comunita imprenditoriale l’area di presentazione coincide con il data

warehouse, in quanto e tutto quello che possono vedere e toccare mediante gli apposi-

ti strumenti in loro possesso. E fortemente consigliabile che i dati vengano presentati,

memorizzati e siano accessibili in schema dimensionali (il modello multidimensionale e

descritto nel capitolo 4), in quanto risultano essere di piu facile uso per gli utenti di data

warehouse.

Strumenti di accesso ai dati:

E l’insieme degli strumenti di front-end che gli utenti business hanno a loro disposizione

per consultare l’area di presentazione. Possono essere semplici strumenti per eseguire

query ad hoc oppure strumenti che eseguono analisi piu complesse, come verra illustrato


nel paragrafo 2.3.1. Tuttavia nell’80-90 per cento dei casi gli utenti utilizzano applicazioni

che forniscono automaticamente e ad intervalli di tempo prestabiliti informazioni strut-

turate in modo pressoche invariabile e che quindi non implicano la costruzione diretta

di query. In ogni caso questi strumenti dovranno possedere un motore di ottimizzazione

delle interrogazioni, a prescindere dal fatto che esse vengano o meno costruite dell’utente.

2.1.2 Architetture per il data warehousing

Come accennato nel paragrafo precedente la presenza e le modalita di utilizzo della staging

area definiscono l’architettura del sistema di data warehousing. La scelta dell’architettura

da utilizzare dipende delle esigenze e dal tipo dell’organizzazione entro la quale il progetto

dovra essere realizzato, tuttavia esistono caratteristiche irrinunciabili per un sistema di

data warehousing che possono essere cosı enunciate: [GR06]

• Separazione: l’elaborazione analitica e quella transazionale devono essere mantenute

il piu possibile separate;

• Scalabilita: l’architettura hardware e software deve poter essere facilmente ridimen-

sionata a fronte della crescita nel tempo dei volumi di dati da gestire ed elaborare

e del numero di utenti da soddisfare;

• Estendibilita: deve essere possibile accogliere nuove applicazioni e tecnologie senza

riprogettare integralmente il sistema;

• Sicurezza: il controllo sugli accessi e essenziale a causa della natura strategica dei

dati memorizzati;

• Amministrabilita: la complessita dell’attivita di amministrazione non deve risultare

eccessiva.

In seguito vengono presentati alcuni modelli architetturali.

Architettura a un livello

E un’architettura scarsamente utilizzata nella pratica. Ha come obiettivo quello di mi-

nimizzare la quantita di dati memorizzati eliminando le ridondanze. Come mostrato in

Figura 2.2 il data warehouse in questo caso e virtuale, poiche viene implementato come

una vista multidimensionale dei dati operazionali da un apposito middleware.


Figura 2.2: Architettura ad un livello per un sistema di data warehousing

Una tale architettura presenta i seguenti punti deboli:

• Non rispetta il requisito di separazione dell’elaborazione analitica da quella transa-

zionale. Le interrogazioni di analisi vengono infatti ridirette sui dati operazionali

dopo essere state reinterpretate dal middleware, interferendo cosı con il normale

carico di lavoro transazionale;

• I requisiti di integrazione e correttezza dei dati possono essere soddisfatti, ma con

un’elevata complessita;

• E impossibile avere un livello di storicizzazione superiore a quello delle sorgenti.

Architettura a due livelli

Con questa architettura si riesce a soddisfare il requisito di separazione, come si evince

dalla Figura 2.3. Nonostante si articoli su quattro livelli distinti viene chiamata architet-

tura a due livelli per evidenziare la separazione tra le sorgenti e il data warehouse. I dati

che il data warehouse utilizzera sono contenuti in database aziendali relazionali o legacy,

oppure provenienti da sistemi informativi esterni all’azienda (livello delle sorgenti). Tali

dati saranno estratti, ripuliti per eliminare le inconsistenze e completare eventuali parti


Figura 2.3: Architettura a due livelli per un sistema di data warehousing

mancanti, integrati per fondere sorgenti eterogenee secondo uno schema comune, me-

diante gli strumenti ETL accennati precedentemente ed approfonditi nel paragrafo 2.1.3

(livello di alimentazione). Le informazioni vengono raccolte nel data warehouse che potra

essere direttamente consultato o usato come sorgente per costruire data mart (livello del

warehouse). Accanto al DW, il contenitore dei metadati mantiene informazioni sulle sor-

genti, sui meccanismi di accesso, sulle procedure di pulitura e alimentazione, sugli utenti,

sugli schemi dei data mart ecc. Infine si potranno consultare in modo efficiente e flessi-

bile i dati integrati a fini di stesura di report, di analisi e di simulazione (livello di analisi).

Architettura a tre livelli

Al livello delle sorgenti e quello del data warehouse, viene aggiunto un terzo livello che

viene chiamato livello dei dati riconciliati. Questo livello materializza i dati operazionali

ottenuti a valle del processo di integrazione e ripulitura dei dati sorgente: quindi dati

integrati, consistenti, corretti, volatili, correnti e dettagliati. Il data warehouse non verra

quindi piu alimentato direttamente dalle sorgenti, ma dai dati riconciliati.


Un vantaggio di questa architettura, mostrata in Figura 2.4, e che il livello dei dati ricon-

ciliati crea un modello di dati comune e di riferimento per l’intera azienda, introducendo

al contempo una separazione netta tra le problematiche legate all’estrazione e integrazio-

ne dei dati dalle sorgenti e quelle inerenti l’alimentazione del DW. Tuttavia presenta lo

svantaggio di introdurre un’ulteriore ridondanza rispetto ai dati operazionali sorgente.

Figura 2.4: Architettura a tre livelli per un sistema di data warehousing


2.1.3 Gli strumenti ETL

Il ruolo degli strumenti di extraction-trasformation-loading e quello di alimentare una

sorgente dati singola, dettagliata, esauriente e di alta qualita che possa a sua volta ali-

mentare il data warehouse. Le procedure di popolamento del data warehouse possono

raggiungere elevati livelli di complessita, in relazione alle discrepanze esistenti tra le sor-

genti, al loro livello di correttezza e al livello di precisione rappresentativa nel tempo che

si desidera mantenere nel sistema informazionale. Sono caratterizzate da una sequenza di

fasi che dipende dalle politiche di aggiornamento che si e deciso di adottare, politiche che

prevedono azioni piu o meno articolate da parte delle procedure di popolamento. La com-

plessita di queste procedure e tale che sul mercato sono presenti diversi prodotti software

orientati specificamente al supporto delle fasi di estrazione, pulizia, trasformazione

e caricamento dei dati nel processo di alimentazione del data warehouse.

Occorre precisare che, nella letteratura, i confini tra pulitura e trasformazione sono spesso

sfumati dal punto di vista terminologico, per cui e spesso poco chiara l’attribuzione di

una specifica operazione all’uno o all’altro processo.

Estrazione

Le operazioni di estrazione sono eseguite all’atto dell’inizializzazione del livello riconciliato

per essere poi ripetute periodicamente, in base all’intervallo di aggiornamento stabilito

dal progettista, al fine di acquisire informazioni relative agli eventi verificatisi durante

la vita del sistema. I dati che andranno a popolare il data warehouse sono solo quelli

essenziali all’analisi e non tutti i dati ospitati sui sistemi di origine. Esistono due tipologie

di approcci all’estrazione:

• Estrazione statica: vengono trattati tutti i dati presenti nelle sorgenti operazionali.

E l’unica soluzione possibile all’atto dell’inizializzazione, ma puo essere impiegata

ogni qual volta la quantita ridotta dei dati lo permetta;

• Estrazione incrementale: con questo approccio vengono presi in considerazione i

soli dati prodotti o modificati dalle sorgenti nell’intervallo di tempo intercorso dal-

l’ultimo aggiornamento del data warehouse. Puo essere suddiviso ulteriormente

in immediato e ritardato. Nel primo caso ogni modifica ai dati viene registrata

immediatamente, mentre nel secondo caso posticipano tale operazione.


L’estrazione incrementale generalmente si basa sui log mantenuti dal DBMS transaziona-

le. Inoltre l’estrazione puo anche essere guidata dalle sorgenti in quei casi in cui e possibile

ricevere, in modo asincrono, le notifiche delle modifiche dalle applicazioni operazionali.

Pulizia

Spesso i dati provenienti dalle sorgenti non sono di qualita adeguata agli standard richiesti

per il sistema informazionale. Devono quindi essere applicate analisi in grado di rilevare

e possibilmente correggere le situazioni che potrebbero essere critiche o condurre a errori.

Tra gli errori e le inconsistenze tipiche che rendono “sporchi” i dati segnaliamo: [GR06]

• Dati duplicati (per esempio, un cliente che compare piu volte nell’anagrafica);

• Inconsistenza tra valori logicamente associati (per esempio, tra i dati della persona

ed il suo codice fiscale);

• Dati mancanti (per esempio, la professione di un cliente);

• Uso non previsto di un campo (per esempio il campo destinato al codice fiscale

usato per memorizzare il numero di telefono d’ufficio);

• Valori impossibili o errati (per esempio, 30/02/2011);

• Valori inconsistenti per la stessa entita dovuti a differenti convenzioni (per esem-

pio, la nazione indicata mediante sigla piuttosto che con il nome completo) e

abbreviazioni (per esempio, ‘Piazza Garibaldi’ e ‘P.za Garibaldi’);

• Valori inconsistenti per la stessa entita dovuti a errori di battitura (per esempio,

‘Piazza Garibaldi’ e ‘Piazza Gribaldi’).

Per correggere errori di scrittura e riconoscere sinonimi vengono utilizzati degli appositi

dizionari, mentre per stabilire le corrette corrispondenze tra valori vengono applicate

regole proprie del dominio applicativo.

Trasformazione

Durante questa fase vengono eseguite le trasformazioni necessarie a conformare i dati delle

sorgenti alla struttura del data warehouse; in caso di architettura a tre livelli l’output di

questa fase e il livello dei dati riconciliati. La presenza di piu fonti eterogenee complica


notevolmente questa fase, in quanto viene richiesta una complessa fase di integrazione.

Nella fase di trasformazione possono essere effettuate molte operazioni, tra cui:

• Conversione e normalizzazione: operano a livello di formato di memorizzazione e

di unita di misura per uniformare i dati;

• Matching : Stabilisce le corrispondenze tra campi equivalenti in sorgenti diverse;

• Selezione: riduce il numero di campi e di record rispetto alle sorgenti.

Negli strumenti ETL le attivita di pulitura e trasformazione sono spesso allacciate e

sovrapposte.

Caricamento

Al termine, si procede al caricamento vero e proprio dei dati sul data warehouse. Questa

procedura puo avvenire in due modalita.

Refresh. I dati vengono completamente riscritti all’interno del DW. Viene solitamente

utilizzata insieme all’estrazione statica durante la fase di inizializzazione.

Update. Vengono aggiunti al DW i soli cambiamenti verificatisi nelle sorgenti operaziona-

li. Questa tecnica viene solitamente utilizzata in abbinamento all’estrazione incrementale

al fine di ottenere un aggiornamento periodico del DW.

2.2 Il modello multidimensionale

La progettazione di data warehouse e data mart si basa su un paradigma di rappresenta-

zione multidimensionale dei dati, in grado di offrire un duplice vantaggio: sotto il profilo

funzionale, risulta efficace per garantire tempi di risposta rapidi a fronte di interrogazioni

complesse; sul piano logico, le dimensioni corrispondono in modo naturale ai criteri di

analisi utilizzati dai knowledge worker [Ver06].

Il modello multidimensionale si basa sul fatto che gli oggetti che influenzano il processo

decisionale sono fatti del mondo aziendale come ad esempio le vendite o le spedizioni. Le

occorrenze di un fatto vengono dette eventi : ogni singola vendita o spedizione effettuata

e un evento. Per ciascun fatto, interessano in particolare i valori di un insieme di misure

che descrivono quantitativamente gli eventi.

2.2 Il modello multidimensionale 27

La quantita degli eventi all’interno di una azienda e troppo elevata per poter analizzare

ogni singolo evento singolarmente. Per questo motivo per poterli agevolmente seleziona-

re e raggruppare (come vedremo nel capitolo 5) si immagina di collocarli in uno spazio

n-dimensionale, i cui assi vengono chiamati appunto dimensioni di analisi. Per esempio

nel caso in cui il fatto in questione siano le vendite, le dimensioni di analisi potrebbero

essere: i prodotti, i negozi e le date.

Il concetto di dimensione genera la metafora del cubo.

Cubo multidimensionale. Un cubo multidimensionale e incentrato su un fatto

di interesse per il processo decisionale. Esso rappresenta un insieme di eventi, de-

scritti quantitativamente da misure numeriche. Ogni asse del cubo rappresenta una

possibile dimensione di analisi.

Figura 2.5: Cubo multidimensionale che modella le vendite in una catena di negozi

Ovviamente se le dimensioni sono piu di tre, si tratta piu propriamente di un ipercu-

bo.


Normalmente ciascuna dimensione e associata ad una gerarchia di livelli di aggregazione

che ne raggruppa i valori in diversi modi. I livelli che compaiono nella gerarchia vengono

detti attributi dimensionali

Figura 2.6: Una possibile gerarchia per la dimensione negozi

2.2.1 Modellazione concettuale: il Dimensional Fact Model

Un modello concettuale deve per definizione fornire una serie di strutture, dette costrutti,

atte a descrivere la realta di interesse in una maniera facile da comprendere e che pre-

scinde dai criteri di organizzazione dei dati nei calcolatori [ACPT06]. Il modello Entity/

Relationship e un modello concettuale molto diffuso nelle imprese per la progettazione e

documentazione di basi di dati relazionali.

Mentre e ormai universalmente riconosciuto che un data mart si appoggia su una vi-

sione multidimensionale dei dati, non c’e ancora accordo su come portare a termine la

progettazione concettuale a partire dai requisiti utente. Non esiste infatti un modello

concettuale adottato universalmente per la progettazione e documentazione di basi di

dati per il data warehousing. Il modello Entity/Relationship non risulta essere adatto a

tale scopo in quanto non e in grado di mettere correttamente in luce gli aspetti peculiari


del modello multidimensionale, senza contare che risulterebbe poco economico dal punto

di vista grafico-notazionale.

Il Dimensional Fact Model (DFM), proposto da Golfarelli nel 1998, e un modello concet-

tuale specificamente concepito per fungere da supporto alla progettazione di data mart;

e essenzialmente di tipo grafico, e puo essere considerato come una specializzazione del

modello multidimensionale per applicazioni di data warehousing. La rappresentazione

concettuale generata dal DFM consiste in un insieme di schemi di fatto. Gli elementi di

base modellati dagli schemi di fatto sono i fatti, le misure, le dimensioni, le gerarchie e

gli attributi dimensionali. In questa sede non saranno trattati gli aspetti di modellazione

avanzata.

Nelle Figure 2.7 e 2.8 sono riportati lo schema di fatto e lo schema Entity/Relationship

relativi alle vendite.

Figura 2.7: Semplice schema di fatto delle vendite

Figura 2.8: Schema Entity/Relationship corrispondente allo schema di fatto di Figura 2.7


Come si puo evincere dalla figura, un fatto e raffigurato da un rettangolo che ne riporta il

nome insieme ai nomi delle eventuali misure; le dimensioni sono rappresentati da piccoli

cerchi collegati al fatto tramite linee. E importante evidenziare come un fatto esprime

un’associazione molti-a-molti tra le dimensioni. Per tale motivo lo schema Entity/Re-

lationship corrispondente ad uno schema di fatto consiste in un’associazione n-aria tra

entita che modellano le dimensioni.

Le gerarchie vengono rappresentate da alberi direzionati i cui nodi sono attributi dimen-

sionali e i cui archi modellano associazioni molti-a-uno tra coppie di attribuiti dimensio-

nali. La Figura 2.9 ne fornisce una rappresentazione.

Figura 2.9: Schema di fatto delle vendite arricchito

Se si volesse tradurre questo schema di fatto nel corrispondente schema E/R si avrebbe

un’esplosione in termini grafico-notazionali, come gia si era accennato in precedenza.

Tutti gli attributi dimensionali all’interno di uno schema di fatto devono avere nomi

diversi tra loro. Nomi uguali possono essere differenziati qualificandoli con il nome di

un attributo dimensionale che li precede nella gerarchia (per esempio, citta negozio e

citta marca).


2.2.2 Modellazione logica

Mentre per la fase di modellazione concettuale non ci si deve preoccupare delle scelte che

si dovranno fare durante la fase di modellazione logica, per quest’ultima non si puo dire

la stessa cosa. Sara infatti in questa fase che si dovra scegliere il DBMS da utilizzare

durante la progettazione fisica. I dati soggetti ad analisi possono essere rappresentati

secondo due modelli logici: quello relazionale, che da luogo ai cosiddetti sistemi ROLAP

(Relational OLAP), e quello multidimensionale, per il quale i sistemi utilizzati vengono

detti MOLAP (Multidimensional OLAP).

Esiste anche una terza soluzione, intermedia alle due appena menzionate ed e il cosiddetto

HOLAP (Hybrid OLAP).

2.2.2.1 I sistemi ROLAP

Adottare una soluzione di questo genere implica il dover modellare i concetti multidi-

mensionali osservati fin ora in elementi bidimensionali, ovvero le tabelle del modello

relazionale. Una tale operazione viene effettuata mediante il cosiddetto star schema

(Figura 2.10).

Figura 2.10: Star schema per le vendite


Uno schema a stella e composto da:

• Un insieme di tabelle, chiamate tabelle delle dimensioni (dimension table). Cia-

scuna di queste tabelle e caratterizzata da una chiave primaria e da un insieme di

attributi che descrivono le dimensioni di analisi a diversi livelli di aggregazione;

• Una tabella chiamata tabella dei fatti (fact table) in cui sono presenti le chiavi di

tutte le tabelle delle dimensioni. La chiave primaria di questa tabella sara data

dall’insieme delle chiavi esterne delle dimension table. La tabella dei fatti contiene

inoltre un attributo per ogni misura.

La visione multidimensionale si ottiene eseguendo il join tra la fact table e le dimension

table.

La seguente query SQL fornisce la quantita e l’incasso totale delle vendite di surgelati

relative all’anno 2010 per la regione Emilia Romagna, raggruppata per responsabili.

1 SELECT DT2. r e sponsab i l e , SUM(FT. quant i ta ) , SUM(FT. i n ca s s o )

2 FROM Vendite FT, Prodotto DT1, Negozio DT2, Data DT3

3 WHERE FT. prodotto = DT1. prodotto ID AND

4 FT. negoz io = DT2. negoz io ID AND

5 FT. data = DT3. data ID AND

6 DT1. c a t e go r i a = ’ s u r g e l a t i ’ AND

7 DT2. r eg i one = ’ Emil ia Romagna ’ AND

8 DT3. anno = 2010

9 GROUP BY DT2. r e s pon s ab i l e

Si noti come le dimension table violino la terza forma normale, ovvero contengono at-

tributi che dipendono transitivamente da una chiave. Una tale situazione introduce una

ridondanza e per tanto richiede piu spazio per la memorizzazione dei dati, ma allo stesso

tempo richiede un minor numero di join per reperire le informazioni. Si potrebbe pero

essere interessati ad avere uno schema logico piu vicino agli enunciati della teoria relazio-

nale; lo snowflake schema (Figura 2.11) lo permette in quanto caratterizzato da una

parziale normalizzazione delle dimension table.


Uno schema snowflake e ottenibile da uno schema a stella scomponendo una o piu dimen-

sion table in piu tabelle, in modo tale da eliminare alcune delle dipendenze funzionali

transitive in esse presenti. Le tabelle delle dimensioni le cui chiavi sono importate nella

fact table vengono dette primarie, mentre chiameremo secondarie le rimanenti.

In questo modo e possibile trovare il giusto compromesso tra spazio in memoria utilizzato

e numero di join da effettuare per ricavare l’informazione desiderata. Si noti come a ogni

passo di normalizzazione corrisponda un arco nello schema di fatto e una sotto-gerarchia

che invece verra memorizzata in una tabella a parte.

Affinche lo snowflaking sia efficace, tutti gli attributi del sottoalbero dell’attributo da cui

ha origine la normalizzazione devono essere spostati nella nuova relazione.

La scelta di mappare elementi del mondo multidimensionale nel modello relazionale po-

trebbe apparire una forzatura. Tuttavia una tale scelta e giustificata da un insieme di

motivazioni di varia natura, prima fra tutte la constatazione che il modello relazionale

e di fatto lo standard nel settore dei database. Inoltre, l’evoluzione subita dai DBMS

relazionali nell’arco degli anni della loro presenza sul mercato ne fa degli strumenti estre-

mamente raffinati ed ottimizzati.

Figura 2.11: Snowflake schema ottenuto mediante una parziale normalizzazione dello star

schema di Figura 2.10


2.2.2.2 I sistemi MOLAP

Nell’approccio MOLAP il data warehouse memorizza i dati usando strutture intrinseca-

mente multidimensionali: i dati vengono fisicamente memorizzati in vettori e l’accesso e

di tipo posizionale. Il sistema alloca una cella per ogni possibile combinazione dei valori

delle dimensioni e l’accesso ad un fatto avviene in modo diretto, sulla base delle coordi-

nate fornite.

L’utilizzo di una tale soluzione rappresenta la soluzione naturale per un sistema di data

warehousing e puo fornire prestazioni ottimali, in quanto le operazioni di query multidi-

mensionale non devono essere simulate mediante complesse istruzioni SQL. Il principale

problema a cui pero e soggetta la soluzione MOLAP, e la sparsita dei dati, rappresentata

in Figura 2.12.

Figura 2.12: Rappresentazione del fenomeno di sparsita dei dati: in bianco le celle relative

ad eventi effettivamente accaduti

Mediamente in un cubo multidimensionale meno del 20% delle celle contiene effettivamen-

te delle informazioni, mentre le restanti celle risultano essere vuote poiche corrispondono

ad eventi non accaduti. La memorizzazione di celle non informative provoca uno spreco

dello spazio su disco.

Il fenomeno della sparsita dei dati viene affrontato partizionando il cubo n-dimensionale

in questione, in piu sottocubi n-dimensionali che vengono detti chunk. Si parla di chunk

densi, se la maggior parte delle celle contengono dati, chunk sparsi altrimenti [GR06].

Un tale approccio permette di operare su blocchi di dati di dimensione inferiore e che

quindi potranno essere caricati agevolmente in memoria.


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]


• Tipo 1 : Sovrascrittura (Overwrite). E una tecnica che prevede la semplice so-

vrascrittura di uno o piu attributi nelle dimensioni esistenti. Il vecchio valore andra

perso, per tanto e bene utilizzare questa metodologia quando non si ha interesse nel

memorizzare lo storico per l’attributo dimensionale in questione. Si supponga di

porsi nello scenario in cui una tale modifica debba essere effettuata su uno schema

a stella (ovvero uno scenario nel quale e stata adottata una soluzione ROLAP). Nel

momento in cui interverra una modifica a un valore di una tupla della dimension

table sara sufficiente sovrascrivere il vecchio valore con il nuovo. Come conseguenza

tutti i dati della fact table vengono associati al nuovo valore della dimension table.

• Tipo 2 : Creazione di una nuova riga (Create new row). E la tecnica stan-

dard per registrare la verita storica, ovvero consente di modificare le dimensioni in

modo che esse vengano poi associate correttamente ai fatti. Nell’esempio di uno

star schema gli eventi della fact table dovranno essere associati ai dati dimensionali

che erano validi quando si e verificato l’evento. Per realizzare questa tecnica ba-

stera aggiungere una nuova riga nella dimension table appropriata, senza andare ad

eliminare quella vecchia. Al vecchio record non sara piu possibile associare nessun

nuovo evento. Per il soddisfacimento di un tale vincolo e possibile aggiungere una

colonna contenente un flag che indichi la versione corrente, oppure assegnare ad

ogni versione una data di inizio ed una data di fine, la versione in cui la data di fine

non e stata settata sara quella corrente.

• Tipo 3 : Aggiunta di una nuova colonna (Add a new column). Questa

tecnica supporta variazioni degli attributi che avvengono in modo poco frequente.

Essa infatti dimostra una minor flessibilita ai cambiamenti rispetto la tecnica di

tipo 2. Mentre per quest’ultima ogni cambiamento richiedeva l’aggiunta di una

nuova riga, per la tecnica di tipo 3 e richiesta la valorizzazione di apposite colonne.

Il numero delle colonne a disposizione e stabilito in fase di progettazione e per tanto

il livello di storicizzazione risulta essere limitato. Tuttavia rende possibile riferirsi

ad un attributo che conterra sia il nuovo che il vecchio valore.

• Tecnica ibrida. Si basa sulla combinazione delle tecniche viste fino ad ora e

viene talvolta indicata come tecnica di tipo 6 (1+2+3 = 6). Per esempio, puo

essere impiegata per avere la gestione dello storico offerto dalle soluzioni di tipo

2, ma con la possibilita di raggiungere agevolmente il valore corrente dell’attributo

2.3 La Business Intelligence (BI) 37

partendo dai vecchi valori. Quest’ultima caratteristica puo essere ottenuta mediante

la tecnica di tipo 3 memorizzando per ogni vecchio valore anche il valore corrente

in un’apposita colonna.

Prima di affrontare la scelta della tecnica con la quale si desidera fronteggiare lo slowly

changing dimensions occorre precisare che l’adozione di gerarchie dinamiche implica un

sovraccosto in termini di spazio e puo comportare una forte riduzione delle prestazioni.

E quindi indispensabile valutare con attenzione i casi in cui impiegarle.

2.3 La Business Intelligence (BI)

L’aumento esponenziale del volume dei dati operazionali ha reso il calcolatore l’unico sup-

porto adatto al processo decisionale, inoltre l’utilizzo massiccio di tecniche di analisi dei

dati aziendali ha reso il sistema informativo un elemento strategico per la realizzazione

del business. Per questi motivi il ruolo dell’informatica e passato da passivo strumento

per la registrazione delle operazioni, a fattore decisivo per l’individuazione di elementi

critici dell’organizzazione e di potenziali aree di business.

Il termine Business Intelligence venne introdotto nel 1989 da Howard Dresner, per indi-

care un insieme di strumenti e procedure che consentono a un’azienda di trasformare i

propri dati di business in informazioni utili al processo decisionale, da rendere disponibili

alla persona giusta e nel formato idoneo. Le informazioni ottenute sono utilizzate dai

decisori aziendali (decision maker) per definire e supportare le strategie di business.

L’insieme delle applicazioni IT in un’azienda viene detto portafoglio applicativo (Fi-

gura 2.14) e puo essere diviso in tre segmenti principali:

• Portafoglio direzionale: e l’insieme delle applicazioni utilizzate dai manager

aziendali per analizzare lo stato dell’azienda e prendere le decisioni migliori nel

minor tempo possibile;

• Portafoglio operativo: comprende le applicazioni informatiche per i processi

primari dell’azienda;

• Portafoglio istituzionale: comprende le applicazioni informatiche per i processi

di supporto, quali amministrazione, gestione delle risorse umane, contabilita.


Figura 2.14: Rappresentazione del portafoglio applicativo aziendale

Il portafoglio direzionale viene anche detto piattaforma per la Business Intelligence. Essa,

al fine di garantire ai manager analisi potenti e flessibili, deve possedere un’apposita

infrastruttura hardware e software di supporto composta da:

• Hardware dedicato;

• Infrastrutture di rete;

• DBMS;

• Software di back-end;

• Software di front-end.

Il ruolo chiave di una piattaforma di business intelligence e la trasformazione dei da-

ti aziendali in informazioni fruibili a diversi livelli di dettaglio e, quindi, in conoscenza.

La Figura 2.15 rappresenta quella che viene chiamata piramide della Business Intelligence.

Decisioni efficaci e tempestive:

L’abilita individuale e collettiva dei decision maker, che possiamo indicare con il termine

di knowledge worker, rappresenta uno dei principali fattori che influenzano le prestazioni

e la competitivita di un’organizzazione.


Figura 2.15: Piramide della Business Intelligence: dai dati alla conoscenza

La maggior parte dei knowledge worker elabora le proprie decisioni utilizzando in modo

prevalente metodologie semplici e intuitive, che tengono conto di elementi quali esperienze

passate, conoscenza del contesto, informazioni disponibili. Questa attitudine determina

uno stile decisionale di indole statica, che trova difficolta ad adattarsi a condizioni mu-

tevoli determinate dai cambiamenti dell’ambiente economico. Nelle situazioni reali, i

processi decisionali risultano troppo complessi e dinamici per essere affrontati con effica-

cia mediante analisi intuitive, e richiedono invece un ordinamento piu rigoroso, basato su

metodologie analitiche e modelli matematici.

Un ambiente di business intelligence si propone di offrire ai knowledge worker strumenti

e metodologie che permettono di individuare decisioni efficaci e tempestive.

Decisioni efficaci. Se il decision maker dispone di informazioni e conoscenze piu attendi-

bili, ricavate sulla base di rigorose analisi quantitative, e in grado di formulare decisioni e

piani d’azione che consentono di realizzare con maggiore efficacia gli obiettivi prefissati.

In effetti, il ricorso a strumenti formali di indagine induce i decision maker a descrivere in

modo esplicito i criteri di valutazione delle scelte alternative e i meccanismi che regolano il

fenomeno analizzato. L’attivita di studio e di riflessione che ne scaturisce determina una

maggiore consapevolezza e una comprensione piu approfondita della logica che governa

il processo decisionale.


Decisioni tempestive. Le imprese operano in contesti economici caratterizzati da un ele-

vato livello competitivo e da forte dinamicita. Di conseguenza, la capacita di reagire

in modo tempestivo alle azioni dei competitori e alle nuove condizioni di mercato rap-

presenta un fattore decisivo per determinare il successo di un’impresa o addirittura per

consentire la sua sopravvivenza.

Se il decision maker dispone di un ambiente di business intelligence in grado di faci-

litare il suo compito, ci possiamo attendere che la qualita del processo decisionale ne

tragga un complessivo beneficio [Ver06].

2.3.1 Accedere al data warehouse

Fino ad oggi lo strumento principe per la Business Intelligence e stato sicuramente il Data

Warehouse, le cui installazioni si stanno rapidamente consolidando, oltre che nelle grandi

aziende anche in quelle di media dimensione. In particolare possiamo elencare alcuni dei

meriti che sono riconosciuti al DW: [GR06]

• Consente di gestire serie storiche dei dati;

• Permette di effettuare analisi multidimensionali;

• Si basa su un modello semplice che puo essere facilmente assimilato dai manager;

• E alla base dei sistemi per il calcolo degli indicatori.

Nel capitolo 3 abbiamo accennato a strumenti di accesso ai dati come una componente

dei sistemi di data warehousing. Li avevamo definiti come degli strumenti di front-end che

gli utenti business hanno a loro disposizione per consultare l’area di presentazione, ovvero

il data warehouse. Di seguito presenteremo i due principali approcci all’interrogazione di

un DW da parte degli utenti finali: la reportistica e l’analisi multidimensionale.

Reportistica

E un approccio che permette agli utenti di accedere in modo tempestivo ai dati contenuti

nei DW e nei data mart. Solitamente l’accesso avviene a intervalli di tempo predefiniti

e le informazioni che si ricavano sono strutturate in modo invariabile. Proprio per que-

st’ultimo aspetto solitamente l’interrogazione viene definita a priori secondo quelle che


sono le necessita dell’utente e successivamente integrata in un’applicazione. In questo

modo l’utilizzatore di tale applicazione potra eseguire l’interrogazione quando piu ne ha

bisogno sui dati correnti.

Un rapporto (o report) e scomponibile in due parti: interrogazione e presentazione. L’in-

terrogazione e la parte che andra a reperire i dati di interesse dal DW o data mart, mentre

la presentazione provvede a presentare i dati ottenuti in forma grafica o tabellare. La

validita di uno strumento di reportistica non e data solo dalla ricchezza nella presenta-

zione dei rapporti, ma anche dalla flessibilita dei meccanismi per la loro distribuzione.

Un rapporto infatti puo essere sia generato manualmente dall’utente che automaticamen-

te per una distribuzione periodica agli utenti interessati, per esempio mediante posta

elettronica.

Analisi multidimensionale

L’analisi multidimensionale e la piu nota modalita di reperimento di informazioni con-

tenute in un data warehouse. Si differenzia dalla reportistica statica proprio grazie alla

sua dinamicita, permette infatti di soddisfare quegli utenti le cui necessita di analisi non

sono ben note a priori. Mentre con gli strumenti di reportistica l’utente era limitato ad

un ruolo passivo, con gli strumenti di analisi multidimensionale l’utente svolge un ruolo

attivo durante tutta la sessione di analisi.

Facendo riferimento al concetto di cubo multidimensionale, trattato nel capitolo 4, de-

finiamo ora le operazioni che vengono utilizzate durante l’analisi multidimensionale, le

cosiddette operazioni OLAP. Come prima cosa osserviamo quegli operatori che permet-

tono di modellare la dimensione del cubo e quindi la quantita di dati che esso contiene.

E possibile individuare due categorie distinte.

Restrizione. La grandezza del cubo viene ridotta mediante l’imposizione di vincoli

sugli attributi dimensionali. Esistono sostanzialmente due operatori all’interno di questa

categoria:

• Slice: il cubo viene “tagliato a fettine”. La sua dimensionalita infatti viene ridotta

fissando un valore per una o piu delle dimensioni originarie. Per esempio, per le

vendite potrebbe essere richiesto di osservare le sole vendite dell’anno 2010, in questo

modo viene eliminata la dimensione tempo. Oppure si potrebbe voler osservare le


sole vendite del negozio x relativamente al prodotto y, in tal caso ad essere eliminate

saranno la dimensione negozio e prodotto;

• Dice: il cubo viene “tagliato a cubetti”. Viene ridotto l’insieme dei dati attraverso

la formulazione di un criterio di selezione complesso. Tipicamente la dimensionalita

rimane invariata. Per esempio, per le vendite se si vuole visualizzare le sole vendite

tra il 2004 ed il 2010 per i soli prodotti che presentano un costo superiore ai 100 euro.

Si osserva che con l’imposizioni di tali vincoli la dimensionalita rimane invariata.

Figura 2.16: Operatori di slice-and-dice

Nella letteratura queste due operazioni vengono racchiuse nel termine slice-and-dice (let-

teralmente, tagliare a fettine e cubetti).

Aggregazione. L’aggregazione e un meccanismo di fondamentale importanza nelle basi

di dati multidimensionali. Si supponga di voler analizzare le vendite nel loro dettaglio

mensile, anziche a livello giornaliero; cio significa dover raggruppare, per ciascun prodot-

to e negozio tutte le celle relative ai giorni di uno stesso mese in un’unica macro-cella.

L’aggregazione puo essere operata contemporaneamente su piu dimensioni, ovvero si po-

trebbe decidere di aggregare le vendite per mese, tipo di prodotto e citta del negozio.

Anche in questo caso si possono individuare due operatori:

• Roll-up: talvolta indicato col termine drill-up, significa letteralmente arrotolare o

alzare. Con questa operazione si induce un aumento nell’aggregazione dei dati

eliminando un livello di dettaglio da una gerarchia. Puo essere utilizzata anche per

ridurre la dimensionalita del risultato, qualora tutti i dettagli di una certa gerarchia

vengano eliminati. Ad esempio, la rimozione della dimensione tempo conduce a


consolidare le misure tramite la somma su tutti i periodi temporali presenti nel

cubo di dati;

• Drill-down: talvolta indicato con il termine roll-down, significa letteralmente trivel-

lare. E il duale dell’operatore roll-up, infatti esso diminuisce l’aggregazione dei dati

introducendo un ulteriore livello di dettaglio in una gerarchia. Per esempio, puo

essere utilizzato per passare dall’aggregazione per regione del cliente a quella, piu

fine, per citta del cliente. Come il roll-up permette di ridurre la dimensionalita, il

drill-down, essendo il suo duale, permette di aumentarla. Potremo infatti visualiz-

zare gli incassi annuali di ogni categoria di prodotto, aggiungendo le informazioni

sull’area geografica dei clienti.

Figura 2.17: Effetti degli operatori di roll-up e drill-down sul cubo multidimensionale

Aggregazione e restrizione possono essere combinate per permettere un processo di analisi

mirato con precisione alle esigenze dell’utente.

Come osservato in precedenza, le operazioni descritte sin ora permettono di alterare la

quantita di dati da analizzare secondo quelle che sono le specifiche dell’analisi. Esistono

tuttavia altre operazioni che possono essere usate per manipolare il cubo, e sono:

• Pivoting: talvolta chiamata rotazione, permette di ruotare gli assi scambiando tra

loro alcune dimensioni per ottenere una diversa vista sul cubo di dati;

• Drill-across: permette di stabilire un collegamento tra due o piu cubi correlati al

fine di compararne i dati;

• Drill-through: e disponibile solo in alcuni strumenti OLAP e consiste nel passaggio

dai dati aggregati multidimensionali del data warehouse ai dati operazionali presenti

nelle sorgenti o nel livello riconciliato.


2.3.2 Business Intelligence: oltre il data warehouse

Nel precedente paragrafo abbiamo evidenziato le caratteristiche che hanno permesso il

successo del data warehouse come strumento per la business intelligence. Tuttavia la

sua ampia diffusione ha comportato una rapida maturazione degli utenti che, comprese

appieno le sue potenzialita, cominciano a percepirne i limiti. Alcuni di queste limitazioni

sono:

• I dati vengono aggiornati con una periodicita che difficilmente e inferiore alla

settimana/giorno.

• Quando vengono eseguite complesse interrogazioni, al di fuori del modello multidi-

mensionale, il DW risulta essere poco efficiente;

• Registra solo il passato e non offre scenari per la formulazione di previsioni.

L’utente necessita di tecniche di analisi piu potenti e non basate sul modello multidimen-

sionale, analisi che gli permettano di operare su dati provenienti da fonti eterogenee e

con aggiornamenti piu rapidi. Inoltre sorge la necessita di poter “predire il futuro”.

A tali scopi si propongono varie soluzioni: il data mining, un processo di esplorazione e

analisi di un insieme di dati, generalmente di grandi dimensioni, per individuare eventua-

li regolarita, estrarre conoscenza e ricavare regole ricorrenti significative; l’analisi what-if

che permette di formulare scenari di previsione basati su modelli di business e trend

aziendale; il business-performance-management (BPM), inteso come un framework per

il controllo della performance aziendale che permette di condividere la strategia scelta a

tutti i livelli dell’azienda. Il data mining e l’analisi what-if sono tecniche ben note nella

letteratura, ma che tuttavia, a causa della loro complessita, sono state quasi sempre igno-

rate in ambito aziendale, in favore del data warehousing, la cui complessita risulta essere

decisamente inferiore. Il BPM invece rappresenta una soluzione innovativa soprattutto

dal punto di vista tecnologico.

Al giorno d’oggi il panorama aziendale e da considerarsi pronto per utilizzare tecniche

all’avanguardia come quelle appena descritte.


2.3.2.1 Data Mining

Le attivita di data mining costituiscono un processo di analisi di natura iterativa svolto su

voluminose basi di dati, con l’obiettivo di estrarre informazioni e conoscenze che risultino

accurate e potenzialmente utili ai knowledge worker nel corso dei processi decisionali.

Prendiamo in considerazione l’analisi multidimensionale e osserviamo come essa non per-

metta all’utente di individuare modelli significativi come sequenze ripetute, correlazioni

e associazioni tra i dati o raggruppamenti interessanti all’interno della grande mole di

dati che si vuole esaminare. I modelli appena citati sono solo alcuni esempi di quelli che

vengono chiamati pattern, ovvero una rappresentazione sintetica e ricca di semantica di

un insieme di dati (Rizzi, 2003). Il data mining raccoglie tutta una serie di metodologie

dell’intelligenza artificiale e del pattern recognition come per esempio algoritmi genetici,

logica fuzzy e reti neurali, con l’obiettivo di aiutare l’utente nel processo di estrazione

della conoscenza (knowledge discovery). Il processo di knowledge discovery, rappresentato

in Figura 2.18, e di tipo iterativo e prevede quattro fasi distinte: [GR06]

• Selezione: vengono selezionati i dati da sottoporre al processo. Essi possono

provenire da data base operazionale, dal data warehouse oppure da data stream

alimentati per esempio dalle macchine di produzione;

• Preparazione: i dati vengono ripuliti e trasformati nel formato richiesto dagli algo-

ritmi del passo successivo;

• Data mining : viene scelto ed eseguito l’algoritmo opportuno per generare i pattern;

• Valutazione: I pattern individuati vengono visualizzati ed esaminati. Se i risultati

non sono soddisfacenti si innesca una retroazione verso le fasi precedenti.

Vediamo ora alcune delle principali funzionalita di data mining ed i relativi pattern che

esse si prestano ad individuare.

Caratterizzazione. E un processo che si focalizza su un attributo target e opera su

di esso con svariate finalita. Puo infatti operare una caratterizzazione di tale attributo

osservando il valore che esso assume per tutti i record che appartengono ad una deter-

minata classe, oppure evidenziare la distribuzione dei valori che l’attributo assume per

i record appartenenti ad una medesima classe confrontandoli, per esempio, con quelli


Figura 2.18: Il processo di knowledge discovery

di una classe diversa. E una tecnica molto semplice da realizzare e i risultati vengono

visualizzati all’utente in forma grafica.

Serie storiche. Talvolta l’attributo target e soggetto ad un’evoluzione temporale che

consiste in una sequenza dei valori che tale attributo assume. Le serie storiche sono una

funzionalita di data mining che studiano fenomeni caratterizzati da una dinamica tempo-

rale e si propongono di predire il valore della variabile target per uno o piu periodi futuri.


Regole associative. Consentono di determinare le regole di implicazione logica presenti

nella base di dati, ovvero regole della forma:

X ⇒ Y

Se per esempio X e Y sono insiemi di prodotti , avremo che le transazioni che contengono

prodotti in X tendono a contenere anche quelli in Y. Ad ogni regola riscontrata vengono

attribuite due misure: il supporto e la confidenza. Con il supporto si indica la percen-

tuale delle transazioni che contengono sia X che Y, mentre la confidenza indica in che

percentuale le transazioni che contengono X contengono anche Y.

Le aziende della grande distribuzione ricorrono a regole di associazione per pianificare la

disposizione dei prodotti sugli scaffali o nei cataloghi

Clustering. Il termine cluster viene utilizzato per riferirsi ad un sottogruppo omogeneo

presente all’interno di una popolazione. Le tecniche di clustering svolgono operazioni

di segmentazione di una popolazione eterogenea. Solitamente e una tecnica che viene

utilizzata durante la fase preliminare di data mining, in quanto consente di individuare

categorie di dati tra loro omogenei, consentendo cosı alle successive attivita di mining di

focalizzarsi sul cluster in interesse.

Alberi decisionali. Vengono utilizzate per comprendere un determinato fenomeno,

permettono infatti di classificare, in ordine di importanza, le cause che portano al verifi-

carsi di un evento. In prossimita di ciascun nodo dell’albero viene effettuata una scelta,

solitamente attraverso il confronto di un attributo con una costante; gli archi che esco-

no dal nodo rappresentano l’esito del confronto. Le decisioni finali sono contenute nelle

foglie.


2.3.2.2 Analisi what-if

Assumendo un particolare insieme di condizioni iniziali l’analisi what-if consente di for-

mulare alcuni scenari di previsione al fine di valutare il comportamento di un sistema

reale. E evidente come questo tipo di approccio superi quelli che sono i limiti delle ana-

lisi che si basano sulla semplice consultazione del data warehouse (ovvero reportistica ed

analisi multidimensionale, osservate nel paragrafo precedente).

Come prima cosa l’analista dovra riprodurre un modello che sia in grado di simulare il

sistema in esame, ovviamente maggiore sara l’accuratezza con il quale viene disegnato,

piu attendibili saranno i risultati che da esso si ricaveranno. In genere il modello viene

costruito mediante un processo iterativo, dove ad ogni passo viene verificato il suo com-

portamento confrontando i risultati in output con un insieme di dati di test. Le tecniche

di analisi what-if possono essere classificate in base al metodo utilizzato per la creazione

del modello. Esistono sostanzialmente due tipologie:

• Tecniche induttive: Sono le soluzioni piu semplici da realizzare in quanto vengono

osservati solo gli effetti del comportamento di un sistema, mentre le cause sono

completamente ignorate. La costruzione del modello fa riferimento al principio

descritto sinteticamente dalla seguente frase: “se fino ad ora e andata cosı, andra

cosı anche dopo!”. Le tecniche induttive si basano infatti sul comportamento che il

sistema ha avuto durante un certo intervallo temporale. Per questo motivo vengono

talvolta dette estensionali;

• Tecniche deduttive: I problemi osservati nell’approccio induttivo vengono superati

grazie ad una approfondita conoscenza delle regole che governano il sistema. Il

modello che verra generato sara caratterizzato da un insieme di rapporti del tipo

causa-effetto. I limiti di queste tecniche emergono nel caso in cui i rapporti prima

citati formino dei cicli di retroazione.

Solitamente, indipendentemente dalla tecnica scelta, la modellazione viene effettuata sui

dati del data warehouse, poiche esso rappresenta il principale serbatoio che memorizza le

serie storiche degli eventi verificatisi in azienda.


2.3.2.3 Business Performance Management (BPM)

Fusione e acquisizioni, cambiamenti nei modelli di business, nuovi requisiti industriali e

mutamenti nelle aspettative dei clienti pongono un grande numero di problemi a livello

di processi che le aziende devono continuamente affrontare. La gestione dei processi bu-

siness consente alle aziende di gestire i cambiamenti incrementali dei processi che sono

richiesti simultaneamente in molte aree dell’azienda.

Business Performance Management (BPM). Insieme di attivita atte a mi-

surare le proprie prestazioni incoraggiando l’efficacia dei processi aziendali e l’uso

efficiente delle risorse umane, materiali ed economiche.

La misurazione delle prestazioni dei processi aziendali puo essere realizzata mediante

degli specifici indicatori detti Key Performance Indicator (KPI). Il punto di forza

dei KPI e quello di permettere ai manager di fissare delle regole che non si prestino a

equivoci o a interpretazioni personali, il che non accade quando si utilizzano allo stesso

tempo regole di comportamento e direttive aziendali.

Il BPM richiede che i valori degli indicatori siano continuamente aggiornati e resi di-

sponibili al momento giusto nella forma piu adatta a supportare le attivita decisionali.

Si differenzia dalla classica soluzione di data warehousing per le seguenti caratteristiche:

[GR06]

• Utenti : il BPM interessa sempre i decisori, ma a livello operativo e tattico anziche

strategico;

• Tempo di risposta: dal momento che le decisioni dei livelli tattico e operativo devono

avvenire con maggior frequenza rispetto a quelle del livello strategico, i sistemi di

BPM dovranno avere periodi di aggiornamento piu brevi rispetto a quelli del data

warehouse;

• Livello di dettaglio: poiche gli eventi di interesse dei BPM sono attivita ben speci-

fiche, il dettaglio delle informazioni che dovranno avere a disposizione e di conse-

guenza piu elevato rispetto a quello del data warehouse;

• Tempo di vita: a differenza del livello di dettaglio, il tempo di vita delle informazioni

per il BPM sara decisamente minore rispetto a quello che richiedono i sistemi di


data warehousing. Questo perche gli utenti BPM sono interessati alle performance

attuali della propria attivita;

• Interfaccia utente: le informazioni verranno presentate all’utente sotto forma re-

port o tramite allarmi innescati automaticamente mediante il controllo di regole di

business.

Alla luce di quanto appena detto risulta evidente come DW e BPM siano profondamente

differenziati e allo stesso tempo complementari.

Si noti come BPM sia anche l’acronimo utilizzato per il business process management che

pero e inerente alle modalita di gestione aziendale per processi.

2.3.3 Ciclo delle analisi di Business Intelligence

Ciascuna analisi di business intelligence si sviluppa secondo modalita autonome che ri-

sentono del contesto, delle caratteristiche soggettive dei decision maker e degli strumenti

analitici disponibili. Tuttavia e possibile identificare un percorso ideale che caratterizza

l’evoluzione delle singole analisi di business intelligence, come rappresentato in Figura 2.19

[Ver06].

Figura 2.19: Fasi di un’analisi di business intelligence

Analisi. In questa fase si deve comprendere in maniera precisa il problema da affrontare,

un decision maker elabora un modello del fenomeno analizzato, selezionando i fattori che

risultano maggiormente rilevanti. La possibilita di esplorare secondo diverse viste logiche

i cubi di dati nel corso delle analisi multidimensionali, permette a un decision maker di


modificare con flessibilita e tempestivita le sue ipotesi. Osserviamo quindi come le me-

todologie di business intelligence permettano di sviluppare rapidamente diversi percorsi

di analisi.

Comprensione. In un secondo momento il decision maker dovra approfondire ogni

caratteristica del problema rilevato durante la fase di analisi. In pratica si tratta di tra-

sformare le informazioni precedentemente identificate in conoscenza. Questo processo di

trasformazione puo avvenire mediante l’intuizione e l’esperienza del decision maker op-

pure tramite eventuali informazioni non strutturate in suo possesso.

Decisione. E la fase in cui le conoscenze vengono tradotte in decisioni e successivamente

in azioni. La business intelligence permette di svolgere le fasi di analisi e comprensione

in modo piu rapido e di conseguenza anche decisioni piu efficaci e tempestive.

Misura. Durante la fase di misura ci si preoccupa di misurare le prestazioni, basate

su metriche comprendenti non solo indicatori finanziari ma anche prestazionali relativi ai

diversi segmenti aziendali.

Le metodologie di business intelligence riducono i tempi del ciclo analisi-decisione-azione-

revisione, con un miglioramento della qualita dei processi decisionali.

CAPITOLO 3

La tecnologia Oracle BI 11g

Introduzione al mondo Oracle

La Oracle Corporation e una multinazionale americana specializzata nello sviluppo e

commercializzazione di sistemi hardware e prodotti software enterprise. Ha sede in Cali-

fornia, nella Silicon Valley.

Venne fondata nel 1977 da Larry Ellison, Bob Miner e Ed Oates con il nome “Software

Development Laboratories” (SDL). Due anni dopo, nel 1979, la societa venne rinominata

“Relational Software Inc.”. Negli anni Ottanta, in seguito al successo del progetto Oracle,

un database commissionato dalla CIA, la societa assunse il suo nome attuale.

Presente in oltre 145 paesi nel mondo, Oracle Corporation oggi produce, sviluppa, com-

mercializza e offre servizi legati all’infrastruttura tecnologica, alle business applications e

ai sistemi hardware.

Dal gennaio 2005 con l’acquisizione di PeopleSoft, e quindi della piattaforma ERP JD

Edwards, Oracle ha lanciato la sua strategia di acquisizioni che fino ad ora l’ha portata

ad acquisire quasi 60 aziende e a raggiungere numerosi primati. In particolare, People-

soft ha assicurato la leadership nelle applicazioni per la gestione delle Risorse Umane,

Siebel Systems in area CRM, Hyperion in ambito Enterprise Performance Management

e Business Intelligence; mentre BEA Systems ha assicurato dei primati in alcune aree

54 La tecnologia Oracle BI 11g

del Middleware. Con Sun Microsystems, Oracle ha esteso la propria proposta anche ai

sistemi operativi e ai sistemi hardware oltre a diventare proprietario di Java.

Nel nostro Paese, Oracle e presente dal 1993 con sedi principali a Milano e Roma e con

filiali a Torino, Padova, Bologna e Vercelli.

Oracle in Italia opera al fianco di circa 900 Business Partner e dedica loro uno specifico

programma, denominato Oracle PartnerNetwork (OPN) Specialized, a garanzia di un

supporto continuativo ed efficiente [Oraa].

3.1 Oracle e la business intelligence

In questa sezione sono riportati gli aspetti del pensiero Oracle riguardo alla costruzione

di un business case per la business intelligence [Ora09].

Business case. E la collezione di (buoni) motivi per dare il via ad un progetto.

Il business case tipico per la BI e quello di aiutare a prendere decisioni migliori, tut-

tavia avere le giuste informazioni e solo una parte del processo decisionale. I benefici

dell’avere una soluzione di BI si realizzano quando si implementa una decisione e non

dal processo decisionale in se. Una soluzione di BI, aiuta a migliorare le funzionalita di:

reportistica, analisi e previsioni (in ordine dalla meno importante alla piu importante).

Ogni business case inizia con una comprensione del livello di ambizione che l’azienda

sceglie di avere. Esistono tre differenti livelli di ambizione:

• Efficienza: Concentrarsi sul miglioramento dell’efficienza aiuta gli utenti a lavorare

meglio nell’ambito delle mansioni che gia svolgono;

• Efficacia: Curare l’aspetto dell’efficacia del business aiuta l’organizzazione ad

operare le scelte giuste;

• Cambiamento: Consente di avere la possibilita di fare nuove cose.

I diversi incarichi che le persone ricoprono in azienda portano ciascuno ad avere una

prospettiva diversa del medesimo problema. Si noti, infatti, che i responsabili IT foca-

lizzeranno la loro attenzione sull’efficienza, mentre i dirigenti aziendali sono interessati a

gestire il cambiamento.

3.1 Oracle e la business intelligence 55

Un business case per la business intelligence e disegnato su cinque distinti livelli:

• Dati ed infrastruttura;

• Strumenti di BI ed applicazioni di gestione delle prestazioni;

• Uso, governance e BICC (BI Competency Center, coordina la gestione delle infor-

mazioni);

• Processi gestionali ed operativi;

• Strategia di business.

I vari livelli si “appoggiano” uno all’altro. E quindi necessario coinvolgere tutti i livelli in

modo da creare un link diretto tra i requisiti di business del cliente e le varie componenti

che costituiscono la struttura operativa che supporta i suddetti requisiti.

I livelli di ambizione possono essere combinati con quelli appena descritti generando la

Tabella 3.1, nelle celle sono riportati degli esempi di attivita che devono essere affrontate

durante la realizzazione del business case.

Standardizzazione degli strumenti di BI

Riportiamo al lettore i risultati di due ricerche relative all’impiego delle tecnologie di

business intelligence all’interno delle aziende:

• il 40% delle organizzazioni utilizzano ancora dai 3 ai 5 strumenti di BI, ed oltre il

20% almeno 6 o piu strumenti di BI (Forrester Research, 2008);

• le aziende che hanno implementato una soluzione di BI usando gli strumenti di un

unico fornitore software sono aumentate dal 24% del 2005 al 42% del 2007. Dal

sondaggio del 2007 e anche emerso che le aziende che hanno classificato la propria

soluzione BI come “di successo” implementavano un sistema realizzato utilizzando

gli strumenti di un unico fornitore software.

La Figura 3.1 illustra la situazione appena descritta


Efficienza Efficacia Cambiamento

Strategia di Eccellenza Eccellenza Nuovi modelli

business operativa gestionale di business

Processi Riduzione dei Creazione di un’ Nuovi processi di

costi, maggiori

prestazioni, piu

qualita

organizzazione

che sia moderna,

agile ed allineata

business, integrazione

della catena per la

crezione del valore

Uso e governance Il BICC Il BICC crea BICC esteso,

supporta gli stru-

menti usati

e condivide cono-

scenza all’interno

dell’organizzazio-

ne

creazione e condivisio-

ne della conoscenza al-

l’interno di tutta la

catena della creazione

del valore

Strumenti di BI e

applicazioni di ge-

stione delle presta-

zioni

Standardizzazione

degli strumenti

Aggiunta di nuo-

ve funzionalita

Converge con la ge-

stione dei processi di

business, le applica-

zioni business ed il

middleware

Dati ed infrastrut-

tura

Concentrarsi sul

TCO

Fare il punto sul-

la flessibilita

Implementazione

di un’architettura

orientata ai servizi

(SOA)

Tabella 3.1: Matrice business case per la BI.

3.1 Oracle e la business intelligence 57

Figura 3.1: Standardizzazione degli strumenti e successo della BI

La proposta Oracle, per quanto riguarda gli strumenti di business intelligence, e data

dalla suite Oracle Business Intelligence Foundation. Essa e composta da Oracle Business

Intelligence Enterprise Edition, Oracle BI Publisher, Oracle Essbase, Oracle Scorecard e

Strategy Management e Oracle Essbase Analytics Link (EAL) [Ora11a].

Il componente di maggior rilievo e senza dubbio la suite Oracle Business Intelligence En-

terprise Edition (da ora in poi piu semplicemente OBIEE), giunta alla versione 11.1.1.3.0,

rilasciata il 13 agosto 2010. La Figura 3.2 fornisce una panoramica della sua architettura.

Figura 3.2: Architettura di OBIEE 11g


La suite OBIEE 11g, e completamente integrata con il Fusion Middleware di Oracle.

Questo, dal punto di vista architetturale, si traduce principalmente con l’adozione di

Oracle Web Logic Application Server come piattaforma per tutti i servizi JEE della

suite, a cui si affiancano i servizi C++ e J2SE ereditati dalla precedente release.

3.2 Architettura logica

L’architettura logica del sistema Oracle Business Intelligence e composta da un unico in-

sieme integrato di componenti gestibili, detto dominio BI (BI domain). Tali componenti

possono risiedere su di un unico host oppure essere separati in piu host per ragioni di

performance, disponibilita e sicurezza.

Figura 3.3: Architettura logica di OBIEE 11g su un singolo host

3.2 Architettura logica 59

Un dominio BI e composto da: componenti Java, componenti di sistema e da un insieme

di altri componenti tra cui repository dei metadati e presentation catalog [Orad].

Componenti Java

Vengono distribuiti come applicazioni JEE per servizi SOAP, HTTP ed altre forme di

richiesta. Nell’architettura mostrata in Figura 3.3 possiamo notare la presenza di due

contenitori JEE: l’Administration Server ed il Managed Server.

L’Administration Server contiene i componenti Java necessari per l’amministrazione

del sistema. Tali componenti sono:

• JMX MBeans: provvede a schematizzare gli accessi per la gestione del dominio BI;

• Fusion Middleware Control: e l’interfaccia utente di amministrazione usata per

gestire il dominio BI;

• WebLogic Server Administration Console: e l’interfaccia utente di amministrazione

per la gestione avanzata di WebLogic, componenti JEE e sicurezza.

Figura 3.4: Architettura logica di OBIEE 11g su piu host


Il Managed Server fornisce l’ambiente di run-time per servizi Java-based e applicazioni

interne al sistema. Un dominio di BI puo possedere piu Managed Server che possono

essere distribuiti su uno o piu host. I componenti Java gestiti sono:

• Action Services: fornisce i servizi Web dedicati che vengono richiesti dall’Action

Framework (descritto nel paragrafo 3.4.5) e che consentono all’amministratore di

configurare manualmente quali directory del servizio Web possono essere sfogliate

dagli utenti quando questi eseguono una determinata azione;

• SOA Services: fornisce servizi Web dedicati per gli oggetti nel presentation catalog

per invocare analisi, agenti e condizioni;

• BI Office: provvede all’integrazione tra OBIEE ed i prodotti Microsoft Office;

• Real-Time Decisions (RTD): fornisce soluzioni software enterprise di analisi che

permettono alle aziende di prendere le migliori decisioni in tempo reale;

• BI Plugin: e un’applicazione JEE che ha il compito di instradare le richieste SOAP

e HTTP ai Presentation Services (che saranno descritti in seguito);

• BI Publisher: fornisce una soluzione di reportistica per la creazione, gestione e

distribuzione di report “pixel perfect” a dipendenti, clienti e fornitori;

• Security Services: fornisce servizi Web dedicati che consentono l’integrazione del BI

Server (che descriveremo in seguito) con la piattaforma di sicurezza Oracle Fusion

Middleware.

Sia l’Administration che il Managed Server vengono eseguiti su Java virtual machine

dedicate.

Infine il Node Manager fornisce servizi per la gestione dei processi per l’Administration

ed il Managed Server. Esso infatti permette di avviare, arrestare e riavviare le loro istanze

in remoto.

Componenti di sistema

I componenti di sistema forniscono i servizi base (C++ o J2SE) per poter eseguire OBIEE,

e sono:

3.2 Architettura logica 61

• BI Server: fornisce le funzionalita di query ed accesso ai dati che sono il cuore di

OBIEE;

• Presentation Services: forniscono il framework e l’interfaccia per la presentazione

dei dati di business intelligence. E loro compito gestire il Presentation Catalog (che

sara trattato successivamente);

• Scheduler: permette di schedulare la consegna di analisi agli utenti in momenti

specifici. BI Publisher possiede uno scheduler proprio;

• JavaHost: offre servizi che permettono al Presentation Server di supportare com-

ponenti come i task dello Scheduler, BI Publisher e la generazione dei grafici;

• Cluster Controller: ha il compito di distribuire le richieste al BI Server ed assicurare

che il carico di lavoro di tali richieste siano bilanciate su tutti i BI Server nel dominio

BI.

L’OPMN (Oracle Process Manager and Notification server) ha il compito di gestire i

componenti appena descritti.

Repository dei metadati

Il repository dei metadati e un file con estensione rpd dalle dimensioni solitamente com-

prese tra 0.5MB e 2MB. Ha il compito di memorizzare i metadati di cui necessita il BI

Server per trasformare una query logica, ovvero una interrogazione che viene costruita

dall’utente che non e a conoscenza della struttura delle sorgenti, nella relativa query fisica

da eseguire sui dati sorgente. Un repository e suddiviso in tre livelli, come mostrato in

Figura 3.5: [Orac]

• Livello fisico: definisce gli oggetti e le loro relazioni, necessarie al BI Server per

costruire le query native sui dati fisici. Puo essere creato importando tabelle, cubi

e flat file dalle fonti dati. Il livello fisico ha il compito di separare il comportamento

logico delle applicazioni dal modello fisico, dando quindi la possibilita di unire piu

fonti dati fisiche in un unico oggetto logico. Una separazione di questo tipo assicura

una elevata portabilita;


Figura 3.5: Traduzione di una query logica nella relativa query fisica attraverso i 3 livelli

del repository

• Livello logico: definisce il modello business dei dati e la mappatura con gli schemi

fisici. In questo livello si determina il comportamento analitico percepito dagli utenti

e viene definito l’insieme degli oggetti e delle relazioni a disposizione dell’utente;

• Livello di presentazione: fornisce un modo sicuro e personalizzato per rappresen-

tare il modello business. Nel livello di presentazione vengono create le cosiddette

subject area che permettono di suddividere il modello business in piu parti.

Il repository dei metadati viene gestito dall’Administration Tool, un’applicazione Win-

dows appartenente alla suite dei client tools, trattata nel paragrafo 3.5

Come accennato in precedenza, il BI server si serve del repository per trasformare le query

logiche nelle query native che saranno poi eseguite sui dati sorgente. La Figura 3.6 mo-

stra come il BI Server interagisce con le query dei client, le sorgenti dati, l’Administration

Tool e il repository.

Presentation Catalog

Ha il compito di memorizzare in una struttura di directory gli oggetti creati dagli utenti.

Tali oggetti possono essere: analisi, dashboard, filtri, prompt, ecc. Ogni qual volta un

utente salva un oggetto come quelli appena indicati, esso verra automaticamente memo-

rizzato all’interno del Presentation Catalog.

3.3 Installazione del prodotto 63

Figura 3.6: Architettura del BI Server

Come per il repository esiste un’applicazione anche per la gestione del Presentation

Catalog ed e il Catalog Manager.

3.3 Installazione del prodotto

Requisiti di sistema

OBIEE 11g offre senza dubbio un’architettura piu scalabile e strumenti di gestione piu

maturi rispetto la release precedente. Per contro, la complessita di gestione e superiore

e sono richieste maggiori risorse di sistema. I requisiti di sistema consigliati da Oracle

sono: [Ora11b]

• Spazio su disco: 20GB o piu;

• Memoria RAM: 4GB o piu;

• Spazio temporaneo: 950MB o piu;

• Spazio di swap: 3GB o piu;

• CPU: dual-core Pentium, 1.5GHz o maggiore.


DBMS supportati:

• Oracle 10.2.0.4+ , 11.1.0.7+, 11.2.0.1+;

• IBM DB2 9.1+, 9.5+, 9.7+;

• MS SQL Server 2005, 2008;

• Teradata 12, 13.

Sistemi operativi supportati: [Orae]

• Oracle/Red Hat Enterprise Linux 4 (Update 7+), 5 (Update 3+);

• SUSE Linux Enterprise Server 10 (SP1+), 11;

• Windows 2003 SP2/R2+;

• Windows Server 2008 SP1+;

• Windows Server 2008 R2.

Installazione

Il pacchetto di installazione di Oracle Business Intelligence, include i seguenti prodotti:

[Orab]

• OBIEE 11g (Answers, Dashboards, Delivers, Repository Administration Tool, Of-

fice e Oracle Business Intelligence Publisher);

• Oracle Business Intelligence Publisher;

• Oracle Real-Time Decisions.

E possibile installare uno, due o tutti e tre i prodotti che condivideranno la stessa

struttura Oracle Fusion Middleware all’interno del medesimo dominio WebLogic. Una

tipica installazione di Oracle BI prevede una Fusion Middleware home e le seguenti

sottodirectory:

• wlserver 10.3 : e la home del WebLogic server e contiene: i componenti Java, un

Administration Server e uno o piu Managed Server;

3.3 Installazione del prodotto 65

• user projects : contiene i domini dei prodotti, inclusi uno o piu domini BI;

• Oracle BI1 : contiene i file binari (in sola lettura) propri di Oracle Business Intelli-

gence.

Figura 3.7: Tipica struttura delle directory di Oracle BI

Sono inoltre previste tre modalita di installazione:

• Simple Install : l’installazione verra eseguita con i settaggi di default, su un singolo

computer e nel minor numero di passi;

• Enterprise Install : permette di effettuare una installazione enterprise distribuita.

La configurazione non e quella di default, sara possibile infatti specificare impo-

stazioni come: percorsi delle directory, nomi degli host, numeri di porta e molto

altro;

• Software Only : con questa modalita di installazione vengono installati i soli file

binari, la configurazione dovra per tanto essere eseguita separatamente. Per sistemi

a 64-bit costituisce l’unica modalita di installazione possibile.

Non esiste un’unica procedura di installazione. Essa dipende dal sistema operativo (Win-

dows o Linux) e dalla sua architettura (32 o 64 bit). Cio che le accomuna e la necessita di

creare uno schema su un database mediante l’utility RCU (Repository Creation Utlity).

Per installazioni su macchine a 64 bit o macchine Linux non e prevista l’installazione

dei client tools, in quanto questi ultimi sono disponibili solo per macchine Windows 32-

bit. E tuttavia possibile scaricare ed installare i soli client tools, facendoli poi collegare


in remoto con il server sul quale e installato OBIEE.

Per i sistemi a 64 bit e inoltre richiesto che l’installazione della JDK e di WebLogic

venga fatta separatamente prima di procedere all’installazione, che avverra in modalita

“Software Only”.

3.4 Componenti di front-end

OBIEE 11g fornisce una suite completamente integrata di prodotti complementari per

fornire una gamma completa di funzionalita di analisi.

I Presentation Services forniscono l’interfaccia utente che viene utilizzata per la visualiz-

zazione dei dati provenienti dal BI Server. Tramite questa interfaccia gli utenti possono

accedere agli strumenti di front end che verranno descritti di seguito [Ora11a].

3.4.1 Analisi e reportistica

OBIEE 11g mette a disposizione dell’utente un ambiente web per la creazione di analisi,

reportistica e query ad-hoc. Questo ambiente era conosciuto nella precedente versione con

il nome di “BI Answers”, in OBIEE 11g si parlera di “BI Analysis and Reporting”.

Le funzionalita messe a disposizione dell’utente sono:

• Indipendenza dai dati sorgente: gli utenti interagiscono con una vista logica delle

informazioni, che maschera completamente la complessita della struttura dei dati

sorgente. Inoltre non e richiesto che gli utenti siano a conoscenza di come le regole

business sono calcolate. Esse infatti vengono definite nel repository (come descritto

precedentemente);

• Condivisione online delle analisi: una volta salvata la propria analisi, l’utente po-

tra condividerla online pubblicandola all’interno di una Dashborad (trattate nel

paragrafo 3.4.2);

• Salvataggio delle analisi: misure, attributi descrittivi, filtri, pattern di ordinamento,

grafici e viste in tabelle pivot possono essere aggiunte, eliminate e modificate in ogni

momento. Al termine delle modifiche, la nuova analisi puo essere salvata e condivisa

con un gruppo di utenti;

3.4 Componenti di front-end 67

• Potenti analisi ad-hoc: poiche il processo analitico e spesso iterativo, non vengono

imposti vincoli sull’ordine con il quale l’analisi viene costruita. Infatti, per esempio,

la selezione delle misure, l’aggiunta o la modifica di filtri, l’aggiunta o la rimozione

di colonne e la possibilita di visualizzare il risultato, sono attivita che possono essere

effettuate in un qualsiasi momento ed ordine durante la costruzione delle analisi;

• Personalizzazione: le informazioni a cui accedono gli utenti vengono filtrate e

personalizzate automaticamente in base all’identita e al ruolo dell’utente stesso.

Una sessione di analisi in OBIEE 11g comincia con la selezione della subject area, per

esempio le vendite. Successivamente vengono mostrati all’utente tutti gli oggetti business

che avra a disposizione per costruire l’analisi. Una volta terminato, il BI Analysis and

Reporting genera la relativa query in SQL logico e la invia al BI Server che provvede a

convertirla nella equivalente query fisica.

La Figura 3.8 mostra l’interfaccia messa a disposizione dell’utente per la creazione delle

analisi. A sinistra possiamo notare la subject area, mentre al centro la visualizzazione

del risultato.

Figura 3.8: Costruzione di un’analisi con BI Analysis and Reporting

Una caratteristica fondamentale che un’analisi deve possedere e la chiarezza del risultato.

OBIEE 11g offre svariate modalita di visualizzazione tra cui grafici e diagrammi, tabelle

pivot, viste geospaziali, ecc.


3.4.2 Dashboard

Una dashboard (o cruscotto) e una collezione di oggetti che, raccolti per aree tematiche,

mostrano un certo quadro della situazione. La maggior parte di tali oggetti vengono

creati mediante BI Analysis and Reporting. Le dashboard hanno il compito di facilitare

l’accesso degli utenti ad analisi costruite in precedenza e offrono le seguenti funzionalita:

• Potenza di analisi: le dashboard costituiscono un potente ambiente per l’analisi

interattiva dei dati, in quanto permettono la loro navigazione;

• Condivisione online delle informazioni: la possibilita di pubblicare online le dash-

board costituisce un fondamentale metodo per la condivisione delle informazioni;

• Personalizzazione: ogni cruscotto puo essere personalizzato in modo tale da vi-

sualizzare automaticamente i dati in base all’identita e al ruolo dell’utente che li

richiede;

• Filtraggio dati: possono essere visualizzate analisi prefiltrate da valori di default o

immessi manualmente dagli utenti;

• Condivisione offline delle informazioni: le dashboard possono essere salvate e di-

stribuite per un utilizzo di tipo offline come report o Briefing Book (decritti nel

paragrafo 3.4.6). Inoltre il contenuto di un cruscotto puo essere scaricato in file

Excel o PowerPoint;

• Salvataggio personalizzazioni: gli utenti possono modificare analisi, filtri, layout,

ecc. e salvare le modifiche sia per uso personale che condiviso;

• Personalizzazione dello stile: Il look and feel delle dashboard puo essere modificato

utilizzando i Cascading Style Sheet (CSS).

Gli utenti interagiscono con le dashboard filtrando i dati mediante l’inserimento di valori

in un prompt, eseguendo operazioni di drill-down per accedere a informazioni piu detta-

gliate, modificando l’ordinamento delle colonne, ecc.

La creazione dei cruscotti, molto spesso, avviene per mano degli utenti stessi senza nessun

coinvolgimento di specialisti IT.

La Figura 3.9 mostra un esempio di dashboard.


Figura 3.9: Un esempio di dashboard interattiva

3.4.3 Scorecard e Strategy Management

Oracle Scorecard e Strategy Management estende la suite Oracle BI con funzionalita de-

stinate a comunicare gli obiettivi strategici in tutta l’organizzazione e il monitoraggio dei

loro progressi nel tempo. Permette di stabilire obiettivi specifici, definire le modalita per

misurare il loro successo, e comunicare informazioni a tutta l’organizzazione. I dipendenti

possono quindi capire il loro impatto sul raggiungimento del successo e allineare le loro

azioni di conseguenza.

Figura 3.10: Un esempio di scorecard


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:


• rilevare il verificarsi di determinate condizioni e di inviare degli alert agli utenti

interessati;

• avviare direttamente processi esterni.

Queste funzionalita vengono offerte rispettivamente dal BI Delivers e dall’Action Fra-

mework che saranno brevemente descritti di seguito.

BI Delivers

BI Delivers, attraverso la creazione di Agenti, offre la possibilita di monitorare proattiva-

mente le informazioni di business, allertare gli utenti tramite mail, dashboard e dispositivi

mobili come telefoni cellulari e permette di prendere decisioni rapide in funzione degli alert

che sono stati ricevuti.

Gli agenti possono essere concatenati, ovvero possono scambiarsi informazioni tra loro.

Essi vengono creati mediante un’apposita interfaccia, mostrata in Figura 3.12, nella quale

l’utente puo specificare le opzioni di consegna degli alert, definire profili, programmare

l’esecuzione automatica di un report e molto altro ancora.

Figura 3.12: Creazione di un agente tramite BI Delivers


Action Framework

E una particolare funzione altamente innovativa che agisce da collegamento fra l’analisi

e l’azione dando agli utenti la possibilita di attivare un processo di business o un Web

service direttamente dal proprio cruscotto.

3.4.6 BI Mobile

Sempre piu frequentemente gli utenti manifestano il desiderio di avere a disposizione o

di poter reperire le informazioni business anche quando non sono in ufficio. OBIEE offre

tre possibili soluzioni a questo problema.

Briefing Books

Un Briefing Book e un documento che cattura il contenuto di una dashboard e ne consen-

te la visualizzazione in modalita disconnessa, da parte di chiunque disponga del software

Briefing Book reader. Offrono un metodo per creare istantanee delle dashboard, visua-

lizzarle offline, o condividerle con gli altri e ne possiedono lo stesso “look and feel”. I

Briefing Book forniscono anche un metodo per archiviare le informazioni di una dash-

board poiche possono essere salvati localmente sul PC di un utente. I Briefing Book

personalizzati possono essere distribuiti automaticamente (via e-mail) tramite Oracle BI

Delivers a gruppi di utenti.

BI Mobile

Le aziende richiedono che le informazioni possano essere reperibili in qualsiasi momento.

I dispositivi mobili svolgono un ruolo chiave in questo contesto, per tanto OBIEE offre

la possibilita di accedere a tutti i contenuti delle dashboard tramite dispositivi mobili.

Si noti come un tale approccio renda ancora piu efficace il ruolo giocato dagli agenti che

hanno il compito di inviare gli alert.

Plug-in Office

L’Add-In di Microsoft Office integra le informazioni di Business Intelligence provenienti

dal BI Server, BI Analysis and Reporting, dashboards e BI Publisher con l’ambiente

di Microsoft Office. Questo permette di incorporare dati aziendali aggiornatissimi nei

3.5 L’Administration Tool 73

documenti di Microsoft Word, Excel e PowerPoint. Gli utenti possono quindi condividere

questi documenti sul Web per attuare un processo decisionale veramente collaborativo.

3.5 L’Administration Tool

E uno strumento facente parte dei client tool che permette di operare con efficienza sui

metadati contenuti nel repository. La Figura 3.13 mostra l’interfaccia dell’Administration

Tool; si noti la netta separazione dei tre livelli del repository.

Figura 3.13: Suddivisione dei tre livelli del repository nell’Administration Tool

L’Administration Tool aiuta gli amministratori a preparare le formule (per esempio una

percentuale rispetto a un totale) e ne assicura la correttezza, oppure consente di creare

centinaia di misure di confronto per le serie temporali (per esempio, vendite dell’anno

precedente, percentuale di modifica rispetto all’anno precedente, rapporto di vendita

rispetto all’anno precedente, e cosı via) in pochi secondi. Funzionalita sofisticate di

gestione del progetto permettono inoltre a piu amministratori di operare simultaneamente

sui repository dei metadati.

Ecco alcune delle principali funzionalita offerte dall’Administration Tool:

• Gestione delle modifiche: fornisce numerosi servizi per facilitare la gestione delle

modifiche. Per esempio, un wizard di rinomina semplifica il cambiamento dei nomi


di piu oggetti simultaneamente, la sostituzione di testo, la modifica di maiuscole/-

minuscole e l’aggiunta di prefissi o suffissi. Questo, a sua volta, semplifica il trasci-

namento e il rilascio di colonne fisiche nel livello della modellazione e mappatura

business e consente di attribuire loro nomi logici piu leggibili e significativi;

• Amministrazione dei metadati: per semplificare le operazioni con i repository di

grandi dimensioni, il tool di amministrazione permette all’amministratore di strut-

turare e organizzare i metadati, per esempio utilizzando cartelle, per organizzare gli

oggetti. L’amministratore puo inserire tutte le tabelle dimensionali in una singola

cartella e tutte le gerarchie in una cartella differente o, alternativamente, inserire

una tabella dimensionale e le gerarchie correlate nella stessa cartella e utilizzare

icone grafiche per contrassegnare gli oggetti per finalita specifiche;

• Dipendenza e analisi degli impatti: una utility consente all’amministratore di cer-

care nei metadati oggetti per tipo, pur filtrando le proprieta e le relazioni con gli

altri oggetti. Per esempio, un amministratore puo trovare tutte le colonne logiche

che dipendono da una specifica tabella o colonna fisica per determinare quali ogget-

ti di business vengano influenzati dall’eventuale eliminazione dal database di una

specifica colonna fisica;

• Esportazione/importazione: il tool di amministrazione offre funzionalita di espor-

tazione e importazione dei metadati per spostare i sistemi dagli ambienti di staging

a quelli di produzione e per esportare i metadati su file a scopo di documentazione.

Una utility di documentazione del repository genera un elenco di colonne di pre-

sentazione, colonne del modello di business loro corrispondenti, formule e sorgenti

fisiche mappate;

• Collaborazione multi-utente per l’amministrazione: l’Administration Tool puo esse-

re utilizzato sia in modalita offline che online. Le modifiche online hanno effetto

immediatamente, senza dover riavviare il server. La modalita offline permette a

diversi amministratori di operare modifiche in modo concomitante su uno stesso

repository di metadati. Quando gli oggetti sono selezionati per la modifica, questi e

gli oggetti da cui dipendono sono disponibili agli altri amministratori esclusivamente

in formato di sola lettura;

3.6 Comparazione con gli altri competitor 75

• Amministrazione degli utenti: il tool di amministrazione offre inoltre un modo per

visualizzare (e terminare) le sessioni utente correnti; per vedere le variabili utilizzate

in ciascuna sessione; per elencare le voci cache disponibili per area tematica, utente,

o tabella fisica; per riferire sulla storia recente dell’uso della cache.

3.6 Comparazione con gli altri competitor

In questo paragrafo osserviamo le caratteristiche dei prodotti dei principali vendor di

software per la business intelligence, caratteristiche che devono essere considerate dalle

organizzazioni che vogliono adottare soluzioni di business intelligence che soddisfino le

loro richieste.

Riportiamo ora alcune considerazioni fatte da Gartner, una delle piu importanti aziende

di analisi del mercato IT. La Figura 3.14 mostra il Magic Quadrant pubblicato da Gartner

nel gennaio 2011 [Gar11].

Figura 3.14: Quadrante magico di Gartner relativo alle piattaforme di Business

Intelligence del mese di gennaio 2011


I criteri di valutazione adottati dal Magic Quadrant sono: la completezza di visione

e la capacita di esecuzione. Chi eccelle in entrambe fa parte dei leader. Chi ha

buona completezza di visione ma non ha una solida capacita di esecuzione fa parte dei

visionari. Chi ha buona capacita di esecuzione ma ha una visione incompleta fa parte

degli sfidanti, mentre, per concludere, chi ha una visione incompleta e al tempo stesso

ha scarsa capacita di esecuzione viene definito come player di nicchia.

Osserviamo ora le caratteristiche dei maggiori vendor di prodotti per la business intelli-

gence.

Oracle

Pro: la piattaforma OBIEE e considerata lo standard di riferimento per la BI nella mag-

gior parte delle aziende che la utilizzano. Inoltre permette un alto livello di integrazione

con le applicazioni aziendali e con l’infrastruttura informativa e supporta un elevato nu-

mero di utenti contemporaneamente.

Contro: la release 11g ha avuto un ciclo di sviluppo e rilascio relativamente lungo. Le

funzionalita di data mining ed analisi what-if vengono offerte come parte di Oracle da-

tabase e del prodotto Oracle Real-Time Decision, entrambi i quali sono separati dalla

piattaforma OBIEE.

Microstrategy

Pro: Microstrategy ha costruito la sua piattaforma da zero ed e specializzata nelle imple-

mentazioni di BI che girano su grandi data warehouse. E stata una dei primi produttori

ad investire pesantemente in applicazioni BI per dispositivi mobili. Fornisce un eccellen-

te supporto del prodotto che consente agli amministratori di risolvere in breve tempo i

problemi riscontrati. Si pone al primo posto per livello di integrazione dei componenti

della piattaforma.

Contro: nonostante l’ambiente di sviluppo Microstrategy sia uno dei piu potenti e fles-

sibili, presenta una ripida curva di apprendimento. La creazione di dashboard e re-

port ad-hoc non e particolarmente user-frendly per gli utenti business. Inoltre, i clienti

Microstrategy indicano come limitazione piu grande il costo del software.


Microsoft

Pro: Microsoft ha sempre investito nella costruzione e miglioramento delle sue funzio-

nalita di BI in tre dei suoi prodotti: Microsoft Office, Microsoft SQL Server e Microsoft

SharePoint, al fine di aumentare il loro valore. I costi delle licenze sono tra i piu bassi e

la possibilita di poter utilizzare funzionalita di business intelligence integrate in prodotti

gia presenti nelle aziende, conferisce ai prodotti Microsoft il piu alto grado di “capacita

di esecuzione” tra tutti i prodotti di BI presenti sul mercato.

Contro: la scelta di offrire funzionalita di BI in una soluzione multi prodotto, soprattut-

to considerando che tali prodotti svolgono anche funzionalita non-BI, presenta per certi

versi una limitazione rispetto alle soluzioni di altri vendor, che integrano tutte (o quasi

tutte) le funzionalita di business intelligence all’interno di un unico prodotto. Un’altra

limitazione e data dalla scarsa disponibilita di strumenti orientati agli utenti business,

facendo dei prodotti Microsoft BI delle soluzioni destinate agli sviluppatori. Infine, non

esiste un unico livello per i metadati e le funzionalita offerte per la loro modellazione sono

molto limitate.

SAP

Pro: la combinazione di SAP e Business Object rappresenta la piattaforma piu installata

in assoluto. Il volume di dati e di utenti dei clienti SAP sono tra i maggiori sul mercato

(quasi il doppio della media). Le sue funzionalita di reporting e di costruzione di query

ad-hoc vengono definite dai suoi clienti come i maggiori punti di forza del prodotto. La

piattaforma SAP/BO viene completata nelle aree della collaborazione e nel supporto alle

decisioni dai prodotti: StreamWork, Text-Analysis ed altri prodotti di gestione dell’in-

formazione con integrazione dei dati.

Contro: tra le piu frequenti lamentele mosse dai clienti fanno parte le basse performance

e l’alto livello di difficolta delle implementazioni. L’esperienza dei clienti e la qualita del

software e del supporto tecnico sono tra i piu bassi rilevati nel sondaggio Gartner.

IBM

Pro: IBM detiene la leadership per quanto riguarda la “completezza di visione”. Il pro-

dotto offerto per la business intelligence da IBM e IBM Cognos che offre la possibilita di

effettuare sia analisi statiche sia di tipo predittivo. In particolare, quest’ultima tipologia


di analisi costituisce uno dei maggiori punti di forza del prodotto.

Contro: Uno dei maggiori punti deboli del prodotto IBM e dato dalle performance, an-

che se la versione 10.1 di IBM Cognos dispone di funzionalita specifiche per affrontare

problemi di performance. La scarsa diffusione del prodotto puo essere ricercata nella

elevata difficolta dell’implementazione dei progetti di business intelligence e dalla scarsa

usabilita del prodotto stesso. Infine, i costi elevati delle licenze (ben sopra alla media)

costituiscono un ulteriore motivo di angoscia per i clienti.

In cinque anni, il mercato delle piattaforme software di Business Intelligence ha subi-

to notevoli trasformazioni, sopratutto per il susseguirsi di importanti acquisizioni. Di

seguito vengono messe a confronto due istantanee con le posizioni occupate dai principali

player sul quadrante magico.

Figura 3.15: Confronto delle posizioni occupate dai maggiori vendor di piattaforme di

Business Intelligence nel quadrante magico di Gartner nel 2006 e nel 2011


Nel 2006 i due principali leader del mercato erano Business Objects e Cognos. A

distanza di 5 anni il quadrante dei leader si e decisamente affollato. Le strategie che hanno

contraddistinto l’evoluzione del mercato sono riconducibili a due modelli fondamentali:

• l’acquisizione/fusione di piu realta per potenziare e completare l’offerta;

• l’investimento interno finalizzato a sviluppare la propria vision che sia in grado di

contraddistinguere la propria offerta rispetto ai competitor.

Oracle ha seguito la prima strategia e, in virtu dell’anticipo con cui ha effettuato le sue

mosse sul mercato, e quella che, avendo avuto il tempo necessario per realizzare un’offerta

completa, ha meglio capitalizzato gli investimenti in termini di posizionamento.

3.6.1 Prodotti open source

Un numero crescente di organizzazioni si dimostra sempre piu attratto dalle promesse del

software open source. Sono soluzioni ricche di funzionalita che possono ridurre il costo

totale di proprieta dell’infrastruttura IT. Software come Linux, OpenOffice, MySQL e

Firefox sono considerate soluzioni mainstream e vengono ampiamente adottate. Osser-

viamo ora, se anche le soluzioni open source di business intelligence sono abbastanza

mature per poter essere utilizzate dalle aziende.

Non si deve guardare molto lontano per avere la prova della maturita raggiunta dalla BI

open source. Unionfidi, un’importante istituzione finanziaria italiana attiva nel credito a

piccole e medie aziende, ha sostituito tutte le soluzioni BI esistenti, comprese quelle di

reporting, con una suite BI open source a partire dal 2006. Un altro esempio e quello del

ministero della Sanita che ha scelto una suite open source per sviluppare un nuovo sistema

di supporto decisionale. Molte organizzazioni, sia pubbliche sia private, stanno attual-

mente implementando soluzioni BI open source che rispondono al nome di JasperSoft,

Pentaho o SpagoBI, suite che rendono disponibile un ampio spettro di funzionalita,

dall’ETL a funzioni ad-hoc di analisi e reporting. Spago BI ha inoltre il vantaggio di

essere un prodotto italiano, sviluppato e supportato da Engineering, un grande system

integrator nazionale.

Tuttavia e bene sottolineare che sia JasperSoft che Pentaho offrono versioni Community

e Professional. Mentre le prime sono completamente open source, le versioni Professional

includono invece componenti aggiuntivi closed source.


Nonostante le tecnologie open source per la business intelligence non siano direttamen-

te confrontabili con le suite proprietarie (le piu importanti descritte precedentemente) e

bene riportare un concetto fondamentale che Gartner ha espresso nel seguente modo:

“mentre i vendor tradizionali possono ancora vantare una posizione di preminen-

za nell’offerta tecnologica complessiva, l’adozione dell’open source aumenta perche

considerata sufficientemente valida”

ETL open source

Anche nel campo dell’ETL il mondo open source offre una vasta gamma di prodotti.

Kettle, per esempio, e un tool ETL facente parte della suite BI di Pentaho. E poi Talend

(utilizzato all’interno di JasperSoft dove viene chiamato JasperETL), Jitterbit, Snaplo-

gic, CloverETL. Non saranno comparabili a quelli offerti dai “megavendor”, ma vengono

ritenuti sufficientemente validi per il loro basso costo e le adeguate funzionalita. Possono

pertanto essere un’alternativa al software proprietario.

La caratteristica che consente di implementare con successo un progetto BI fa comunque

riferimento alle prestazioni. In molte implementazioni di BI open source si e spesso scelto

di utilizzare MySQL, che puo essere considerato un buon DBMS transazionale, ma che

rivela tutte le sue limitazioni quando impiegato per la costruzione di data warehouse e

data mart a livello enterprise. Per questo motivo alcuni vendor open source hanno svi-

luppato soluzioni di database, basate su MySql, ma che prevedono un motore di storage

completamente differente, adatto a supportare carichi di lavoro BI di tipo enterprise. Na-

turalmente la scelta di un database analitico open source non si limita a soluzioni basate

su MySql.

L’importanza della query performance non deve essere sottovalutata durante la scelta del

DBMS analitico. Le soluzioni Oracle e SQL Server, grazie anche alle loro tecniche di in-

dicizzazione e compressione, si collocano tra le migliori per quanto riguarda le prestazioni

per le attivita di query.

CAPITOLO 4

Il caso di studio: Realizzazione di una

soluzione di Business Intelligence per

l’azienda Cadey

4.1 Presentazione dell’azienda

Cadey s.r.l nasce nel 1959 ed e tra le aziende leader nel panorama della cosmetica italiana.

Ha sede a Piacenza e conta 54 dipendenti con un fatturato di 38,8 milioni.

Cadey si vuole affermare come il marchio italiano di riferimento per la cura della persona,

in grado di offrire ai consumatori prodotti innovativi dall’ottimo rapporto qualita prezzo

presenti in tutti i canali distributivi: ipermercati, supermercati e profumerie.

Famiglie di prodotti

• Solari, marchio Bilboa (prodotti di punta dell’azienda).

• Creme per il corpo, marchio Cambia Pelle e Staminaline.

82Il caso di studio: Realizzazione di una soluzione di Business Intelligence per

l’azienda Cadey

• Depilazione, marchio Depilsoap.

• Cura capelli, marchio Bilba e Luminose.

Tipologia di clienti

• Canale GDO.

• Negozi specializzati casa toilette.

• Grossisti.

• Normal trade.

Struttura organizzativa

Figura 4.1: Struttura commerciale dell’azienda Cadey s.r.l.

4.2 Struttura data center Cadey 83

Figura 4.2: Organigramma dell’azienda Cadey s.r.l.

4.2 Struttura data center Cadey

La soluzione tecnologica adottata dall’azienda Cadey che andremo ad illustrare, e stata

scelta poiche in grado di:

• fornire una solida piattaforma iniziale che potra crescere nel tempo senza disperdere

gli investimenti di partenza;

• fornire una soluzione in grado di fornire continuita d’esercizio anche a seguito di

crash di alcune componenti.

Elemento centrale della soluzione proposta e la soluzione di virtualizzazione su piattafor-

ma VMware implementata in questa fase su due nodi.

VMware vSphereTM elimina la proliferazione dei server eseguendo le applicazioni all’in-

terno di macchine virtuali installate su un numero inferiore di server e con un utilizzo


l’azienda Cadey

piu efficiente delle risorse di rete e storage. Le organizzazioni che utilizzano una tale

soluzione possono conseguire rapporti di consolidamento per singolo server elevatissimi,

grazie a straordinarie funzionalita di gestione della memoria e ottimizzazione dinamica.

La complessita di gestione dell’hardware viene ridotta mediante la virtualizzazione totale

di server, storage e hardware di rete.

VMware vSphereTM aiuta quindi a realizzare una solida infrastruttura protetta, che ga-

rantisce la continuita aziendale anche in presenza di guasti hardware o di indisponibilita

del data center. Grazie a queste sue funzionalita, la scelta di Cadey e stata VMware

vSphere Standard. Essa rappresenta una soluzione di fascia entry-level per il consolida-

mento applicativo di base, allo scopo di ridurre sensibilmente i costi hardware, accelerando

nel contempo la distribuzione delle applicazioni.

Configurazione hardware

Server:

nodi VMware N◦2 PRIMERGY RX300 S6. Caratteristiche tecniche:

• doppio processore quad core;

• 16GB di RAM;

• scheda fibre channel;

• N◦2 hard disk 146GB SAS.

Storage:

Controller a 2 canali FC 4GB - N◦4 hard disk da 450GB SAS 15k (3 hard disk raid 5 +

1 hard disk spare)

Soluzione e strategia di backup:

Sono previsti due livelli di backup, il primo su disco mentre il secondo su nastro.

Sul server e presente l’unita nastro LTO3 per l’esecuzione del secondo livello di copia.

4.3 Struttura del data mart vendite 85

4.3 Struttura del data mart vendite

La soluzione di business intelligence che l’azienda Cadey ha deciso di adottare, consiste

nella suite Oracle Business Intelligence fondata su un Enterprise Data Warehouse realiz-

zato su database Oracle 11g.

Il processo ETL per la costruzione del data warehouse non rientra nelle attivita da me

svolte presso il cliente durante l’esperienza di tirocinio. Tuttavia propongo la struttura

del data mart relativo alle vendite sul quale si basano le attivita di sviluppo del progetto

da me affrontato.

Figura 4.3: Schema concettuale del data mart delle vendite

Nelle prossime sezioni vengono descritti i passi che consentono di presentare i dati all’in-

terno del data mart all’utente finale, in una forma a lui comprensibile.


l’azienda Cadey

4.4 Costruzione dei metadati

Il repository dei metadati, come anticipato nella sezione 3.2, e un file che ha il compito di

memorizzare i metadati necessari al BI Server per trasformare una query logica, ovvero

una interrogazione che viene costruita dall’utente che non e a conoscenza della struttura

delle sorgenti, nella relativa query fisica da eseguire sui dati sorgente.

Lo strumento che Oracle BI mette a disposizione degli sviluppatori per la costruzione

dei metadati e l’Administration Tool. Con esso e possibile mappare i dati presenti nelle

sorgenti fisiche nei dati di presentazione, utilizzabili dall’utente finale, passando per tre

livelli distinti: livello fisico, livello logico e livello di presentazione.

Di seguito vengono descritte le tre fasi, prendendo come riferimento il repository dei

metadati utilizzato dall’azienda Cadey. Essendo le dimensioni del progetto troppo elevate

per poterle esaminare in modo esaustivo, ho deciso di prendere in esame solo una fact

table e una dimension table ed osservare il passaggio dei dati dalle sorgenti fisiche, fino

alla loro visualizzazione in report utilizzabili dagli utenti business.

4.4.1 Livello fisico

La costruzione di questo livello inizia con l’importazione delle tabelle che andranno a

costituire le sorgenti. Tali sorgenti possono essere eterogenee, tuttavia in questo caso

proverranno dal medesimo data mart. La Figura 4.4 mostra il livello fisico costruito nel

nostro caso di studio.

Il database e l’oggetto collocato piu in alto nel livello fisico e definisce la sorgente dati

alla quale il BI Server dovra inviare le query. Il connection pool definisce le modalita

di collegamento al database, mentre lo schema contiene le tabelle e le colonne dello

schema fisico.

Le tabelle importate sono le seguenti:

• F SPED: fact table relativa alle vendite;

• L CLI: dimension table relativa ai clienti, sulla quale viene eseguita una parziale nor-

malizzazione con le tabelle L GEO NAZIONE, L GEO REGIONE e L GEO PROVINCIA

che contengono rispettivamente i dati relativi alla nazione, regione e provincia del

cliente;

4.4 Costruzione dei metadati 87

• L CLI NAZIONE, L CLI REGIONE e L CLI PROVINCIA: alias per le tabelle

L GEO NAZIONE, L GEO REGIONE e L GEO PROVINCIA rispettivamente.

Verranno utilizzate per riferisi alle tabelle appena elencate.

Figura 4.4: Rappresentazione del livello fisico nell’Administration Tool

Definizione dei vincoli di integrita referenziale

Una volta importate le tabelle, occorre definire i vincoli di foreign key. Nel nostro caso

saranno:

F SPED.DOC CLI DM ID = L CLI.CLI ID

L CLI.CLI PROVINCIA ID = L CLI PROVINCIA.PROVINCIA ID

L CLI PROVINCIA.REGIONE ID = L CLI REGIONE.REGIONE ID

L CLI REGIONE.NAZIONE ID = L CLI NAZIONE.NAZIONE ID


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 Livello logico

E il livello dove gli schemi fisici vengono semplificati e riorganizzati per formare le basi

della vista che l’utente avra dei dati.

La costruzione del livello logico inizia con l’importazione degli oggetti dal livello fisico e

con la definizione delle relazioni tra di essi (Figura 4.7). Infatti, solo grazie a quest’ultimo

passaggio si riescono a definire i ruoli degli oggetti stessi, ovvero quali sono le fact table

e quali le dimension table.

Figura 4.7: Rappresentazione del livello logico e della relazione che lega la dimension

table “ClienteDim” con la fact table “Spedito - Vendite”

Per ogni tabella del livello logico, le source table identificano le relative tabelle sor-

genti nel livello fisico. Si noti che per la dimension table ClienteDim compare la so-

la tabella L CLI come sorgente, mentre vengono omesse le tabelle L CLI NAZIONE,

L CLI REGIONE e L CLI PROVINCIA. Questo perche e possibile mappare una source

table su piu tabelle fisiche, a patto che siano in relazione tra loro nel modello fisico.


l’azienda Cadey

Per ognuna delle misure e possibile definire una regola di aggregazione. In questo mo-

do si definisce il comportamento che tale misura dovra avere ogni qualvolta si desidera

cambiare il livello di dettaglio con il quale analizzare i dati. Nel nostro caso ogni misura

possiede come regola di aggregazione la somma.

Creazione di nuove colonne nel livello logico

All’interno del livello logico e possibile creare nuove colonne, utilizzando colonne gia

presenti all’interno di una formula. Possono essere utilizzate:

• Colonne logiche: vengono utilizzate colonne appartenenti al livello logico. La regola

di aggregazione della colonna creata viene automaticamente individuata sulla base

delle regole di aggregazione delle colonne logiche utilizzate nella formula;

• Colonne fisiche: vengono utilizzate colonne appartenenti al livello fisico. In questo

caso la regola di aggregazione deve essere specificata manualmente, in quanto le

colonne utilizzate nella formula non ne possiedono una.

La differenza tra le due metodologie risiede nell’ordine con il quale le aggregazioni vengono

eseguite. Nel primo caso infatti saranno effettuate a livello di colonna, mentre nel secondo

a livello di riga.

Creazione delle gerarchie

La creazione di una gerarchia conferisce una organizzazione gerarchica alle colonne logiche

appartenenti ad una dimension table. In questo modo si possono definire i percorsi di

drill-down che l’utente potra effettuare durante la fase di analisi. La struttura di una

gerarchia e gestibile dal solo livello logico. La Figura 4.8 mostra la gerarchia utilizzata

nel nostro caso di studio.

L’introduzione di una gerarchia permette di definire:

• Level-based measures: Sono misure che vengono calcolate ad uno specifico livello

di aggregazione e che per tanto non vengono influenzate dai drill-down su altri livelli;

• Share measures: Sono misure che vengono calcolate facendo il rapporto tra le

normali misure e misure level-based. Vengono utilizzate per calcolare le percentuali.


Figura 4.8: Gerarchia relativa alla dimension table ClienteDim

Figura 4.9: Diagramma completo del livello logico relativo alle vendite


l’azienda Cadey

4.4.3 Livello di presentazione

Rappresenta la vista che ha l’utente dei dati. Ha il compito di semplificare il livello logi-

co. Nel livello di presentazione e infatti possibile nascondere determinate colonne oppure

riorganizzare i dati in cataloghi o cartelle separate. La Figura 4.10 fornisce una rappre-

sentazione del livello di presentazione.

Figura 4.10: Rappresentazione del livello di presentazione nell’Administration Tool

Le presentation table possono essere utilizzate per riorganizzare i dati. Esse possono

contenere colonne logiche provenienti da piu tabelle logiche e risultano essere indipendenti

da queste ultime.

La definizione delle subject area permette, come vedremo piu avanti, la suddivisione in

piu ambiti di analisi negli strumenti di front end.

4.4.4 Validazione del repository

Una volta terminata la costruzione dei tre livelli occorre validare il repository appena

creato. Per essere considerato valido, un repository deve possedere i seguenti requisiti:

4.5 Costruzione della reportistica 93

• Tutte le colonne logiche sono mappate direttamente o indirettamente su una o piu

colonne fisiche;

• Tutte le dimension table del livello logico hanno una chiave logica;

• Tutte le tabelle logiche sono in logical join con almeno un’altra tabella logica;

• Devono essere presenti almeno due tabelle logiche: una fact table ed una dimension

table. Eventualmente possono entrambe essere mappate sulla medesima tabella

fisica.

• Non ci devono essere cicli nelle relazioni definite nel modello logico;

• Esiste almeno una subject area per ogni modello business (si noti che nell’esempio

trattato e presente un solo modello business, quello delle vendite).

Una volta validato il repository e possibile caricarlo all’interno del BI Server attraverso

l’Enterprise Manager.

4.5 Costruzione della reportistica

Mentre la costruzione dei metadati e un compito strettamente riservato agli sviluppatori,

la costruzione della reportistica puo essere fatta anche dagli utenti business.

Oracle BI mette infatti a disposizione una semplice GUI (Figura 4.11) per la creazione

di report e dashboard.

Figura 4.11: Costruzione di un report tramite “Oracle BI Analysis and Reporting”


l’azienda Cadey

Nella parte sinistra e collocata la subject area. In essa si possono reperire gli oggetti

necessari alla costruzione del report. OBIEE 11g permette la costruzione di analisi con-

tenenti oggetti provenienti da piu subject area.

Nella parte destra, invece, e possibile modellare il report modificando l’ordine e le pro-

prieta delle colonne (in alto), oppure definire opportuni filtri (in basso).

Di seguito una dashboard e un report di tipo grafico, relativi alle vendite analizzate

per famiglia dell’articolo.

Figura 4.12: Dashboard relativa alle vendite analizzate per famiglia dell’articolo

Figura 4.13: Report grafico che descrive la situazione mostrata nella dashboard di

Figura 4.12

4.5 Costruzione della reportistica 95

Conclusioni

La struttura di questo lavoro di tesi rappresenta il percorso seguito durante i mesi di

tirocinio.

Le prime settimane sono state infatti dedicate ad attivita di studio individuale e a corsi

di formazione, che mi hanno portato ad acquisire le nozioni di base dei sistemi di data

warehousing e business intelligence. I primi due capitoli riassumono il percorso formativo

intrapreso.

La seconda parte del tirocinio e stata dedicata allo studio della tecnologia Oracle BI 11g,

al fine di apprendere le caratteristiche tecniche del prodotto, descritte nel terzo capitolo,

e le metodologie di sviluppo di un progetto di business intelligence.

Quindi, solamente dopo aver seguito un percorso di formazione adeguato, sono stato

coinvolto nello sviluppo di una soluzione di business intelligence presso l’azienda Cadey

s.r.l di Piacenza. Durante questa esperienza ho potuto partecipare alle seguenti attivita:

• Installazione della piattaforma di business intelligence;

• Costruzione dei metadati, ovvero il processo di mappatura dei dati fisici del data

mart delle vendite nei dati di presentazione utilizzabili dall’utente;

• Costruzione della reportistica, report e dashboard, in base alle esigenze mostrate

dal cliente.

Il quarto capitolo descrive come sono state affrontate alcune di queste attivita.

L’esperienza di tirocinio mi ha permesso di maturare sotto l’aspetto professionale e di

acquisire conoscenze che considero di fondamentale importanza per il mio futuro.

ELENCO DELLE FIGURE

1.1 Rappresentazione di un processo aziendale . . . . . . . . . . . . . . . . . 3

1.2 Le attivita aziendali secondo Anthony . . . . . . . . . . . . . . . . . . . . 5

1.3 Relazioni tra i sistemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Componenti di un sistema di data warehousing . . . . . . . . . . . . . . 18

2.2 Architettura ad un livello per un sistema di data warehousing . . . . . . 21

2.3 Architettura a due livelli per un sistema di data warehousing . . . . . . . 22

2.4 Architettura a tre livelli per un sistema di data warehousing . . . . . . . 23

2.5 Cubo multidimensionale che modella le vendite in una catena di negozi . 27

2.6 Una possibile gerarchia per la dimensione negozi . . . . . . . . . . . . . . 28

2.7 Semplice schema di fatto delle vendite . . . . . . . . . . . . . . . . . . . 29

2.8 Schema Entity/Relationship delle vendite . . . . . . . . . . . . . . . . . . 29

2.9 Schema di fatto delle vendite arricchito . . . . . . . . . . . . . . . . . . . 30

2.10 Star schema per le vendite . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.11 Snowflake schema per le vendite . . . . . . . . . . . . . . . . . . . . . . . 33

2.12 Rappresentazione del fenomeno di sparsita dei dati . . . . . . . . . . . . 34

2.13 Suddivisione del cubo multidimensionale in chunk . . . . . . . . . . . . . 35

2.14 Rappresentazione del portafoglio applicativo aziendale . . . . . . . . . . . 38

2.15 Piramide della Business Intelligence . . . . . . . . . . . . . . . . . . . . . 39

2.16 Operatori di slice-and-dice . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.17 Operatori di roll-up e drill-down . . . . . . . . . . . . . . . . . . . . . . . 43

98 ELENCO DELLE FIGURE

2.18 Il processo di knowledge discovery . . . . . . . . . . . . . . . . . . . . . . 46

2.19 Fasi di un’analisi di business intelligence . . . . . . . . . . . . . . . . . . 50

3.1 Standardizzazione degli strumenti e successo della BI . . . . . . . . . . . 57

3.2 Architettura di OBIEE 11g . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.3 Architettura logica di OBIEE 11g su un singolo host . . . . . . . . . . . 58

3.4 Architettura logica di OBIEE 11g su piu host . . . . . . . . . . . . . . . 59

3.5 Traduzione di una query logica nella relativa query fisica attraverso i 3

livelli del repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.6 Architettura del BI Server . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.7 Tipica struttura delle directory di Oracle BI . . . . . . . . . . . . . . . . 65

3.8 Costruzione di un’analisi con BI Analysis and Reporting . . . . . . . . . 67

3.9 Un esempio di dashboard interattiva . . . . . . . . . . . . . . . . . . . . 69

3.10 Un esempio di scorecard . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.11 Costruzione di un report pixel perfect mediante BI Publisher Layout Editor 70

3.12 Creazione di un agente tramite BI Delivers . . . . . . . . . . . . . . . . . 71

3.13 Suddivisione dei tre livelli del repository nell’Administration Tool . . . . 73

3.14 Quadrante magico di Gartner relativo alle piattaforme di Business Intelli-

gence del mese di gennaio 2011 . . . . . . . . . . . . . . . . . . . . . . . 75

3.15 Confronto delle posizioni occupate dai maggiori vendor di piattaforme di

Business Intelligence nel quadrante magico di Gartner nel 2006 e nel 2011 78

4.1 Struttura commerciale dell’azienda Cadey s.r.l. . . . . . . . . . . . . . . . 82

4.2 Organigramma dell’azienda Cadey s.r.l. . . . . . . . . . . . . . . . . . . . 83

4.3 Schema concettuale del data mart delle vendite . . . . . . . . . . . . . . 85

4.4 Rappresentazione del livello fisico nell’Administration Tool . . . . . . . . 87

4.5 Rappresentazione dei vincoli di integrita referenziale delle tabelle del livello

fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.6 Diagramma completo del livello fisico relativo alle vendite . . . . . . . . . 88

4.7 Rappresentazione del livello logico nell’Administration Tool . . . . . . . . 89

4.8 Rappresentazione di una gerarchia nell’Administration Tool . . . . . . . 91

4.9 Diagramma completo del livello logico relativo alle vendite . . . . . . . . 91

4.10 Rappresentazione del livello di presentazione nell’Administration Tool . . 92

4.11 Costruzione di un report tramite “Oracle BI Analysis and Reporting” . . 93

ELENCO DELLE FIGURE 99

4.12 Dashboard relativa alle vendite analizzate per famiglia dell’articolo . . . . 94

4.13 Un esempio di report grafico . . . . . . . . . . . . . . . . . . . . . . . . . 94

ELENCO DELLE TABELLE

1.1 Caratteristiche dei diversi tipi di sistemi informativi. . . . . . . . . . . . 10

1.2 Differenze tra sistemi OLTP e sistemi OLAP. . . . . . . . . . . . . . . . . 14

3.1 Matrice business case per la BI. . . . . . . . . . . . . . . . . . . . . . . . 56

BIBLIOGRAFIA

[ACPT06] Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, and Riccardo Torlone. Basi

di dati - modelli e linguaggi di interrogazione. McGraw-Hill, second edition,

2006.

[Des07] Giulio Destri. Introduzione ai sistemi informativi aziendali. Monte Universita

Parma, 2007.

[Gar11] Gartner. Magic quadrant for business intelligence platform, January 2011.

[GR06] Matteo Golfarelli and Stefano Rizzi. Data Warehouse - teoria e pratica della

progettazione. McGraw-Hill, second edition, 2006.

[KRT+07] Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy, and Bob

Becker. The Datas Warehouse Lifecycle Toolkit. Wiley Publishing, second

edition, 2007.

[LL06] Kenneth Laudon and Jane Laudon. Management dei sistemi informativi.

Pearson Prentice Hall, second edition, 2006.

[Oraa] Oracle. Company profile. http://www.oracle.com/global/it/corporate/

company_profile.html.

[Orab] Oracle. Oracle business intelligence enterprise edition 11g - installation guide.

[Orac] Oracle. Oracle business intelligence enterprise edition 11g - metadata

repository builder’s guide.

http://www.oracle.com/global/it/corporate/company_profile.html

http://www.oracle.com/global/it/corporate/company_profile.html

104 BIBLIOGRAFIA

[Orad] Oracle. Oracle business intelligence enterprise edition 11g - system

administrator’s guide.

[Orae] Oracle. Oracle fusion middleware 11g - certification matrix.

http://www.oracle.com/technetwork/middleware/downloads/

fmw-11gr1certmatrix.xls.

[Ora09] Oracle. Building a better business case for business intelligence, 2009.

[Ora11a] Oracle. Oracle business intelligence foundation suite - technical overview.

http://www.oracle.com/us/obiee-11g-technical-overview-078853.

pdf, January 2011.

[Ora11b] Oracle. Oracle fusion middleware 11g - system requirements and specifications,

January 2011.

[Pas04] Paolo Pasini. I sistemi informativi direzionali - le tecnologie dell’informazione

a supporto dei processi manageriali d’azienda. Egea, 2004.

[PM05] Maurizio Pighin and Anna Marzona. Sistemi informativi aziendali - struttura

e applicazioni. Pearson Prentice Hall, 2005.

[TRS03] Marco Tagliavini, Aurelio Ravarini, and Donatella Sciuto. Sistemi per la

gestione dell’informazione. Apogeo, 2003.

[Ver06] Carlo Vercellis. Business Intelligence - modelli matematici e sistemi per le

decisioni. McGraw-Hill, 2006.

http://www.oracle.com/technetwork/middleware/downloads/fmw-11gr1certmatrix.xls

http://www.oracle.com/technetwork/middleware/downloads/fmw-11gr1certmatrix.xls

http://www.oracle.com/us/obiee-11g-technical-overview-078853.pdf

http://www.oracle.com/us/obiee-11g-technical-overview-078853.pdf

Business Intelligence: un caso di studio nel settore cosmetico · 2017-01-05 · Il termine...

Documents

Transcript of Business Intelligence: un caso di studio nel settore cosmetico · 2017-01-05 · Il termine...