• Non ci sono risultati.

Dal Data Mart alla reportistica: un esempio di migrazione tecnologica in un'azienda di consulenza informatica

N/A
N/A
Protected

Academic year: 2021

Condividi "Dal Data Mart alla reportistica: un esempio di migrazione tecnologica in un'azienda di consulenza informatica"

Copied!
171
0
0

Testo completo

(1)

Anno Accademico 2015/2016

UNIVERSITÀ DI PISA

DIPARTIMENTO DI INFORMATICA

Corso di Laurea Magistrale per l’economia e per l’azienda

(Business Informatics)

Dal Data Mart alla reportistica:

un esempio di migrazione tecnologica in

un’azienda di consulenza informatica

Relatrice

Candidata Prof.ssa Alina Sirbu

Giulia Cofini Matricola 499358

(2)

Tesi di Laurea Magistrale 2015/2016

ii

UNIVERSITÀ DI PISA

DIPARTIMENTO DI INFORMATICA

Corso di Laurea Magistrale per l’economia e per l’azienda

(Business Informatics)

Dal Data Mart alla reportistica:

un esempio di migrazione tecnologica in

un’azienda di consulenza informatica

Relatrice

Candidata __________________

(3)

Tesi di Laurea Magistrale 2015/2016

iii

“Si può insegnare a un computer a dire: “Ti amo”,

ma non gli si può insegnare ad amare.”

(4)

Tesi di Laurea Magistrale 2015/2016

iv

Sommario

Il presente lavoro affronta l’approccio che si è avuto in azienda per effettuare una migrazione tecnologica in seguito alla richiesta fatta dal cliente. Si è studiata la nuova tecnologia, si è messa in relazione con quella esistente e si è provveduto a delineare un breve confronto tra le due, inquadrandole nella letteratura.

In particolare, ci si è soffermati ad analizzare tre strutture rilevanti esistenti nel Data Warehouse e si è provveduto a migrarle su Database Greenplum seguendone i vari passaggi di Estrazione, Trasformazione e Loading. In quest’ambito si è andata a identificare la costituzione di un piccolo Data Mart che sarà oggetto di ulteriori elaborazioni di tipo front-end. Considerate delle richieste di analisi utili in ottica business, il Data Mart verrà utilizzato per sviluppi di reportistica attraverso Business Object.

Parole chiave

Database Greenplum, Data Warehouse, ETL, Data Mart, Reportistica, Business Object

(5)

Tesi di Laurea Magistrale 2015/2016

(6)

Tesi di Laurea Magistrale 2015/2016

vi

INDICE

Riferimenti alle figure ix

Riferimenti alle tabelle xii

Definizione acronimi xiii

Introduzione xiv

CAPITOLO 1 - STRUTTURA DI UN DATA WAREHOUSE

1.1 Data Warehouse – Teoria di William Inmon ... 2

1.2 Data Warehouse – Teoria di Ralph Kimball ... 5

1.2.1 Differenze e analogie con Inmon ... 7

1.3 La Business Intelligence ... 12

1.3.1 BI come processo aziendale ... 12

1.3.2 BI come tecnologia... 13

CAPITOLO 2 - ELEMENTI DI TEORIA DEL DATABASE DI

GREENPLUM

2.1 Greenplum Database ... 15 2.2 Architettura ... 16 2.2.1 Masters ... 17 2.2.2 Segmenti ... 19 2.2.3 Collegamenti ... 22

CAPITOLO 3 - DATA WAREHOUSE PRESENTE IN AZIENDA

3.1 Architettura Oracle ... 23

3.2 Gestione delle strutture del DW ... 26

3.2.1 Processi Back-End ... 27

3.2.1.1 Staging Area ... 27

3.2.1.2 Operational Data Store ... 28

3.2.1.3 Definition Data Store... 29

3.2.2 Processi Front-End ... 29

CAPITOLO 4 - INDIVIDUAZIONE DATA MART

4.1 Modello logico ... 31

(7)

Tesi di Laurea Magistrale 2015/2016

vii

4.2.1 Flusso di caricamento ... 35

4.3 Tabelle delle dimensioni ... 47

4.3.1 Dimensione Customer ... 47

4.3.1.1 Flusso di caricamento ... 51

4.3.2 Dimensione Asset ... 65

4.3.2.1 Flusso di caricamento ... 67

CAPITOLO 5 - MIGRAZIONE STRUTTURE

5.1 Processi Back-end ... 83

5.1.1 FT_CONTRACT ... 84

5.1.2 DM_CUSTOMER ... 92

5.1.3 DM_HW_ASSET ... 100

5.2 Processi Front-End attraverso Business Object ... 106

5.2.1 Universo ... 106

5.2.2 Esempi di Report ... 111

CAPITOLO 6 - STRUTTURA BACK-END ESISTENTE vs MIGRATA

6.1 Performance con il tool OWB ... 115

6.1.1 FT_CONTRACT ... 115

6.1.2 DM_CUSTOMER ... 122

6.1.3 DM_ASSET... 125

6.2 Performance con Informatica Power Center ... 130

6.2.1 FT_CONTRACT ... 131

6.2.2 DM_CUSTOMER ... 135

6.2.3 DM_HW_ASSET ... 138

6.3 Esempi di confronto performance ... 141

6.3.1 Caricamento del DWH ... 141

6.3.2 Esecuzione query nel DWH ... 145

Conclusione 150

Riferimenti 153

(8)

Tesi di Laurea Magistrale 2015/2016

(9)

Tesi di Laurea Magistrale 2015/2016

ix

RIFERIMENTI ALLE FIGURE

Figura1.1: modello DW proposto da Inmon Figura1.2: modello DW proposto da Kimball

Figura2.1: Architettura del DataBase di Greenplum Figura2.2: Indirizzamento della query in modo parallelo Figura2.3: Indirizzamento della query in un singolo segmento Figura2.4: Lavorazione di una query

Figura3.1: Data base e istanza Figura4.1: Modello Logico

Figura4.2: Script creazione FT_CONTRACT Figura4.3: Diagramma Strutture FT_CONTRACT Figura4.4: Script creazione ST_CONTRACT Figura4.5: Script creazione DW_HIST_CONTRACT

Figura4.6: Script creazione PRC_WT_D_DW_HIST_CONTRACT Figura4.7: Script creazione WT_DELTA_DW_HIST_CONTRACT Figura4.8: Script creazione VS_WT_DELTA_HIST_CONTRACT Figura4.9: Script creazione WT_DELTA_HIST_CONTRACT Figura4.10: Script creazione VS_WT_FT_CONTRACT Figura4.11: Script creazione WT_FT_CONTRACT Figura4.12: Script creazione WT_FT_CONTRACT Figura4.13: Script PRC_COPY_CONTRACT Figura4.14: Script VS_WT_FT_CONTRACT_TOT Figura4.15: Script WT_FT_CONTRACT_TOT Figura4.16: Screen Toad FT_CONTRACT Figura4.17: Script creazione DM_CUSTOMER Figura4.18: Diagramma Strutture DM_CUSTOMER Figura4.19: Script ST_CUSTOMER

Figura4.20: Script creazione VS_H_CUSTOMER

Figura4.21: Script creazione WT_DELTA_DW_HIST_CUSTOMER Figura4.22: Script creazione PRC_WT_DELTA_DW_HIST_CUSTOMER Figura4.23: Script creazione WT_H_CUSTOMER

Figura4.24: Script creazione DW_HIST_CUSTOMER Figura4.25: VS_DM_CUSTOMER_DELTA

Figura4.26: DM_CUSTOMER dal tool Toad Figura4.27: Script creazione DM_HW_ASSET Figura4.28: Diagramma Strutture DM_HW_ASSET Figura4.29: Script creazione ST_HW_ASSET

(10)

Tesi di Laurea Magistrale 2015/2016

x Figura4.30: Script creazione VS_H_HW_ASSET

Figura4.31: Script creazione PRC_WT_DELTA_DW_HIST_HW_ASSET Figura4.32: Script creazione WT_DELTA_DW_HIST_HW_ASSET Figura4.33: Script creazione WT_H_HW_ASSET

Figura4.34: Script creazione DW_HIST_HW_ASSET Figura4.35: Script creazione VS_DM_HW_ASSET

Figura4.36: Script creazione PRC_WT_DELTA_DM_HW_ASSET_PRE Figura4.37: Script creazione WT_DELTA_DM_HW_ASSET

Figura4.38: Script creazione PRC_COPY_HW_ASSET Figura4.39: Script creazione WT_DELTA_DM_HW_ASSET Figura4.40: Screen dal tool Toad per la DM_HW_ASSET Figura5.1: Diagramma Strutture FT_CONTRACT

Figura5.2: Script di creazione della ST_CONTRACT

