Realizzazione di KPI per consentire miglioramenti qualitativi inerenti ai servizi

(1)

UNIVERSITÀ DI PISA Dipartimento di Informatica

Corso di Laurea Magistrale in Informatica per l’Economia e per l’Azienda (Business Informatics)

TESI DI LAUREA

Realizzazione di KPI per consentire miglioramenti qualitativi inerenti ai servizi RELATORE Antonio FRANGIONI CANDIDATO Ada GENTILE ANNO ACCADEMICO 2017-18 I Sessione

(2)

Un pianeta in un sasso, l’infinito in un passo (Baciami Ancora - Jovanotti)

(3)

Indice

Introduzione 1

1 Business Intelligence 3

1.1 Cos’è la BI? . . . 3

1.1.1 Controllo di gestione . . . 4

1.1.2 Decision Support System . . . 5

1.2 Processo di BI . . . 6 1.2.1 Data Source . . . 7 1.2.2 ETL . . . 7 1.2.3 Data Warehouse . . . 8 1.2.4 Data Mining . . . 9 1.3 Definizione di DW . . . 10

1.4 Modello multidimensionale Concettuale . . . 12

1.5 Modello multidimensionale: Cubo . . . 13

1.6 Data Mart Design . . . 14

2 Caso di studio 16 2.1 Azienda ospitante . . . 16

2.2 Azienda committente . . . 16

2.3 Presentazione del problema . . . 17

2.3.1 Definizione dei tempi . . . 18

2.3.2 Raccolta dei requisiti . . . 18

2.4 Progettazione DW . . . 20

2.4.1 Analisi dei requisiti . . . 20

2.4.2 Data Mart Concettuale . . . 27

(4)

3 Caso di studio - ETL 29

3.1 Strumenti . . . 29

3.1.1 MS SQL Server . . . 29

3.1.2 SAP Data Services . . . 31

3.2 Fonti di dati . . . 33 3.3 Processo di ETL . . . 35 3.3.1 WF: Import tabelle . . . 36 3.3.2 WF: Min IDLettura . . . 37 3.3.3 WF: Tabelle Pivot . . . 37 3.3.4 WF: Contatore . . . 39 3.3.5 WF: Tabella Anomalie . . . 40

3.4 Gestione dei job . . . 42

3.5 Problematiche riscontrate . . . 43

4 Caso di studio - DW 45 4.1 Strumenti . . . 45

4.1.1 SAP BO Information Design Tool . . . 45

4.2 Livello Aziendale . . . 46

4.2.1 Colonne calcolate . . . 47

4.3 Verifica Integrità . . . 48

5 Reporting 50 5.1 Reportistica . . . 50

5.1.1 Key Performance Indicator . . . 51

5.2 Strumenti . . . 54

5.2.1 SAP BO Web Intelligence . . . 54

5.3 Report . . . 55

5.3.1 Analisi Giorno Lavorativo . . . 55

5.3.2 Analisi Per Fasce . . . 57

5.3.3 Analisi Tempi di Ciclo . . . 58

5.3.4 Analisi di Dettaglio . . . 59

5.3.5 Report storico Giornaliero e Mensile . . . 59

(5)

Conclusioni 63

Acronimi 65

(6)

Introduzione

“BI is about providing the right data at the right time to the right people so that they can take the right decisions” – Nic Smith with Microsoft BI Solutions Marketing. La Business Intelligence - d’ora in poi BI - è comunemente descritta come l’insieme di processi aziendali istituiti per la raccolta, conservazione ed analisi di dati, attraverso l’uso di soluzioni software dedicate, con lo scopo di estrarne informazioni strategiche, tipicamente usate da dirigenti d’azienda, per poter meglio supportare le decisioni e creare rapporti informativi per il controllo direzionale.

L’obiettivo di questo lavoro di tesi è la determinazione di un set di indicatori di performance (Key Performance Indicators) idonei all’individuazione di eventuali criticità legate all’attività degli operatori di campo.

Inizialmente si provvederà ad esaminare le richieste del cliente e definire un’analisi dei requisiti. Successivamente si passerà ad una prima analisi delle informazioni fornite dalla committenza e all’organizzazione dei dati nel modo più appropriato per soddisfare le loro esigenze. I risultati, infine, saranno rappresentati in appositi report navigabili su diversi livelli di granularità.

Lo scopo del progetto è quello di soddisfare l’esigenza di monitorare e analizzare, tramite opportune tecniche di Business Intelligence, i comportamenti e le tempistiche dei propri operatori che, tramite un apposito terminale, registrano i timestamps sull’inizio e la fine di ogni attività svolta. L’ obiettivo è quello di creare flussi automatici che, tramite opportuni processi di Extraction Trasformartion and Loading dei dati, permettano di preparare una struttura dati consona ad analizzare i periodi di attività e inattività dell’operatore e che consenta di sviluppare opportuni indicatori di performance. I risultati derivanti dal processo analitico saranno utili alle aree

(7)

INTRODUZIONE manageriali per monitorare, analizzare ed eventualmente intervenire con azioni correttive sul l’andamento e il comportamento dei singoli operatori.

L’elaborato si compone di una prima parte teorica di definizione delle fasi di progettazione di un Business Process e dell’architettura e modellazione di un Data Warehouse. La parte centrale è interamente dedicata alla presentazione delle fasi inerenti lo sviluppo del progetto. Iniziando dalla descrizione dei flussi di acquisi-zione dei dati ed effettuando una successiva analisi dimensionale, si procede con la configurazione di uno strumento di ETL che permetta l’elaborazione dei dati. Successivamente si passerà alla implementazione e descrizione del Data Warehouse dedicato. Per concludere verranno esposti i risultati ottenuti tramite la presentazione di report di sintesi e di dettaglio e la realizzazione di dashbord di controllo su diversi livelli di granularità.

(8)

Capitolo 1

Business Intelligence

In questo capitolo si farà una breve introduzione teorica dei concetti esposti in tutto l’elaborato. Si parte da un aspetto economico dando una definizione di Business Intelligence e della sua utilità all’interno dell’azienda. Successivamente si definiscono gli aspetti più informatici e tecnici della BI dando una definizione di Data Warehouse.

1.1 Cos’è la BI?

Per poter capire meglio cos’è la Business Intelligence dobbiamo prima di tutto illustrare il sistema informativo aziendale. Esso viene definito come l’insieme delle attività, processi, risorse tecnologiche e persone preposte alla gestione dell’infor-mazione. Per gestione delle informazione si intendono una serie di attività che partono dall’acquisizione ed elaborazione dei dati, con la rispettiva archiviazione, per concludere con la trasmissione e presentazione degli stessi sotto forma di conoscenza. Nell’"era dell’informazione" il ruolo del sistema informativo aziendale diventa sempre più di primaria importanza, sia per l’economia che per i modelli di business. La globalizzazione e la nascita di nuovi mercati hanno incrementato la già enorme mole di dati da analizzare, imponendo ai manager aziendale di doverli gestire in tempi brevi e a costi sostenuti. Proprio per queste motivazioni le applicazioni analitiche sono diventate uno strumento fondamentale per il ruolo strategico aziendale, seguite nel contempo, dalla reportistica e lo scambio delle informazioni interne all’azienda [5].

(9)

CAPITOLO 1. BUSINESS INTELLIGENCE

da Hans Peter Luhn, ricercatore e inventore tedesco, mentre stava lavorando per IBM. Non si ha un’unica definizione di BI ma, una possibile e completa, potrebbe essere di vederlo come un sistema di metodi, processi e strumenti che rendono possibile la raccolta regolare e organizzata dei dati aziendali. Attraverso una serie di analisi o aggregazioni, i dati raccolti (definiti grezzi), diventano informazioni1 semplici, efficaci ed accessibili a diversi tipi di dettaglio per trasformarsi, infine, in conoscenza per i manager aziendali che possono costruire un supporto alle decisioni strategiche, tattiche e operative.

Figura 1.1: Processo di BI

1.1.1 Controllo di gestione

Uno tra i campi in cui la BI gioca un ruolo fondamentale è nel controllo di gestione. Il controllo di gestione viene definito come l’insieme di processi che permettono di conseguire gli obiettivi stabiliti in sede di pianificazione, rilevando, attraverso la misurazione di appositi indicatori (KPI), lo scostamento tra obiettivi pianificati e risultati conseguiti, informando gli organi responsabili affinché possano decidere e attuare le opportune azioni correttive2_.

E’ dunque, importante tenere sotto controllo non solo gli obiettivi a breve termine ma anche quelli a lungo termine in modo da non concentrarsi troppo su obiettivi specifici rischiando di discostarsi dal quadro generale. Da un punto di vista operativo, il controllo di gestione si concretizza attraverso la definizione del budget, la sua applicazione nella gestione è il controllo orientato a guidare il comportamento degli operatori aziendali verso il raggiungimento dei traguardi prefissati [3].

