Realizzazione di un datawarehouse con il sistema SAP HANA

(1)

UNIVERSITÀ DI PISA

Facoltà di Economia

Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea Magistrale in Informatica per l’Economia e

per l’Azienda (Business Informatics)

TESI DI LAUREA

REALIZZAZIONE DI UN DATA WAREHOUSE CON

IL SISTEMA SAP HANA

RELATORE

Prof. Antonio ALBANO

Candidato

Fiorella MARCHINI

(2)

(3)

Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Albano, relatore della mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.

Desidero, inoltre, ringraziare il tutor aziendale Salvatore Morello che ha supervisionato la stesura della tesi e per avermi dedicato numerose ore per la mia formazione.

Vorrei ringraziare M´ethode (Davide, Diego, Marco e Paolo) che mi ha dato l’opportunit`a di svolgere lo stage aziendale.

Ringrazio con affetto i miei genitori, le mie sorelle e i miei nipoti che mi hanno sostenuto durante gli anni di universit`a.

(4)

(5)

Nel presente lavoro di tesi vengono affrontate le tematiche inerenti la fase di progettazione e realizzazione di un sistema di Business Intelligence per l’analisi del processo delle vendite di una azienda di occhialeria. Tale sistema permetter`a di rispondere a specifiche esigenze di analisi del processo produttivo e di vendita fornendo supporto al management nel processo decisionale dell’azienda.

Il lavoro viene introdotto descrivendo brevemente il ciclo attivo dell’azienda focalizzandosi poi sull’analisi dei requisiti e sulla successive fasi di progettazione e implementazione del data warehouse. Inoltre vengono presentate le principali caratteristiche dello strumento utilizzato, DBMS SAP HANA. In un secondo momento viene mostrato il processo di ETL per il caricamento dei dati operazionali e infine vengono mostrati i risultati delle analisi effettuate, descrivendo gli strumenti utilizzati durante il lavoro.

(6)

(7)

RIASSUNTO . . . 5

1 INTRODUZIONE 11 1.1 Presentazione del problema . . . 11

1.2 Rassegna della letteratura . . . 13

1.3 Contenuto della tesi . . . 14

2 CASO DI STUDIO: gestione ordini vendite, consegne, fatturazione 16 2.1 L’azienda committente . . . 17

2.1.1 Organizzazione produttiva dell’azienda . . . 18

2.1.2 Descrizione ciclo attivo dell’azienda . . . 19

2.2 Raccolta dei requisiti. . . 20

2.3 Conclusioni . . . 23

3 SPECIFICA DEI REQUISITI E PROGETTAZIONE DEI DATA MART 24 3.1 Introduzione . . . 24

3.2 Processo Ordine di Vendita . . . 26

3.2.1 Specifica dei requisiti . . . 26

3.2.2 Progettazione concettuale. . . 35

3.2.3 Progettazione logica . . . 37

3.3 Processo Consegna (Delivery) . . . 38

(8)

3.4 Processo Fatturazione (Billing) . . . 43

3.4.1 Specifica dei requisiti . . . 43

3.5 Riepilogo delle misure e delle dimensioni . . . 48

3.6 Data Warehouse finale . . . 50

3.7 Conclusioni . . . 50

4 SAP HANA -HIGH PERFORMANCE ANALYTIC APPLIANCE 51 4.1 DBMS SAP HANA . . . 51

4.2 Architettura . . . 53

4.3 Vantaggi/Chances e Limiti di SAP HANA . . . 54

4.3.1 Vantaggi . . . 54

4.3.2 Limiti . . . 54

5 PROCESSO DI ETL 55 5.1 Introduzione . . . 55

5.2 SAP Business Objects Data Services . . . 57

5.2.1 SAP BusinessObjects Rapid Mart . . . 58

5.3 ETL del progetto . . . 60

5.3.1 Rapid Mart Sales . . . 60

5.3.2 Data Flow . . . 64

5.4 Conclusioni . . . 71

6 AMBIENTE DI SVILUPPO DELLA REPORTISTICA 72 6.1 Introduzione . . . 72

(9)

6.2.2 Web Intelligence . . . 76

7 ANALISI OLAP - REPORTISTICA 79

7.1 Report semplici . . . 79

7.2 Rapporti relativamente difficili con l’SQL per analisi OLAP 87

7.3 Rapporti difficili senza l’SQL analitico . . . 92

(10)

(11)

INTRODUZIONE

1.1 Presentazione del problema

Negli ultimi decenni il mondo in cui viviamo `e cambiato radicalmente

e con esso anche il modo di fare impresa. Lo sviluppo dell’ICT

(Information and Comunication Technology) a livello globale, l’evoluzione dei computer e del software hanno cambiato il modo con cui le imprese fanno business. Oggigiorno le aziende di tutte le dimensioni, ricercano strumenti, strategie e soluzioni per migliorare le performance e la competitivit`a rispetto ai concorrenti.

Negli ultimi anni si è riscontrato che per poter raggiungere tali obiettivi non basta avere a disposizione una grande mole di informazioni ma è necessario riuscire ad interpretarle nel modo pi ù opportuno al fine di prendere decisioni pi ù intelligenti e raggiungere

un vantaggio competitivo rispetto ai concorrenti. In tal modo si

possono ricavare degli indicatori chiari ed efficaci che permettono ai manager e ai responsabili di ogni area di monitorare e valutare le prestazioni di un determinato processo aziendale.

Qui si colloca la Business Intelligence definita, come scritto in [Albano 12], “un insieme di metodologie e sistemi informatici

(12)

processi decisionali” .

“I dati operazionali accumulati nel tempo, integrati con quelli provenienti da fonti esterne, sono una fonte potenziale di informazione utilizzabile dai dirigenti aziendali indipendentemente dal loro livello

gerarchico. L’informazione si ricava dai dati sintetizzati in forme

opportune e la sua rilevanza dipende da chi la riceve. Quando poi l’informazione si trasforma in conoscenza possono essere prese delle decisioni e intraprese le azioni conseguenti”.[Albano12]

Dopo aver raccolto le richieste da parte del cliente, i dati interessanti vengono selezionati ed estratti da varie sorgenti (gestionale, contabile ecc); essi non vengono gestiti con i classici sistemi in quanto basati e progettati per le attivit`a operative di tutti i giorni, ma su sistemi

progettati ad hoc definiti come data warehouse. In seguito tali dati

verranno acceduti dai sistemi di reportistica i quali permettono al management di effettuare delle analisi estremamente flessibili consentendo loro di prendere le decisioni pi `u opportune per l’azienda.

Il presente lavoro di tesi nasce dall’esigenza dell’azienda di modernizzare il precedente data warehouse che ormai non soddisfaceva pi `u le richieste del management.

In particolare le nuove richieste del management erano:

• Aggiornamento dei report: i vecchi report non fornivano

abbastanza informazioni e il precedente sistema non forniva i dati per un loro completamento.

• Controllo del processo delle vendite: uso di indicatori chiave per l’azienda e rapporti di dettaglio che sintetizzano l’andamento del

processo aziendale. In tal modo, il management, la funzione

vendite e la funzione marketing potranno prendere le migliori decisioni o eventualmente modificarle in corso d’opera.

(13)

• Analisi delle consegne: analisi dei tempi di consegna per monitorare il funzionamento del reparto logistico, prevenire ritardi nelle consegne e prendere provvedimenti migliorativi in caso di malfunzionamenti.

• Programmazione della produzione: analisi delle richieste dei clienti per un adeguata programmazione della produzione e dello stoccaggio del magazzino.

1.2 Rassegna della letteratura

Per la realizzazione di codesto lavoro sono state utilizzate varie fonti sia per la parte teorica necessaria alla progettazione del data warehouse sia fonti pi `u tecniche necessarie per l’acquisizione di competenze sugli strumenti software utilizzati e soprattutto sugli strumenti per il processo di ETL e per la fase di reportistica.

Per quanto riguarda la fase di analisi dei requisiti e le fasi di progettazione, sia concettuale che logica, i testi di riferimento sono stati [Kimball 02] e [Albano 12].

Per la fase di ETL `e stato necessario sviluppare due tipi di competenze, una progettuale e una tecnica.

In questa fase i dati vengono estratti da vari sistemi operazionali, trasformati e caricati all’interno del data warehouse. `E di facile intuizione che tale fase sia molto onerosa in quanto devono essere riorganizzati ed elaborati grandi quantit`a di dati in breve tempo.