Figura5.3: Script di creazione della DW_HIST_CONTRACT

Figura5.4: Script di creazione della VS_WT_ETL_FT_CONTRACT Figura5.5: Script di creazione della WT_ETL_FT_CONTRACT

Figura5.6: Script di creazione della VS_WT_ETL_FT_CONTRACT_TOT Figura5.7: Script di creazione della WT_ETL_FT_CONTRACT_TOT Figura5.8: Script di creazione della FT_CONTRACT

Figura5.9: Screen di pgAdmnin della FT_CONTRACT Figura5.10: Diagramma Strutture DM_CUSTOMER Figura5.11: Script di creazione della ST_CUSTOMER

Figura5.12: Script di creazione della DW_HIST_CUSTOMER

Figura.5.13: Script di creazione della VS_ETL_WT_DM_CUSTOMER Figura5.14: Script di creazione della WT_ETL_DM_CUSTOMER Figura5.15: Script di creazione della DM_CUSTOMER

Figura5.16: Screen di creazione della DM_CUSTOMER su pgAdminIII Figura5.17: Diagramma Strutture DM_HW_ASSET

Figura5.18: Script di creazione della ST_HW_ASSET

Figura5.19: Script di creazione della DW_HIST_HW_ASSET

Figura5.20: Script di creazione della VS_ETL_WT_DM_HW_ASSET Figura5.21: Script di creazione della WT_ETL_DM_HW_ASSET Figura5.22: Script di creazione della DM_HW_ASSET

Figura5.23: Screen di creazione della DM_HW_ASSET su pgAdminIII Figura5.24: Screen di creazione universo

Figura5.25: Screen di esempio creazione filtro con prompt Figura5.26: Esempio di report riguardante gli asset

Figura5.27: Closing Week e Opening Month Figura5.28: Closing Month e Opening Week

(11)

Tesi di Laurea Magistrale 2015/2016

xi

Figura5.30: Esempio di report riguardante i servizi Figura6.1: Screen OWB di MP_WT_H_CONTRACT Figura6.2: Screen OWB di MP_DW_CONTRACT

Figura6.3: Screen OWB di MP_DELTA_HIST_CONTRACT Figura6.4: Screen OWB di MP_WT_FT_CONTRACT

Figura6.5: Screen OWB caricamento primo livello CONTRACT Figura6.6: Screen creazione FN_RUN_II_LEV_CONTRACT Figura6.7: Screen OWB per MP_WT_FT_CONTRACT Figura6.8: Screen OWB per MP_FT_CONTRACT Figura6.9: Screen OWB per MP_WT_H_CUSTOMER Figura6.10: Screen OWB per MP_DW_CUSTOMER

Figura6.11: Screen OWB per MP_DM_CUSTOMER_DELTA Figura6.12: Screen OWB per MP_DM_CUSTOMER

Figura6.13: Screen OWB LOAD_CUSTOMER Figura6.14: Screen OWB MP_WT_H_HW_ASSET Figura6.15: Screen OWB MP_DW_HW_ASSET Figura6.16: Screen OWB MP_DM_HW_ASSET Figura6.17: Screen OWB LOAD_HW_ASSET

Figura6.18: Screen OWB LOAD_II_LEV_CONTRACT Figura6.19: Screen OWB LOAD_I_LEV_DREAM

Figura6.20: Screen Informatica per MP_DW_HIST_CONTRACT Figura6.21: Screen Informatica per MP_WT_FT_CONTRACT Figura6.22: Screen Informatica per MP_WT_FT_CONTRACT_TOT Figura6.23: Screen Informatica per MP_ FT_CONTRACT

Figura6.24: Screen Informatica per le sessioni del CONTRACT Figura6.25: Screen Informatica per WKL_CONTRACT

Figura6.26: Screen Informatica per MP_DW_HIST_CUSTOMER Figura6.27: Screen Informatica per MP_DM_CUSTOMER Figura6.28: Screen Informatica per le sessioni CUSTOMER Figura6.29: Screen Informatica per WKL_CUSTOMER

Figura6.30: Screen Informatica per MP_DW_HIST_HW_ASSET Figura6.31: Screen Informatica per MP_HW_ASSET

Figura6.32: Screen Informatica per le sessioni HW ASSET Figura6.33: Screen Informatica per WKL_HW_ASSET Figura6.34: Screen Informatica di WF_LOAD_DREAM Figura6.35: Screen Toad interrogazione vs_log

Figura6.36: Screen Toad interrogazione vs_log Figura6.37: Screen Toad interrogazione vs_log

(12)

Tesi di Laurea Magistrale 2015/2016

xii

RIFERIMENTI ALLE TABELLE

Tabella1.1: Pro e contro la dottrina di Inmon Tabella1.2: Pro e contro la dottrina di Kimball Tabella1.3: Inmon vs Kimball

Tabella4.1: Valori tappo previsti

Tabella5.1: Tabella riassuntiva oggetti universo

Tabella6.1: Strutture coinvolte nella creazione FT_CONTRACT Tabella6.2: Strutture coinvolte nella creazione DM_CUSTOMER Tabella6.3: Strutture coinvolte nella creazione DM_HW_ASSET Tabella6.4: Tempi in Greenplum e Oracle a confronto

(13)

Tesi di Laurea Magistrale 2015/2016

xiii

DEFINIZIONE ACRONIMI

BE: Back End

BI: Business Intelligence DB: Database

DDS: Definition Data Store DM: Data Mart

DWH: Data Warehouse

ETL: Extract Transformation Load FE: Front End

MPP: Massively Parallel Processing ODS: Operational Data Store

(14)

Tesi di Laurea Magistrale 2015/2016

xiv

INTRODUZIONE

Si presenta un caso di studio aziendale in cui si andrà ad affrontare una migrazione tecnologica che descriverà il passaggio da un database Oracle ad un database Greenplum.

Questo lavoro nasce dall’interazione con l’azienda CDS, a Hewlett Packard

Enterprise Company, poi divenuta ES Field Delivery Srl presso la quale si è proposto, in accordo con l’Università di Pisa, di poter mostrare processi aziendali concreti nell’ambiente accademico.

Così come CDS, a Hewlett Packard Enterprise Company operava nel settore informatico, fornendo servizi di Hardware Maintenance, End-User Workplace e Application Support all’interno del gruppo Hewlett Packard Enterprise, ES Field

Delivery Srl appartiene al gruppo DXC Technology e si rivolge ad aziende leader operanti in vari settori produttivi. L’Azienda abbraccia i valori, condivide gli obiettivi e adotta standard di condotta di Hewlett-Packard Enterprise Company (HPE), e proprio in accordo con i colleghi HPE-DXC si è resa possibile la sperimentazione in oggetto, frutto di esperienza nel campo della consulenza informatica.

Essendo un’azienda di consulenza si tratterà nell’elaborato la commessa su cui si opera; essa rappresenterà il cliente che l’ha affidata ad HPE - DXC Technology. Viene fatta subito una premessa in merito: il cliente non verrà menzionato nel presente elaborato, né verranno utilizzati dati sensibili o di carattere aziendale, tutto ciò che viene descritto rispecchierà lo sviluppo reale, mantenendo però l’anonimato

(15)

Tesi di Laurea Magistrale 2015/2016

xv

delle strutture del Data Warehouse esistente. Per questo motivo si è pensato di identificare tale cliente in un’entità fittizia, chiamata Dream che indicherà un’azienda operante nel settore delle telecomunicazioni.

Dove, invece, non si è potuta mantenere una precisa copia dell’operato aziendale, si è provveduto a proiettarne la logica implementando però strutture ad hoc per lo studio.

La proposta che è stata fatta è quella di poter analizzare in modo accurato, all’interno della commessa in cui si opera, un importante evento che prevede una

migrazione tecnologica.

L’attuale Database Oracle in uso, dovrà essere dismesso e, al suo posto, dovrà

essere utilizzato il Database Greenplum. La sostituzione del DB e conseguentemente dei tool su cui operare, prevede una traslazione di tutte le strutture esistenti sul nuovo sistema. La migrazione non sempre può avvenire in modo automatico, considerando il fatto che tale processo prevede anche un’ottimizzazione, seppur superficiale, di quello che sono le strutture in uso.

Prima di poter operare, si è reso necessario capire a livello teorico ciò che stava accadendo, attraverso studi mirati alla soluzione della richiesta del cliente. L’obiettivo sviluppato nel corso della collaborazione è stato la realizzazione di una

vera e propria migrazione di strutture su cui quotidianamente si svolgono analisi, in modo da dare prova della concretezza del lavoro attraverso reportistiche che mettano in evidenza l’andamento temporale del business.