1_{E’ importante distinguere il dato come una misurazione di un evento, un fatto oggettivo espresso}

attraverso numeri o parole, l’informazione è ottenuta attraverso l’elaborazione del dato ed ha un significato rilevante. [2]

(10)

Le fasi operative [4] del controllo di gestione sono suddivise in:

• la programmazione e redazione del budget, cioè definendo degli obiettivi azien-dali economici-finanziari, di strategie e di tempi da applicare per poter stilare il budget sulla base dei dati consuntivi degli anni precedenti;

• la gestione e analisi degli scostamenti periodici, mettendo in pratica le strategie delineate e controllate periodicamente grazie al budget, si verifica lo stato di raggiungimento degli obiettivi economici apportando, dove necessario, degli accorgimenti;

• il controllo annuale, si elabora l’analisi finale degli scostamenti e il budget annuale, appurando i risultati raggiunti con quelli prestabiliti all’intero anno.

Figura 1.2: Fasi del controllo di gestione

1.1.2 Decision Support System

Un Decision Support System (DSS) è un sistema software che permette di au-mentare l’efficacia dell’analisi in quanto fornisce supporto a tutti coloro che devono prendere decisioni strategiche. La sua funzione principale è quella di estrarre in poco tempo e in modo versatile le informazioni utili ai processi aziendali, provenienti da una rilevante quantità di dati. Il DSS appoggia i dati in un database e contiene strumenti di BI e modelli di supporto decisionale. L’obiettivo di un DSS è quello di

(11)

collezionare, trasformare e diffondere informazioni in modo intelligente, per aiutare a prendere decisioni. I dati accumulati nel tempo, integrati con quelli delle fonti esterne all’azienda, sono possibili fonti di informazioni che verranno riassunti in modo appropriato in base al destinatario che le richiede. I dati vengono da prima organizzati in un database speciale chiamato data warehouse e successivamente analizzati con tecniche appropriate, chiamate OnLine Analytical Processing (OLAP) o con tecniche semi-automatiche ed esplorative, chiamate data mining. Quando l’esperienza, competenza e attitudine si aggiungono alle informazioni, la conoscenza viene creata e le successive azioni possono essere intraprese.

L’attività di analisi di dati con strumenti di BI possono essere dei seguenti tipi: • Generazione di report sintetici, rappresentano in maniera efficace le

informazio-ni, utili soprattutto per poter valutare l’andamento delle operazioni di base dell’azienda;

• Analisi Multidimensionali, basate sui dati storici dell’andamento aziendale per poter scoprire eventuali anomalie o tendenze interessanti;

• Analisi esplorativa, si tenta di scoprire in maniera automatica un modello3

interessante di un insieme di dati con tecniche di data mining.

1.2 Processo di BI

Il sistema di BI si compone di quattro fasi:

1. Data Source: raccolta dei dati del patrimonio dell’azienda; 2. ETL: pulizia, validazione e integrazione dei dati;

3. Data Warehouse: successiva elaborazione, aggregazione e analisi;

4. Strumenti di analisi: utilizzo fondamentale di queste informazioni nei processi aziendali.

3_{Un modello è una rappresentazione concettuale che evidenzia in una forma opportuna}

(12)

Figura 1.3: Fasi della BI

1.2.1 Data Source

E’ la prima fase del processo di BI e si intende il momento di raccolta dei dati da vari sistemi interni (eterogenei e non) o da sistemi esterni. Con dati interni ci si riferisce ai dati forniti direttamente dal cliente che richiede una consulenza mentre, i sistemi esterni, sono ad esempio le banche dati o le società private che raccolgono informazioni sui consumatori. Inoltre è da tener conto che la struttura dei dati non è sempre uniforme: si hanno dati in forma tabellare o semplicemente di testo.

1.2.2 ETL

L’espressione inglese ETL (Extract, Transform, Load ) identifica una serie di operazioni di estrazione, trasformazione e caricamento dei dati in un sistema, comu-nemente il Data Warehouse o Data Mart [1]. I dati vengono prima di tutto estratti dalle sorgenti e successivamente subiscono un processo di trasformazione volto a migliorarne la qualità e a renderli omogenei per l’immagazzinamento.

I dati "grezzi" vengono:

• estrapolati solo quelli di interesse per l’analisi;

• ripuliti da eventuali duplicati , da dati mancanti o semplicemente errati; • raggruppati in base alla granularità4 _{necessaria alle analisi, non eccessivamente}

dettagliata (fine-grain) ma neanche eccessivamente generica (coarse-grain). È fondamentale scegliere il giusto livello di granularità per evitare di presentare dettagli che non verranno mai presi in considerazione o di dimenticarne altri essenziali;

• matchati con altri dati di diverse tabelle;

4_{Per granularità si intende il livello di dettaglio dei dati salvati nel DW. Più alto è il livello di}

(13)

• normalizzati5_{, dove necessario;}

Infine vengono memorizzati in appositi sistemi dedicati per permettere di popolare il DW o di aggiornarlo periodicamente. Tutte le operazioni descritte precedentemente vengono svolte in maniera del tutto automatica.

Figura 1.4: Processo ETL

1.2.3 Data Warehouse

Il Data Warehouse è un particolare database che ha lo scopo di immagazzinare i dati dell’azienda che sono stati precedentemente puliti e trasformati con delle procedure ETL. La particolarità di tale archivio è contenere dati ottimizzati per produrre facilmente analisi e relazioni utili a fini decisionali aziendali.

Il DW si differenzia da un normale database (DB) operazionale sia a livello di performance che di funzioni. Nel primo caso i DW a livello di analisi, non interferisce con i processi di repository dei dati rendendo le risposte immediate per la gestione di grande mole di dati rispetto al DB che, con le transazioni operative, effettua una prima estrapolazione per poi eseguire la reportistica sulle analisi 6.

Nel secondo caso il DW, per il suo obiettivo, permette di registrare uno storico dei dati con successive operazione per migliorarne la qualità ed aggregazioni per fini

5_{La normalizzazione è un procedimento volto all’eliminazione della ridondanza informativa e del}

rischio di incoerenza dal database.