Da un punto di vista progettuale è stato necessario capire come organizzare i flussi di dati nella maniera pi ù corretta. Da un punto di vista tecnico è stato necessario sviluppare competenze sullo strumento usato per i processi di caricamento, SAP Data Services. Le competenze

(14)

sono state sviluppate mediante affiancamenti interni all’azienda e consultando i manuali proprietari [SAP 13] e [SAPDS 12].

Per quanto riguarda l’uso del DBMS SAP HANA, sono stati consultati i manuali proprietari [SAP HANA 13] e [SAP 13].

Anche per la fase di reportistica `e stato necessario sviluppare competenze sullo strumento, SAP BusinessObjects BI. In questo caso, le competenze sono state sviluppate attraverso un corso interno, affiancamenti interni e consultando il manuale [SAP BO12].

1.3 Contenuto della tesi

Il presente lavoro di tesi è stato svolto durante un periodo di stage presso la società di consulenza Méthode S.R.L. con sede a San Vendemiano in provincia di Treviso.

Per il progetto sono state coinvolte alcune figure:

• Un Project Manager, responsabile dell’organizzazione e della fase di presentazione del progetto e dell’assegnazione del team di sviluppo.

• Un Project Leader, responsabile delle consulenze presso il committente; con la responsabilit`a di raccolta, analisi e stesura dei requisiti e di seguire il lavoro di un altro consulente.

• Un sviluppatore ETL e reportistica, con il compito di implementare il processo di ETL e di estrapolare i dati dal data warehouse.

Nel presente lavoro la seconda e terza figura hanno lavorato parallelamente, dalla progettazione del data warehouse allo sviluppo della reportistica.

(15)

Nel Capitolo 2 viene presentato il caso di studio, analizzando il processo di vendita e presentando la raccolta dei requisiti di analisi necessari per le analisi richieste dal cliente.

Nel Capitolo 3 viene presentata la specifica dei requisti di analisi, la progettazione concettuale dei data mart e la relativa progettazione logica in base alle richieste da parte dell’azienda committente.

Nel Capitolo 4 viene descritta la tecnologia usata nel presente progetto di tesi, SAP HANA. Essa `e una tecnologia in-memory che permette di gestire grandi volumi di dati strutturati e non.

Nel Capitolo 5 viene descritto l’ambiente tecnologico utilizzato per la fase di ETL, SAP Business Objects Data Services e i modelli preconfigurati Rapid Mart desrivendo il lavoro svolto durante il progetto.

Il Capitolo 6 `e dedicato alla descrizione dell’ambiente di sviluppo usato in fase di reportistica, SAP Business Objects BI, per le analisi multidimensionali dei dati.

Il Capitolo 7 `e dedicato alla descrizione di alcuni dei report richiesti dal committente. Inizialmente viene mostrata la query manuale che permette di generare il relativo report e poi viene descritto come

costruirlo con lo strumento a dispozione. Inoltre viene mostrato il

codice SQL che BO genera per l’interrogazione del data warehouse. Per ovvi motivi, non verranno visualizzati i dati originali presenti nel data warehouse.

(16)

CASO DI STUDIO: gestione

ordini vendite, consegne,

fatturazione

Realizzare nel tempo una crescita adeguata e sostenibile dei ricavi `e

sempre pi `u difficile. Le aziende nel recente passato hanno

frequentemente realizzato la loro crescita attraverso l’espansione internazionale, le acquisizioni, gli aumenti dei prezzi. Oggi, in uno scenario di mercati prevalentemente saturi, queste mosse non sono pi ù sostenibili. La crescita deve quindi avvenire con un lavoro sistematico sulle attività commerciali, che rappresentano una delle opportunità pi ù interessanti per l’azienda in quanto spesso la qualità dei metodi e dei processi di vendita è bassa se paragonata a quella di altri comparti dell’azienda come la produzione, la logistica e il controllo di gestione.

I processi commerciali hanno storicamente ricevuto minore attenzione ed investimento in quanto è diffusa l’idea che queste attività siano meno strutturabili rispetto a quelle con flussi ripetitivi, fisici ed informativi e che parte fondamentale sia giocata dalle relazioni personali e dalla creatività individuale del venditore.

(17)

CONSEGNE, FATTURAZIONE

strategia commerciale, cioè dalle corrette scelte di prodotto, mercato e di canale distributivo, pu ò essere vanificato da una struttura di vendita non all’altezza di veicolare la proposta di valore con le corrette modalità.

Con il termine processo di vendita si intende l’insieme delle attivit`a

dell’azienda per la vendita di prodotti e servizi ai clienti. Inoltre

comprende tutte quelle attivit`a di identificazione e valutazione dei probabili clienti e di presentazione delle vendite.

Il presente lavoro di tesi nasce dall’esigenza, da parte dell’azienda, di analizzare il suo ciclo attivo attraverso un sistema di business intelligence che permetta al management e alla funzione vendite di controllare i dati di tutto il ciclo attivo e magari determinare in anticipo le entrate future. In questo capitolo verrà descritta brevemente l’azienda committente, il suo ciclo attivo ed infine i requisiti raccolti per poter iniziare il lavoro di analisi dei dati che porterà l’azienda alla possibilità di prendere le migliori decisioni per essa stessa.

2.1 L’azienda committente

Il presente lavoro di tesi `e stato sviluppato per una nota azienda italiana, di medio/grandi dimensioni, operante a livello mondiale nel settore dell’occhialeria.

L’azienda `e nata come fabbrica artigiana specializzata nella realizzazione di aste per occhiali in materiale prezioso. Negli anni successivi `e cresciuta creando una propria linea di prodotti ed espandendosi prima nei mercati europei e statunitensi per arrivare allo

stato attuale ad una copertura a livello mondiale. La Mission

dell’azienda `e la creazione di occhiali dal design ricercato e di materiali di alta qualit`a avente come obiettivo il mercato del lusso e dell’alta moda.

(18)

2.1.1 Organizzazione produttiva dell’azienda

L’azienda di cui sopra, ha il pieno controllo dell’intera filiera produttiva, dalla creazione delle collezioni, alla produzione, fino alla

distribuzione dei prodotti. La produzione delle aste per occhiali

avviene principalmente per alcuni marchi dell’alta moda e per alcuni marchi proprietari.

Ciclo produttivo

Il ciclo produttivo dell’azienda ha il seguente schema generale: • Acquisto di materie prime.

• Controllo qualitativo e quantitativo del materiale ricevuto. • Esecuzione delle lavorazioni.

• Controllo del prodotto finito. • Eventuale immagazzinamento.

• Spedizione dei prodotti finiti al cliente.

L’azienda segue due principali logiche produttive:

• Make to order, la produzione viene attivata solo dopo aver ricevuto gli ordini dei clienti. Pertanto prima avviene la vendita al cliente e solo dopo l’azienda si attiva per l’acquisto delle materie prime necessarie e per la produzione dei prodotti finiti che sono stati gi`a venduti.

• Make to stock, la produzione viene attivata in base a delle previsioni interne senza avere ancora ricevuto ordini dai clienti. L’azienda usa entrambe le filosofie cercando di integrarle per

(19)

filosofia per i marchi proprietari facendo delle previsioni sul passato e sulla situazione attuale del mercato.

2.1.2 Descrizione ciclo attivo dell’azienda

Nel presente lavoro viene mostrato solo una parte del processo produttivo di cui prima e precisamente si parla del “ciclo attivo” dell’azienda.

“Il ciclo attivo è l’insieme delle operazioni che un’azienda intrattiene verso i suoi clienti e che determina dei guadagni finanziari per l’azienda” [ak04]. In poche parole il ciclo attivo rappresenta le attività che l’azienda deve svolgere per vendere i propri prodotti e/o servizi, e tutte quelle attività che le permettono di gestire tutte le fasi della vendita.

Le principali operazioni di cui `e composto il ciclo attivo sono:

• La gestione dell’anagrafica del cliente con tutti i suoi dati fondamentali, ragione sociale, partita iva, modalit`a di pagamento ecc.

• La gestione dei documenti necessari per la vendita del bene e/o servizio partendo dall’ordine di vendita immesso dal cliente, la consegna del bene e/o servizio da parte dell’impresa, fino ad arrivare alla fattura attiva e alle note di credito attive.

Tramite tali operazioni le aziende possono tenere sotto controllo il loro ciclo attivo ed, eventualmente, riuscire a determinare in anticipo le entrate che si verificheranno.

In particolare, le principali attivit`a del ciclo attivo dell’azienda si possono schematizzare come segue:

(20)