Si è strutturata la tesi attraverso un percorso logico che possa guidare il lettore in tutte le fasi di studio, analisi, ricerca e sviluppo effettuate nel corso dei precedenti

(16)

Tesi di Laurea Magistrale 2015/2016

xvi

mesi.

Seguendo questa impostazione, nel primo capitolo si trattano in via teorica i punti cardine del Data Warehouse, e viene mostrata l’evoluzione che la Business

Intelligence ha avuto nel corso del tempo fino ad arrivare a come si presenta oggi. Il secondo capitolo si riferisce allo studio che si è fatto per poter approcciare alla nuova tecnologia, ci si concentra dunque sulla nuova architettura e sul Database di Greenplum e sugli usi che ne vengono comunemente fatti.

Illustrate le conoscenze necessarie per poter affrontare lo sviluppo, il terzo capitolo descrive il Database Oracle, su cui attualmente si opera, e su come lo si utilizza per i processi Back-end e Front-end.

Il cuore della sperimentazione è rappresentato dal quarto e quinto capitolo: il primo citato, a valle di una presentazione delle strutture scelte per la migrazione, mostra tutti i nuovi processi relativi allo sviluppo del flusso ETL con tecnologie Oracle; il secondo, poi, si concentra sulla migrazione delle strutture precedentemente analizzate.

Una volta effettuata la migrazione della tabella dei fatti e delle dimensioni, si viene a formare un Data Mart che verrà presentato nel capitolo cinque. Partendo da esso, congiuntamente a tipologie di analisi, simili a quelle che richiede il cliente, si provvederà alla costituzione di un universo e conseguentemente di report.

Analizzate le dinamiche dei flussi Back-end e dell’interfaccia Front-end, l’ultimo capitolo illustra le differenze di performance che si hanno utilizzando il “vecchio”

(17)

Tesi di Laurea Magistrale 2015/2016

(18)
(19)

Tesi di Laurea Magistrale 2015/2016

2

CAPITOLO 1: Struttura di un

Data Warehouse

In questo capitolo verrà introdotto il concetto di Data Warehouse (DWH) data da Inmon, ideatore della struttura, e si arriverà a descriverne i cambiamenti che hanno interessato la teoria dei DWH nel tempo, fino ad arrivare a quello conosciuto e utilizzato oggi. Nel corso dell’excursus verrà citato Kimball (1944) altro studioso del tema e scrittore di un famoso manuale noto nell’ambito accademico e

lavorativo. Le due dottrine verranno messe a confronto e ne verranno evidenziate analogie e differenze sino a descrivere la Business Intelligence operativa attualmente negli ambiti aziendali.

1.1 Data Warehouse – Teoria di William Inmon

William Inmon, nato a San Diego, in California, il 20 Luglio 1945 è stato colui che per primo ha dato un’organizzazione diversa da quella usuale al data base e ha

pensato di strutturarlo in maniera più conforme a quelle che erano le necessità: per la prima volta, nel 1992, si parla di Data Warehouse. Questo, viene definito come “una raccolta di dati integrata, orientata al soggetto, variabile nel tempo e non

volatile di supporto ai processi decisionali.” Nota di particolare attenzione

dovrebbe venir posta sull’espressione “supporto ai processi decisionali” in quanto

la raccolta di dati, interpretata da Inmon come un grande magazzino-contenitore, non è fine a se stessa, ma serve per uno scopo: prendere decisioni in ambito aziendali. Rispetto ad altri sistemi di supporto alle decisioni, l’integrazione dei dati

(20)

Tesi di Laurea Magistrale 2015/2016

3

richiede, inoltre, di essere dettagliata in base alle singole caratteristiche previste per la raccolta dati che deve essere:

· Integrata in quanto i dati sono provenienti da più sistemi transazionali ed

eterogenei. Il processo per rendere omogenei i dati può prevedere una codifica uniforme a livello semantico, la trasformazione alla stessa unità di misura, ecc.;

· Orientata al soggetto, inteso come destinatario aziendale sia esso applicativo o

fisico; si deve far i modo che i dati raccolti siano facilmente letti, compresi ed elaborati dagli utenti. Facendo un paragone con quello che è un Data Base, non basta più eliminare la ridondanza normalizzando le estrazioni, ma occorre fornire dati organizzati per permettere la produzione di informazioni per essere multidimensionali;

· Variabile nel tempo perché si prevede una linea temporale maggiore rispetto a

quella prevista nei sistemi operazionali. Nel DWH sono contenute una serie di informazioni relative alle aree di interesse che colgono la situazione relativa ad un determinato fenomeno in un determinato intervallo temporale piuttosto esteso. Facendo un paragone con un sistema transazionale in cui i dati corrispondono ad una situazione aggiornata e non storicizzata, generalmente i dati all’interno di un DWH sono aggiornati ad una data antecedente a quella in cui l’utente effettua l’interrogazione e facilmente sono storicizzati;

· Non volatile in quanto i dati non sono modificabili e sono accessibili in sola

lettura. Ovviamente in caso di anomalie sul dato si dovrà procedere ad aggiornamenti e bonifiche, ma questi casi particolari non ricadono nella definizione teorica.

(21)

Tesi di Laurea Magistrale 2015/2016

4

distribuzione di informazioni presenti all'interno o all'esterno delle aziende come supporto ai decision maker e rappresentano il dato in modo multidimensionale e dinamico, evidenziandone le movimentazioni che esso subisce nel tempo. Si precisa, infine, come un DWH possa venir costruito su architetture differenti che vanno dalla logica accentrata ad una distribuita. La possibilità di avere differenti architetture sarà l’aspetto cardine della ricerca effettuata nel lavoro sviluppato. Di seguito verrà schematizzata l’architettura di un DWH proposto da Inmon.

Figura1.1: modello DWH proposto da Inmon, [2] [3][6]

Per completezza, si dà indicazione di quello di cui si occupa ogni layer presentato in figura:

 On-line Transaction Processing (OLTP): sistema transazionale caratterizzato da un elevato numero di operazioni transazionali quali INSERT, UPDATE e DELETE. L’elaborazione delle query è molto veloce, si mantiene l’integrità dei dati ed è garantita l’efficacia di tutte le transazioni

effettuate al secondo.

Nel database OLTP ci sono dati dettagliati e attuali, e lo schema utilizzato per memorizzare i database transazionali è il modello di entità;

(22)

Tesi di Laurea Magistrale 2015/2016

5

3 Forma Normale (3FN): è un procedimento volto all’eliminazione della

ridondanza del dato. In particolare, la terza forma include le caratteristiche della seconda e della prima, dunque se: “ per ogni relazione contenuta nella

base dati: tutte le tuple della relazione hanno lo stesso numero di attributi; non presenta gruppi di attributi che si ripetono; tutti i valori di un attributo sono dello stesso; esiste una chiave primaria; l'ordine delle righe è irrilevante; per ogni relazione tutti gli attributi non-chiave dipendono funzionalmente dall'intera chiave composta”, con l’aggiunta dell’ultima caratteristica: “tutti gli attributi non-chiave dipendono direttamente dalla

chiave”;

 Data Mart: raccoglitore di dati che permette di formulare strategie sulla base degli andamenti passati. Un Data Mart è un sottoinsieme logico o fisico di un data warehouse di maggiori dimensioni;

 On-line Analytical Processing (OLAP): sistema caratterizzato da un basso volume di transazioni, in cui le query prevedono aggregazioni e i tempi di risposta costituiscono una misura di efficacia; in genere è utilizzato con tecniche di Data Mining;

 Reporting Layer: interfaccia di reportistica utente;

Extract Transformation Load (ETL): verrà descritto ampiamente nel

prossimo paragrafo.

1.2 Data Warehouse – Teoria di Ralph Kimball

Ralph Kimball, nato nel 1944 a Duluth, in Minnesota, è uno studioso di Warehousing e BI. La sua architettura [7] prevede che i DWH siano utilizzati per un

(23)

Tesi di Laurea Magistrale 2015/2016

6

Il suo approccio prevede in prima battuta lo studio dei processi aziendali e la comprensione della chiave di business, in modo che possa venir sviluppato un DWH specifico per il problema che si è identificato e a cui si deve rispondere. Il sistema Kimball, che ha ereditato il nome proprio dal suo ideatore, prevede, a valle di un’analisi opportuna, una documentazione costante che accompagni tutti i processi di riferimento. I passi successivi prevedono l’utilizzo di software ETL per

rendere i dati provenienti da diverse fonti, il più possibile omogenei e comunicanti tra loro. L’acronimo ETL, merita di essere evidenziato in quanto rappresenta un’importante fase di manipolazione dei dati che si compone di:

· Extract: estrazione dei dati dalle diverse fonti alimentanti e conversione degli stessi in modo da consolidarli in un formato leggibile dal Data Warehouse; · Transformation: la trasformazione dei dati si può ottenere attraverso task

intermedi, ne vengono citati alcuni di esempio:

o Applicando regole matematiche o funzioni di business richieste;

o Pulendo i dati, uniformandoli al tipo di dato atteso oppure eliminando i

valori NULL;

o Filtrando i risultati in modo da ottenerne un set ristretto;

o Dividendo le colonne ottenute nel caso si volessero visualizzare diverse

combinazioni di dati;

o Effettuando join per “mettere insieme” dati provenienti da diverse tabelle

source;

· Load: infine si possono caricare i dati elaborati o all’interno del DWH oppure all’interno di un repository letto dalle applicazioni BI.

(24)

Tesi di Laurea Magistrale 2015/2016

7

tridimensionale la cui modellazione prevede lo schema a stella: la tabella denominata fatto o tabella dei fatti è centrale ed è circondata dalle tabelle dimensionali chiamate dimensioni che arricchiscono la prima di informazioni. La tabella dei fatti contiene tutte le misure che sono rilevanti per il business studiato e per l’analisi che si vuole intraprendere, inoltre contiene le chiavi esterne delle

dimensioni che circondano la tabella dei fatti. Le tabelle delle dimensioni sono denormalizzate in modo che l’utente possa effettuare operazioni di up o

drill-down senza dover effettuare ulteriori join.

Successivamente verrà schematizzata la modellazione di un DWH proposto da Kimball.

Figura1.2: modello DWH proposto da Kimball, [1][6]

1.2.1 Differenze e analogie con Inmon

Il Data Warehouse proposto da Inmon segue un approccio top-down. Nella filosofia di Inmon, il primo passo da compiere è la costruzione di un grande DWH aziendale centralizzato in cui tutti i dati disponibili sono provenienti da sistemi di transazione differenti e devono essere consolidati in un sistema orientato all’utente, integrato,

(25)

Tesi di Laurea Magistrale 2015/2016

8

variabile nel tempo e non volatile che supporta il processo decisionale. Il Data Mart risultante deve essere definito e costruito per rispondere alle esigenze analitiche dei reparti aziendali.

Di seguito si propone una tabella riassuntiva che evidenzia i pro e i contro della metodologia di Inmon. [2], [3], [7]

Inmon

PRO CONTRO

Tutti i dati aziendali sono raccolti nel Data Warehouse che è l’unico sistema di raccolta dati.

Nel tempo vengono impiegate diverse tabelle e la crescita del modello può renderne difficile la gestione.

La ridondanza dei dati è ridotta al minimo; questo rende i processi ETL più snelli e veloci,

diminuendo la possibilità di fallimento.

Le risorse necessarie per lo sviluppo e la manutenzione devono essere esperte sia di DWH che di business. Devono avere competenze tecniche e aziendali.

I processi business sono facilmente comprensibili.

Il sistema è reso molto flessibile, i cambiamenti sono gestibili

facilmente (è come se la modifica da apportare, fosse da fare in un singolo punto.).

Il Data Mart viene costruito direttamente dal Data Warehouse, il lavoro di cui necessita l’ETL sarà oneroso.

In grado di gestire differenti esigenze di reporting.

Tabella1.1: Pro e contro la dottrina di Inmon

(26)

Tesi di Laurea Magistrale 2015/2016

9

costruzione di un DWH secondo il metodo bottom-up. Nella filosofia di Kimball occorre analizzare i reparti aziendali che causano criticità in modo da capire quale sia il business su cui fornire basi di dati di supporto alle decisioni; il data mart viene subito costruito. Il modello dimensionale viene utilizzato secondo la metodologia dell’informatico per rispondere meglio alle esigenze delle diverse aree interne all’azienda. Come fatto in precedenza si riassumono i punti a favore della

dottrina di Kimball e quelli che ne vanno contro [1], [7]

Kimball

PRO CONTRO

Lo schema a stella è facilmente comprensibile dagli utenti esperti di business e può essere utilizzato velocemente per inviare

segnalazioni.

La presenza di dati ridondanti può causare anomalie nell’aggiornamento dei dati nel lungo periodo.

L’immagazzinamento dei dati è piccolo, occupa meno spazio nel Data Base e rende pratica la gestione.

Per via delle dimensioni grandi delle tabelle dei fatti, un’aggiunta di

colonna potrebbe richiedere un lavoro oneroso e causare problemi di

prestazioni. Un piccolo team di sviluppatori e

architetti è sufficiente per

consentire al DWH un’esecuzione efficace.

Permette al Data Mart di essere orientato verso operazioni di reportistica.

Non è possibile gestire tutte le esigenze di reporting aziendale perché il modello è orientato verso i processi di business, piuttosto che l'impresa nel suo complesso. Più strutture a stella possono

essere interrogate per ottenere analisi di diversa tipologia rispetto

(27)

Tesi di Laurea Magistrale 2015/2016

10

a quelle pensate in un primo step.

Tabella1.2: Pro e contro la dottrina di Kimball

Le due dottrine vengono confrontate nella tabella seguente che mette in evidenza altri aspetti non descritti in modo esplicito in precedenza. [1], [2], [3]

Caratteristiche

Inmon

Kimball

Requisiti di supporto alle decisioni Strategico Tattico Requisiti di integrazione dei dati L’integrazione dei dati è in ambito aziendale Singoli requisiti di business Struttura dei dati I dati soddisfano varie e multiple esigenze di informazioni Key Performance

Indicator (KPI), misure di performance aziendale, scorecard

Persistenza dei dati nel sistema di origine I sistemi di origine sono caratterizzati da un alto tasso di cambiamento Sistemi di origine relativamente stabili

Abilità Necessità di grandi

team di specialisti

Gestibile da piccoli team, non necessariamente formati da specialisti

Vincoli temporali

Tempo lungo per soddisfare le necessità aziendali

Tempi di sviluppo brevi, con priorità assegnate

(28)

Tesi di Laurea Magistrale 2015/2016

11 Tabella1.3: Inmon vs Kimball

Ovviamente, non c’è un modello che in assoluto è preferibile all’altro, occorre

scegliere quello che meglio si adatta alle proprie esigenze. Le linee guida da seguire per intraprendere una scelta di questo tipo sono:

· Reportistica: se lo scopo è produrre una reportistica strategica, il sistema di Inmon funziona meglio rispetto a quello di Kimball che è orientato ai processi business;

· Tempistica: se la prima consegna del Data Warehouse si può prolungare e il cliente è disposto ad attendere eapprovare tale stima, l’approccio di Inmon può essere seguito; nel caso in cui i tempi devono essere ridotti, sicuramente è meglio la dottrina di Kimball;

· Staff: Inmon può essere seguito se l’azienda può permettersi un team di specialisti e di grandi dimensioni;

· Frequenze di modifiche: se si prevede di ricevere segnalazioni e di dover modificare il sistema rapidamente, l’approccio di Inmon funziona meglio

perché flessibile.

All’interno del progetto in cui si sta operando è prevista una stretta collaborazione

tra il team di sviluppatori e il team conoscitore di business, identificato negli utenti e nelle figure professionali di intermediari che costantemente fanno da “collante”

tra le parti. Inoltre, per le caratteristiche che ha il progetto dalla nascita, si decise di costruire prima la base di dati e poi di estrarne il DWH. Rispetto a quanto detto, se si dovesse identificare il Data Warehouse su cui si andrà a lavorare secondo una metodologia descritta, esso andrebbe inserito sotto Inmon.

(29)

Tesi di Laurea Magistrale 2015/2016

12

1.3 La Business Intelligence

L’excursus sulle metodologie di DWH è stato utile per poter definire la Business Intelligence (BI), ramo dell’informatica che accompagna le tecniche di supporto

alle decisioni aziendali. Una definizione più precisa di questa disciplina si può rimandare al suo ideatore Hans Peter Luhn ricercatore dell’IBM che nel 1958 ne

coniò il termine e la descrisse come:

● un insieme di processi aziendali per raccogliere dati ed analizzare

informazioni strategiche;

● la tecnologia utilizzata per realizzare questi processi;

● le informazioni ottenute come risultato di questi processi attraverso il

software.

Fatta eccezione dell’ultimo aspetto riguardante i software, che è estremamente

vasto e non di focus per il presente elaborato, le prime due definizioni verranno trattate singolarmente e dettagliatamente nei paragrafi seguenti.

1.3.1 BI come processo aziendale

Il motivo per cui le aziende raccolgono dati sta nel fatto che esse li utilizzano per trarne informazioni, valutazioni e stime relativamente al contesto aziendale e nel business in cui concorrono, con lo scopo di ottenerne vantaggio competitivo. La BI si sofferma nello studio del passato e nell’analisi del presente per capire le