6_Fonte: _https _: _{//www.bucap.it/news/approf ondimenti − tematici/gestione − del −}

(14)

analitici, il DB invece, mantiene in memoria solo una versione dei dati non potendo risalire ad eventuali modifiche precedenti.

1.2.4 Data Mining

Il Data Mining è un processo di selezione, esplorazione e analisi, per mezzo di sistemi automatici e semi-automatici, di grandi quantità di dati al fine individuare eventuali regolarità (pattern) o tendenze ed estrarre informazioni e conoscenze (kno-wledge7_{) utili nei processi decisionali.}

Figura 1.5: Processo di Data Mining

Le tecniche tipiche del data mining sono:

• Classificazione: permette di predire i dati per mapparli in un insieme di classi o regole predeterminate. Si ha quindi un training set (insiemi di oggetti) con ciascuno degli attributi, uno di questi attributi è quello obiettivo (target) e il suo valore è la classe da predire;

• Clustering Analysis: insieme di tecniche di analisi volte alla selezione e raggruppamento elementi omogenei in un insieme di dati. La bontà delle analisi dipende soprattutto dalla scelta della metrica e da come è calcolata la distanza tra gli elementi;

7_{Conoscenza: serie di informazioni che aggregate consentono di diffondere sapere, cultura o}

(15)

• Regole associative: sono relazioni di casualità validi tra gli attributi delle osservazioni prese in esame. Si ha quindi un insieme di transazioni (ad esempio un carrello della spesa) formate ciascuna da un insieme di oggetti (prodotti all’interno del carrello);

• Regressione: permette di predire il valore di una variabile sulla base di valori di altre variabili, assumendo un modello di dipendenza lineare/non lineare; • Time series: è l’analisi di sequenze temporali volte a trovare sequenze simili

in una sequenza data o tra coppie di sequenze simili. Le serie storiche vengono studiate sia per interpretare un fenomeno, individuando componenti di trend, di ciclicità, di stagionalità e/o di accidentalità, sia per prevedere il suo andamento futuro8_;

• Anomaly Detection: è il rilevamento di anomalie, cioè elementi o osservazioni che non sono conformi ad un modello previsto o ad altri elementi del dataset.

1.3 Definizione di DW

Un data warehouse è una raccolta di dati storici integrati, non volatile, orientata ai soggetti e finalizzata al recupero di informazioni di supporto ai processi decisionali [1]. Analizzando nel dettaglio la definizione:

• Orientata ai soggetti. I dati all’interno del DW sono organizzati per tema diversamente ai DB operazionali organizzati per applicazioni e il cui obiettivo è ottimizzare l’elaborazione delle transazioni. Il DW oltre ad essere direttamente consultato, può essere usato come sorgente per la costruzione di Data Mart 9. • Integrati. Un DW colleziona dati da diverse fonti e le integra mediante il

processo ETL per evitare errori sintattici o semantici dovuti dalla loro diversa provenienza.

• Tempificata. Diversamente dai DB operazionali che conservano solo i dati più recenti, un DW conserva gli storici dei dati al fine di poter analizzare i cambiamenti nel tempo o il trend di un evento.

8_{Fonte: http://www.dis.uniroma1.it/˜}_{desantis/NOTE/timeseries.pdf}

9_{Un data mart è un database che ha le stesse caratteristiche di un DW ma più piccolo e}

(16)

• Non volatile. I dati nel DW hanno il solo scopo di essere estratti e analizzati ma mai modificati.

• Supporto alle decisioni. Dato che il fine ultimo è l’estrazione di informazioni significative, il design deve essere specificamente realizzato al fine di riuscire a rispondere alle business questions richieste. Vengono fornite tre categorie di supporto alle decisioni: Reports, considerati al più basso livello, rendono più semplice la presentazione dell’informazione ai manager; Analisi di dati multidimensionali o più comunemente OLAP (OnLine Analytic Processing), è un tipo di strumento di analisi dei dati il cui obiettivo è ottenere informazioni utili; Analisi esplorativa dei dati, è una tecnica di scoperta di modelli di dati utili con algoritmi di data mining.

Con il termine data warehousing si intende il processo di immagazzinamento dei dati in un DW per consentire agli utenti finali di analizzarli con le applicazioni di BI. L’architettura utilizzata in molti casi e nello specifico nel caso in analisi, è l’archi-tettura a due livelli che permette di separare la gestione del DB operazionale dalla gestione del DW e le operazioni operative dalle operazioni di BI.

Il DW viene caricato e aggiornato periodicamente dei dati con le operazioni di ETL direttamente dal DB operativo. Questa situazione in genere si presenta quando esistono DB operativi di alta qualità con schemi sufficientemente simili a quelli del DW [1].

(17)

1.4 Modello multidimensionale Concettuale

Il modello grafico concettuale per i data mart è il Dimensional Fact Model (DFM) costituito da fatti, dimensioni e misure (Figura 1.7).

Un fatto è un concetto di interesse per l’impresa sulla cui vuole effettuare un’analisi. Una sua importante caratteristica è la granularità (livello di dettaglio) che da’ il significato al fatto e alle misure e dimensioni pertinenti. La granularità è l’intervallo con la quale si prendono le misure ed è il primo fondamentale step da definire quando si vuole sviluppare un data mart.

Una dimensione è una proprietà con dominio finito di un fatto e ne descrive la granularità di rappresentazione. Ad ogni dimensione sono associati degli attributi dimensionali che lo descrivono, alcuni di essi sono organizzati in gerarchie10_{. Le}

dimensioni sono scelte considerando la necessità dell’utente nell’esaminare il fatto e gli sviluppi futuri del DW.

La misura è una proprietà numerica e descrive quantitativamente un fatto, è un’utile valutazione di performance del processo da analizzare. Una misura puo’ essere: additiva, cioè puo’ essere significativamente aggregata con la funzione SUM (somma) di qualsiasi dimensione (es. il numero di prodotti in un giorno o mensilmente), semi-additiva che può essere aggregata con la funzione SUM solo su alcune dimensioni ma non tutte (es. saldo conto mensile) e non-addittiva che non può essere aggregata ad alcuna funzione (es. percentuali, medie o misure d’intensità) [1].

Graficamente si ha un rettangolo con un nome che rappresenta il fatto e all’interno le misure associate. Esternamente al fatto si hanno dei cerchi bianchi collegati direttamente al rettangolo che rappresentano le dimensioni.

Le gerarchie sono rappresentate come un albero direzionato e gli attributi dimensionali sono collegate alle dimensioni.

Nella fase successiva il modello concettuale multidimensionale si trasforma in uno schema relazionale applicando una serie di regole di mappatura. Il risultato dipende dalla complessità dello schema ma, fondamentalmente si possono definire tre strutture tipo:

1. Star Schema consiste in una tabella del fatto, contenente i dati da analizzare, e un insieme di tabelle una per ciascuna dimensione. Ogni tabella delle dimensioni

(18)

è collegata direttamente alla tabella del fatto;

2. Snowflake Schema è una variante dello star schema dove solo alcune tabelle delle dimensioni sono collegate direttamente alla tabella del fatto, mentre alcune suddividono i loro dati in ulteriori tabelle addizionali collegate alla dimensioni da cui derivano;

3. Constellation schema che contiene più di una tabella dei fatti che condividono alcune tabelle delle dimensioni.

Figura 1.7: Dimensional Fact Model

1.5 Modello multidimensionale: Cubo

Un modello multidimensionale a cubo (Data Cube) rappresenta i fatti a n dimen-sioni per punti in uno spazio n-dimensionale. Un punto (cioè un fatto) è identificato dai valori delle dimensioni e ha un insieme di misure associate [1].

Ogni asse del cubo identifica una dimensione di analisi ed ogni cella del cubo contiene un valore per ciascuna misura. Inoltre ciascuna dimensione può essere vista a più livelli di dettaglio individuati da attributi strutturati in gerarchie.

(19)

Figura 1.8: Data Cube

Le operazioni che possono essere effettuate su un cubo sono:

• Pivoting: operazione che permette di ruotare le dimensioni (ovvero gli assi) del cubo, consentendo all’analista di presentare il risultato in modi differenti; • Drill-down: operazione che consente di passare ad un livello di maggiore

dettaglio ad esempio risalendo le gerarchie degli attributi dimensionali;

• Roll-up: consente di navigare la gerarchia spostandosi ad un livello di aggrega-zione più elevato;

• Slicing e Dicing: permettono rispettivamente di ridurre la dimensionalità e di filtrare i dati definendo dei criteri. Lo slicing effettua una rotazione delle dimensioni di analisi, ad esempio, per ottenere i totali delle dimensioni. Il dicing compie un’estrazione di un subset di informazioni dall’aggregato che si sta analizzando.

• Drill across: consente di ottenere il massimo livello di dettaglio di dati che hanno generato un certo aggregato.

1.6 Data Mart Design

Il processo di modellazione di un data mart si divide nelle seguenti fasi:

1. Analisi dei requisiti. E’ la fase iniziale dove il progettista raccoglie, filtra e analizza i requisiti degli utenti finali, con l’obiettivo di definire le esigenze di utilizzo del data mart. In questa fase si identificano e analizzano le business questions a cui rispondere con le attività di analisi, si definisce e descrive il fatto,

(20)

la sua granularità e le misure preliminari, si descrivono le relative dimensioni e gli attributi più idonei a descriverla.

2. Modello concettuale. Questa fase prevede l’uso dei requisiti determinati nella fase precedente per poter disegnare uno schema concettuale iniziale per il data mart. In questa fase si stabiliscono le corrispondenze tra il fatto e le dimensioni e le relazioni tra gli attributi e le dimensioni. Ciascuna dimensione e misura viene successivamente mappata in un diagramma (DFM) con la tabella del fatto e, lo schema creatosi, viene affinato in modo da renderlo più aderente ai bisogni dell’utente.

3. Modello logico. Partendo dallo schema concettuale si crea lo schema rela-zionale logico con l’obiettivo di massimizzare la velocità di reperimento dei dati. In questa fase si definiscono le Primary Keys11 _{(PK) delle tabelle delle}

dimensioni e le associate Foreign Keys12(FK) utili per relazionare le dimensioni alla tabella del fatto.

4. Modello finale. Il modello ottenuto dalle precedenti fasi sarà uno schema con al centro la tabella del fatto e le misure e per ogni tabella delle dimensioni si avrà un’associazione alla tabella del fatto tramite le PK e FK.

Tutte le fasi precedentemente descritte per la modellazione del data mart saranno poi descritta nel dettaglio successivamente, applicate al progetto in esame.

11_{La chiave primaria è l’insieme di attributi che permettono di individuare univocamente un}

record o tupla in una tabella.

12_{La chiave esterna è un vincolo di integrità referenziale tra due o più tabelle. Essa identifica}

(21)

Capitolo 2

Caso di studio

Si presentano di seguito le due aziende coinvolte nel progetto descritto nella tesi. Sarà introdotto il problema posto dall’azienda committente, lo scopo e gli obiettivi da raggiungere con l’intento di offrire un quadro completo ed esaustivo dell’ambiente di riferimento. Infine si introdurrà la progettazione del DW con tutte le sue fasi di analisi.

2.1 Azienda ospitante

Il lavoro di tesi esposto, si è svolto all’interno della società di consulenza e sviluppo IT Pivot Consulting s.r.l, che opera dal 1999 fornendo assistenza specializzata ad imprese e aziende in molteplici settori sviluppando progetti in ambiti Automotive, Manufacturing, Pubblica Amministrazione, Fashion, Energetic Industries, Logistics Company e Chemical Industries. Uno dei sui core business principali e’ realizzare applicazioni per il mondo SAP, in particolare legate alla business intelligence.

2.2 Azienda committente

L’azienda committente del progetto è un’azienda toscana che si occupa della gestione del ciclo di contabilizzazione ed incasso dei consumi idrici. Si pone come partner qualificato a livello nazionale nel settore Metering e Billing con una gamma di servizi completa e di elevato livello qualitativo. Ad oggi è attiva su tutta la filiera dei servizi al contatore, operando nel mercato delle utilities di acqua, gas ed energia elettrica per i servizi tecnici e nel mercato per le attività del "post-contatore" con

(22)

CAPITOLO 2. CASO DI STUDIO

servizi di lettura e sostituzione dei contatori, fatturazione, stampa e incasso conto terzi.

2.3 Presentazione del problema

Lo scopo principale del presente progetto di tesi è quello di fornire all’azienda committente una serie di report schedulati e dinamici che permettano alla stessa di:

1. valutare le prestazioni, in termini di tempo di esecuzione delle attività operative di ciascun operatore di campo in funzione del tipo di attività;

2. individuare le prestazioni anomale nella conduzione delle attività da parte degli operatori di campo.

La realizzazione di tale applicativo è quindi finalizzata a supportare, con appositi Decision Support System, i processi di controllo di gestione per la valutazione delle performance dei singoli operatori. I processi realizzati per rispondere alla domanda della committenza sono stati creati in modo tale da soddisfare la necessità di valutare l’andamento delle attività sul campo dell’azienda per effettuare delle azioni riparative monitorando e analizzando i propri dati.

Ogni operatore dell’azienda è fornito di un apposito terminale nella quale registra l’ora di inizio e fine del turno di lavoro, inizio e fine di un’attività e l’esito di essa, il tipo e i dettagli di ogni operazioni. Sulla base di queste rilevazioni, l’azienda ha l’esigenza di studiare i comportamenti degli operatori e calcolarne i diversi tempi delle attività al fine di migliorare le prestazioni lavorative del dipendente e delle attività stesse.

Per favorire la valutazione del personale, verificare e controllare l’andamento delle attività in maniera costante sono stati definiti, in collaborazione con l’azienda committente, alcune metriche e KPIs13 (Key Performance Indicator ).

La definizione di KPI è strettamente legata alla definizione degli obiettivi dell’analisi perciò è stata prima effettuata una definizione delle richieste dell’azienda per poi successivamente definirli. Essa gioca un ruolo importante nella realizzazione dei flussi in quanto, spesso, le manipolazioni dei dati e la definizione di alcune misure derivate

(23)

devono essere effettuate tenendo in considerazione la necessità di dover valorizzare tali indicatori.

2.3.1 Definizione dei tempi

Per la definizione degli indicatori è stata fatta una classificazione dei tempi che caratterizzano l’intera giornata lavorativa di un operatore che inizia con la timbratura all’ingresso del cartellino e si conclude con la timbratura all’uscita. I tempi sono così suddivisi:

• Tempo lavorativo (LAV) corrisponde ai minuti di lavoro e si suddivide: – Tempo Operativo (OP) tempo impiegato per effettuare tutte le attività

finalizzate al servizio erogato dall’azienda. Esso si divide ulteriormente in: ∗ Tempo Attività Produttive (ATT) è il tempo collegato

diretta-mente all’erogazione del servizio;

∗ Tempo Attività Accessorie (ACC) è il tempo operativo funzio-nale alla gestione dell’attività produttiva;

– Tempo Inoperativo (INOP) tempo impiegato dall’operatore per effet-tuare tutte le attività non finalizzate al servizio erogato dall’azienda; • Tempo Attività (TA) è il tempo che intercorre tra l’apertura e la chiusura

dell’attività, cioè il tempo impiegato per una singola attività;

• Tempo Spostamento (TS) è il tempo che intercorre tra la chiusura dell’at-tività precedente e l’apertura dell’atdell’at-tività successiva, cioè il tempo che impiega l’operatore per raggiungere il luogo in cui eseguirà l’attività operativa;

• Tempo di Ciclo (TC) fa riferimento ad ogni singola attività ed è la somma tra TS dell’attività precedente e TA dell’attività in esame.

2.3.2 Raccolta dei requisiti

La prima fase del progetto è la raccolta dei requisiti che consiste nell’incontro con l’azienda committente per poter definire gli obiettivi da raggiungere in modo da poter soddisfare le loro esigenze creando un data mart apposito.

(24)

Figura 2.1: Schema suddivisione dei tempi

Sono stati quindi effettuati diversi incontri con l’amministrazione aziendale della committenza per comprendere quali siano i processi chiave che necessitano di uno strumento analitico per il supporto alle decisioni e quali sorgenti informative sono a disposizione per soddisfare queste esigenze. Viene quindi deciso di utilizzare un approccio top-down: partendo dalle informazioni che dovrebbero essere elaborate ed inserite nel DW per calcolare gli indicatori di performance desiderati, sono state definite le fonti informative necessarie.

Per ogni processo identificato, vengono raccolti i requisiti di analisi dei dati richiesti, le business questions (BQs) a cui dare risposta e le misure specifiche di ciascun requisito.

Le BQs definite con la committenza sono: N.BQ Requisiti d’analisi

1 Totale dei tempi di analisi quali accessorio, attività, inopera-tivo e di ciclo e le relative incidenze in percentuale per ogni operatore calcolato giornalmente.

2 Numero interventi/operazioni effettuati da ogni operatore per ogni commessa distribuiti su fascia oraria giornaliera e rispettivi totali per esito dell’operazione.

3 Totale tempo di ciclo, relativi quartili e numero interventi analizzati per ogni operatore considerando il gruppo di appar-tenenza formato da esito operazione, tipo misura, tipo lettura e operazione di affiancamento.

(25)

4 Totale attività, numero delle stesse aventi esito positivo e totale tempo operativo impiegato per operatore e giorno. 5 Rapporto delle attività aventi esito positivo rispetto alle

attivi-tà non accessorie e totale tempo operativo per ogni operatore, per settimana (numero settimana) e mese di riferimento. 6 Numero delle letture anomale per operatore il cui totale del

tempo di ciclo, totale del tempo di spostamento sono minori o maggiori ad una determinata soglia definita per esito e tipologia di tempo. I totali sono calcolati per giorno, settimana, mese e YearToDate14 _.

2.4 Progettazione DW

La progettazione di un Data Warehouse è organizzata in fasi. Essa inizia con l’analisi dei requisiti, prosegue con la progettazione concettuale del Data Mart fino alla definizione del progetto logico che fornisce gli schemi relazionali del Data Mart che poi sarà integrato dando vita allo schema del Data Warehouse.

2.4.1 Analisi dei requisiti

La fase di analisi dei requisiti si suddivide in due sottofasi principali: la raccolta dei requisiti, visto nei paragrafi precedenti, e la specifica dei requisiti che produce una descrizione dei requisiti di analisi dei dati che ne evidenzi le caratteristiche salienti da modellare successivamente con la progettazione concettuale [1].

Ciascun elemento dell’analisi dei requisiti viene descritto in delle tabelle riassuntive: • Tabella della specifica dei requisiti di analisi: in cui si formalizzano le business question (BQ) ed evidenziando le dimensioni, le misure e le metriche

coinvolte;

14_{Indica le informazioni che si riferiscono al periodo compreso tra l’inizio dell’anno e la data}

(26)

• Tabella del fatto: in cui si descrive il fatto da modellare nel DW, se ne descrive il significato con la granularità stabilita;

• Tabella delle dimensioni: in cui si specificano le dimensioni di analisi del fatto;

• Tabella degli attributi dimensionali: in cui si descrivono gli attributi di ogni dimensione, una tabella per ogni dimensione;

• Tabella delle gerarchie dimensionali: in cui si descrivono le gerarchie delle tabelle dimensionali;

• Tabella delle dimensioni che cambiano: in cui si specifica quale strategia viene adottata per le slowly changing dimensions 15 _[1];

• Tabella delle misure: in cui si descrivono le misure del fatto.

Prendendo in esame le BQs richieste dalla committenza, si è creata la tabella delle specifiche (Tabella 2.2) per analizzare ogni singola richiesta definendo le preliminari dimensioni e misure di interesse.

Nella Tabella 2.3 si riporta la descrizione del fatto TempiOperazioni con annesse dimensioni e misure preliminari. Si è deciso di stabile la granularità del fatto fine (molto specifica), in quanto le analisi richieste che verranno effettuate faranno

riferi-mento ad ogni singola attività svolta specifica al secondo.

La scelta della granularità è stata dettata dal fatto che ogni singolo operatore, nel caso di esito negativo dell’operazione di lettura, potrebbe registrare, nello stesso minuto, più operazioni. Se avessimo optato per una granularità maggiore, durante le operazioni di ETL si potrebbero perdere informazioni importanti per l’analisi. La cardinalità della tabella si stima sui 6’000’000 di record.

15_{Slowly Changing Dimension sono quelle dimensioni con attributi che possono cambiare nel}

tempo. Si considerano quattro strategie per cambiare il valore degli attributi: Tipo 1: Il valore di un attributo che cambia va trattato come un valore errato da sostituire con il nuovo valore; Tipo 2: Si vuole conservare la storia perciò si tiene sia il vecchio che il nuovo valore; Tipo 3: Si conserva il valore storico e anche la data in cui è effettuata la modifica: Tipo 4: Gli attributi cambiano frequentemente perciò non vanno trattati con le soluzioni precedentemente elencate.

(27)

N. BQ Dimensioni Misure

1 Operatore(Nominativo) Data(Giorno, Mese, Anno)

TATT, TACC, TINOP, TC

2 Operatore(Nominativo) Data(Giorno, Mese, Anno) Chiusura(Esito), Time(Ora, Minuto, Secondi) Appalto(DescrAppalto) Operazio-ne(IDOperazione)

NOperazioni

3 Operatore(Nominativo)

Chiusu-ra(Esito) Misura(Tipo) Lettura(Tipo) Operazione(IDOperazione, Affiancamento)

TC, NOperazioni

4 Chiusura(Esito) Data(Giorno, Mese, Anno) Operatore(Nominativo) Operazione(Tipo)

NOperazioni, TACC, TATT, NAttivitàPos. 5 Operatore(Nominativo) Data(Settimana,

Me-se, Anno) Chiusura(Esito) Operazione(Tipo)

NAttivitàPos., TAC-CE, TATT, NAttività-NonAcces.

6 Operatore(Nominativo) Data(Giorno, Setti-mana, Mese, Anno) Chiusura(Esito)

NLettureAnomale, TC, TS

Tabella 2.2: Tabella dei requisiti

Descrizione Dimensioni Preliminari Misure Preliminari La tabella del fatto è

rela-tiva alle tempistiche degli operatori di campo al fine di avere una valutazione sul loro operato

Operatore, Comune, Con-tatore, Data, Time, Ap-palto, Misura, Operazione, Lettura, Chiusura, Accessori

TS, TA, TC, TACC, TI-NOP, TATT, NLetture, NLettureAnomale, NAtti-vità, NAttivitàPos., NAt-tivitàNonAccess. , NOpe-razioni

Tabella 2.3: Tabella del Fatto - TempiOperazione

Per una prima analisi sulla base dei requisiti raccolti, si riportano in forma tabellare le descrizioni di ogni dimensione del fatto (Tabella 2.4) individuate nella tabella precedente e arricchite da altre che potrebbero essere utili.

Dimensione Descrizione Granularità

Operatore Anagrafica dell’operatore di campo che ha svolto l’operazione

Un operatore

(28)

Contatore Anagrafica del Contatore Un Contatore

Data Data relativa ad ogni operazione di lettura effettuata

Una data

Time Ora relativa ad ogni operazione di lettura effettuata

Un’ora

Appalto Nome dell’appalto di riferimento dell’attività Un appalto Misura Descrizione tipi di misure (Acqua o Gas) Una misura

Operazione Dettagli dell’operazione Un’ operazione

Lettura Dettagli sulla lettura Una lettura

Chiusura Dettagli sull’esito dell’attività Una chiusura Accessori Dettagli sugli accessori utilizzati durante

un’operazione

Un accessorio

Tabella 2.4: Tabella delle dimensioni

Per ogni dimensione precedentemente descritta si sono successivamente indivi-duati i possibili attributi descrittivi ritenuti di interesse per le analisi(Tabella 2.5). Risultano essere utili, per poter valutare meglio i vari tempi, l’introduzione di attri-buti come Affiancamento in quanto indica se l’operazione è svolta da un operatore affiancato da un neo-assunto.

Questo, come è prevedibile, influenza inevitabilmente il tempo di esecuzione dell’ope-ratore che è incaricato di istruire il collega inesperto dedicandogli del tempo.

Un altro attributo che influisce sulle tempistiche è l’esperienza dell’operatore infatti maggiore sarà la competenza minore sarà il tempo impiegato all’attività.

Dimensione Attributo Descrizione Tipo

Operatore Nominativo Nominativo dell’operatore di campo VARCHAR Esperienza Grado di esperienza dell’operatore VARCHAR Comune Indirizzo Indirizzo posizione del contatore VARCHAR

(29)

Città Città posizione del contatore VARCHAR Provincia Provincia posizione del contatore VARCHAR Regione Regione posizione del contatore VARCHAR

Contatore Diametro Dettagli del contatore DECIMAL

Potenza Dettagli del contatore DECIMAL

Accessibilità Stato di accessibilità del contatore (Accessibile, Parzialmente Accessibile

o Non Accessibile)

VARCHAR

Data Giorno Giorno di registrazione lettura DATE

GrnSettimana Giorno della settimana di registrazio-ne lettura (L,M,M,...).

DATE

Settimana Settimana di registrazione lettura DATE Mese Mese di registrazione lettura DATE Anno Anno di registrazione lettura DATE

Time Ora Ora di registrazione lettura TIME

Minuto Minuto di registrazione lettura TIME Secondo Secondo di registrazione lettura TIME

Appalto DesAppalto Descrizione dell’appalto VARCHAR

AreaManager Area Manager di competenza VARCHAR Misure TipoMisura Descrizione del tipo di misura VARCHAR Operazione TipoOp Specifica il tipo di attività (es.

lettura, sostituzione, ..)

VARCHAR

Affiancamento Attività svolta da un operatore che istruisce un neo-assunto

VARCHAR

EsitoOp E’ l’esito che definisce l’operazione VARCHAR Lettura DescrLettura Descrizione sulla lettura VARCHAR

DataLettura Data di effettuazione della lettura DATE OraLettura Ora di effettuazione della lettura TIME

(30)

TipoLettura Descrive il genere di operazione (es. massiva, appuntamento)

VARCHAR

Chiusura TipoChiusura Categoria del tipo di chiusura VARCHAR DesChiusura Giustifica l’esito dell’attività VARCHAR EsitoCh. Specifica l’esito dell’attività (es.

Assente, Negativo, Positivo)

VARCHAR

Accessori DesAccessori Descrizione sugli accessori VARCHAR

Tabella 2.5: Tabella degli attributi dimensionali

Dalle analisi effettuate si evince che all’interno della dimensione Data, Time e Comune si hanno delle gerarchie dove è possibile navigare tramite le operazioni di Roll-Up (risale la gerarchia ad una visione aggregata con livello di dettaglio minore) e Drill-Down (riscende la gerarchia ad una visione aggregata con livello di dettaglio maggiore).

Tutte le gerarchie sono bilanciate in quanto i possibili livelli sono in numero predefi-nito e i valori degli attributi che ne fanno parte sono sempre definiti [1].

Le gerarchie sono specificate nella Tabella 2.6.

Dimensione Descrizione Tipo Gerarchia

Data Giorno → Mese → Anno Bilanciata

GrnSettimana → Settimana → Anno Bilanciata

Time Secondo → Minuto → Ora Bilanciata

Comune Indirizzo → Città → Provincia → Regione Bilanciata Tabella 2.6: Tabella delle Gerarchie

Infine si analizzano le misure (Tabella 2.7) ritenute di interesse per il risultato dell’analisi da svolgere.

(31)

Misura Descrizione Aggregabilità Calcolata

TempoSpostamento(TS) Tempo di spostamento Semi-Addittiva No TempoAttività (TA) Tempo di attività Semi-Addittiva No

TempoCiclo (TC) TA + TS Semi-Addittiva Si

TempoINOP (TINOP) Tempo inoperativo Semi-Addittiva No TempoAttività (TA) Tempo di attività Semi-Addittiva No TempoAccess. (TACC) Tempo accessorio Semi-Addittiva No

NOperazioni Count(Operazioni) Addittiva No

NAttivitàNonAcc. Count(Attività) Addittiva No

NAttività Count(Attività) Addittiva Si

NAttivitàPositive Count(Attività) Addittiva No

NLetture Count(Letture) Addittiva No

NLettureAnomale Count(Letture) Addittiva No

(32)

2.4.2 Data Mart Concettuale

Dopo aver definito l’analisi e la specifica dei requisiti con tutte le dimensioni e gli attributi dimensionali ritenuti interessanti, viene definito lo schema concettuale del data mart. Il modello concettuale del data mart è un modello preliminare definito dall’analisi che gli utenti eseguono come descrizione formale dei requisiti. Come già detto, la determinazione della granularità del fatto è il primo step chiave nella modellazione del data mart; scegliere la granularità indica il significato del fatto e permette di scegliere le misure e dimensioni più adatte. Il fatto è stato deciso di modellarlo con una grana fine in modo da poter avere la possibilità di aggregare i dati e ottenere informazioni a più livelli di dettaglio.

(33)

2.4.3 Data Mart Logico

Il modello venutosi a creare ha uno schema di tipo Star Schema che, come detto nei primi capitoli, posiziona la tabella dei fatti al centro dove si relaziona con tutte le dimensioni tramite una FK (una per ogni dimensione). Inoltre come si può notare dalle tabelle precedentemente descritte, alcune dimensioni hanno un solo attributo. In questi casi si è deciso di lasciarle come tabelle, anziché trasformarle in attributi del fatto, in modo da avere la possibilità in futuro di poter modificare il data mart aggiungendo facilmente solo gli attributi alla dimensione nel caso in cui il cliente vorrà avere maggiori dettagli a riguardo.

(34)

Capitolo 3

Caso di studio - ETL

In questo capitolo si espongono nel dettaglio le singole fasi del processo ETL messo a punto per il caso di studio. Verranno descritti gli strumenti software utilizzati per questa fase del progetto e i dettagli delle operazioni svolte. Saranno motivate le scelte tecniche per garantire il funzionamento desiderato del processo e le annesse problematiche riscontrate.

3.1 Strumenti

Di seguito verranno descritti i software utilizzati per la realizzazione del processo di ETL e della fonte dei dati. Si descriverà il software Data Services di SAP per il processo di ETL e del software MS SQL Server di Microsoft come fonte di dati.

3.1.1 MS SQL Server

SQL Server è il DBMS relazionale prodotto da Microsoft e utilizzato per la realiz-zazione del processo di data warehousing e della piattaforma di business intelligence. SQL Server Management Studio (SSMS) è un’applicazione software lanciata da Microsoft per l’accesso, la configurazione, la gestione, l’amministrazione e lo sviluppo di tutti i componenti di SQL Server, database SQL di Azure e Azure SQL Data Warehouse.

Questo tool abbina un gruppo esteso di strumenti grafici con numerosi editor di script per consentire a sviluppatori e amministratori di accedere a SQL Server.

(35)

CAPITOLO 3. CASO DI STUDIO - ETL

SSMS è suddiviso in quattro aree principali:

1. Esplora oggetti, che consente all’utente di navigare, selezionare e agire su qualsiasi oggetto all’interno del server. All’interno di questa finestra ci sono diversi nodi tra cui i database del sistema a cui si è connessi, management che gestisce i piani di manutenzione , security contenente la lista dei login degli utenti che possono connettersi a SQL Server;

2. Work area, è l’area in cui è possibile immettere query o testo. Negli editor di query sono incluse le caratteristiche di compilazione delle istruzioni disponibili per il linguaggio di programmazione in uso;

3. Risultato e Messaggi, permettono di visualizzare il risultato di una query o eventuali messaggi di errore nell’esecuzione;

4. Proprietà, dove è possibile visualizzare e modificare le proprietà dell’oggetto selezionato al momento.

(36)

3.1.2 SAP Data Services

SAP (Systeme, Anwendungen, Produkte in der Datenverarbeitung) è una software house multinazionale tedesca per la produzione di software gestionale. E’ una delle principali aziende al mondo nel settore ERP 16 (Enterprise Resource Planning) e in generale nelle soluzioni informatiche per le imprese. Il linguaggio nativo, su cui si basano tutti i suoi prodotti, è ABAP. Innumerevoli sono i moduli SAP, ciascuno dei quali gestisce una differente area aziendale (es. Controllo di gestione, Logistica, Gestione risorse umane) e ad essi sono dedicati i software specifichi per l’area di utilizzo.

Il Sap Data Services (SDS) è un software volto all’integrazione e trasformazione dei dati, permette agli utenti di creare flussi di lavoro che prelevano dati da diverse fonti (DBMS, file di testo, CSV) per combinarli, trasformarli e perfezionarli ed infine inviarli al sistema di destinazione o data warehouse.

SDS offre le funzionalità avanzate di data quality, di integrazione di dati e supporta sia l’elaborazione batch17 _{sia i servizi in tempo reale. Ogni processo è creato tramite}

un tool grafico che consente di creare workflow che regolano il flusso dati, le regolo di controllo e le logiche di mappatura e trasformazione di dati [9].

La finestra principale del SDS è diviso in quattro aree principali: l’area del progetto che riassume in sottocartelle il workflow del progetto, l’area di lavoro in cui si svolge la progettazione del job, la libreria degli oggetti contenente gli oggetti della repository locale e la barra degli strumenti, contenente le scorciatoie degli oggetti comunemente usati (Vedi Figura 3.2).

L’ambiente di sviluppo è organizzato il workflow che regolano il flusso di lavoro e le logiche da adottare per le operazioni di trasformazione [9].

16_L’ERP _è _un _sistema _informativo _aziendale _per _la _gestione _di _tutti _i

proces-si dell’azienda: (vendite, acquisti, gestione magazzino, contabilità etc.). Fon-te: https : //innovaf ormazioneblog.altervista.org/cose − sap/?doing_wp_cron = 1523450359.3052380084991455078125

17_{In informatica, batch processing, è l’elaborazione sequenziale di uno o più programmi considerati}

come un insieme unico (batch). Elaborazioni batch vengono eseguite nei grandi e moderni sistemi in tempo reale e time sharing nei momenti di disponibilità e permettono di conseguire l’impiego ottimale delle risorse operative del sistema. Fonte: http : //www.sapere.it/enciclopedia/batch.html

(37)

Figura 3.2: Esempio Designer del tool SDS

Gli elementi grafici principali del SDS sono:

• Workflow, permette di creare una nuova area di lavoro, in esso vengono aggiunte tutte le operazioni da fare. I workflow possono essere collegati tra di loro o eseguiti singolarmente. Sono oggetti riusabili cioè possono essere richiamati e utilizzati più volte e per più job ma se si effettuano delle modifiche sull’oggetto, questa si riflettono in tutte le sue chiamate;

• Data Flow, crea e gestisce un nuovo flusso di dati. Permette il trasferimento di dati da una sorgente verso una destinazione; così come il workflow anche questo nodo è riutilizzabile e richiamabile in altri job;

• Query, richiede un input e un output. Crea un template per una query: è possibile visualizzare lo schema delle tabelle a cui è collegato, scegliere le opzioni di trasformazione di una normale query (Select, From, Where, Group By ecc.) e mappare le colonne dalla tabella origine a quella destinazione;

(38)

• Tabella, crea un template di una tabella che può essere in input o in output;

• Script, è un oggetto non riusabile definito in un workflow in cui è possibile inserire del codice in linguaggio ABAP estendendo le funzionalità non coperte dai componenti esistenti;

• Condizionale, è un nodo che permette di inserire dei filtri condizionali del tipo IF-ELSE sui dati indirizzando il flusso dati verso output diversi a seconda del valore di un record;

• Try, nodo che inizia un blocco try-catch di un flusso che potrebbe generare un errore;

• Catch, nodo che conclude un blocco try-catch catturando l’errore generato dal flusso;

• Data Transfer, permette di creare una staging area in fase di esecuzione per trasferire i dati dalla fonte al datastore di destinazione. E’ consigliato per il trasferimento di un gran volume di dati in quanto migliora le prestazioni abilitando le operazioni di push-down sul server.

• Merge, permette di combinare più set di dati in entrata, con lo stesso schema, per produrre un unico set in uscita con la stessa struttura del set in input. E’ l’equivalente dell’operazione di SQL "UNION ALL".

3.2 Fonti di dati

La fase di estrazione consiste nell’acquisizione dei dati da numerose fonti tra loro eterogenee che possono basarsi su tecnologie diverse presentandosi sia come fonti relazionali, sia non relazionali. La fase di estrazione, inoltre, deve tener conto

(39)

delle caratteristiche della base di dati sorgente e dei singoli campi da estrarre: non è opportuno riportare campi che non verranno utilizzati soprattutto quando si tratta di una grande mole di dati.

Le fonti di dati per questo progetto di tesi sono le tabelle del DB transazionale dell’azienda committente presenti su MS SQL server.

Ogni operatore dell’azienda, come già introdotto, è dotato di un device dove annota i dettagli dell’operazione che sta eseguendo: le informazioni sul contatore, i timestamp di inizio e fine di ogni operazione, esito dell’operazione e descrizione facoltativa della stessa.

Tutti i dati registrati in real time vengono inviati al DB transazionale di MS SQL server e catalogati in diverse tabelle arricchiti con i dati già presenti su DB (tabelle anagrafiche). Per l’analisi richiesta dalla committenza non si ha necessità di utilizzare tutte le tabelle presenti, quelle ritenute utili sono18:

• LETTURA, indica tutte le informazioni dettagliate relative ad una singola lettura: quale operatore l’ha eseguita, a quale contatore è riferita, il tipo di operazione svolta, il timestamp della lettura attuale e quella precedente ecc. • TEMPOLETTURA, contiene le informazioni aggiuntive sui tempi della lettura

effettuata: CodLetturista, IDLettura, Data, TipoChiusura e TempoLettura. • TIPOLETTURA identifica la tipologia di lettura ad esempio se è su

appunta-mento o massiva.

• CONTATORE, include tutte le informazioni relative al contatore. Tra cui l’indirizzo in cui si trova, l’intestatario, l’anno di installazione, modello e marca. • CHIUSURA, contiene le informazioni relative all’esito dell’operazione con

annessa descrizione breve. L’esito viene categorizzato in tre risultati: ’A’ cliente Assente, ’P’ operazione conclusa positivamente e ’N’ operazione conclusa negativamente (es. impianto inaccessibile, cliente sconosciuto, indirizzo errato); • APPALTO, include tutte le informazioni in riferimento all’azienda appaltatrice; • CONTRATTO mette in relazione un contratto con il rispettivo appalto;

18_{Per semplicità i nomi delle tabelle e dei campi sono state sintetizzate e/o modificate rispetto}

(40)

• OPERAZIONE contiene l’IDoperazione e la sua rispettiva Descrizione; • LOTTO e VALIDAZIONE LOTTO contengono un dettaglio relativo alla

ripartizione delle letture rilevate;

• COMUNE, contiene le informazioni generali su tutti i comuni in cui l’azienda opera.

3.3 Processo di ETL

Per il caso di studio in esame è stato realizzato un processo di ETL (job) svolto su SDS. È bene sottolineare che, per attenersi agli obiettivi prefissati, è necessaria una conoscenza strutturale sia dello schema dei dati già presenti nel Data Warehouse e sia dello schema del database operazionale per garantire la coerenza dei dati che verranno utilizzati per alimentare il data mart. Avendo un’unica fonte dati non vi è stata la necessità di integrare gli stessi con un processo di Data Integration. Un Job è l’unico oggetto in Data Services che puo’ essere eseguito e testato in modalità manuale o pianificata, esso è formato da un workflow che definisce il processo decisionale per l’esecuzione dei suoi dataflow. In generale, durante l’esecuzione di un Job, il ruolo di un workflow è di organizzare l’esecuzione temporale dei dataflow, gestire la configurazione dell’ambiente di esecuzione prima e dopo che i dataflow siano terminati e prendere percorsi alternativi in presenza di determinate condizioni. Il job in analisi è formato da sette workflow collegati tra loro, come mostrato nella Figura 3.3, che verranno di seguito descritti.

(41)

3.3.1 WF: Import tabelle

All’interno del primo workflow è contenuto un dataflow che permette di importare i dati presenti sul server del DB transazionale sul server del DB che costituirà la base di dati del DW. Prendendo in esame ciascuna tabella, si è stabilito quali campi riportare nel DW e quali chiavi assegnare ad ogni tabella. Dopo aver effettuato una serie di test, si è preferito effettuare un filtro iniziale del campi di interesse per evitare un inutile dispendio di risorse, di tempi per il caricamento dei dati e migliorare la leggibilità ai fini della validazione dei dati. Il filtro è stato settato mantenendo una granularità del dettaglio massima. Come mostrato in Figura 3.4, i nodi coinvolti all’interno del dataflow sono quelli delle tabelle di input e output collegate ad un nodo di query che ci permette di filtrate e mappare le colonne.

(42)

3.3.2 WF: Min IDLettura

Nel secondo workflow abbiamo due dataflow sequenziali. Il fine ultimo è quello di conoscere (per una data commessa) la lettura minima registrata dato un tipo specifico di operazione, stato di lettura e esito uguale a ’A’ (Assente) e ’P’ (Positivo). Il primo dataflow è formato da tre tabelle (LETTURA, CONTATORE e CHIUSU-RA) di input, messe in relazione tra di loro per avere non solo il dettaglio della lettura ma anche l’arricchimento dello stesso con le informazioni relative ai contatori, come da richiesta. L’esito di queste operazioni è stato salvato in un’unica tabella di output(LETTURECONTATORE) avente le seguenti informazioni (Figura 3.5): ID-Lettura, IDContatore, Stato, TipoOperazione, Esito, CodAppalto e ChiaveContatore. Il secondo dataflow prende in input la tabella precedentemente creata e ne esegue una query (Figura 3.6) che raggruppa l’IDContatore, CodAppalto e ChiaveContatore estraendo il valore minimo di IDLettura. In questo modo, la tabella di output, avrà per ogni contatore di quell’appalto una sola lettura in modo univoco.

Figura 3.5: Contenuto primo DF

3.3.3 WF: Tabelle Pivot

Nel workflow seguente abbiamo un’importazione ma, diversamente dal workflow descritto precedentemente, le tabelle che vengono importate sono tabelle pivotizzate. Una tabella pivot è uno strumento analitico e di reporting necessario alla creazione

(43)

Figura 3.6: Esempio Query di raggruppamento

di tabelle riassuntive. Uno dei fini principali di queste tabelle è l’organizzazione di dati complessi tramite una scelta opportuna dei campi e degli elementi che devono comporla. Inoltre è possibile scambiare le righe e le colonne per poter visualizzare riepiloghi diversi dei dati di origine, filtrare i dati o aggregarli per poter ottenere dei subtotali.

Per la creazione delle tabelle pivot sono state effettuate due viste direttamente sulle tabelle del DB transazionale e importato su SDS i risultati delle stesse. Il codice eseguito (due query distinte per tabella) è quello della Figura 3.7 e Figura 3.8 che ci ha permesso di trasporre i dati di riga in colonna.

La prima tabella pivot contiene per ogni lettura e operazione la sintesi di diversi dettagli di chiusura. La seconda invece indica per ogni IDLettura l’elenco dei codici degli accessori. Una volta importate sul SDS vengono mappate nella tabella che sarà successivamente inviata al DW.

(44)

Figura 3.7: Query tabella Pivot LETTURADETTAGLIACCESSORI

Figura 3.8: Query tabella Pivot LETTURAACCESSORI

3.3.4 WF: Contatore

Obiettivo del presente flusso è quello di arricchire la tabella del contatore con alcuni dati presenti in tabelle che non saranno trasportate sul DB di destinazione. Nei due workflow seguenti si utilizzano le tabelle CONTATORE e APPALTO e vengono effettuate operazioni di :

• Select and Where per filtrare righe e colonne per favorire le operazioni di anticipazione delle query;

• Join tra le tabelle di interesse;

• Data transfer per facilitare le operazioni di trasporto di una grande quantità di dati dalla sorgente alla destinazione (Figura 3.9). Dopo aver effettuato tali operazioni i tempi computazionali risultano notevolmente diminuiti.

Alla fine di questo processo si avrà la tabella CONTATORE2 con la chiave univoca dell’IDContatore. Il workflow successivo effettua il join tra la tabella APPALTOCO-MUNE e VALIDAZIONELOTTO per poter ottenere la tabella finale VALIDAZIO-NELOTTO con tutte le informazioni necessarie e arricchite.

Anche in questo caso sono state apportate migliorie sulle query per poter ottimizzare le prestazioni.

(45)

Figura 3.9: DF - Utilizzo nodo data transfer

3.3.5 WF: Tabella Anomalie

Durante la fase di Data Understanding19 _{sono state riscontrate alcune operazioni}

che avevano dei dati mancanti o dei tempi registrati molto diversi dalle operazioni con le stessa tipologia. Si è avuta la necessità, quindi, di individuarle per poterle analizzare successivamente caso per caso.

Il workflow seguente si suddivide in tre dataflow per trovare tutte le "anomalie" presenti nei dati, dove per anomalie si intendono tutte le letture classificabile come outlier20 rispetto alle letture registrate e validate nel DB.

Nel primo si mettono in join tutte le letture (tabella LETTURE), filtrate prima a livello di riga con il valore ID maggiore 230 milioni (> 230’000’000), con i corrispettivi tempi di lettura (tabella TEMPILETTURA) il cui IDLettura è nullo. Inoltre a quest’ultimo campo si modifica il valore NULL con il valore zero. La sostituzione di tale valore è stata necessaria in quanto nei diversi strumenti degli step successivi il valore NULL non era ritenuto valido o veniva sostituito con un valore vuoto. Si ottengono infine tutti gli ID delle letture da noi considerate atipiche.

Una volta ottenuti gli ID delle letture anomale, queste vanno arricchite di tutte le sue corrispondenti informazioni (contatore, appalto, operazione ecc.) mettendole in

19_{E’ la fase in cui si analizzano i dati a disposizione per capirne il significato}

20_{Outlier è un termine utilizzato in statistica per definire, in un insieme di osservazioni, un valore}

(46)

join con le appropriate tabelle (Figura 3.10) e ottenendo LETTUREANOMALE. Infine si crea una tabella contenente le informazioni necessarie all’analisi chiamata TEMPIOPERAZIONI e venutasi a creare matchando le letture anomale, i tempi operazioni e le chiusure (Figura 3.11).

Figura 3.10: DF - Join con tutte le tabelle di informazioni

(47)

3.4 Gestione dei job

La gestione dei Job avviene tramite il Central Management Console di SAP Data Services (CMS), l’interfaccia di amministrazione attraverso la quale gli utenti schedulano e monitorano i caricamenti.

Inoltre lo strumento CMS viene utilizzato per misurare lo stato di salute del DW, infatti è possibile:

• monitorare i tempi di esecuzione dei vari Job;

• controllare eventuali log degli errori prodotti dall’esecuzione dei Job; • monitorare il numero di record presenti nelle tabelle dello star schema. In accordo con la committenza tutti i workflow sono stati inclusi in un unico job che viene fatto eseguire in background due volte al giorno. L’ultimo workflow presente nella Figura 3.3 permette di gestire la schedulazione del job.

Al suo interno si è creato uno script che prende in ingresso due variabili globali DataInizio e DataFine che indicano il range di date selezionate per estrapolare i dati dal DB transazionale e caricarli sul DW.

Lo script, nel caso le due variabili siano entrambe inizializzate e scritte correttamente, esegue la selezione altrimenti segnalerà gli errori tramite dei messaggi. Nel caso di non inizializzazione di una delle variabili (o entrambe), lo script valorizzerà in automatico come data di inizio il 30esimo giorno precedente alla data attuale e come data di fine la data precedente a quella attuale.

Una volta avvenuta la selezione e collegato il dataflow allo script (Figura 3.12), le tabelle TEMPIOPERAZIONI e LETTURA vengono dapprima filtrate con delle condizioni e poi unite tramite join per definire la tabella finale TEMPIOPERAZIONI2 (Figura 3.13). Soprattutto in questo caso, dove la quantità di dati è decisamente aumentata, sono state effettuate operazioni di anticipazioni delle query per renderle meno costose.

(48)

Figura 3.12: Workflow

Figura 3.13: DF - Esportazione

3.5 Problematiche riscontrate

In questa fase di ETL sono state riscontrate delle criticità sui dati che abbiamo risolto intervenendo su diversi fronti.

1. Molti dei dati all’interno delle tabelle risultavano essere con valori NULL o Blank. Si è deciso di uniformare i dati utilizzando la funzione nvl() di SDS che permette di sostituire il valore NULL con un campo definito da noi come campo di default. Nel caso in analisi si è stabilito di trasformare i valori numerici NULL in 0 (es. NVL(ID,0)).

2. Alcune tra le query utilizzate risultavano essere molto costose in termini di cicli computazionali a causa delle operazioni di Join tra tabelle. In sostanza per poter migliorare le prestazioni e quindi i tempi di esecuzione di una query, è stato necessario anticiparne il flusso di esecuzione [1]. Si filtrano, quindi, prima le righe e/o le colonne e successivamente si combinano le tuple tramite il join.

(49)

3. Sono stati riscontarti problemi a livello di conversione di date in quanto i due tool, SSMS e SDS, utilizzavano due formati differenti. Per evitare problematiche maggiori nelle fasi successive ma soprattutto per una maggiore correttezza concettuale, tutti le conversioni di formato sono state fatte nel processo ETL.

(50)

Capitolo 4

Caso di studio - DW

Dopo aver descritto in modo teorico, nel primo capitolo, cos’è un DW e il suo processo di creazione, si procede ad applicare tali fasi al caso in esame. Prima di entrare nei dettagli delle fasi di progettazione verrà fornita, come nel capitolo precedente, una panoramica sullo strumento software utilizzato.

4.1 Strumenti

Lo strumento utilizzato in questa fase del progetto è Business Objects Information Design Tool. Anche questo tool è proprietario di SAP e fa parte della suite di programmi di SAP Business Objects.

4.1.1 SAP BO Information Design Tool

BO Information Design Tool (IDT) è un ambiente di progettazione di metadati di SAP BusinessObjects che consente di estrarre, definire e manipolare i metadati delle origini relazionali e OLAP per creare e distribuire universi SAP BusinessObjects [7]. Il modello è detto “universo” costituito da l’insieme organizzato di oggetti metadati con lo scopo di semplificare la fase di interrogazione e consultazione del database da parte dell’utente finale per poter eseguire analisi dei dati e report esplicativi. Gli oggetti includono dimensioni, indicatori, gerarchie, attributi, calcoli predefiniti, funzioni e query. Il livello di oggetti metadati, detto livello aziendale (business layer ), viene creato in base a uno schema di database relazionale o un cubo OLAP, in modo tale che gli oggetti siano mappati direttamente alle strutture del database mediante

(51)

CAPITOLO 4. CASO DI STUDIO - DW

espressioni SQL o MDX. Un universo include connessioni che identificano le origini dati in modo da consentire l’esecuzione delle query sui dati [7].

IDT viene utilizzato per la reportistica, analisi strategica dei dati, pianificazione e budget. Presenta un’interfaccia utente che consente l’interrogazione di database SQL inoltre, permette di salvare la documentazione generata in diversi formati facilmente condivisibili con altri utenti. Viene utilizzato un Query Panel, dove l’utente seleziona i campi che vuole estrapolare e le condizioni che devono rispettare; oltre a poter vedere i risultati della query in forma tabellare e anche possibile visualizzarli graficamente. L’universo contiene due tipi di strutture: le classi sono gruppi di oggetti logici che rappresentano una categoria di oggetti, gli oggetti sono componenti che mappano i dati o una derivazione di dati nel DB [6].

IDT può supportare molti tipi di schemi DB, inclusi quelli relativi ad DW. L’interfaccia utente si divide in:

• Progetti Locali, permette di esplorare i progetti locali e per aprire e convali-dare le risorse;

• Risorse del repository, impostando una nuova sessione contiene tutti gli oggetti del repository selezionato;

• Livello Aziendale, è lo stato che contiene tutte le classi e gli oggetti, è possibile controllare le dimensioni e le misure definite nell’universo. Si può avere un riepilogo per vedere il numero di attributi, dimensioni, misure e classi contenute nel livello aziendale;

• Livello della basi di dati, è utilizzato per definire e gestire la struttura della base di dati, incluse tabelle dall’origine dati e join tra tabelle, e le relative connessioni.

4.2 Livello Aziendale

Il ruolo principale del livello aziendale è definire e organizzare i metadati che forniscono un’astrazione delle entità dei DB relazionali o di cubi OLAP comprensibili agli utenti aziendali. Esso può essere considerato come un workbench da utilizzare per comporre e modificare un insieme di metadati che formeranno l’universo per le

(52)

CAPITOLO 4. CASO DI STUDIO - DW

Figura 4.1: Esempio ambiente di lavoro IDT

applicazioni di analisi di dati e creazione di report [7].

Gli oggetti metadati comprendono dimensioni, gerarchie, indicatori, attributi e condi-zioni predefinite ed è possibile aggiungerne altri in base ai requisiti di progettazione dell’universo.

I livelli aziendali possono essere creati direttamente in base a un cubo OLAP o utilizzando una base dati creata da un database relazionale. Inoltre, è possibile creare oggetti query, elenco di valori, parametri e percorsi di navigazione. Il livello aziendale è l’universo in fase di creazione e, una volta completato, viene pubblicato in un repository come universo.

All’interno del livello aziendale possono essere effettuate delle operazioni di mappatu-re delle colonne o operazioni aggiuntive per poter calcolamappatu-re delle colonne necessarie in fasi di analisi.

4.2.1 Colonne calcolate

Durante questa fase si è avuta la necessità di arricchire le informazioni con alcune colonne calcolate tramite il linguaggio SQL.