• Emissione dell’ordine di acquisto da parte del cliente in cui vengono raccolti tutti i dati ad esso relativi.

• Invio merci ed emissione della bolla di uscita, della fattura rilasciata al cliente e di tutta la documentazione necessaria che mette in evidenza i rapporti tra l’azienda e il cliente nel tempo. • Gestione dei pagamenti dei clienti ed eventuali resi.

2.2 Raccolta dei requisiti

In questo paragrafo verranno descritti brevemente i requisiti di analisi richiesti dall’azienda committente.

Definire efficacemente i requisiti del business è molto importante in quanto essi rappresentano le fondamenta della attività successive. Diventa pertanto molto importante conoscere in maniera accurata sia i bisogni e le priorità degli utenti di business sia comprendere i requisiti di business del singolo progetto.

Come evidenziato in [Albano 12], nella fase di raccolta dei requisiti si effettuano delle analisi sulla natura e sugli scopi dell’azienda per riuscire a comprendere il contesto di lavoro, analisi sui processi aziendali per individuare le informazioni a cui i responsabili sono interessati. Tutto ci `o avviene tramite interviste ai responsabili stessi i quali possono dare indicazioni precise o rimanere pi `u sul generale. Dopo tali interviste, vengono raccolti i requisiti di analisi usando la terminologia dei dirigenti e si verifica che i dati operazionali che l’azienda ha a disposizione siano compatibili con i requisiti.

Le richieste del committente sono state molto generiche infatti egli ha semplicemente richiesto di poter eseguire delle analisi sul ciclo attivo e, precisamente, effettuare delle analisi relative agli ordini di vendita, alla

(21)

• Tenere giornalmente sotto controllo gli ordini di vendita e i resi e quindi, in seguito, cercare di capire le motivazioni che portano i clienti a rendere i prodotti.

• Tenere sotto controllo le spedizioni, quali sono state evase e quali no, quali spedizioni hanno una scadenza in tempi brevi e capire se `e possibile migliorare questi tempi. Si possono fare controlli sulle spedizioni scadute ma che non sono state ancora evase e quindi attivare un processo che cerchi di scoprire il motivo di tale ritardo. • Tenere sotto controllo il fatturato negli anni delle varie organizzazioni e linee di prodotto e intervenire anticipatamente in caso si noti qualche malfunzionamento. Ad esempio la linea ”JustForty” ha un fatturato dei primi quattro mesi del 2013 del 60% in meno rispetto agli stessi mesi del 2012. Quali potrebbero

essere le cause? Con tali controlli si pu `o capire il problema

anticipatamente e cercare di porne rimedio.

Per far ci ò, è stato necessario reingegnerizzare il data warehouse dell’azienda rispetto a quello già in uso per avere le informazioni necessarie a soddisfare le loro richieste.

Dopo un’attenta analisi e dalle precedenti richieste sono scaturite le seguenti necessit`a:

• Per gli ordini di vendita, analisi per organizzazione, per linea di prodotto e per responsabile come ad esempio:

– Confrontare il numero di ordini di vendita mensile rispetto

all’anno precedente.

– Confrontare il valore e le quantit`a ordinate tra anno corrente

e anno precedente.

(22)

– Confrontare il valore e le quantit`a nette (ordinato - reso) ordinate tra anno corrente e anno precedente.

• Per le spedizioni, analisi per organizzazione e per linea di prodotto come ad esempio:

– Confrontare il valore e le quantit`a spedite tra anno corrente e

anno precedente.

– Confrontare il valore dello spedito con il costo di spedizione

e calcolarne il relativo margine.

– Confrontare le quantit`a spedite con le quantit`a non ancora

evase e che scadono nel mese corrente, quante sono le quantit`a scadute e non ancora evase.

• Per le fatture, analisi per organizzazione , per linea di prodotto e per responsabile come ad esempio:

– Le prime 10 organizzazioni con il maggiore fatturato per

l’anno 2013, mettendo in evidenza il fatturato mensile di ognuna di esse.

– Confrontare il valore, le quantit`a fatturate e i resi mensili tra

anno corrente e anno precedente.

`E importante mettere in evidenza i seguenti aspetti:

• Ad ogni ordine di vendita pu `o essere associata nessuna (ordine non ancora evaso), una o pi `u fatture.

• Ad una fattura viene associato un solo ordine.

• Ad un ordine vengono associati uno o pi ù invii di merce in base alla disponibilità in magazzino o in base agli accordi con il cliente. • Ad una spedizione vengono associati uno o pi ù ordini nel caso in

(23)

2.3 Conclusioni

Nel presente capitolo, dopo una breve presentazione dell’azienda committente `e stata data una breve descrizione del suo ciclo attivo ed infine descritte le problematiche che volevano risolvere e i relativi requisiti di analisi richiesti dalla stessa.

(24)

SPECIFICA DEI REQUISITI E

PROGETTAZIONE DEI DATA

MART

In questo capitolo viene presentata la fase di specifica dei requisiti in cui le informazioni, raccolte precedentemente, vengono descritte in maniera pi `u formale e strutturata. Successivamente vengono mostrate le fasi di progettazione concettuale e progettazione logica dei tre data mart, oggetto di tesi, e infine una visione del data warehouse contenente i tre data mart di cui prima.

3.1 Introduzione

In base alle richieste, generiche, del committente, si `e deciso di apportare le opportune modifiche, di cui parleremo nei capitoli successivi, per permettergli di eseguire vari tipi di analisi, semplici e complesse, coinvolgendo una o pi `u tabelle dei fatti, varie dimensioni e misure.

(25)

DEI DATA MART

fatti, dimensioni e misure. Verranno descritte, nel dettaglio, le varie tabelle dei fatti, le dimensioni e le misure coinvolte. Infine verranno mostrati i modelli della progettazione concettuale e logica per ogni data mart.

Il contenuto del presente capitolo `e stato suddiviso secondo la tipologia del processo ognuno corrispondente alla relativa tabella dei fatti:

• Ordine di vendita e linee di vendita pianificate. • Consegna.

• Fatturazione.

Le prime due sono state unificate in un’unica tabella con granularità la singola linea dell’ordine. Ordine di vendita corrisponde al singolo ordine ma per avere maggiore dettaglio sui singoli materiali comprati e poter fare analisi pi ù approfondite è stato necessario l’uso di linee di vendita pianificate.

Consegna indica la singola spedizione e relativa consegna dei

materiali venduti. Ad ogni ordine possono corrispondere pi `u

spedizioni.

Fatturazione indica la singola riga di una fattura con, pertanto, la specifica dei materiali venduti. Ad ogni ordine corrispondono una o pi `u fatture.

Per ogni sezione che descrive un processo viene mostrata la specifica dei requisiti, la progettazione concettuale e la progettazione logica del data mart.

I tre data mart hanno diverse dimensioni in comune pertanto si `e deciso di presentare la struttura delle dimensioni nel dettaglio solo per il processo ordine di vendita.

(26)

3.2 Processo Ordine di Vendita

Il processo ordine di vendita rappresenta l’unione di ordine di vendita che comprende il singolo ordine del cliente (Sales Order) e di linee di vendita pianificate (Sales Schedule Lines) che mostra ogni singola riga di un ordine.

3.2.1 Specifica dei requisiti

Di seguito vengono riportati, in forma tabellare, i requisiti di analisi e per ognuno le dimensioni, le metriche e le misure coinvolte. Successivamente viene definita la tabella dei fatti con la sua granularit`a e le misure usate; quindi viene mostrata nel dettaglio ogni dimensione con i propri attributi e le eventuali relazioni gerarchiche tra essi; inoltre per ogni attributo viene mostrato un esempio.

(27)

DEI DATA MART

Analisi ordini di vendita

N Requisito di analisi Dimensioni Misure

1 Numero ordini di vendita per mese e per organizzazione rispetto al mese dell’anno precedente

Data, Organizzazione

-2 Numero ordini di vendita per mese e per linea di prodotto rispetto al mese dell’anno precedente

Data, LineaProdotto

-3 Trovare l’importo e le quantit`a totali degli ordini per organizzazione nel 2013

Data, Organizzazione ValoreLordoOrdinato, QuantitaLordeOrdinato 4 Trovare l’importo lordo, i resi e

l’importo netto degli ordini per marca con i totali parziali per il 2013

Data, LineaProdotto, Data ValoreLordoOrdinato, ValoreReso, ValoreNettoOrdinato 5 Confrontare l’importo lordo e i resi

degli ordini dell’anno corrente per organizzazione rispetto ai valori dell’anno precedente

Data, Organizzazione ValoreLordoOrdinato, ValoreReso

6 Trovare l’importo mensile e cumulato nel 2013 per trimestre e linea di prodotto

Data, LineaProdotto ValoreLordoOrdinato

7 Confrontare il valore e le quantit`a ordinate per linea di prodotto e tipologia di prodotto(sport, luxury) tra anno corrente e anno precedente.