(30)

Tesi di Laurea Magistrale 2015/2016

13

risultanti, permettono di simulare scenari realistici e/o di predire possibili dinamiche future. In questo senso, si è avvantaggiati nel futuro imminente nell’affrontare una problematica o una particolare situazione aziendale. La BI si

basa su un mix di software differenti per poter ottenere risultati come reportistica, cruscotti, analisi di budgeting e forecasting rivolti al performance management che li studia per intraprendere manovre business mirate ad ottenere una qualche forma di ottimizzazione.

Per questo motivo la BI va intesa come un ampio campo di attività, sistemi informativi aziendali e tecnologie informatiche finalizzate a supportare i processi decisionali, tipicamente il processo più supportato è il controllo di gestione.

A completare quanto detto in precedenza va aggiunto che le informazioni risultanti possono avere differenti livelli di dettaglio per qualsiasi funzione aziendale e possono essere utilizzati nei diversi rami in cui l’azienda è composta (es. area Marketing, Area finanziaria, HR, ecc…).

Ogni sistema di BI ha un obiettivo preciso che deriva dalla vision aziendale e dagli obiettivi della gestione strategica presente in azienda.

1.3.2 BI come tecnologia

Nella letteratura la BI viene citata come il processo di "trasformazione, di dati e

informazioni, in conoscenza".

Un’applicazione BI si può descrivere come uno strumento software che, acquisendo

e manipolando masse di dati presenti su un database, produce report, statistiche, indicatori e grafici aggiornati. Esso può essere più o meno user-friendly e può venir manipolato direttamente dall’utente. I sistemi di BI sono identificabili come "sistemi per il supporto alle decisioni"; con l’evoluzione e la complessità delle

(31)

Tesi di Laurea Magistrale 2015/2016

14

operazioni svolte, mirate ad ottenere un’analisi più complessa, si può utilizzare il

termine "business performance management" per riferirsi a sistemi di BI di nuova generazione.

I dati generati dai vari sistemi (contabilità, produzione, ricerca e sviluppo (R&S), customer relationship management (CRM), ecc.) possono venire archiviati in Data Warehouse, che ne conservano le qualità informative. Le persone coinvolte nei processi di BI utilizzano applicazioni software ed altre tecnologie per raccogliere, immagazzinare, analizzare e distribuire le informazioni.

(32)

Tesi di Laurea Magistrale 2015/2016

15

CAPITOLO 2: Elementi di teoria

del Database di

Greenplum

L’attività di migrazione aziendale è finalizzata a rendere Greenplum l’unico

Database (DB) a disposizione degli sviluppatori e degli utenti finali. Prima di addentrarsi nei tecnicismi del processo di migrazione e nell’utilizzo del nuovo DB,

è stato indispensabile studiare la nuova tecnologia. In questo capitolo si tratteranno gli aspetti teorici e tecnici del DB di Greenplum. Si descriveranno le caratteristiche, si cercheranno di approfondire gli aspetti relativi all’architettura e al funzionamento

dei componenti coinvolti.

2.1 Greenplum Database

Pivotal Greenplum Database[16] è un server del database di elaborazioni massicce e

parallele (Massively Parallel Processing - MPP) la cui architettura è stata appositamente progettata per gestire i DWH che operano su larga scala e i carichi di lavoro della BI.

MPP (conosciuto anche come architettura non-condivisa) si riferisce a sistemi con due o più processori che cooperano per effettuare un’operazione: ogni processore è

costituito da una propria memoria, da un proprio sistema operativo e da dischi. Un’architettura così costruita prevede alte prestazioni e permette di distribuire il carico di lavoro di un DWH multi-terabyte in modo che possano essere utilizzate tutte le risorse in parallelo per elaborare una query.

(33)

Tesi di Laurea Magistrale 2015/2016

16

agiscono insieme come un unico sistema coeso di Data Base Management System (DBMS). La tecnologia PostgreSQL ha subito delle modifiche per poter essere adattata alle esigenze del DB Greenplum, se ne analizzano nel dettaglio gli aspetti:

● Per permettere la struttura di lavoro in parallelo prevista dal DB Greenplum

sono state apportate delle integrazioni al catalogo di sistema, all’ottimizzatore, all’esecutore delle query e ai componenti che permettono la

gestione delle transazioni;

● Sono state incluse funzionalità che permettono di ottimizzare PostgreSQL per

la BI come il caricamento dei dati in parallelo (tabelle esterne), la gestione delle risorse, l’ottimizzatore delle query e il miglioramento della memoria; ● Sono state introdotte caratteristiche che sono state ereditate successivamente

anche da PostgreSQL standard come, ad esempio, la possibilità di partizionare le tabelle.

2.2 Architettura

Il Database Greenplum[16] memorizza ed elabora grandi quantità di dati,

distribuendo i dati e l'elaborazione del carico di lavoro su più server o host. In altre parole si può descrivere come un array di singoli database basati su PostgreSQL 8.2 che lavorano insieme per presentarsi come un unico database. Esso è principalmente composto da tre elementi: il Master che è il punto d’ingresso ed è l’istanza a cui si collegano i client per trasferire istruzioni SQL; i Segmenti sono

coordinati dal master e hanno il compito di memorizzare ed elaborare i dati; i

Collegamenti, come suggerito dal nome, permettono l’interazione tra i primi due.

(34)

Tesi di Laurea Magistrale 2015/2016

17

far riferimento ai vari componenti appena citati che verrano meglio analizzati.

Figura2.1: Architettura del DataBase di Greenplum

Il Database è stato pensato per elaborare una grande mole di dati in modo efficiente, per essere utilizzato nella Big Data Analysis che è la nuova frontiera dell’Information Technology.

2.2.1 Masters

Il nodo master è l'ingresso per il sistema Greenplum, accetta le connessioni client e le query SQL, e distribuisce il carico di lavoro alle istanze dei segmenti.

Il processo parte dagli utenti, che, attraverso il loro client psql o interfacce di programmazione (Application Programming Interface - API) ad esempio JDBC o ODBC si collegano al DB.

Nel componente risiede il catalogo di sistema globale, cioè l’insieme delle tabelle

di sistema che contengono i metadati; non sono contenuti, invece, i dati richiesti dagli utenti che sono contenuti nei segmenti. Il compito del master è di eseguire

(35)

Tesi di Laurea Magistrale 2015/2016

18

l’autenticazione delle connessioni client, di elaborare i comandi SQL che immette l’utente distribuendo i carichi tra i vari segmenti. Una volta ottenuti i risultati delle

elaborazioni di ogni segmento atteso, presenta i risultati finali al programma client. La maggior parte delle operazioni come la scansione, join, aggregazione e ordinamento vengono eseguite dei segmenti in parallelo.

Figura2.2: Indirizzamento della query in modo parallelo

Alcune query possono accedere ai dati mediante un solo segmento, come quelle che prevedono l’INSERT, l’UPDATE, la DELETE di una singola riga o le SELECT

che filtrano la tabella in base alla colonna-chiave. In questi casi il piano della query non viene distribuito in tutti i segmenti, ma è indirizzato ad un unico segmento, cioè quello che contiene la riga interessata.

(36)

Tesi di Laurea Magistrale 2015/2016

19

Figura2.3: Indirizzamento della query in un singolo segmento

Sul master, il processo di lavoro della query viene chiamato Query Dispatcher. Esso è responsabile della creazione e del dispacciamento il piano di query, inoltre, si fa carico di presentare i risultati finali.

2.2.2 Segmenti

I segmenti sono indipendenti dal DB PostgreSQL, ognuno di essi contiene una porzione di dati ed eseguono la maggior parte dell’elaborazione prevista che gli viene passata dal nodo master. Il nodo, che è l’unità minima dell’architettura, smista l’elaborazione negli n segmenti di cui è composto in modo da parallelizzare l’esecuzione richiesta. Nel momento in cui un utente si connette al sistema ed

esegue una query, i processi per gestirla vengono creati in ogni segmento e smistato sui nodi. Per eseguire una query i segmenti elaborano il piano di esecuzione della

(37)

Tesi di Laurea Magistrale 2015/2016

20

stessa, così, ogni nodo coinvolto esegue un’operazione che deve essere fatta per risolvere l’intera query e produrne il risultato.

Oltre alle comuni operazioni dei DB, Greenplum ha un’operazione aggiuntiva

chiamata motion, essa prevede lo spostamento delle tuple tra i segmenti durante l’elaborazione della query. Per ottenere il massimo parallelismo, Greenplum esegue

uno slice del piano ovunque vi sia un’operazione di motion, producendo una “fetta” (da elaborare) che i segmenti possono eseguire in modo indipendente gli uni dagli altri.