Data, LineaProdotto, ValoreNettoOrdinato, QuantitaOrdinate

Tabella dei fatti

Rappresenta la tabella che contiene informazioni su un particolare fenomeno che si verifica in azienda e di interesse per il processo

decisionale. Ogni fatto `e caratterizzato da un insieme di attributi

numerici, detti misure che lo descrivono.

Nella tabella successiva viene mostrata la tabella dei fatti relativa all’ordine di vendita. In essa viene descritta anche la granularità del fatto che determina il tipo di analisi che si possono effettuare sui dati; è consigliabile rappresentare i dati con una granularità pi ù fine in quanto

(28)

poi, da essi, si possono ottenere dati meno dettagliati con semplici aggregazioni invece, il contrario non `e possibile farlo.

Fatto dell’ordine di vendita

Descrizione Dimensioni Misure

Un fatto `e rappresentato dalla singola riga dell’ordine, per avere il dettaglio sul materiale ordinato Data, Organizzazione, Cliente, LineaProdotto, Materiale, TipologiaDocumento, Responsabile ValoreLordoOrdinato, ValoreNettoOrdinato, ValoreReso, QuantitaLordeOrdinate, QuantitaNetteOrdinate, QuantitaRese

Cardinalit`a: circa 3Mil di record annui

Tabella delle dimensioni

Le dimensioni descrivono il contesto dei fatti permettendo di analizzare le misure dei fatti secondo prospettive diverse di analisi.

(29)

DEI DATA MART

Dimensioni dell’Ordine

Nome Descrizione Granularit`a

Data Dimensione temporale Giorno Cliente Anagrafica Cliente, negozio a

cui l’azienda vende

Cliente Organizzazione Anagrafica organizzazione Singola

organizzazione LineaProdotto Il marchio Singolo

marchio del cliente

Materiale Anagrafica del materiale, del prodotto

Singolo materiale venduto TipologiaDocumento tipo di documento dell’ordine,

identifica se `e un reso o un ordine

singola tipologia Responsabile Anagrafica del singolo agente

di vendita

Agente

Attributi dimensionali

Per ogni dimensione, presentata precedentemente, vengono mostrati i

principali attributi dimensionali. Non verranno elencati tutti gli

(30)

Data

Attributo Descrizione Esempio

Giorno Il giorno 20 Mese Il mese 01 Trimestre Il trimestre T1 Anno L’anno in formato 2013 Data La data 2013/09/03

Cliente

Codicecliente Codice Cliente 01202 NomeCliente Nome/ragione sociale del

negozio

Forty IndirizzoCliente Indirizzo del negozio via Cimabue NomeResponsabile Nome del responsabile del

negozio

Italo Calvino CodNazioneCliente Codice della nazionalit`a del

negozio

I DescrNazioneCliente Descrizione della nazionalit`a

del negozio

(31)

DEI DATA MART

Materiale

CodiceMateriale Codice Materiale, codice del singolo occhiale

10120 DescrMateriale Nome descrittivo dell’occhiale occhiale

modello X TipologiaMateriale Tipologia dell’occhiale, sole o

vista

Sole

LineaProdotto

CodLineaProdotto Codice della singola linea di prodotto

34567 DescrLineaProdotto Nome descrittivo della singola

linea di prodotto

Just Forty TipologiaProdotto tipologia del prodotto:

Luxury Fashion, Sport, Casual Trend

(32)

Responsabile

CodiceResponsabile Codice del responsabile 01202 NomeResponsabile Nome dell’agente di vendita Mario Rossi IndirizzoResp Indirizzo del responsabile via Picasso CodNazioneResp Codice della nazionalit`a del

responsabile

I DescrNazResp Descrizione della nazionalit`a

del responsabile

Italia EAttivo Flag per sapere se l’agente `e

attivo o no

(33)

DEI DATA MART

Organizzazione

CodOrganizzazione Codice della singola organizzazione

2356 DescrOrganizzazione Nome descrittivo della singola

organizzazione

Azienda Italy NomeRespOrg Nome del responsabile

dell’organizzazione

Mauro Bianchi IndirizzoOrg Indirizzo dell’organizzazione via

Garibaldi CodCittaOrg Codice della citt`a

TV DescrCittaOrg Descrizione della citt`a

Treviso NazioneOrg Nazione dell’organizzazione Italia

TipologiaDocumento

(34)

Tabella delle gerarchie dimensionali

Vengono descritte le gerarchie dimensionali specificando per ogni dimensione le possibili relazioni fra gli attributi. `E sempre consigliabile definire tali gerarchie perch`e permettono all’utente un’analisi interattiva sui dati, passando da un livello di dettaglio ad un altro in un’unica sessione di analisi.

Nel progetto è presente un’unica gerarchia tra gli attributi della dimensione Data. Essa è data da giorno→ mese → trimestre → anno ed è una gerarchia bilanciata in quanto sono sempre presenti tutti gli attributi.

Tabella delle misure

Vengono mostrate le misure di ogni fatto mettendo in evidenza se essa è additiva e se è derivata. L’additività è una proprietà molto importante perchè permette di aggregare le misure con la funzione somma per qualsiasi dimensione. Le misure semi-additive invece, possono essere sommate solo per alcune dimensioni. Infine le misure non additive non possono essere sommate in alcun modo, le uniche operazioni applicabili ad esse sono il conteggio o calcoli sul valore medio.

Di seguito viene mostrata la tabella con tutte le misure per Ordine di Vendita.

(35)

DEI DATA MART

Misure

Misura Descrizione Aggregabilit`a Derivata

ValoreLordoOrdinato Valore al lordo di una riga d’ordine

Additiva NO ValoreReso Valore dei prodotti resi Additiva NO ValoreNettoOrdinato Ammontare al netto dei

resi di una riga d’ordine

Additiva SI

(ValoreLordoOrdinato - ValoreReso)

QuantitaLordeOrdinateQuantit`a totali ordinate Additiva NO QuantitaRese Quantit`a di prodotti

restituite

Additiva NO QuantitaNetteOrdinateQuantit`a al netto dei resi

ordinate

Additiva SI

(QuantitaLordeOrdinate - Reso)

CostoMateriale Costo del singolo occhiale

Semi Additiva

NO CostoAstuccio Costo dell’astuccio

dell’occhiale

Semi Additiva

NO

3.2.2 Progettazione concettuale

La progettazione concettuale permette di descrivere le analisi dei dati utilizzando un linguaggio formale ma senza alcuna pretesa di completezza. Con esso si pu `o descrivere come sono organizzati i dati

(36)

modellano le gerarchie dimensionali e il loro tipo (bilanciata, incompleta, ricorsiva), le dimensioni degeneri e gli attributi descrittivi dei fatti.

Il formalismo grafico qui utilizzato per rappresentare a livello concettuale la struttura del data warehouse `e il modello dimensionale dei fatti, DFM (Dimensional Fact Model). In esso i fatti vengono modellati con un rettangolo diviso in due parti, il nome del fatto nella parte superiore e le misure nella parte inferiore. Le dimensioni, invece, sono rappresentate da archi non direzionati nel caso in cui non siano multi-valore e da un pallino finale denominato con il nome della dimensione. Anche gli attributi dimensionali vengono rappresentati allo stesso modo ma l’arco parte dalla dimensione corrispondente. Gli archi mettono in evidenza le dipendenze funzionali tra gli attributi. Le dimensioni degeneri del fatto hanno solo un arco che termina con un pallino, invece quelle descrittive non hanno il pallino.

Nella Figura 3.1 viene mostrato il modello concettuale del Data Mart Ordine di Vendita.

(37)

DEI DATA MART Ordini ValoreLordoOrdinato ValoreReso ValoreNettoOrdinato QuantitaLordeOrdinate QuantitaRese QuantitaNettOrdinate CostoMateriale CostoAstuccio Data Giorno Mese Trimestre Anno Data Cliente Materiale CodiceCliente NomeCliente IndirizzoCliente NomeResponsabile CodNazioneCliente DescrNazioneCliente CodiceMateriale DescrMateriale CodLineaProdotto DescrLineaProdotto TipologiaProdotto CodOrganizzazione DescrOrganizzazione NomeRespOrg IndirizzoOrg CodCittaOrg DescrCittaOrg Organizzazione LineaProdotto Responsabile TipologiaDocumento TipologiaMateriale CodiceResponsabile NomeResponsabile IndirizzoResp CodNazioneResp DescrNazResp EAttivo NazioneOrg TipoDocumento

Figura 3.1: Schema concettuale del data mart per l’analisi degli ordini di vendita.

3.2.3 Progettazione logica

Di seguito viene data una breve descrizione sui possibili modelli logici esistenti per poi presentare la progettazione logica del data mart per l’analisi degli ordini di vendita. Come specificato in [Kimball 02] i modelli logici relazionali possono essere:

• Schema a stella: nel caso in cui vi sia la presenza di una sola tabella dei fatti in relazione con pi `u tabelle dimensionali.

• A fiocco di neve: nel caso in cui vi sia una tabella dei fatti in relazione con pi `u tabelle dimensionali che sono in relazione con altre tabelle dimensionali.

• Schema a costellazione: nel caso in cui vi siano pi `u tabelle dei fatti che condividono tutte o alcune dimensioni.

(38)

Lo schema relazionale adottato in questo progetto `e quello a stella in cui ogni dimensione viene modellata mediante una tabella relazionale. Gli attributi sottolineati indicano che essi fanno parte della chiave primaria della tabella. I campi con post-fisso “ FK” indicano le chiavi esterne verso le tabelle dimensionali. I campi con post-fisso “ PK” indicano le chiavi surrogate delle tabelle dimensionali, i cui valori vengono generati automaticamente in fase di caricamento. La tabella dei fatti deve possedere tutte le chiavi primarie surrogate delle tabelle dimensionali, gli attributi descrittivi e le misure.

Di seguito viene mostrato lo schema logico.

Ordini Data_FK Cliente_FK Organizzazione_FK Materiale_FK LineaProdotto_FK Responsabile_FK TipologiaDocumento_FK ValoreLordoOrdinato ValoreReso ValoreNettoOrdinato QuantitaLordeOrdinate QuantitaRese QauntiaNetteOrdinate CostoMateriale CostoAstuccio Data Data_PK Number Giorno Number Mese Number Trimestre Number Anno Number Data Date Cliente Cliente_PK Number CodiceCliente Varchar NomeCliente Varchar IndirizzoCliente Varchar NomeResponsabile Varchar CodNazioneCliente Varchar DescrNazioneCliente Varchar Organizzazione Organizzazione_PK Number CodOrganizzazione Varchar DescrOrganizzazione Varchar IndirizzoOrg Varchar NomeRespOrg Varchar CodCittaOrg Varchar DescrCittaOrg Varchar NazioneOrg Varchar Materiale Materiale_PK Number CodiceMateriale Varchar DescrMateriale Varchar TipologiaMateriale varchar LineaProdotto Prodotto_PK Number CodLineaProdotto Varchar DescrLineaProdotto Varchar TipologiaProdotto Varchar TipologiaDocumento TipDocumento_PK Number TipoDocumento Varchar Responsabile Responsabile_PK Number CodiceResponsabile Varchar NomeResponsabile Varchar IndirizzoResp Varchar CodNazResp Varchar DescrNazResp Varchar EAttivo Varchar

Figura 3.2: Schema logico del data mart per l’analisi degli ordini di vendita.

3.3 Processo Consegna (Delivery)

(39)

DEI DATA MART

nel momento in cui avviene la consegna, viene rilasciata una bolla di

accompagnamento. Ovviamente i dati di codesta bolla verranno

inseriti nel gestionale. Per ogni ordine di vendita si possono avere pi `u consegne e quindi pi `u bolle.

3.3.1 Specifica dei requisiti

Analisi processo consegna

N Requisito di analisi Dimensioni Misure

8 Quantit`a di materiale spedita per linea di prodotto per mese e anno corrente

Data,

LineaProdotto

QuantitaSpedita

9 Per occhiali da sole e da vista restituire le quantit`a e il valore dello spedito, il costo della spedizione, il Margine e la sua percentuale

Data, Materiale QuantitaSpedita, ValoreSpedito, CostoSpedizione, Margine,

MarginePerc 10 Per linea di prodotto

le quantit`a spedite , quelle scadute e non ancora evase, le quantit`a non spedite ma non ancora scadute, quelle che scadono nei mesi successivi

Data QuantitaSpedita, QuantitaScaduta, QuantitaInScadenza

(40)

Nella tabella successiva viene mostrata la tabella dei fatti relativa al processo di consegna.

Fatto della consegna

Un fatto `e rappresentato dalla singola consegna Data, Cliente, Organizzazione, LineaProdotto, Materiale ValoreSpedito, CostoSpedizione, QuantitaSpedita, QuantitaScaduta, QuantitaInScadenza, Margine

Cardinalit`a: circa 7Mil record annui

Di seguito vengono descritte le dimensioni del fatto Consegna.

Dimensioni di Consegna

organizzazione LineaProdotto Il marchio Marchio Materiale Anagrafica del materiale Singolo

(41)

DEI DATA MART

Come si pu `o facilmente notare le dimensioni del processo Consegna rappresentano un sottoinsieme delle dimensioni del processo Ordine di

Vendita. Pertanto si `e deciso di non replicare inutilmente le stesse

informazioni.

Di seguito viene mostrata la tabella con tutte le misure per Consegna.

Misure

ValoreSpedito Valore dei materiali spediti

Additiva NO CostoSpedizione Costo da affrontare per

la spedizione

Semi Additiva

NO QuantitaSpedita Quantit`a spedite Additiva NO QuantitaScaduta Quantit`a di materiali

non ancora spediti e scadute

Additiva NO QuantitaInScadenza Quantit`a di materiali

non ancora spediti che scadranno in tempi brevi

Additiva NO

Margine Margine tra valore spedito e costo di spedizione

Additiva SI (ValoreSpedito -CostoSpedizione)

(42)

3.3.2 Progettazione concettuale

Nella Figura 3.3 viene mostrato il modello concettuale del data mart per l’analisi del processo di consegna.

Consegna ValoreSpedito CostoSpedizione QuantitaSpedita QuantitaScaduta QuantitaInScadenza Margine Data Giorno Mese Trimestre Anno Data Cliente Materiale CodiceCliente NomeCliente IndirizzoCliente NomeResponsabile CodNazioneCliente DescrNazioneCliente CodiceMateriale DescrMateriale CodLineaProdotto DescrLineaProdotto TipologiaProdotto CodOrganizzazione DescrOrganizzazione NomeRespOrg IndirizzoOrg CodCittaOrg DescrCittaOrg Organizzazione LineaProdotto TipologiaMateriale NazioneOrg

Figura 3.3: Schema concettuale del data mart per l’analisi delle

consegne.

3.3.3 Progettazione logica

La progettazione logica `e simile a quella del data mart per l’analisi degli ordini di vendita.

(43)

DEI DATA MART Consegna Data_FK Cliente_FK Organizzazione_FK Materiale_FK LineaProdotto_FK ValoreSpedito CostoSpedizione QuantitaSpedita QuantitaScaduta QuantitaInScadenza Margine Data Data_PK Number Giorno Number Mese Number Trimestre Number Anno Number Data Date Cliente Cliente_PK Number CodiceCliente Varchar NomeCliente Varchar IndirizzoCliente Varchar NomeResponsabile Varchar CodNazioneCliente Varchar DescrNazioneCliente Varchar Organizzazione Organizzazione_PK Number CodOrganizzazione Varchar DescrOrganizzazione Varchar IndirizzoOrg Varchar NomeRespOrg Varchar CodCittaOrg Varchar DescrCittaOrg Varchar NazioneOrg Varchar Materiale Materiale_PK Number CodiceMateriale Varchar DescrMateriale Varchar TipologiaMateriale varchar LineaProdotto Prodotto_PK Number CodLineaProdotto Varchar DescrLineaProdotto Varchar TipologiaProdotto Varchar

Figura 3.4: Schema logico del data mart per l’analisi delle consegne.

3.4 Processo Fatturazione (Billing)

In questa fase l’azienda invia la fattura al cliente relativamente a uno o pi `u ordini.

3.4.1 Specifica dei requisiti

Di seguito vengono elencati i requisiti di analisi richiesti relativamente al processo di fatturazione.

(44)

Analisi processo fatturazione

N Requisito di analisi Dimensioni Misure