Per poter meglio capire quanto appena descritto, si procede mostrando un esempio e viene considerata la seguente query:

SELECT Customer.name, Sales.amount FROM Sales JOIN Customer USING (c_id)

WHERE dateCol = '28-04-2017';

Il piano della query prevede una motion per distribuire le tuple tra i segmenti per soddisfare l’operazione di JOIN. La motion risulta necessaria in quanto la tabella

Customer viene distribuita in base alla colonna c_id, mentre la tabella Sales viene

distribuita secondo la colonna s_id. La JOIN, invece, richiede che entrambe le tabelle siano distribuite secondo la c_id (chiave di join), quindi viene eseguito uno slice delle operazioni e vengono create slice_1 e slice_2.

Sui segmenti, un processo di lavoro della query viene chiamata Query Executor ed è responsabile del completamento della sua porzione di lavoro e di comunicare i risultati intermedi agli altri processi.

(38)

Tesi di Laurea Magistrale 2015/2016

21

ogni esecuzione ogni segmento avrà un numero di processi di lavorazione della query parallelizzato sui vari nodi. I processi correlati che lavorano sulla stessa “porzione” del piano della query sono chiamati bande. Man mano che parte dell’esecuzione è stata effettuata, le tuple scorrono il piano delle query da una

banda di processi alla successiva.

Figura2.4: Lavorazione di una query

Un segmento esegue in genere da due a otto nodi Greenplum, a seconda dei core della CPU, RAM, capacità di memorizzazione, interfaccia di rete e carichi di lavoro. La configurazione dei segmenti presenti dovrebbe essere identica; il modo

(39)

Tesi di Laurea Magistrale 2015/2016

22

per ottimizzare le prestazioni del Database Greenplum è quello di distribuire i dati e i carichi di lavoro in modo uniforme su un ampio numero di segmenti in modo che ognuno di essi possa lavorare simultaneamente e possa completare l’esecuzione più o meno in contemporanea.

2.2.3 Collegamenti

Il collegamento è il livello di rete dell'architettura Greenplum Database e permette la comunicazione tra gli elementi sopra descritti. Esso regola la comunicazione dei processi tra i segmenti e l’infrastruttura di rete utilizzando un tessuto standard di

commutazione 10-Gigabit Ethernet.

Per impostazione predefinita, l'interconnessione utilizza User Datagram Protocol (UDP) per inviare messaggi sulla rete. Il software Greenplum esegue la verifica dei pacchetti assicurando un'affidabilità equivalente al Transmission Control Protocol (TCP), mentre per efficienza supera TCP. In altre parole, l’utilizzo del protocollo

UDP garantisce velocità, mentre per la sicurezza si simula il protocollo TCP attraverso un software predisposto.

(40)

Tesi di Laurea Magistrale 2015/2016

23

CAPITOLO 3: Data Warehouse

presente in azienda

Dopo aver presentato l’architettura e le caratteristiche che dovrà assumere il DWH

migrato, questa sezione si occuperà di descrivere le caratteristiche di quello attualmente in uso. Come è stato precedentemente fatto per Greenplum, si entrerà nel dettaglio dell’architettura del DB Oracle per poi esplicitare nel secondo paragrafo come vengono messi in pratica nell’ambito aziendale i punti esaminati in

teoria. Si tratterà in modo distinto la parte Back-End (BE) e la parte Front-End (FE) dei processi svolti.

3.1 Architettura Oracle

Il Database di Oracle[19] è un Relational Database Management System

(RDBMS), cioè basato sul modello relazionale introdotto da Edgar F. Codd. Oracle ha esteso questo concetto in modo da consentire la memorizzazione e la gestione di modelli business complessi all’interno di un DB: si riesce a navigare in una grande banca dati, si riescono a memorizzare molte informazioni e si rende possibile la loro manipolazione alle applicazioni utente. Accennando velocemente la definizione di RDBMS, esso permette di distinguere due tipi di operazioni:

● Logiche: in cui un’applicazione utente richiede un’informazione

specifica sia essa di interrogazione o di manipolazione record (aggiunta, cancellazione, modifica);

(41)

Tesi di Laurea Magistrale 2015/2016

24

venir svolte e poi le effettua in modo del tutto trasparente per l’utente.

Ad esempio, decide se utilizzare un indice per interrogare la tabella, oppure se è meglio effettuare altri passi per farlo.

Un Database Server è il perno nella gestione delle informazioni e per questo motivo ci si addentrerà nel dettaglio dell’infrastruttura. Per prima cosa si precisa che il server oltre a gestire la grande mole di dati, deve rendere l’intero sistema

affidabile: deve sì permettere l’accesso in contemporanea a più utenti, ma deve anche garantire che tali accessi siano autorizzati. Inoltre, in caso di malfunzionamenti deve garantire soluzioni efficienti per un eventuale recupero sia a livello di ambiente che di informazioni.

Un server Oracle è costituito da due strutture, il database e l’istanza: il primo indica i file fisici che si trovano sul disco in cui sono memorizzati i dati, la seconda comprende l’insieme delle aree di memoria e dei processi di

background necessari per accedere al DB. Dato lo stretto collegamento tra i due, spesso si utilizza il termine DB per riferirsi ad entrambi, senza porsi il problema di effettuare la distinzione. La figura successiva mostra gli elementi coinvolti: per ogni connessione utente all’istanza, il cliente esegue l’applicazione. Ogni

processo del client è associato ad un processo del server che, a sua volta, ha una propria memoria conosciuta come Program Global Area (PGA).

(42)

Tesi di Laurea Magistrale 2015/2016

25 Figura3.1: Data base e istanza, [19]

Un compito importante è svolto dalla System Global Area (SGA), una regione di memoria condivisa che contiene dati e informazioni per il controllo di un'istanza. La SGA si occupa della cache, dei dati bufferizzati, dei comandi SQL e delle informazioni sull'utente. Le strutture fisiche fondamentali per un'istanza sono:

Control files: in cui sono memorizzate informazioni essenziali sul corretto

funzionamento del DB. Tra queste il DBID che è l’identificativo dell'istanza,

il valore di CKPT necessario per la sincronizzazione dei datafile e i dati relativi ad alcune viste da interrogare quando il DB stesso non è in accessibile;

(43)

Tesi di Laurea Magistrale 2015/2016

26

Online redo logs: cioè l'archivio delle transazioni necessarie per il

funzionamento del DB stesso, il numero minimo di redo logs è 2.

● i rollback/undo segments;

Tablespace (TBS): unità logiche di memorizzazione in cui è diviso il DB,

ogni TBS è costituito almeno da un data file;

● un tablespace di tipo "temporaneo".

Oracle memorizza i dati sia logicamente, sotto forma di tablespace, sia fisicamente, sotto forma di file (datafile). Un TBS, che è formato da uno o più datafile, contiene vari tipi di segment; ogni segment, a sua volta, si suddivide in uno o più extent. Ogni extent comprende gruppi contigui di data block, che rappresentano la più piccola informazione memorizzabile da Oracle. A livello fisico, i file comprendono almeno due o più extent.

Oracle tiene traccia dei dati memorizzati attraverso informazioni presenti nelle tabelle di sistema. Esse contengono il dizionario dei dati, cioè una collezione di tabelle che possiedono informazioni riguardo a tutti gli oggetti nel DB e, nel caso in cui fossero presenti, anche degli indici e dei cluster.

3.2 Gestione delle strutture del DW

Il Data Warehouse presente in azienda tiene conto dei punti cardine, ampliamente discussi in precedenza, su cui si basano le dottrine di costruzione, implementazione e gestione del Data Warehouse. In questa sezione si andranno a dettagliare i processi di tipo Back-End per la manipolazione dei dati e quelli di tipo Front-end per la generazione di report.

(44)

Tesi di Laurea Magistrale 2015/2016

27

3.2.1 Processi Back-End

Nei riferimenti di letteratura si è descritto il processo ETL come un processo di vita del dato: si passa dall’estrazione da fonti eterogenee, a trasformazioni per raffinarlo in base all’analisi che si deve compiere fino al caricamento dello stesso su un DW.

In azienda, soprattutto per ragioni di praticità e di facilità di organizzazione di cui non entriamo in merito, il flusso ETL è vincolato alle diverse Aree di cui può essere composto un Data Warehouse. In ogni Area, chiamata anche Schema, si effettuano precise operazioni note anche in letteratura. Sul DW di analisi, ci sono molti Schema, ma ci si concentrerà sui principali e su quelli utilizzati per la costituzione della struttura che si andrà a migrare e che verrà presentata nel dettaglio nel prossimo capitolo. Gli Schema che si andranno ad approfondire sono quelli che si trovano su istanze di I livello : STaging Area (ST), Operational Data Store (ODS),