11 I primi 7 marchi dell’anno 2013 con maggiore fatturato Data, LineaProdotto ValoreFatturato, QuantitaFatturata 12 Per ogni organizzazione il fatturato e i resi per ogni anno e mese confrontato con l’anno precedente Organizzazione, Data, TipologiaDocumento ValoreFatturato, ValoreReso

13 Resi, quantit`a e valore fatturato per ogni linea di prodotto per ogni mese rispetto al mese dell’anno precedente LineaProdotto, Data ValoreFatturato, QuantitaLordeFatturate, QuantitaRese, QuantitaNetteFatturate 14 Resi, quantit`a e valore

fatturato per ogni linea di prodotto e per ogni anno. Calcolare le relative variazioni tra gli anni

Cliente, Data ValoreFatturato,

QuantitaLordeFatturate, QuantitaRese

Nella tabella successiva viene mostrata la tabella dei fatti relativa al processo di fatturazione.

(45)

DEI DATA MART

Fatto della Fattuazione

Un fatto `e rappresentato dalla singola riga della fattura. Ad ogni riga corrisponde un materiale venduto

Materiale, Data, Cliente, Organizzazione, LineaProdotto, TipologiaDocumento ValoreFatturato, QuantitaLordeFatturate, QuantitaRese, QuantitaNetteFatturate Cardinalit`a: circa 8Mil record annui

(46)

Dimensioni di Fatturazione

organizzazione Materiale Anagrafica del materiale Singolo

materiale LineaProdotto Il marchio dell’azienda cliente Singolo

marchio TipologiaDocumento tipo di documento dell’ordine,

identifica se `e un reso o un ordine

singola tipologia Responsabile Anagrafica dell’agente di

vendita

Agente

Come si pu `o facilmente notare le dimensioni del processo Fatturazione rappresentano un sottoinsieme delle dimensioni del

processo Ordine di Vendita. Pertanto si `e deciso di non replicare

inutilmente le stesse informazioni.

(47)

DEI DATA MART

Misure

ValoreFatturato Valore del fatturato Additiva NO QuantitaLordeFatturateQuantit`a fatturate Additiva NO QuantitaRese Quantit`a di materiali

restituiti

Additiva NO QuantitaNetteFatturate Quantit`a al netto dei resi Additiva SI

(QuantitaLordeFatturate - QuantitaRese)

3.4.2 Progettazione concettuale

Nella Figura 3.5 viene mostrato il modello concettuale del data mart per l’analisi del processo di fatturazione.

Fatture ValoreFatturato QuantitaLordeFatturate QuantitaRese QuantitaNetteFatturate Data Giorno Mese _Trimestre Anno Data Cliente Materiale CodiceCliente NomeCliente IndirizzoCliente NomeResponsabile CodNazioneCliente DescrNazioneCliente CodiceMateriale DescrMateriale CodLineaProdotto DescrLineaProdotto TipologiaProdotto CodOrganizzazione DescrOrganizzazione NomeRespOrg IndirizzoOrg CodCittaOrg DescrCittaOrg Organizzazione LineaProdotto TipologiaMateriale NazioneOrg TipologiaDocumento TipoDoc Responsabile CodResp NomeResp IndResp CodNazResp DescrNazResp EAttivo

Figura 3.5: Schema concettuale del data mart per l’analisi della

(48)

3.4.3 Progettazione logica

La progettazione logica `e simile a quella del data mart per l’analisi degli ordini di vendita. Fatture Data_FK Cliente_FK Organizzazione_FK Materiale_FK LineaProdotto_FK Responsabile_FK TipologiaDocumento_FK ValoreFatturato QuantitaLordeFatturate QuantitaRese QuantitaNetteFatturate Data Data_PK Number Giorno Number Mese Number Trimestre Number Anno Number Data Date Cliente Cliente_PK Number CodiceCliente Varchar NomeCliente Varchar IndirizzoCliente Varchar NomeResponsabile Varchar CodNazioneCliente Varchar DescrNazioneCliente Varchar Organizzazione Organizzazione_PK Number CodOrganizzazione Varchar DescrOrganizzazione Varchar IndirizzoOrg Varchar NomeRespOrg Varchar CodCittaOrg Varchar DescrCittaOrg Varchar NazioneOrg Varchar Materiale Materiale_PK Number CodiceMateriale Varchar DescrMateriale Varchar TipologiaMateriale varchar LineaProdotto Prodotto_PK Number CodLineaProdotto Varchar DescrLineaProdotto Varchar TipologiaProdotto Varchar TipologiaDocumento TipDocumento_PK Number TipoDocumento Varchar Responsabile Responsabile_PK Number CodiceResponsabile Varchar NomeResponsabile Varchar IndirizzoResp Varchar CodNazResp Varchar DescrNazResp Varchar EAttivo Varchar

Figura 3.6: Schema logico del data mart per l’analisi della fatturazione.

3.5 Riepilogo delle misure e delle dimensioni

Nelle due tabelle che seguono vengono mostrate le dimensioni e le misure che le tabelle dei fatti condividono.

(49)

DEI DATA MART

Dimensioni dei fatti

Dimensione Ordine Consegna Fatture

Data X X X Cliente X X X Organizzazione X X X Materiale X X LineaProdotto X X X TipologiaDocumento X X Responsabile X X

Misure dei fatti

Misura OrdiniVendita Sped/Consegna Fatturazione

ValoreLordoOrdinato X ValoreReso X ValoreNettoOrdinato X QuantitaLordeOrdinate X QuantitaRese X QuantitaNetteOrdinate X CostoMateriale X CostoAstuccio X ValoreSpedito X CostoSpedizione X QuantitaSpedita X QuantitaScaduta X QuantitaInScadenza X Margine X ValoreFatturato X QuantitaLordeFatturate X QuantitaRese X QuantitaNetteFatturate X VariazioneQtaFatturate% X

(50)

3.6 Data Warehouse finale

Come si nota dalla tabella del riepilogo delle dimensioni, nella precedente sezione, i tre data mart condividono quasi tutte le

dimensioni ad esclusione di TipologiaDocumento, Materiale e

Responsabile.

Lo schema relazionale del data warehouse, pertanto, è uno schema a costellazione in cui vi sono tre tabelle dei fatti che condividono pi ù dimensioni. Lo schema finale del data warehouse non è stato inserito in quanto complesso per il numero di tabelle dimensionali e tabelle dei fatti.

3.7 Conclusioni

In questo capitolo sono state descritte le fasi di specifica dei requisiti di analisi, progettati i data mart, prima secondo il formalismo grafico-concettuale DFM poi secondo un modello logico-relazionale.

Dai requisiti sono stati individuati tre principali soggetti di analisi, gli ordini di vendita, le consegne di materiale ai clienti e le relative fatturazioni. Ognuno di essi `e stato modellato con un diverso data mart e poi messi insieme al fine di ottenere il data warehouse finale. Tale schema relazionale viene riassunto mediante l’uso di tabelle contenenti la condivisione delle misure e delle tabelle dimensionali tra i fatti.

(51)

SAP HANA

-HIGH PERFORMANCE

ANALYTIC APPLIANCE

Nel presente capitolo verr`a brevemente descritto il sistema SAP HANA soffermandosi su alcuni dettagli della sua architettura.

SAP HANA `e una piattaforma “In-Memory” progettata per processare grandi volumi di dati transazionali in real time. SAP HANA include alcuni strumenti per la modellazione dei dati, per la gestione

dei dati e per la sicurezza. Esso viene fornito in combinazione a

dell’hardware dedicato.

4.1 DBMS SAP HANA

Come descritto in [Albano 12] i principali DBMS memorizzano i record di una tabella uno dopo l’altro in un insieme di pagine fisiche della memoria permanente (memorizzazione per righe). Questa soluzione ottimizza le prestazioni delle applicazioni OLTP in quanto operano e modificano pochi record alla volta. Per `o per applicazioni OLAP, che

(52)

raggruppamenti di grandi insiemi di dati solo su alcuni attributi, si possono ottenere migliori prestazioni con sistemi che usano una memorizzazione per colonne dei dati di una tabella. Precisamente nelle pagine fisiche vengono memorizzati valori contigui di un singolo attributo.

SAP HANA `e un DBMS relazionale ibrido che permette la

memorizzazione dei dati sia per riga che per colonna. Rispetto ai

tradizionali DBMS, SAP HANA in fase di creazione delle tabelle permette di poter scegliere se memorizzare i dati della tabella specificata con uno o con l’altro motore.

Un altra caratteristica che rende SAP HANA veloce `e il fatto che i dati vengono mantenuti e processati in memoria, offrendo quindi il

massimo delle prestazioni in termini di velocit`a, inoltre per

minimizzare l’occupazione della memoria richiesta vengono utilizzati avanzati algoritmi di compressione.

Ad intervalli regolari le modifiche vengono riportate in memoria permanente tramite savepoint. Ad ogni transazione invece corrisponde un entry nel file di log che, per mantenere alte le prestazioni, viene salvato su disco a stato solido.

Il DBMS viene fornito con un ambiente di lavoro, SAP HANA Studio, che permette di effettuare interrogazioni usando l’SQL, MDX e l’utilizzo di funzioni analitiche quali ROLLUP, CUBE, RANK, DENSE RANK, ROW NUMBER, LEAD, LAG. Il motore di calcolo interno del DBMS permette di eseguire dei calcoli in modo tale che siano eseguiti nel DBMS senza dover spostare i dati al livello di applicazione. SAP HANA supporta anche un’estensione di SQL, SQL Script che viene usato per l’inserimento di grandi quantit`a di dati nelle basi di dati.

(53)

HIGH PERFORMANCE ANALYTIC APPLIANCE

4.2 Architettura

Figura 4.1: Architettura SAP HANA

In Figura 4.1 viene mostrata l’architettura di SAP HANA. La piattaforma `e composta da diversi elementi.

• SAP HANA Database: Database Management System ibrido

in-memory che combina la tecnologia di memorizzazione dei dati per riga o per colonna.

• SAP HANA Client: un insieme di librerie che vengono utilizzate da applicazioni esterne per connettersi al DBMS SAP HANA. • SAP HANA studio: un ambiente grafico basato su Eclipse per la

modellazione dei dati, l’amministrazione e la gestione della sicurezza del DBMS SAP HANA. Tramite l’area di modellazione dei dati si possono creare, modificare o cancellare oggetti ad esempio si possono creare tabelle sfruttando l’interfaccia grafica stessa o attraverso l’SQL.

(54)

4.3 Vantaggi/Chances e Limiti di SAP HANA

4.3.1 Vantaggi

Di seguito vengono riassunti i principali vantaggi nell’utilizzo di SAP HANA.

• Miglioramento delle performance, queries eseguite da 10 a 100 volte pi `u velocemente, caricamento dei dati e calcoli eseguiti pi `u rapidamente.

• Compressione dei dati, minimizza l’occupazione di memoria

utilizzando avanzati algoritmi di compressione e

un’organizzazione “column-oriented”.

• Miglioramento dei processi di pianificazione e previsione impiegando modelli analitici che scoprono trend (tendenze) e pattern (modelli).

4.3.2 Limiti

Per quanto SAP HANA sia innovativa, ci sono anche alcuni limiti da tenere bene in mente.

• Non `e una piattaforma per il caricamento, il processamento e l’analisi di enormi volumi, petabyte e oltre, di dati strutturati. Pertanto SAP HANA, momentaneamente, non `e adatta per l’analisi dei social network e dei social media.

• Non `e pre-ottimizzata per supportare applicazioni non-SAP, le quali richiedono un notevole re-engineering dell’applicazione da parte dei gruppi dell’IT.

(55)

PROCESSO DI ETL

In questo capitolo si parler`a del processo di ETL corrispondente alle fasi di estrazione, trasformazione e caricamento dei dati nel data warehouse, necessario affinch´e questi ultimi siano disponibili per la creazione di report.

Verr`a presentato il principale strumento utilizzato per

l’implementazione e lo sviluppo delle procedure di ETL, SAP BusinessObjects Data Services in abbinamento al nuovo standard SAP BusinessObjects Rapid Mart e come questo sia stato utilizzato all’interno del presente progetto.

5.1 Introduzione

Una volta che il data warehouse `e stato progettato bisogna realizzarlo. In questa fase si affrontano i problemi tipici del processo di ETL (Extract, Transform, Load) dovuti all’eterogeneit`a delle sorgenti dei dati. Prima di caricare i dati nel data warehouse, essi devono essere sottoposti a due particolari operazioni:

• Trasformazione: provenendo da sorgenti diverse `e necessario rendere i dati omogenei eliminando differenze sintattiche e

(56)

semantiche.

• Pulitura: i dati devono essere controllati per eliminare errori di rappresentazione, gestire i valori nulli o aggiungere informazioni necessarie.

È facilmente intuibile che questa è una delle fasi fondamentali in quanto le scelte impattano pesantemente sulle performance e sull’affidabilità delle analisi successive.

Inoltre, oltre che fondamentale, `e una fase molto costosa sia per le grandi quantit`a di dati elaborate sia per gli sviluppatori che devono gestire i vari processi.

“Un sistema ETL ben disegnato estrae i dati da sorgenti separate, controlla e si assicura che i dati siano conformi a degli standard di qualit`a e di consistenza stabiliti al momento della progettazione del data warehouse, rende omogenei i dati provenienti dalle diverse sorgenti e infine li inserisce nella base di dati di destinazione” [Kimball 04].

La Figura 5.1 mostra i passi del processo di ETL come descritto da [Davenport 08].

Figura 5.1: Fasi processo ETL

I dati vengono estratti dalle sorgenti dati usando uno strumento di estrazione dati. I dati estratti vengono quindi elaborati tramite varie

(57)

Durante questa fase di trasformazione vengono gestiti gli aspetti di

qualit`a, integrit`a e le modifiche necessarie. Al termine della

trasformazione i dati sono quindi caricati nel data warehouse di destinazione e resi disponibili per le analisi.

5.2 SAP Business Objects Data Services

SAP BusinessObjects Data Services (DS) `e lo strumento che SAP offre per l’integrazione dei dati da sorgenti eterogenee, infatti tramite questo strumento `e possibile estrarre, trasformare e caricare i dati per aggiornare il data warehouse.

Le operazioni da eseguire attraverso SAP BusinessObjects Data Services vengono progettate e lanciate tramite l’ambiente Data Services Designer.

L’ambiente Data Services Designer permette di creare diversi progetti, un progetto raccoglie tutti gli elementi, chiamati oggetti, necessari all’integrazione e quindi al processo ETL. In particolare un progetto è composto da diversi job, ogni job rappresenta un elemento eseguibile del progetto. Sarà quindi compito del job eseguire quei task necessari a caricare e aggiornare il nostro datawarehouse. L’esecuzione di un job pu ò essere lanciata manualmente o programmata per esecuzioni ad orari e giorni predefiniti.

I task all’interno di un job sono organizzati tramite i work flow. Il work

flow `e un oggetto che definisce il processo di esecuzione dei flussi dati.

Un workf low si compone dei seguenti elementi:

• Uno Script `e un oggetto ad uso singolo all’interno del quale `e possibile definire del codice di script per l’invocazione di funzioni, per eventuali inizializzazioni e per assegnare valori alle variabili.

(58)

• Il Conditional è un oggetto usato per implementare logiche di if/then/else in un work flow. Ad esempio pu ò essere utilizzato per verificare se un’esecuzione è di tipo “FIRST”, primo caricamento, o “DELTA”, e quindi aggiornamento.

• Il While `e un oggetto che permette di ripetere una sequenza di passi in un work flow fino a quando una condizione non viene verificata.

• Il Try/catch è la combinazione di pi ù oggetti, un try e uno o pi ù catch che permettono rispettivamente di catturare un’eccezione e di eseguire un flusso alternativo per l’eccezione catturata.

• Il Data Flow `e un oggetto che definisce il flusso di dati, cio`e definisce l’estrazione, la trasformazione e il caricamento dei dati. Gli elementi principali del data flow sono: la sorgente (ABAP Data Flow, file o tabelle), la destinazione (tabelle) e i trasformatori (query, case, merge, pivot, etc).

In Figura 5.2 si pu `o vedere come gli elementi sopra descritti vengano visualizzati e organizzati nell’ambiente Data Services Designer. Nell’albero sono presenti i progetti con i diversi job associati. In basso `e visibile l’elenco dei datastore ovvero le sorgenti/target di tipo tabellare.

5.2.1 SAP BusinessObjects Rapid Mart

Negli ultimi anni SAP ha sviluppato i Rapid Mart, soluzioni preconfigurate utilizzate come base per la definizione di data warehouse nelle aziende.

Un pacchetto Rapid Mart `e un estensione di SAP BusinessObjects Data Integrator che raccoglie modelli di dati pronti all’uso, con le relative procedure di trasformazione e caricamento dalle applicazioni