Definition Data Store (DDS); mentre lo Schema presente sull’istanza di II livello è

il Data Mart (DM) che rappresenta il “contenitore” di fact e dimensioni presenti all’interno del Data Warehouse. Esso è stato abbondantemente discusso nei capitoli precedenti in quanto rappresenta l’obiettivo delle analisi e delle elaborazioni di tipo

Back-End.

Le strutture create nei vari Schema, si parla quindi non solo di viste e tabelle, ma anche di procedure e funzioni, sono poi gestite nei Workflow che ne elaborano il caricamento nei rispettivi livelli.

3.2.1.1 Staging Area

(45)

Tesi di Laurea Magistrale 2015/2016

28

eterogenei, possono presentare ridondanze e sicuramente devo essere processati prima di poter essere caricati nel Data Mart. Alcune volte lo Schema ST rappresenta uno step talmente transitorio da poter prevedere la cancellazione dei dati una volta “fatti salire” sugli altri Schema. Altre volte, invece, si può predisporre questa Area per permetterle una memorizzazione duratura nel tempo a scopo di archiviazione o per la risoluzione dei problemi. Il DWH preso per l’analisi

rispecchia proprio la seconda descrizione, i dati sono presenti per lunghi periodi di tempo ed è una fonte alimentante esterna che li inserisce. Considerato quest’ultimo

aspetto, risulta ovvio che per poter effettuare successivi controlli è bene che i dati siano presenti per un periodo medio-lungo e che vengano copiati quotidianamente dalla fonte esterna su questo Schema.

3.2.1.2 Operational Data Store

A livello teorico lo Schema ODS potrebbe essere pensato come un’area logica

facente parte del primo livello in cui i dati sono presenti in modo temporaneo prima di essere trasferiti nel Data Warehouse per essere archiviati. Le operazioni effettuate in questo step sono volte ad eliminare le ridondanze per rispettare le regole di business corrispondenti. Secondo la letteratura, infatti, le query eseguite sono relativamente semplici, in quanto l’ODS è studiato per contenere piccole

quantità di dati.

Contrariamente a quanto descritto, in questo step, per scelte progettuali sulle quali non ci si dilungherà, è stato pensato lo schema ODS come contenitore di dati storicizzati. Sono state eliminate le ridondanze e si è provveduto a costituire per delle tabelle definite “portanti” all’interno del Data Warehouse lo storico dei

(46)

Tesi di Laurea Magistrale 2015/2016

29

conto delle richieste di business ricevute. Si prevede poi, di leggere i dati dallo Schema DDS o direttamente dal Data Mart secondo le esigenze e i tagli temporali opportuni; per questo motivo l’ODS non è interessato da query complesse, ma

viene letto attraverso le chiavi primarie o gli indici dove presenti.

3.2.1.3 Definition Data Store

All’interno dei DW nel DDS non si effettuano sempre precise operazioni, in quanto

i dati potrebbero passare direttamente nel DataMart. In questo Schema vengono effettuate delle elaborazioni, come ad es. join con altre tabelle, che potrebbero appesantire il DM se effettuate in quello step. All’interno della struttura presa in

analisi, si potrebbe pensare a questo Schema come un step di transizione in cui operazioni costose o relative a particolari aree di analisi vengono effettuate per non appesantire il Data Mart.

3.2.2 Processi Front-End

Una volta che le strutture a livello BE sono pronte e i dati hanno correttamente terminato tutti i caricamenti a cui sono soggetti si passa ad elaborare i processi FE. Essi possono essere definiti come operazioni che riguardano l’interfaccia utente,

danno evidenza agli utenti dei risultati delle analisi ed elaborazioni richieste. Nel progetto preso in esame, in cui il tool utilizzato è Business Object, il cliente che ha affidato la commessa richiede: ambienti specifici in cui poter effettuare delle query (universi); report sviluppati secondo richieste utente sia a livello di contesto di analisi che di layout e grafica.

Fin qui ci si è riferiti agli “utenti” e “clienti” indicando coloro che si sono affidati alla Hewlett-Packard per gestire l’ambito della BI. Dal prossimo capitolo ai clienti verrà attribuito un nome fittizio in modo da essere citati con precisione.

(47)

Tesi di Laurea Magistrale 2015/2016

30

CAPITOLO 4: Individuazione

Data Mart

Tra tutte le strutture presenti sul Data Warehouse esistente, grazie all’aiuto dei

colleghi, è stato individuato un piccolo insieme che permettesse la formazione di un Data Mart che potesse essere sia di interesse in ottica di business, sia di rilievo per quanto riguarda la migrazione che si è andata ad affrontare.

Sebbene le tabelle coinvolte fossero già note all’interno del progetto in cui si sta

operando, è sembrato doveroso compiere un piccolo step a ritroso per poter favorire la comprensione del lettore. In questo capitolo, dunque, si presenterà in primo luogo il modello logico delle tabelle coinvolte. Nel paragrafo 4.2 verrà dettagliata la tabella dei fatti, mostrando le colonne di cui è composta, la cardinalità prevista e il flusso di caricamento BE che ne permette la generazione. Nella sezione 4.3 verrà effettuata la stessa presentazione distintamente per le tabelle delle dimensioni scelte per l’analisi.

Da questo punto dell’elaborato si analizzerà da vicino il tema aziendale e si

citeranno le strutture coinvolte per la migrazione sul progetto. Verranno presentati gli script utilizzati per la creazione delle stesse strutture e si precisa che esse sono frutto di un rework effettuato ad-hoc per permettere la presentazione della tesi. Partendo dalle reali strutture, per ogni Schema si sono create le tabelle che si andranno a descrivere, modificando campi e variandone il datatype dove opportuno; stesso discorso è stato fatto per le procedure mostrate. In questo caso però, per poter verificare l’effettiva esecuzione e poter monitorare gli effetti prodotti, si è deciso, per esse, di lasciare tabelle tecniche (ad esempio quelle utilizzate sul DWH per i log) all’interno dello script. Per rendere omogenea la

(48)

Tesi di Laurea Magistrale 2015/2016

31

descrizione e soprattutto più comprensibile, non potendo citare la commessa a cui si fa riferimento, si è preferito attribuire ad essa un nome fittizio e un mercato di riferimento. Il caso di studio, dunque, avrà in oggetto l’azienda Dream, fornitrice di

servizi internet e televisivi.

4.1 Modello logico

Come anticipato, la scelta delle strutture da prendere in esame è avvenuta conoscendone già le caratteristiche. Sebbene le entità coinvolte siano già note, si è preferito procedere con la rappresentazione del modello logico.

Attraverso il tool Toad DataModeler, noto negli ambienti professionali, si sono tradotti gli elementi coinvolti sotto forma tabellare per organizzare i dati. In questo modo si è reso possibile fornire un modello logico in cui si mettono in evidenza gli attributi che costituiscono le entità e si definiscono le chiavi primarie ed esterne. Si è identificato come fulcro dell’analisi da condurre lo studio della tabella dei

Contratti, a cui vengono associate altre due strutture: quella relativa ai clienti (tabella Customer) e quella relativa agli asset (tabella Asset) di cui si può beneficiare una volta stipulato un contratto.

La tabella Customer avrà come chiave primaria il Customer Code, che è un codice contenuto nella tabella dei contratti; la tabella Asset ha come chiave primaria

l’Asset Code, contenuto nella Contract. Gli attributi delle tabelle che appaiono in

(49)

Tesi di Laurea Magistrale 2015/2016

32 Figura4.1: Modello Logico

In questa fase non ci si preoccuperà dei dati, ma ci si concentrerà sulle strutture che costituiscono le tabelle. Sarà focus dei paragrafi successivi analizzare nel dettaglio le tabelle scelte, le colonne che le compongono e i data type attesi per i dati che ne verranno caricati. Si precisa, infine, che sebbene le strutture siano già esistenti sul DB per la loro descrizione su questo elaborato si è reso necessario un rework. Quest’ultimo ha interessato il rename delle tabelle coinvolte, dei campi che le

compongono e delle piccole elaborazioni per garantire il distacco dall’organizzazione del DWH utilizzato sul progetto.

4.2 Tabella dei fatti

La tabella scelta per rappresentare i fatti è quella che rappresenta i contratti, la FT_CONTRACT. Un contratto può essere sottoscritto da più clienti e include uno o più asset che sono previsti nel contratto stesso. Si tratta di una delle tabelle

(50)

Tesi di Laurea Magistrale 2015/2016

33

principali, su cui si basa il DB ed ha una cardinalità di circa 308.100.000 record. A causa delle sue dimensioni è previsto un partizionamento che permette di scremare i contratti in essere da quelli cessati. E’ inoltre indicizzata sugli attributi ID_CONTRACT, COD_CONTRACT e sul COD_CUSTOMER.