(59)

Figura 5.2: job e datastore del progetto

Siebel and Salesforce.com. Alcuni di questi pacchetti includono anche oggetti di reportistica ed universi pronti all’uso. Ogni pacchetto pu `o essere esteso e personalizzato per gestire specifiche esigenze.

SAP ha rilasciato diversi modelli Rapid Mart cercando di coprire le principali aree di business di un azienda.

• Area finanziaria che comprende:

– contabilit`a generale,

– contabilit`a clienti,

– contabilit`a fornitori,

– centro di costo,

– immobilizzazioni.

• Area operazionale che comprende:

(60)

– acquisti.

• Area di produzione che comprende:

– piano di produzione,

– manutenzione impianti,

– gestione progetti.

• Gestione del capitale umano.

L’utilizzo di questi pacchetti standard permette di velocizzare l’implementazione di un data warehouse, perché offre gli elementi di uso pi ù comune già pronti all’uso.

5.3 ETL del progetto

Per la progettazione e implementazione del processo ETL sono stati utilizzati gli strumenti descritti in precedenza insieme al pacchetto dedicato all’area vendite (Rapid Mart Sales) presente nell’ultima versione dei rapid mart, SAP BusinessObjects Rapid Marts 4.0.

L’intero progetto `e stato prima sviluppato e testato in un ambiente di sviluppo, ed infine `e stato portato nell’ambiente di produzione.

5.3.1 Rapid Mart Sales

Il pacchetto Rapid Mart Sales fa parte dell’insieme dei pacchetti Rapid Mart offerti da SAP ed `e dedicato a coprire le seguenti esigenze:

• Analizzare i trend delle vendite.

• Determinare il comportamento del cliente.

(61)

• Tracciare le consegne ai clienti.

• Tracciare le performance delle consegne puntuali.

Il pacchetto `e stato adattato al caso di studio del presente progetto

eliminando le informazioni inutili, ridondanti o non pertinenti. In

particolare sono stati eliminati diversi attributi e inseriti di nuovi, sono stati effettuati calcoli ad esempio per i passaggi di valuta e sono stati eliminati alcuni flussi non necessari.

Per quanto riguarda le fasi di ETL il pacchetto utilizzato dispone di otto job predefiniti: uno per la verifica delle connessioni verso sorgenti e destinazione, uno per il caricamento dello schema ed infine sei dedicati al caricamento vero e proprio dei dati.

I job dedicati al caricamento dei dati sono divisi a sua volta in

quattro per il caricamento delle dimensioni

(Sales Load DIMS XX SAP), uno per il riempimento delle tabelle dei fatti (Sales Load FACTS SAP) ed infine uno per il caricamento delle tabelle dei fatti relativi alle vendite (Sales Load SAP). I job per il caricamento delle dimensioni si differenziano tra loro per la frequenza di esecuzione, infatti non tutte le dimensioni variano allo stesso modo. Alcune come l’elenco clienti, varieranno pi `u spesso e quindi andranno caricate giornalmente, altre come la dimensione della valuta, variano raramente e quindi possono essere caricate settimanalmente.

Il job Sales Load SAP `e dedicato al caricamento dei dati relativi alle

vendite. Questo job `e stato modificato per adattarlo alle esigenze

dell’azienda. Le modifiche hanno riguardato alcune sezioni dei work flow presenti nel job quali:

• Sezione Sales Order: questa sezione si occupa estrarre i dati relativi ad un ordine da soluzioni SAP e memorizza le transazioni per singoli documenti su un ordine di vendita nella tabella dei

(62)

fatti SALES ORDER FACT. Un ordine di vendita `e un documento che memorizza l’acquisto di beni o servizi da parte di un cliente.

• Sezione Sales Schedule Lines: questa sezione estrae le

informazioni dettagliate sugli ordini di vendita. Nelle soluzioni SAP, i documenti di vendita hanno la medesima struttura, un’intestazione del documento con vari elementi i quali, a loro volta, possono avere varie linee pianificate. Una linea specifica la quantit`a che deve essere consegnata, la data, e il tempo di consegna. In particolare questa sezione estrae i dati dalla tabella SAP VBEP e salva le informazioni per ogni singola linea

dell’ordine di vendita nella tabella dei fatti

SALES SCHED LINE FACT.

• Sezione Delivery: questa sezione estrae informazioni sulle

consegne, le restituzioni, le spedizioni e le notifiche di spedizione. In particolare questa sezione estrae le informazioni di tutte le categorie dei documenti di consegna dalle tabelle SAP e memorizza i dati nella tabella dei fatti DELIVERY FACT.

• Sezione Billing: questa sezione estrae informazioni di

fatturazione come fatture, fatture pro-forma, note di credito e di debito. Dopo che un materiale viene spedito, una fattura viene inviata al cliente e viene costruito un documento di fatturazione. I dati estratti vengono memorizzati nella tabella dei fatti BILLING FACT.

Anche gli altri job presenti nel rapid mart sono stati modificati e adattati. Di seguito un esempio dei job riscritti.

• J ANAGRAFICHE DWH: il job si occupa di caricare e trasformare i dati relativi all’anagrafica come Organizzazione, LineaProdotti,

(63)

• J SALES FACTS G1 e J SALES FACTS G2: i job si occupano di caricare e trasformare i dati delle tabelle dei fatti.

• J TEST: il job `e utilizzato per testare l’esecuzione di singoli work flow in isolamento prima dell’inserimento nei job principali.

I primi tre job contengono i flussi che, giornalmente, vengono eseguiti per caricare i dati nel DWH. I flussi verranno descritti in maggior dettaglio nelle sezioni successive.

Infine i work flow progettati durante il lavoro di tesi fanno uso di variabili globali che servono per configurare i diversi flussi di lavoro.

Di seguito alcuni esempi di variabili globali usate nei work flow: • $G SDATE e $G EDATE determinano i limiti dell’intervallo

temporale per cui filtrare i fatti caricati nel DWH.

• $G LANGUAGE rappresenta il codice della lingua per la quale verranno estratti dall’origine SAP gli attributi descrittivi.

• $G LOAD DATE e $G LOAD TIME rappresentano il timestamp che verr`a inserito negli appositi campi di ogni record delle tabelle del DWH. Tali variabili indicano la data e il tempo del caricamento.

• $G LOAD TYPE indica se si tratta di un caricamento “FIRST”, con creazione della struttura del DWH e dei dati, o di un caricamento “DELTA”, solo aggiornamento dei dati.

• $G GLOBAL CURRENCY indica la valuta globale da considerare nelle trasformazioni. Ad esempio per il calcolo del fatturato netto. In Figura 5.3 viene mostrato uno screenshot di alcune variabili globali utilizzate.

(64)

Figura 5.3: variabili globali del progetto

5.3.2 Data Flow

Di seguito verranno presentati i principali data flow utilizzati per realizzare le diverse fasi dell’ETL.

Estrazione

Per poter estrarre i dati da SAP `e necessario utilizzare l’ABAP DataFlow il quale genera codice ABAP (Advanced Business Application Programming) che interroga le strutture sorgenti definite nel flusso.

Nella Figura 5.4 viene mostrato un esempio di flusso ABAP Data

Flow. Il flusso estrae i dati dalle tabelle SAP VBRP e VBRK che

contengono i dati di fatturazione, effettua una Inner Join tra le tabelle e il risultato viene salvato in un file. Il file prodotto dal flusso verr`a usato durante la fase di primo caricamento nella base di dati.

Trasformazione

(65)

Figura 5.4: Esempio di ABAP Data Flow

operazioni di pivot o reverse pivot (rotazione da colonne a righe e viceversa), inserimento di nuovi campi, conversioni di tipi di dati, etc.

Di seguito alcune trasformazioni e controlli che vengono spesso applicati ai dati.

• I campi di tipo stringa, provenienti dalle sorgenti, potrebbero avere spazi prima e dopo il valore, per eliminarli viene utilizzata la funzione trim() che provvede ad eliminarli.

• Alcuni valori delle misure e delle dimensioni potrebbero avere valori nulli creando problemi in fase di analisi e caricamento. Tramite la funzione nvl() vengono assegnati dei valori di default, definiti nelle variabili globali, per le date, per i campi numerici e per le stringhe.

• Il valore di alcuni attributi dimensionali, in genere le descrizioni, vengono ottenuti tramite la concatenazione di pi `u attributi.

In Figura 5.5 viene mostrato un flusso che trasforma i dati della fatturazione e li carica nella tabella dei fatti.