(51)

Tesi di Laurea Magistrale 2015/2016

34 Figura4.2: Script creazione FT_CONTRACT

(52)

Tesi di Laurea Magistrale 2015/2016

35

4.2.1 Flusso di caricamento

In questa sezione si analizzeranno tutti gli step che hanno portato alla formazione della fact table. Rispetto al modello logico, si avrà modo di osservare la presenza di campi tecnici che in una prima fase non sono stati presi in considerazione, ma nel corso dello sviluppo si sono resi necessari affinchè la logica di calcolo potesse essere applicata. Gli step che si mostreranno partiranno dal primo Schema del primo livello (ST) e si “salirà” fino al Datamart. Prima di procedere con il dettaglio

della descrizione, si raccolgono in una rappresentazione che potrebbe essere da guida tutte le strutture coinvolte:

Figura4.3: Diagramma Strutture FT_CONTRACT

a) Staging Area

La tabella ST_CONTRACT viene popolata da un fornitore esterno che provvederà anche alla pulizia dei dati in essa contenuti. Si procede, quindi, con lo script di creazione, in cui saranno visibili alcuni dei campi presenti nel modello logico letti; per quanto riguarda i restanti, invece, occorrerà eseguire delle elaborazioni future.

(53)

Tesi di Laurea Magistrale 2015/2016

36

Figura4.4: Script creazione ST_CONTRACT

b) ODS

Nello schema ODS si provvede ad elaborare una struttura storicizzata, mediante l’utilizzo di procedure e viste. A tal proposito, viene riportato lo script della

procedura PRC_WT_D_DW_HIST_CONTRACT che ha il compito di popolare, per il giorno in cui si effettua l’esecuzione, per ogni contratto ancora in corso di

validità, la tabella WT_DELTA_DW_HIST_CONTRACT partendo dalla tabella DW_HIST_CONTRACT che contiene lo storico di tutte le movimentazioni avvenute per i contratti. Ogni giorno, la procedura provvede ad effettuare la TRUNC della tabella e l’INSERT con i record di quel giorno. Si provvede a

mostrare lo script di creazione della DW_HIST_CONTRACT specificando, però, che la sua elaborazione non verrà esplicitata nell’elaborato corrente in quanto

(54)

Tesi di Laurea Magistrale 2015/2016

37

(55)

Tesi di Laurea Magistrale 2015/2016

38

Interessante è lo script della procedura che oltre ad effettuare le elaborazioni descritte nelle righe 45-63 esegue dei check sulla correttezza dell’esecuzione e scritture nella tabella predisposta ai log.

(56)

Tesi di Laurea Magistrale 2015/2016

39

(57)

Tesi di Laurea Magistrale 2015/2016

40

La procedura scrive sulla tabella di cui si presenta lo script di creazione in Figura13; essa è partizionata in base ai record con contratto in essere e quelli che risultano chiusi.

Figura4.7: Script creazione WT_DELTA_DW_HIST_CONTRACT

c) DDS

Nello Schema corrente si è provveduto all’ulteriore elaborazione dei dati presenti sulla tabella dei fatti. In particolare, si andrà a considerare la vista VS_WT_DELTA_HIST_CONTRACT in cui viene letta la tabella presente sull’ODS DW_HIST_CONTRACT per reperire tutti i record elaborati in quel

(58)

Tesi di Laurea Magistrale 2015/2016

41

giorno.

Figura4.8: Script creazione VS_WT_DELTA_HIST_CONTRACT

La tabella WT_DELTA_DATE è una tabella aggiornata giornalmente dal sistema con la data corrente, dove per corrente si intende la data del giorno precedente (sysdate-1): oggi, ad esempio, saranno caricati i dati di ieri.

Allo script della vista segue quello di creazione della tabella omonima: WT_DELTA_HIST_CONTRACT.

(59)

Tesi di Laurea Magistrale 2015/2016

42

In questo punto intervengono diverse strutture presenti nel DW aziendale per il corretto calcolo della struttura CONTRACT. Non è stato possibile presentare interamente lo script coinvolto per la VS_WT_FT_CONTRACT, ma si è pensato, per completezza, di mostrarne almeno il frammento relativo alla create. In Figura17 è presentata la tabella popolata dalla vista citata.

(60)

Tesi di Laurea Magistrale 2015/2016

43 Figura4.11: Script creazione WT_FT_CONTRACT

d) DM

Il primo step che si è compiuto sullo Schema del secondo livello è stato quello di utilizzare una procedura per copiare la tabella WT_FT_CONTRACT dal DDS al DM. Per permettere ciò, ovviamente, è stata creata la tabella sul DM e poi è stata popolata mediante la PRC_COPY_CONTRACT.

Figura4.12: Script creazione WT_FT_CONTRACT

(61)

Tesi di Laurea Magistrale 2015/2016

44

mediante DB-link sui dati della tabella omonima presente sul DDS e inserisce questi sullo schema del secondo livello come mostrato nelle righe 11-27 della Figura19.

Figura4.13: Script PRC_COPY_CONTRACT

Rispetto al modello logico, fino a questo punto erano assenti i campi relativi al VAL_DISCOUNT e al FLG_TERMINATED il cui calcolo è previsto nella vista VS_WT_FT_CONTRACT_TOT in quanto coinvolge strutture esterne a quelle della CONTRACT presenti sul DM. I record vengono calcolati mediante due UNION in cui vengono considerati i contratti presenti nella WT_FT_CONTRACT in join con tabelle presenti nel DW. Si evidenzia come i due campi finora mancanti vengano ottenuti attraverso CASE WHEN precisamente nelle righe 23-34 e 50-54.

(62)

Tesi di Laurea Magistrale 2015/2016

45 Figura4.14: Script VS_WT_FT_CONTRACT_TOT

La tabella WT_FT_CONTRACT_TOT, quindi, presenterà tutti i campi previsti nel modello logico.

(63)

Tesi di Laurea Magistrale 2015/2016

46 Figura4.15: Script WT_FT_CONTRACT_TOT

Per terminare la presentazione degli step utili alla determinazione della tabella dei contratti, si presenta lo screen del tool Toad in cui viene mostrata la FT derivante dallo script di creazione presente in Figura9.

(64)

Tesi di Laurea Magistrale 2015/2016

47 Figura4.16: Screen Toad FT_CONTRACT

4.3 Tabelle delle dimensioni

La tabella dei fatti deve essere accompagnata da dimensioni (DM) per arricchire le informazioni su cui si possono effettuare analisi. Le relazioni tra le diverse tabelle avvengono attraverso le foreign key, la tabella dei fatti contiene i campi con cui si può accedere alle chiavi primarie delle dimensioni. Le interazioni della FT_CONTRACT con le DM permettono l’arricchimento dei dati di interesse sul

DWH.

4.3.1 Dimensione Customer

(65)

Tesi di Laurea Magistrale 2015/2016

48

relativa ai clienti dell’azienda Dream che hanno stipulato un contratto. Come

derivazione del modello logico, la struttura verrà creata dello script riportato in Figura4.17(1-2). La tabella è partizionata secondo i clienti che risultano attivi al giorno corrente e quelli che non usufruiscono più del servizio; vi è, inoltre, un indice definito sul COD_CUSTOMER e uno creato sulla chiave primaria.

Riferimenti

Documenti correlati

A cura di Inail, Direzione centrale prevenzione e Direzione regionale Liguria Segreteria Organizzativa: Elena Mattace Raso (e.mattaceraso@inail.it), Maria Rigano

Syngenta offre una gamma di prodotti per la protezione della coltura che accompagna il maiscoltore dalla semina alla raccolta: prodotti per la concia delle sementi,

nella ricerca di controparti commerciali estere tramite piattaforma dedicata: una vetrina virtuale che offre opportunità di business one-to-one nei

Concept della campagna: “I farmaci  generici sono identici agli altri farmaci

Il voto finale di un esame viene ottenuto facendo la media aritmetica delle votazioni (ognuna da 1 a 10) ottenute nelle quattro prove previste.. Nelle prime tre prove uno studente ha

Giovanni ottiene il punteggio 7, 5 e Antonio risponde esattamente ai 2/3 delle domande alle quali risponde esattamente Giovanni... Antonio e Giovanni rispondono a tutte le 15

dopo aver bevuto mezzo bicchiere ne riempe nuovamente la met` a mancante di acqua e continua in questo modo ogni volta che il suo bicchiere viene dimezzato?. Alla fine il suo

Uno studente migliora la sua preparazione aumentando ogni volta di un terzo del punteggio precedente la sua valutazione.. Uno studente migliora la sua preparazione aumentando ogni