Business Intelligence

Università degli Studi di PadovaDipartimento di Matematica

Corso di Laurea in Informatica

Business Intelligence:progettazione e realizzazione del

data warehouse vendite e integrazione conlo strumento QlikView

Tesi di laurea triennale

RelatoreProf. Mauro Conti

LaureandaBeatrice Feltre

Anno Accademico 2014-2015

Beatrice Feltre: Business Intelligence:progettazione e realizzazione deldata warehouse vendite e integrazione con lo strumento QlikView, Tesi di laureatriennale, c© Dec. 2014.

Sommario

Questo documento ha l’intento di descrivere quanto realizzato da me durante il periododi stage, a conclusione del percorso accademico per il conseguimento della laureatriennale in Informatica.

L’elaborato non si limita ad illustrare il lavoro svolto, ma punta anche a dareuna panoramica del contesto in cui si cala il progetto con nozioni di base legate adaspetti teorici di quanto implementato e approfondimenti sull’ambiente di lavoro esugli strumenti utilizzati.

Lo stage aveva come obiettivo la realizzazione di un data warehouse per levendite in ambito SAP Business ONE, che fosse poi interfacciabile con lo strumentoQlikView per analisi di Business Intelligence.

Convenzioni tipografiche per la stesura del documentoPer la stesura di questo documento ho utilizzato alcune convenzioni tipografiche in

modo da guidare chi legge ad individuare in modo semplice parole, frasi e contenutispecifici relativi a codice o che rimandano ad altre sezioni del documento in particolare:

• Il nome degli strumenti informatici, alla prima occorrenza, vengono evidenziaticon lo stile corsivo;

• Keywords relative a linguaggi di programmazione vengono identificate con lostile MONOSPACE MAIUSCOLO;

• Acronimi e abbreviazioni vengono definiti nella sezione “Acronimi e Abbreviazioni”che si trova al termine del documento. Alla prima occorrenza vengono identificatitramite lo stile grassetto sottolineato e successivamente menzionato anche ilnome per esteso;

• Parole ambigue o termini tecnici che necessitano di spiegazione vengono iden-tificati all’interno del testo mediante il grassetto sottolineato per la primaoccorrenza e troveranno spazio di spiegazione all’interno del Glossario posto afine documento.

iii

Indice

1 Introduzione 11.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Aree di business dell’azienda . . . . . . . . . . . . . . . . . . . 11.2 Il progetto di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Pianificazione delle attività . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1 Introduzione all’ambiente di lavoro . . . . . . . . . . . . . . . . 31.3.2 Progettazione e sviluppo dell’applicazione . . . . . . . . . . . . 31.3.3 Creazione della documentazione . . . . . . . . . . . . . . . . . 3

1.4 L’ABC: Data Warehouse e Business Intelligence . . . . . . . . . . . . . 41.4.1 La piramide informativa . . . . . . . . . . . . . . . . . . . . . . 41.4.2 Data warehouse (DWH) . . . . . . . . . . . . . . . . . . . . . . 51.4.3 Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Dominio Tecnologico 112.1 SAP Business ONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 CpgOne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 SQL Server Management Studio . . . . . . . . . . . . . . . . . 162.3 QlikView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 Gartner Magic Quadrant . . . . . . . . . . . . . . . . . . . . . 182.3.2 Analisi Comparativa . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Transact-SQL, SQL e suoi dialetti . . . . . . . . . . . . . . . . . . . . 23

3 Analisi del dominio e requisiti 253.1 Vincoli di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 Requisti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.3 Tabelle dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Progettazione struttura del data warehouse 354.1 DFM (Dimensional Fact Model) . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Panoramica sul DFM . . . . . . . . . . . . . . . . . . . . . . . 354.2 Fatti, Misure e Dimensioni . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Fatti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.2 Misure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.3 Dimensioni Primarie . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Gerarchie e dimensioni secondarie . . . . . . . . . . . . . . . . . . . . 38

v

vi INDICE

4.3.1 Gerarchia “Geografia” . . . . . . . . . . . . . . . . . . . . . . . 384.3.2 Gerarchia “Tempo” . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.3 Dimensioni secondarie: cliente di consegna . . . . . . . . . . . . 404.3.4 Dimensioni secondarie: prodotto . . . . . . . . . . . . . . . . . 404.3.5 Relazione tra dimensioni e gerarchie . . . . . . . . . . . . . . . 41

4.4 Schema concettuale del data warehouse vendite . . . . . . . . . . . . . 424.5 Progettazione logica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5.1 Scelte Progettuali . . . . . . . . . . . . . . . . . . . . . . . . . 444.5.2 Schema logico del data warehouse vendite . . . . . . . . . . . . 464.5.3 Tabelle del data warehouse vendite . . . . . . . . . . . . . . . . 48

5 Implementazione della struttura e script ETL 535.1 Premesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2 Script per la creazione della struttura . . . . . . . . . . . . . . . . . . 545.3 Organizzazione del codice . . . . . . . . . . . . . . . . . . . . . . . . . 555.4 Recupero e caricamento dei dati . . . . . . . . . . . . . . . . . . . . . 56

5.4.1 ETL con il cursore . . . . . . . . . . . . . . . . . . . . . . . . . 565.5 Descrizione di massima degli script T-SQL . . . . . . . . . . . . . . . . 61

5.5.1 Funzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.5.2 Store Procedure Funzionali . . . . . . . . . . . . . . . . . . . . 615.5.3 Store Procedure Ausiliarie . . . . . . . . . . . . . . . . . . . . . 63

5.6 “How to use” del data warehouse . . . . . . . . . . . . . . . . . . . . . 65

6 Test di quadratura 696.1 Database sorgenti testati . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2 Tipologie di test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.3 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7 Interfacciamento a QlikView 757.1 Creazione ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.2 Script QlikView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.3 Screenshot dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . 78

7.3.1 Cruscotti e Grafici . . . . . . . . . . . . . . . . . . . . . . . . . 787.3.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8 Conclusioni 858.1 Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858.2 Problematiche incontrate . . . . . . . . . . . . . . . . . . . . . . . . . 868.3 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 878.4 Considerazioni finali sull’attività di stage . . . . . . . . . . . . . . . . 87

Ringraziamenti 91

A Appendice A: Descrizione testuale delle tabelle 93A.1 Descrizione delle Dimensioni . . . . . . . . . . . . . . . . . . . . . . . . 93

A.1.1 Asse Geografico . . . . . . . . . . . . . . . . . . . . . . . . . . . 93A.1.2 Asse Temporale . . . . . . . . . . . . . . . . . . . . . . . . . . . 97A.1.3 Asse Prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . 98A.1.4 Asse Acquisto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100A.1.5 Asse Documento . . . . . . . . . . . . . . . . . . . . . . . . . . 101A.1.6 Asse Soggetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

INDICE vii

A.2 Descrizione dei Fatti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104A.2.1 [dbo].DWH_f_rows . . . . . . . . . . . . . . . . . . . . . . . . 104

A.3 Parametrizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107A.3.1 [dbo].DWH_parametri . . . . . . . . . . . . . . . . . . . . . . . 107

B Appendice B: Mappatura campi data warehouse 109B.1 Asse Geografico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109B.2 Asse Temporale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.3 Asse Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112B.4 Asse Prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112B.5 Asse Acquisto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114B.6 Asse Soggetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115B.7 Fatti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Glossario 123

Acronimi 125

Bibliografia 127

Elenco delle tabelle

3.1 Requisiti funzionali, data warehouse vendite . . . . . . . . . . . . . . . 333.2 Requisiti di vincolo, data warehouse vendite . . . . . . . . . . . . . . . 333.3 Requisiti di qualità, data warehouse vendite . . . . . . . . . . . . . . . 34

B.1 origine campi DWH, asse geografico . . . . . . . . . . . . . . . . . . . 110B.2 origine campi DWH, asse temporale . . . . . . . . . . . . . . . . . . . 112B.3 origine campi DWH, asse documento . . . . . . . . . . . . . . . . . . . 112B.4 origine campi DWH, asse prodotto . . . . . . . . . . . . . . . . . . . . 114B.5 origine campi DWH, asse acquisto . . . . . . . . . . . . . . . . . . . . 115B.6 origine campi DWH, asse soggetti . . . . . . . . . . . . . . . . . . . . . 118B.7 origine campi DWH, fatti . . . . . . . . . . . . . . . . . . . . . . . . . 121

Elenco delle figure

1.1 Logo dell’azienda Soluzioni Software S.r.l. . . . . . . . . . . . . . . . . 11.2 Piramide Informativa aziendale . . . . . . . . . . . . . . . . . . . . . . 41.3 Schema fatti, misure e dimensioni con gerarchia . . . . . . . . . . . . . 71.4 Esempi di utilizzo di slice e dice . . . . . . . . . . . . . . . . . . . . . . 81.5 Differenze tra database e data warehouse . . . . . . . . . . . . . . . . 81.6 Processo tipico di Business Intelligence . . . . . . . . . . . . . . . . . . 10

2.1 Logo di SAP Business ONE . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Funzionamento di CpgOne . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Logo di Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . 152.4 Finestra di Microsoft SQL Server Management Studio . . . . . . . . . 172.5 Logo di QlikView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 Gartner Magic Quadrant . . . . . . . . . . . . . . . . . . . . . . . . . . 192.7 Gartner Magic Quadrant per Business Intelligence 2014 . . . . . . . . 212.8 Analisi comparativa QlikView vs. piattaforme tradizionali . . . . . . . 22

viii

3.1 Processo di Business Intelligence calato nel progetto stage . . . . . . . 253.2 UCP - Scenario Principale data warehouse vendite . . . . . . . . . . . 263.3 UC1 - Visualizza Fatti . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4 UC2 - Aggregare in base alle dimensioni . . . . . . . . . . . . . . . . . 28

4.1 Misure individuate per rappresentare i fatti . . . . . . . . . . . . . . . 364.2 Fatti con le dimensioni correlate . . . . . . . . . . . . . . . . . . . . . 374.3 Gerarchia legata alla geografia . . . . . . . . . . . . . . . . . . . . . . 384.4 Gerarchia legata al tempo . . . . . . . . . . . . . . . . . . . . . . . . . 394.5 Dimensioni secondarie per il cliente di consegna . . . . . . . . . . . . . 404.6 Dimensioni secondarie per il prodotto . . . . . . . . . . . . . . . . . . 404.7 Relazione del cliente di fatturazione con la gerarchia “Geografia ” . . . 414.8 Relazione del cliente di consegna con dimensioni e gerarchia . . . . . . 424.9 schema concettuale del data warehouse vendite . . . . . . . . . . . . . 434.10 schema logico del data warehouse vendite . . . . . . . . . . . . . . . . 474.11 Tabelle del data warehouse per l’asse geografico . . . . . . . . . . . . . 484.12 Tabelle del data warehouse per l’asse temporale . . . . . . . . . . . . . 494.13 Tabelle del data warehouse per l’asse soggetti . . . . . . . . . . . . . . 494.14 Tabelle del data warehouse per l’asse acquisto . . . . . . . . . . . . . . 504.15 Tabelle del data warehouse per l’asse prodotto . . . . . . . . . . . . . 504.16 Tabella del data warehouse per l’asse documento . . . . . . . . . . . . 514.17 Tabella per i parametri del data warehouse vendite . . . . . . . . . . . 514.18 Tabella dei fatti del data warehouse vendite . . . . . . . . . . . . . . . 52

5.1 Diagramma di Attività: ETL con l’uso del cursore . . . . . . . . . . . 575.2 Diagramma di Attività: step di creazione del data warehouse . . . . . 665.3 Diagramma di Attività: step di modifica dei parametri . . . . . . . . . 665.4 Diagramma di Attività: step di aggiornamento del data warehouse . . 67

7.1 Screenshot dell’applicativo QlikView che mostra un cruscotto dove sipossono analizzare gli agenti anagrafici . . . . . . . . . . . . . . . . . . 79

7.2 Screenshot dell’applicativo QlikView che mostra alcuni grafici del fattu-rato in base al tempo e all’agente anagrafico . . . . . . . . . . . . . . . 80

7.3 Screenshot dell’applicativo QlikView che mostra il cruscotto per analiz-zare il fatturato su base geografica . . . . . . . . . . . . . . . . . . . . 81

7.4 Screenshot dell’applicativo QlikView che mostra il cruscotto per analiz-zare il fatturato su base geografica . . . . . . . . . . . . . . . . . . . . 82

7.5 Screenshot dell’applicativo QlikView che l’andamento del fatturato degliagenti anafrafici in base al canale di vendita . . . . . . . . . . . . . . . 82

7.6 Screenshot dell’applicativo QlikView che mostra la tabella pivot per ilcanale e per l’agente anagrafico . . . . . . . . . . . . . . . . . . . . . . 83

7.7 Screenshot dell’applicativo QlikView che mostra la top 20 dei clienti diconsegna e l’analisi ABC per gli articoli . . . . . . . . . . . . . . . . . 84

ix

x ELENCO FRAMMENTI DI CODICE

Elenco frammenti di codice

5.1 Esempio di ETL con uso di cursore: Cliente di consegna . . . . . . . . 586.1 Test sul valore finale per righe di fattura . . . . . . . . . . . . . . . . . 706.2 Test sulle quantità totali per il documento fattura . . . . . . . . . . . 716.3 Test sul numero di righe dei fatti mettendole in JOIN con le dimensioni 727.1 Script QlikView principale . . . . . . . . . . . . . . . . . . . . . . . . . 777.2 Script QlikView per le etichette . . . . . . . . . . . . . . . . . . . . . . 77

Capitolo 1

Introduzione

In questa sezione verrà data una breve descrizione dell’azienda che mi ha ospitato perlo stage in modo da capire il contesto in cui opera, il target a cui si rivolge e cosa offreal mercato. Successivamente sarà illustrato il progetto oggetto dello stage e gli obiettiviche si vorrà ottenere al termine dell’attività. Infine sarà presente una panoramica suiconcetti di Data warehouse e Business Intelligence.

1.1 L’azienda

Fondata nel 1986, Soluzioni Software Srl (di cui il logo aziendale è in Figura 1.1) hasede legale e amministrativa a Padova, ma possiede uffici anche a Pescara e Udine.Opera ormai da 30 nel mercato italiano, ha un’organizzazione snella e orientata aiclienti ed è specializzata in software per la gestione aziendale in particolare delle PMI(Piccole e Medie Imprese) che operano nei settori: industria, distribuzione e servizi neiquali conta circa 300 clienti.

Soluzioni Software è in grado di proporre diverse soluzioni in funzione della caratteri-stiche aziendali e al mercato in cui i suoi clienti operano oltre a una solida e costanterelazione con essi che si traduce in servizi di assistenza, consulenza e supporto tecnico.

Figura 1.1: Logo dell’azienda Soluzioni Software S.r.l.

1.1.1 Aree di business dell’azienda

Come appena visto poco sopra, Soluzioni Software offre una vasta Value Propositionper i suoi clienti in particolare opera nelle seguenti aree di business.

1

2 CAPITOLO 1. INTRODUZIONE

ERP e software gestionale

I sistemi ERP (Enterprise Resource Planning) offrono gli strumenti utili per gestire lacomplessità legata alle operazioni, a una rapida innovazione e a un ambiente semprepiù competitivo. Consentono inoltre di visualizzare ed amministrare tutte le risorse inmodo unificato ottimizzando aspetti finanziari e operativi allo scopo di migliorare leperformance aziendali.

Al momento questa area, per Soluzioni Software è l’area di business più importante:ERP e PMI sono parole chiave con l’ottica di offrire soluzioni che mirano a soddisfare leesigenze applicative di uno specifico mercato verticale, di un’area funzionale strategicasecondo i fabbisogni di natura gestionale dell’impresa. I prodotti offerti ai clienti sono:

• AdApta: soluzione gestionale integrata proprietaria pensata per le PMI chevogliono migliorare la propria presenza sul mercato e la propria competitivitàattraverso una gestione attenta ed efficace dei propri processi di business. AdAptaè una classica soluzione ERP con struttura modulare, le cui basi sono aderenzaai più importanti standard di mercato e l’indipendenza dall’hardware, dai sistemioperativi e dai linguaggi di sviluppo;

• SAP Business ONE: piattaforma gestionale sviluppata da SAP1 appositamenteper le PMI che sono alla ricerca di una soluzione il più possibile completa eintuitiva, dai costi contenuti, facilmente implementabile e in particolare chepossa tutelare nel presente e nel futuro gli investimenti effettuati. Il punto diforza di SAP Business ONE sta nel consentire alle PMI di operare con gli stessistrumenti di una grande organizzazione snellendo le operazioni giornaliere nellearee: amministrativa, vendite, acquisti, magazzino e produzione.

Analisi dati e performance aziendale

Fornire risposte migliori e più velocemente - ovvero produrre le informazioni giuste,al momento giusto e nel formato corretto - integrando i dati provenienti dalle diversefonti di informazione aziendali e soddisfare le richieste degli utenti.

Le applicazioni di Business Intelligence di Soluzioni Software semplificano ed ac-celerano la raccolta e l’organizzazione dei dati rendendo più veloce e accurato l’interoprocesso decisionale. È proprio in questo ambito, assieme all’ambiente vendite di SAPBusiness ONE che si cala il progetto di stage da me realizzato.

Gestione documentale

Trova come strumento ARXivar, con il quale è possibile gestire e razionalizzare almeglio tutta la documentazione e le informazioni destrutturate in modo massivo percondividere in modo ottimale le informazioni all’interno dell’azienda.

1.2 Il progetto di stageIl progetto di stage da me svolto rientrava nell’ambito “analisi dati e performanceaziendale” a stretto contatto con i sistemi gestionali, in particolare la soluzione SAP

1 Azienda leader mondiale nel campo dei software gestionali, di cui Soluzioni Software è tra i primipartner italiani.

1.3. PIANIFICAZIONE DELLE ATTIVITÀ 3

Business ONE.

L’esigenza dell’azienda è quella di offrire ai propri clienti un pacchetto completoper analisi di Business Intelligence sulle aree aziendali: vendite, acquisti, magazzino eproduzione. Mi è stato affidato dunque il compito di realizzare una piccola parte diquesto pacchetto, ovvero il data warehouse vendite. Più dettagliatamente, il progettostage, dopo una parte iniziale formativa sul dominio applicativo e concetti di base,consisteva:

• nell’individuazione e definizione di dimensioni, fatti e misure (riguardanti l’ambitoaziendale vendite);

• successiva realizzazione degli script SQL (Structured Query Language) di crea-zione delle strutture di data warehouse e degli script di caricamento dei dati;

• infine, l’integrazione con lo strumento QlikView per la creazione di cruscottistandard di analisi.

1.3 Pianificazione delle attivitàIn questa sezione verrà illustrato il piano di lavoro fornitomi dell’azienda nel qualevengono identificate le attività che si sarebbero dovute svolgere durante il periodo distage. La durata dello stage è stata di 8 settimane, dal lunedì al venerdì con orari:09:00-13:00 e 14:00-18:00 per un totale di circa 8 ore al giorno.

1.3.1 Introduzione all’ambiente di lavoroQuesta attività ha ricoperto circa due settimane, nelle quali ho approfondito cono-scenze legate a Microsoft SQL Server e al linguaggio T-SQL (Transact-SQL); hoappreso concetti di base di data warehouse e Business Intelligence oltre ad aver avutoun’infarinatura generale su QlikView.

1.3.2 Progettazione e sviluppo dell’applicazioneQuesta attività ha occupato quasi il 75% delle ore a disposizione per la realizzazione delprogetto. È infatti l’attività cruciale che prevedeva la definizione delle tabelle di baseper l’ambito vendite e la successiva realizzazione degli script T-SQL per la creazionedella struttura del data warehouse. La sotto-avvitità principe di questa attività èquella che riguardava lo sviluppo degli script per il caricamento dei dati dalla base didati di SAP Business ONE. Una volta terminato il data warehouse l’ho integrato conun foglio di QlikView esistente.

1.3.3 Creazione della documentazionePer la produzione della documentazione si sono usate il monte ore restante dalle attivitàprecedenti. La documentazione non è stata creata al termine delle altre attività, ma èstata redatta al termine delle attività che ne necessitavano. La necessità di quantofatto, nasce dall’esigenza dell’azienda di avere a disposizione quanto di utile per potercomprendere il lavoro fatto, le scelte attuate e per lasciare a chi dovrà utilizzare (siain termini di back-end, quindi la manutenzione, sia in termini di front-end, quindil’utilizzatore vero e proprio del prodotto) quanto da me realizzato.


1.4 L’ABC: Data Warehouse e Business IntelligencePer riuscire a comprendere maggiormente cosa dovessi realizzare, occorre guardare lefondamenta teoriche che stanno alla base di quanto implementato in modo da capirnescelte, aree aziendali che ne beneficeranno dall’utilizzo e cosa permettono di fare.

1.4.1 La piramide informativaUn’organizzazione è caratterizzata da:

• Persone: legate tra loro da una struttura gerarchica;

• Attività Produttive: necessarie alla produzione di beni o servizi che l’aziendaoffre sul mercato;

• Attività Accessorie: a supporto delle attività Produttive.

L’insieme di questi elementi costituisce un sistema organizzato: interagiscono tra loroper raggiungere gli obiettivi fissati per l’azienda. L’organizzazione interna aziendale puòessere vista come una sorta di piramide (Figura 1.2) nella quale si possono identificare3 livelli di attività.

Ogni livello produce degli output che diventano input per il livello successivo:

Figura 1.2: Piramide Informativa aziendale

• Dati: sono la materia prima per l’azienda e in continua crescita in quanto derivanodalle operazioni quotidiane svolte dal livello “Activity”. Possono derivare dadiverse fonti, strutturate o meno, e venire raccolti in grandi archivi a disposizionedi tutti gli utenti che lo richiedono. Devono essere disponibili e facilmentereperibili in quanto utili per svolgere le attività operative;

• Informazioni: sono il valore aggiunto che si può ottenere dai dati e vengonoprodotte dal livello “Control”. Affinché producano valore aggiunto, occorre capirecosa si vuole estrarre dai dati ovvero a cosa il livello “Lead” è interessato.

1.4. L’ABC: DATA WAREHOUSE E BUSINESS INTELLIGENCE 5

C’è dunque la necessità di creare degli archivi decisionali dove memorizzarele informazioni. Questi archivi decisionali sono i data warehouse e sono il legamelogico tra ciò che i manager vedono nelle loro applicazioni per il supporto delledecisioni (Lead) e le attività operazionali delle aziende (Activity). Parleremo piùapprofonditamente delle caratteristiche nella sezione successiva.

• Conoscenza: è la vera finalità del sistema informativo aziendale e deve esseremessa a disposizione delle persone che devono prendere le decisioni strategiche.Affinché il livello “Lead ” possa raggiungerla, occorre che abbia a disposizionedegli strumenti che gli permettano di interpretare il significato delle informazionimediante indici e stime e dare un’idea visuale e immediata della situazione azien-dale che si sta analizzando per attuare eventualmente manovre correttive.

Questi strumenti sono principalmente cruscotti e grafici che permettono oltre adare un’immagine d’insieme delle situazioni di interesse, un’analisi scrupolosanel dettaglio delle stesse. Per fare ciò occorre che l’informazione elaborata dallivello “Control” sia ben strutturata;

Per poter produrre conoscenza, il sistema dell’azienda deve avere a disposizione stru-menti e tecniche per la trasformazione di dati grezzi in informazioni utili e significativeper scopi di analisi di business.

La Business Intelligence è l’insieme di questi strumenti e tecniche. Come si puòvedere anche dalla Figura 1.2, li possiamo trovare nei 2 livelli superiori a quellooperativo e che approfondiremo successivamente alla Sezione 1.4.3.

1.4.2 Data warehouse (DWH)Uno dei primi argomenti formativi previsti dal progetto di stage è quello di datawarehouse. Concetto dell’ambito informatico, ma mai affrontato in ambito accademicoincontrato per la prima volta in questa esperienza di stage è stato da me approfonditoper capire quali sono i fondamenti teorici di quello che dovevo poi realizzare.

Caratteristiche

Un data warehouse (che da ora in poi, può essere identificato da DWH) è un archivioinformatico che contiene dati di un’organizzazione e sono progettati per consentiredi produrre relazioni e analisi facilmente al fine si supportare le decisioni in ambitostrategico per l’azienda.

Per William H. Inmon2 la raccolta dati in un DWH deve necessariamente possedere leseguenti proprietà:

• Integrata: l’integrazione dei dati è fondamentale. In un DWH confluisconodati provenienti da più sistemi transazionali e/o da altre fonti esterne. Perpoterla raggiungerla è possibile avvalersi di metodi di codifica uniformi o ottenereun’omogeneità semantica utilizzando le stesse unità di misura;

• Orientata al Soggetto: il DWH pone il suo focus sui processi aziendali rispettoai processi informatici. I dati contenuti nel DWH sono archiviati in modo da

2 Uno dei primi a teorizzare il data warehouse.


rendere la loro lettura ed elaborazione da parte dell’utente il più facile possibile.L’obiettivo principale non è quindi quello di avere un sistema normalizzato (comelo è per i classici database operativi) ma quello di offrire dati organizzati perfavorire la produzione di report da parte dell’utente;

• Variabile nel Tempo: i dati presenti in un DWH sono presi da una finestratemporale molto più ampia di quella utilizzata per l’archiviazione dei dati insistemi operativi. I dati contenuti sono dunque aggiornati fino ad una certadata che nella maggior parte dei casi è antecedente a quella in cui l’utenteinterroga il sistema. Questo porta ad un’altra sostanziale differenza da un sistematransazionale in cui i dati corrispondono sempre ad una situazione aggiornata eincapace di fornire uno storico del fenomeno analizzato;

• Non volatile: i dati del DWH non possono essere modificabili, ma l’accessoè limitato in sola lettura. Comporta una diversa e semplice progettazione delsistema rispetto a un’applicazione transazionale: non occorre dunque gestireeventuali anomalie dovute agli aggiornamenti e meccanismi complessi di gestionedell’integrità referenziale.

Il DWH è definito un sistema offline in quanto le operazioni di inserimento e aggiorna-mento dei dati solitamente coinvolgono milioni di record. Essendo operazioni moltoonerose devono essere svolte di notte per non avere inconsistenze tra dati presenti neisistemi sorgenti e quelli estratti da essi. Le operazioni diurne consentite sono dunquesolo quelle di consultazione dei dati del DWH.

Cosa modella un data warehouse

Il management di un’organizzazione ragiona in termini di fatti, misure e dimensioni.Vediamo nel dettaglio il loro significato:

• FATTIUn fatto rappresenta un evento che per l’azienda risulta essere interessante daanalizzare come, per esempio, vendite, acquisti o magazzino;

• MISURELe misure sono attributi, proprietà che descrivono quantitativamente il fattosotto diversi punti di vista come ad esempio, le quantità vendute o il valoreeconomico che hanno prodotto;

• DIMENSIONILe dimensioni rappresentano le prospettive di analisi dei fatti e li individuaall’interno di un opportuno contesto. Solitamente una dimensione è un insiemedi attributi organizzata in opportune gerarchie il cui più piccolo livello datirappresentabile individua la granularità di rappresentazione dei fatti. Le istanzedi un fatto possono essere dunque aggregate e selezionate percorrendo la gerarchiadelle dimensioni.

Si possono individuare due diverse tipologie di dimensione:

· dimensione primaria: è l’elemento “Radice” ospitato all’interno dellatabella dei fatti;


· dimensione secondaria: è una pura aggregazione di dimensione primariaalle volte inserite dentro alla tabella dei fatti, questo perché le dimensionisecondarie riferiscono la situazione attuale, ma non è detto che la relazionetra dimensione primaria e secondaria non possa variare nel tempo (peresempio, un cliente potrebbe avere un agente, ma non è detto che rimangasempre quello e occorre gestire la storicità dell’agente di quel cliente).

Esempi di dimensione possono essere l’area geografica, la data o il prodotto.

Uno schema grafico di rappresentazione della struttura del DWH e la relazione trale 3 entità appena descritte è dato dalla Figura 1.3. Si può vedere come questarappresentazione mette in luce le gerarchie delle dimensioni individuate ed è il modellomigliore per poter capire la relazione tra le dimensioni.

Figura 1.3: Schema fatti, misure e dimensioni con gerarchia

Operazioni sui dati

Le operazioni possibili sui dati contenuti nel DWH possono essere:

• DRILL DOWN (o roll down)aumento il dettaglio con cui il fatto individuato viene visualizzato; voglio vederequel fatto come aggregazione di dimensioni che si trovano a un livello più specificodi quello in cui mi trovo. Consideriamo la gerarchia geografica:

città < provincia < regione < area Nielsen < Stato

e supponendo di trovarsi nella dimensione “Regione” l’operazione di drill downporta a visualizzare il fatto sotto il profilo delle province; ripetendo l’operazionearrivo a visualizzare il fatto per città;

• ROLL UP (o drill up)operazione inversa a quella precedente; riduce il grado di dettaglio e aiuta a dareuna visione d’insieme maggiore del fatto che si sta visualizzando. Questo porta


ad aggregare i valori del livello precedente della gerarchia. Mantenendo comegerarchia geografica quella vista poco sopra, e supponendo di trovarci ancora alivello di regione, l’operazione di roll up, mi porta a valutare il fatto, in terminidi aree Nielsen, ovvero i valori delle regioni vengono aggregate secondo le diversearee Nielsen di appartenenza. Ripetendo l’operazione si può vedere il fatto sottoil profilo dello Stato che è dato dall’aggregazione della aree Nielsen;

• SLICEnon effettua nessuna aggregazione sulle misure; il suo intento è quello di estrarreun subset dei dati con restrizione su una dimensione;

• DICEcome l’operazione slice, non effettua nessuna aggregazione sulle misure ma estraeun sottoinsieme di dati con restrizione su due o più dimensioni.

In Figura 1.4 si possono vedere alcuni esempi di operazioni di slice e dice. In particolarei primi due esempi si riferiscono a operazioni di slice mentre l’ultimo è un esempio didice.

Figura 1.4: Esempi di utilizzo di slice e dice

Database vs. Data warehouse

La Figura1.5, riporta le differenze sostanziali tra il database operazionale e il datawarehouse.

Figura 1.5: Differenze tra database e data warehouse


1.4.3 Business IntelligenceAbbiamo visto precedentemente in quale livello della piramide aziendale può collocarsila Business Intelligence, ma vediamo cosa effettivamente si intende con questo termine.Di solito con il concetto di Business Intelligence ci si può riferire a:

1. un insieme di processi aziendali volti a raccogliere dati e analizzare informazionistrategiche;

2. la tecnologia usata per realizzare i processi del punto precedente;

3. le informazioni ottenute come risultato di questi processi.

Nella letteratura viene citata come il processo di “trasformazione di dati e informa-zioni in conoscenza” . Il software utilizzato ha come obiettivo quello di permettereagli utilizzatori di prendere decisioni strategiche sulla base di indicatori ricavati daidati grezzi rielaborati in informazioni precise, aggiornate e significative nel contestodi riferimento. Le persone coinvolte nei processi di Business Intelligence utilizzanoapplicazioni software e non, per raccogliere, trasformare, immagazzinare, analizzare edistribuire le informazioni.

Con il tempo tutto questo ha fatto si che si creasse una nicchia di tecnologie utili nelcampo della Business Intelligence. Le tecnologie più ricorrenti sono:

• ETL (Extract, Transform, Load): tool per l’estrazione, trasformazione ecaricamento dei dati;

• data warehouse per l’archiviazione e immagazzinamento dei dati;

• Modellazione dati e strumenti per definire le logiche di business;

• OLAP (OnLine Analytical Processing) per l’analisi dimensionale di ipercubidi dati;

• Sistemi informativi geografici.

Usufruire della Business Intelligence aiuta le aziende a:

• individuare le opportunità di mercato;

• sapere dove la quota di mercato è insoddisfacente;

• identificare le aree con un costo inaccettabile;

• riconoscere le aree di business ad alte prestazioni;

• avere una visione panoramica dell’esatto profitto per ogni vendita.

ETL

ETL è un’espressione inglese che identifica il processo di estrazione (E), trasformazione(T) e caricamento (L)3 dei in un sistema di sintesi.

• E: I dati sono estratti da sistemi sorgenti di svariato tipo quali database tran-sazionali, file di testo, o altri sistemi informatici (ERP o CRM (CustomerRelationship Management));

3 Load in inglese.


• T: dopo il processo di estrazione, i dati subiscono un processo di trasformazioneche consiste per esempio nel:

· selezionare quelli di interesse per il sistema;· tradurre dati codificati;· derivare nuovi dati calcolati;· eseguire accoppiamenti (join) tra dati recuperati da differenti tabelle;· raggruppare i dati.

Hanno lo scopo di consolidare i dati ovvero di renderli omogenei anche seprovenienti da sorgenti diverse;

• L: vengono poi memorizzati nelle tabelle del sistema di sintesi.

In Figura 1.6 è riassunto dunque il processo tipico di Business Intelligence descrittopoco sopra.

Figura 1.6: Processo tipico di Business Intelligence

Capitolo 2

Dominio Tecnologico

In questo capitolo verrà dato spazio all’approfondimento degli strumenti che hoincontrato e utilizzato durante lo svolgimento dello stage per la realizzazione delprogetto.

2.1 SAP Business ONESAP Business ONE (logo in Figura 2.1) è una soluzione ERP per le PMI innovativa ecaratterizzata da un ottimo rapporto costo-prestazioni.

Figura 2.1: Logo di SAP Business ONE

È una soluzione internazionale, tradotta in 25 lingue diverse e localizzata inoltre 40 paesi, permette di registrare operazioni in multivaluta; scelta da circa 36.000aziende nel mondo è una soluzione completa, integrata, facile e all’avanguardia.

Permette di gestire: contabilità, acquisti, produzione, reportistica e magazzino attra-verso un sistema unico ed integrato; SAP Business ONE è veloce da implementare everticalizzata per il settore di appartenenza dell’azienda che lo utilizza; è progettata persemplificare le attività: aiuta a snellire i processi, intervenire sulla base di informazionitempestive e accelerare l’incremento della redditività.Oltretutto è possibile adattare e personalizzare il software con l’espansione dell’aziendaper soddisfare le esigenze in costante evoluzione.

Ambiente di lavoroL’ambiente di lavoro di SAP Business ONE presenta un classico menu per modulo

funzionale che gestisce: amministrazione, contabilità, banche, magazzino e produzione.Inoltre:

• presenta funzionalità standard di ricerca;

• ha un’interfaccia user-friendly;

11

12 CAPITOLO 2. DOMINIO TECNOLOGICO

• è semplice da navigare e adattabile alle necessità di lavoro dell’utente che loutilizza;

• a livello utente: permette di gestire le attività giornaliere da una singola area dilavoro;

• a livello direzionale: permette di monitorare in ogni momento gli obiettivi dibusiness;

• presenta 4 ambienti di lavoro preconfigurati e personalizzabili per vendite,contabilità, servizi e acquisti e consente di crearne altri a seconda delle necessità;

• permette di usufruire di applicazioni (widget) per gestire il business;

• permette una visione in tempo reale di tutti i documenti aperti in quel momento;

• dà la possibilità di navigare e accedere a documenti e anagrafiche di interesse evederne il dettaglio;

• il sistema avvisa l’utente, con messaggi generati automaticamente al verificarsidi particolari condizioni (es. ordini inseriti con extra sconto);

• permette la navigazione in internet con un browser integrato che permette disalvare i link di interesse.

Reportistica avanzataSAP Business ONE permette la creazione di report o del layout di documenti com-

merciali sofisticati e interattivi che possono accedere ai dati di dettaglio dell’anagraficaclienti, fornitori e prodotti.

Enterprise searchGrazie agli ultimi sviluppi della tecnologia in-memory è possibile un accesso in

tempo reale a tutte le informazioni aziendali e usufruire di funzioni di analisi ad alteprestazioni. È possibile inoltre:

• effettuare ricerche di dati e documenti gestiti con SAP Business ONE e ottenererisultati immediati;

• visualizzare la mappa delle relazioni che mostra graficamente tutti i flussi diprocesso integrati e gestiti dal software.

... e molto altro

• Contabilità: automatizza, integra e gestisce tutti i processi finanziari e dicontabilità, in particolare la contabilità generale, la definizione e l’aggiornamentodei conti, gli inserimenti di prima nota, gli adeguamenti della divisa estera, ledefinizioni di budget, di centri di costo e di regole di distribuzione dei costi ecc;

• Gestione magazzino e produzione: è possibile gestire lo stock su più magaz-zini, tenere traccia dei movimenti di stock e gestire gli ordini di produzione sullabase della pianificazione del fabbisogno di materiale;

• Acquisti: automatizza tutto il processo di approvvigionamento, dall’ordined’acquisto al pagamento della fattura fornitore.

2.1. SAP BUSINESS ONE 13

2.1.1 CpgOneCome visto, SAP Business ONE può essere facilmente modificato e ampliato persoddisfare le esigenze aziendali in continua crescita. Soluzioni Software ha realizzatol’add-on CpgOne: verticalizzazione che risolve i problemi delle imprese legati alcontrollo e alle logiche di vendita impostati dagli attuali canali distributivi.Consente di gestire:

• gerarchia dei clienti;

• gerarchia della forza vendite;

• politiche commerciali: listini, sconti e promozioni, assortimenti;

• contratti con i clienti;

• premi per quantità e valore;

• acquisizione degli ordini da fonte esterna;

• gestione giri agenti: pianificazione dei giri di raccolta degli ordini;

• liste di prelievo avanzate: possibilità di definire regole di evasione dei lotti eassegnare tali regole ai clienti;

• rifatturazioni.

Nativamente integrato a Sap Business ONE, CpgOne è la soluzione ideale per chisi trova ad affrontare processi di concentrazione, ristrutturazione e razionalizzazioneproduttiva tipici di un mercato maturo, garantendo un ottimale controllo dei costi eun eccellente gestione operativa delle vendite.In particolare la soluzione si rivolge alle aziende:

• con diversi canali di vendita;

• in mercati con forte competizione sul prezzo;

• con politiche commerciali attive per promuovere i prodotti;

• con forza vendita strutturata.

Affinché SAP Business ONE possa identificare e utilizzare campi dati utente (ovveronon presenti nella sua versione standard) devono essere individuati dal prefisso:

U_

Il concetto generale di funzionamento di CpgOne è illustrato dalla Figura 2.2. CPGutilizza gli attributi dei clienti e degli articoli per definire politiche commerciali articolate(listini, sconti, promozioni e assortimenti). Il motore di CPG storicizza tali politichesui documenti di vendita; un’analisi di questi consente il monitoraggio di eventualipremi.


Figura 2.2: Funzionamento di CpgOne

CpgOne è uno dei tanti esempi possibili di ampliamento di SAP Business ONEin particolare è quello che ho incontrato durante la realizzazione del progetto stage.

2.2. MICROSOFT SQL SERVER 15

2.2 Microsoft SQL ServerMicrosoft SQL Server (logo in Figura2.3) è un RDBMS (Relational DataBase Mana-gement System) prodotto da Microsoft. A partire dalla versione 2000 è utilizzato ancheper la gestione di basi dati di grandi dimensioni, cosa che prima gestiva solamente basidati medio-piccole.

Figura 2.3: Logo di Microsoft SQL Server

Microsoft SQL Server usa una variante del linguaggio SQL standard chiamataT-SQL. Inoltre supporta anche ODBC (Open DataBase Connectivity).La versione utilizzata durante lo stage è:

Microsoft SQL Server 2008 R2

Viene utilizzato da SAP Business ONE nella versione standard come repository deidati di gestione.In Microsoft SQL Server sono incluse diverse tecnologie di gestione e analisi dei dati.Per lo sviluppo del progetto ho utilizzato esclusivamente la prima delle tecnologieelencate di seguito.

DataBase Engine

È il servizio principale per la memorizzazione, l’elaborazione e la protezione dei dati.Offre tutte le funzionalità per l’elaborazione rapida delle transazioni e l’accesso con-trollato necessarie per soddisfare le esigenze delle più complesse applicazioni aziendaliper l’elaborazione dei dati.

Utilizzato per creare database relazionali per i dati relativi all’elaborazione delletransazioni in linea o all’elaborazione analitica in linea, inclusa la creazione di tabel-le per l’archiviazione di dati e oggetti di database: ad esempio indici, viste e storeprocedure per la visualizzazione, la gestione e la protezione dei dati.

Analysis Services

• Dati Multidimensionali: consente la progettazione, la creazione e la gestionedi strutture multidimensionali contenenti dati aggregati da altre origini di dati,ad esempio i database relazionali;

• Data Mining: consente la progettazione, la creazione e la visualizzazione dimodelli di data mining. Tali modelli possono essere creati da altre origini di datiutilizzando una vasta gamma di algoritmi di data mining standard del settore.


Integration Services

È una piattaforma per la compilazione di soluzioni di integrazione dati ad alteprestazioni, con pacchetti che assicurano l’elaborazione ETL.

Reporting Services

Offre funzionalità Web aziendali per la gestione e la creazione di report utilizzandocome contenuto una serie di origini di dati diverse, la pubblicazione dei report in variformati e la gestione centralizzata della sicurezza e delle sottoscrizioni.

2.2.1 SQL Server Management StudioPer accedere a Microsoft SQL Server è stato utilizzato questo strumento. SQL ServerManagement Studio è un ambiente integrato per l’accesso, la configurazione, la gestione,l’amministrazione e lo sviluppo di tutti i componenti di SQL Server. Abbina un gruppoesteso di strumenti grafici con numerosi editor di script per consentire a sviluppatori eamministratori con qualsiasi livello di esperienza di accedere a SQL Server.Gli sviluppatori possono lavorare in un ambiente familiare, mentre gli amministratoridi database avranno a disposizione un’unica utilità completa che abbina strumentigrafici di facile utilizzo con ampie capacità di scripting.

La caratteristica centrale di SQL Server Management Studio è “Esplora Oggetti”che permette all’utente di navigare, selezionare e agire su qualsiasi oggetto di SQLServer.Uno screenshot dell’interfaccia di SQL Server Management Studio è presente allaFigura 2.4.

• Esplora Oggetti: posto sulla parte sinistra della finestra, rappresenta il menudi navigazione tra gli oggetti del motore di database.Rappresenta gli oggetti contenuti nel server in una struttura ad albero che hacome root il motore di database. Una volta aperto SQL Server ManagementStudio, si ha la creazione di 2 database di sistema: System Databases e DatabaseSnapshots. È possibile aggiungere un numero arbitrario di database.

All’interno di ogni database vengono create delle sottocartelle contenenti in-formazioni omogenee tra di loro: in particolare abbiamo quelle riguardanti letabelle presenti nel database, le viste create dall’utente e la parte di programma-bilità contenente funzioni e store procedure definite su quel database. Per ognitabella poi è possibile vedere le colonne che ha, trigger su di essa e molto altro.Parte importante e da me utilizzata contenuta nel motore di database è il SQLServer Agent.

· SQL Server Agent è un servizio di Windows che esegue attività ammini-strative pianificate, note come processi. I processi sono costituiti da uno opiù passaggi, ciascuno dei quali contiene un’attività, ad esempio il backupdi un database. SQL Server Agent è in grado di eseguire un processo inclusoin una pianificazione, in risposta a un evento specifico, oppure su richiestadell’utente.All’interno del progetto, questo servizio è stato utilizzato per poter automa-tizzare l’aggiornamento del data warehouse in modo che possa essere lanciatoa un determinato orario della giornata. Come detto precedentemente infatti

2.3. QLIKVIEW 17

l’aggiornamento dei dati è fatto “offline” ovvero quando i sistemi operaziona-li non sono in funzione e quindi fuori dall’orario lavorativo. Occorre dunqueavere uno strumento che dia la possibilità di attivare l’aggiornamento inmodo automatico e SQL Server Agent in particolare il job che è un’unità dilavoro, mi sono stati di aiuto.

È inoltre possibile attraverso questo menu, creare, aggiungere, rimuovere interat-tivamente qualsiasi oggetto; generare script di creazione, modifica, rimozione ecombinazione di questi, e molto altro;

• Ambiente di Script: solitamente posto nella parte centrale della finestra,permette all’utente di visualizzare e modificare script aperti precedentemente odi crearne di nuovi. Dà la possibilità di vedere in modo user-friendly la strutturadi una tabella con le sue colonne e di apportare facilmente modifiche su di essa;

• Proprietà: posto sulla destra della finestra mostra le proprietà dell’oggettoattualmente presente nell’ambiente di script;

• Comunicazione con l’utente: posta nella parte bassa della finestra, mostra al-l’utente i risultati di una query o eventuali messaggi di errore dovuti all’esecuzionedel codice.

Figura 2.4: Finestra di Microsoft SQL Server Management Studio

2.3 QlikViewQlikView o QV o Qlik (logo in Figura2.5) è un software di Business Intelligencerealizzato da QlikTech International. Offre una soluzione di analisi completa, cheinclude dashboard e allarmi, analisi sui dati. Consente di analizzare grandi volumidi dati a velocità molto elevata grazie alla struttura del modello dati in-memory. Lerisposte alle query e l’esecuzione dei calcoli sono ottenute in una frazione di secondo.Questa tecnologia permette di eseguire associazioni ad alta velocità con un semplice


click e aggiornare immediatamente la visualizzazione. La sua struttura permette aQlikView di eseguire calcoli “al volo” e offre numerosi vantaggi rispetto all’elaborazionetradizionale tra i quali:

• rapido time-to-value: non ha bisogno di una definizione precostituita di dimen-sione: qualsiasi dato è disponibile come dimensione o misura;

• flessibilità: è possibile visualizzare un’analisi in base a una nuova dimensione omodificare una misura in pochi secondi; le interfacce standard inoltre consentonodi analizzare informazioni provenienti da qualsiasi origine di dati;

• indipendenza dalla sorgente dati: è in grado di caricare dati dalle principalisorgenti, file di testo o tabelle, formati di qualsiasi tipo, nonché data warehouse(sebbene non sia richiesto);

• grandi quantità di dati: è progettato per supportare un numero di tabelle, campi,righe o celle illimitato che dipende esclusivamente dalla capacità della RAM.

Figura 2.5: Logo di QlikView

2.3.1 Gartner Magic QuadrantGartner Magic Quadrant (MQ) è il marchio di una serie di report di ricerca di mercatopubblicata da Gartner1. Il Magic Quadrant (Figura2.6) mira a fornire un’analisiqualitativa in un determinato mercato e la sua direzione, la maturità e i partecipanti.Le analisi sono condotte in diversi settori tecnologici specifici e vengono aggiornateogni 1-2 anni.

Gartner classifica i fornitori sulla base di 2 criteri: completezza di visione e ca-pacità di esecuzione. Secondo una metodologia che Gartner non vuole rivelare, ilpunteggio attribuito a queste 2 componenti, porta a posizionare i fornitori in uno dei 4quadranti che compongono il Magic Quadrant:

• Leaders: fornitori con il punteggio più alto per entrambi i criteri; sono tipica-mente le grandi aziende con un business maturo;

• Challengers: fornitori con un punteggio alto per il secondo criterio (abilitàdi esecuzione), ma lacunosi per l’altro criterio; principalmente grandi aziendestanziali;

1 Società multinazionale leader mondiale nella consulenza strategica, ricerca e analisi nel campodell’Information Techonology.

2.3. QLIKVIEW 19

• Visionaries: fornitori con un punteggio basso per l’abilità di esecuzione, ma unpunteggio alto per la completezza di visione; in genere piccole aziende;

• Niche players: fornitori con un punteggio basso per entrambi i criteri; tipica-mente i nuovi arrivati nel Magic Quadrant.

Figura 2.6: Gartner Magic Quadrant

La Figura 2.7 mostra il Magic Quadrant stilato per la Business Intelligence e lepiattaforme di analisi e aggiornato a Febbraio 2014.Come si può notare, QlikView si colloca nel quadrante “Leaders” ed è il secondo prodottoper la capacità di esecuzione e si pone abbastanza bene in termini di completezza divisione. Questo suo successo è dovuto principalmente a 3 fattori:

• Esperienza associativa;

• Tecnologia chiave;

• Percorso di adozione della Business Discovery.

Esperienza associativa

QlikView permette agli utenti di esplorare i dati, fare scoperte e individuare informazioniutili secondo modalità nuove. Possono accedere ad informazioni inaspettate perché:

• Funziona come la mente umana: è flessibile e gli utenti possono navigare einteragire con i dati come vogliono: non sono dunque obbligati a seguire percorsidi ricerca predefiniti. Possono loro stessi creare nuovi percorsi per arrivare alleinformazioni e prendere decisioni. È inoltre possibile vedere trend nascosti e farescoperte con modalità che nessun’altra piattaforma di Business Intelligence possaoffrire;


• Mette in evidenza la.. forza del grigio: con QlikView gli utenti possonovedere le relazioni all’interno dei dati. È facile vedere anche i dati non associati:le selezioni dell’utente sono evidenziate in verde; i valori di campo correlati sonoevidenziati in bianco mentre i dati non correlati sono evidenziati in grigio. Questopermette all’utente di vedere in modo immediato dove sono presenti lacune eavviare una ricerca per scoprire come mai;

• Consente la ricerca diretta e indiretta: con il tool di ricerca di QlikView èpossibile digitare frasi o parole importanti in qualsiasi ordine e ottenere risultatiassociativi immediati. È possibile eseguire ricerche sull’intero dataset oppurelimitarle al campo in questione; inoltre l’utente può ricercare un’entità di interesseattraverso dettagli personali di quest’ultima per restringere i risultati a quelliche rispondono ai criteri desiderati;

• Fornisce risposte alla stessa velocità con cui vengono formulate ledomande: è possibile formulare le domande in molti modi, per esempio anchesolo cerchiando i dati di grafici, tabelle, diagrammi ecc. All’istante tutti idati dell’intera applicazione vengono filtrati in base a queste selezioni. Questopermette agli utenti di vedere in modo semplice e veloce le relazioni e arrivarerapidamente alle informazioni importanti.

Tecnologia chiave

Business Intelligence in-memory è un altro fattore importante di QlikView nonché lasua tecnologia chiave.Quello che lo porta al successo è quello che fa con questa tecnologia:

• Conserva i dati in memoria per una user experience superveloce: con-serva tutti i dati necessari per l’analisi in memoria con tempi di attesa nulli inquanto esegue i calcoli necessari per fornire le aggregazioni richieste dagli utentiin modo rapido;

• Gestisce automaticamente le associazioni all’interno dei dati: il motoredi QlikView mantiene automaticamente le associazioni tra qualunque dato pre-sente nel dataset utilizzato in un’applicazione. Gli utenti non sono limitati dareport statici, percorsi di ricerca predeterminati o dashboard preconfigurati, mapossono navigare tra i dati in ogni direzione;

• Calcola le aggregazioni in tempo reale, in base alle necessità: il motorecalcola le aggregazioni in tempo reale in base alle selezioni dell’utente. QlikViewcalcola dunque solo le aggregazioni richieste dall’utente; elabora i dati in modoistantaneo in base alle necessità;

• Comprime i dati al 10% delle dimensioni originali: impiega una strutturadi dati (una tabella hash) e utilizza solo il numero di bit richiesto. QlikViewpuò dunque scalare per gestire dataset molto estesi senza far salire i costi degliinvestimenti in hardware solo per spostarli in memoria;

• Ottimizza la potenza del processore: distribuisce i calcoli tra tutti i coredisponibili per massimizzare le prestazioni sperimentate dall’utente. QlikViewè ottimizzato per sfruttare al meglio tutta la potenza di questa architetturaottimizzando l’investimento in hardware.

2.3. QLIKVIEW 21

Percorso di adozione della business discovery

Il terzo importante fattore che differenzia QlikView è il percorso di adozione dellaBusiness Discovery da parte degli utenti.

• Tutto inizia con la Personal Edition: una figura professionale dell’aziendascarica la versione completa di QlikView Desktop gratuitamente dal sito webufficiale.

• Il nuovo cliente ottiene vantaggi immediati: rapidamente l’utente è ingrado di estrarre i dati da più origini e inizia ad esplorarli vedendo l’associazionenei dati riuscendo a risolvere un problema aziendale utilizzando le informazioniraccolte da QlikView. Mostra la soluzione ai colleghi che a loro volta lo scariche-ranno e lo installeranno. Successivamente iniziano a condividere le applicazionicreate;

• Un team espande l’implementazione: in poco tempo QlikView risolve ilproblema di business di un gruppo di lavoro. In genere gli utenti, contenti delrapido successo, diventano esperti di QlikView all’interno dell’azienda;

• L’IT supporta un’implementazione di classe enterprise: quando un di-partimento riesce a risolvere più problemi aziendali, gli altri dipartimenti lonotano. Lungo la strada lo staff IT (Information Tecnology) prende nota deivantaggi in termini di produttività che porta all’adozione di QlikView in tuttal’azienda.

Figura 2.7: Gartner Magic Quadrant per Business Intelligence 2014


2.3.2 Analisi Comparativa

La tabella in Figura 2.8 mette in luce le differenze sostanziali e cruciali tra QlikView ele piattaforme di Business Intelligence tradizionali.

Figura 2.8: Analisi comparativa QlikView vs. piattaforme tradizionali

2.4. TRANSACT-SQL, SQL E SUOI DIALETTI 23

2.4 Transact-SQL, SQL e suoi dialettiTransact-SQL è un linguaggio di interrogazione per database progettato per leggere,modificare e gestire dati memorizzati in un sistema basato sul modello relazionale;estensione proprietaria del linguaggio SQL, viene fornito insieme a Microsoft SQLServer.Espande le prestazioni di SQL aggiungendo:

• Funzioni per controllo di flusso: ovvero costrutti presenti nei classici lin-guaggi di programmazione:

· IF e ELSE consentono l’esecuzione condizionale di blocchi di istruzioni;· BEGIN e END delimitano un blocco di istruzioni. Deve essere utilizzato dalcostrutto precedente se più istruzioni compongono il corpo condizionatodalla clausola;

· WHILE per la creazione di loop di un blocco di istruzioni;· ... BREAK e CONTINUE, RETURN, GOTO.

• Possibilità di definire variabili locali: accessibili solo allo script che leutilizza; non supporta variabili globali definite dall’utente.

· DECLARE dichiara una variabile, attribuendole nome e tipo. È possibileinizializzarla direttamente come risultato di un’istruzione (solitamente unaSELECT) o con un valore definito dall’utente.

· SET per attribuirle un valore lungo il codice.

• Funzioni per manipolazione di stringhe, date ed espressioni numeriche.

• Miglioramento delle istruzioni DELETE e UPDATE: alle quali può essere ag-giunta l’opzione FROM che permette il collegamento ad altre tabelle mediante unaJOIN.

Queste nuove funzionalità introdotte hanno portato Transact-SQL ad un nuovo lin-guaggio non più dichiarativo (come lo è SQL), ma di tipo imperativo.È stato utilizzato per la realizzazione degli script per la definizione del data warehousee per il caricamento dei dati.

Per quanto riguarda invece l’interfacciamento con QlikView è stato utilizzato unopseudo SQL messo a disposizione da quest’ultimo.

Capitolo 3

Analisi del dominio e requisiti

Dopo un’attenta descrizione del dominio tecnologico, il seguente capitolo, oltre adelineare i vincoli che comporta il dominio sulla realizzazione del progetto, vuoleillustrare l’attività di analisi fatta per capire quali sono i requisiti richiesti e chel’applicazione dovrà soddisfare.

3.1 Vincoli di progettoIn questa breve sezione viene dato, al progetto di stage, un grado di dettaglio maggiorelegato al dominio tecnologico. Non poteva essere fatto prima in quanto mancavano leinformazioni necessarie per spiegarlo nel migliore dei modi.

• Sorgente dati

· I dati che popoleranno il data warehouse vendite vengono estratti dall’ERPSAP Business ONE;

· Deve essere considerata la parte standard di SAP Business ONE e la partestandard dell’add-on CpgOne per poter avere un prodotto base adatto atutti i clienti;

• Strumenti e versioni: il progetto deve essere sviluppato su Microsoft SQLServer 2008R2.

In Figura 3.1 viene contestualizzata, al progetto da realizzare, la Figura 1.6 cherappresenta un processo di Business Intelligence generale precedentemente descritta.

Figura 3.1: Processo di Business Intelligence calato nel progetto stage

25

26 CAPITOLO 3. ANALISI DEL DOMINIO E REQUISITI

3.2 Analisi dei requisitiDopo la prima parte riguardante l’introduzione all’ambiente di lavoro, per poterimplementare una soluzione che rispecchiasse le esigenze dell’azienda, ho stilato un’a-nalisi dei requisiti contenente i principali casi d’uso e i requisiti che ho individuatoestrapolandole da diverse fonti:

• un vecchio documento di analisi dei requisiti di un cliente che voleva una soluzionespecifica per il suo settore e su diverso sistema ERP sorgente. Essendo un ambitoaziendale a me abbastanza nuovo, mi è servito per capire quali potessero esserele dimensioni e relative informazioni interessanti secondo le quali ha senso ed hacruciale importanza valutare i fatti;

• interazioni con il tutor aziendale, per capire quali fatti avrebbe dovuto modellareil sistema e le misure principali di interesse per l’ambito vendite.

In questo primo step non è stata fatta solo un’attività di puro “accertamento” dellerichieste. Una volta capiti meccanismi ed elementi che compongono la realtà in cuimi trovavo ad operare, mi sono sorte spontanee delle possibili situazioni che potevanoessere di interesse ai fini delle analisi, portando così ad individuare nuovi requisiti onuove caratteristiche di quanto già presente.

3.2.1 Casi d’usoPer individuare facilmente le funzionalità che il data warehouse vendite dovrà offrireall’utente che utilizza la piattaforma di Business Intelligence (nel nostro caso QlikView)per l’elaborazione di analisi strategiche, sono stati realizzati alcuni diagrammi dei casid’uso che verranno presentati in questa sezione. Si vuole sottolineare il fatto che sonostati realizzati rispecchiando i requisiti relativi al progetto da realizzare: in particolarel’attore dei nostri casi d’uso, è un utente che utilizza QlikView, ma nulla vieta chepossa essere sostituito da un qualsiasi altro software di analisi.Ogni caso d’uso viene identificato da un codice univoco che rispetta la seguente sintassi:

UC[codice univoco del padre].[codice progressivo di livello]

Caso d’uso UCP: Scenario principale

Individuato in Figura 3.2

Figura 3.2: UCP - Scenario Principale data warehouse vendite

3.2. ANALISI DEI REQUISITI 27

• Attori: Utente QlikView;

• Scopo e descrizione: L’utente dopo aver avviato il software può effettuare al-cune operazioni: visualizzare i diversi fatti di interesse e aggregare le informazioniin base alle dimensioni;

• Precondizioni:

· l’utente ha aperto QlikView;· il data warehouse vendite è stato agganciato al foglio di analisi di QlikView;

• Flusso principale degli eventi:

1. l’utente può visualizzare i fatti contenuti nel data warehouse [UC1];2. l’utente può aggregare le informazioni in base alle diverse dimensioni,

combinandole anche tra di loro [UC2];

• PostCondizione: QlikView mostra le informazioni che l’utente desidera.

Caso d’uso UC1: Visualizza Fatti

Individuato in Figura 3.3

Figura 3.3: UC1 - Visualizza Fatti


• Scopo e descrizione: l’utente vuole visualizzare i fatti presenti nel datawarehouse e i dati a loro relativi;


• Precondizione: L’utente sta visualizzando il tab con la scelta di quale partico-lare fatto vuole visualizzare;


1. l’utente può visualizzare gli ordini aperti [UC1.1] ovvero gli ordini che nonsono ancora stati evasi (parzialmente o totalmente);

2. l’utente può visualizzare le bolle aperte [UC1.2] ovvero le bolle che non sonoancora state evase (parzialmente o totalmente);

3. l’utente può visualizzare le fatture emesse [UC1.3];4. l’utente può visualizzare le note di credito emesse [UC1.4].

• PostCondizione: il sistema ha mostrato all’utente il fatto che l’utente ha sceltodi visualizzare.

Caso d’uso UC2: Aggregare in base alle dimensioni

Individuato in Figura 3.4.

Figura 3.4: UC2 - Aggregare in base alle dimensioni



• Scopo e descrizione: l’utente vuole visualizzare i fatti presenti nel datawarehouse e i dati a loro relativi;

• Precondizione: L’utente sta visualizzando il tab con la scelta di quale partico-lare fatto vuole visualizzare;


1. l’utente può aggregare le informazioni per asse geografico [UC2.1];2. l’utente può aggregare le informazioni per asse temporale [UC2.2];3. l’utente può aggregare le informazioni per asse prodotto [UC2.3];4. l’utente può aggregare le informazioni per asse acquisto [UC2.4];5. l’utente può aggregare le informazioni per asse soggetti [UC2.5];6. l’utente può aggregare le informazioni per asse documento [UC2.6];7. l’utente può combinare assieme due o più casi d’uso appena descritti.

• PostCondizione: il sistema ha mostrato all’utente le informazioni aggregate inbase all’asse desiderato.

3.2.2 RequistiIn questa sezione verranno elencati i requisiti individuati che il sistema da realizzaredovrà soddisfare.In particolare i requisiti di qualità sono da considerarsi legati principalmente al progettodi stage.Ogni tabella contiene due colonne che indicano, per ogni requisito, i seguenti attributi:

• Requisito: codice identificativo univoco del requisito;

• Descrizione: breve descrizione del requisito.

I requisiti sono identificati univocamente tramite la seguente codifica:

R[argomento][tipo][importanza]

• argomento può assumere i seguenti valori:

· FM: requisito per i fatti relativo a misure;· FF: requisito proprio dei fatti;· FD: requisito per i fatti relativo a dimensioni;· DG: requisito dimensione per l’asse geografico;· DS: requisito dimensione per l’asse soggetti;· DP: requisito dimensione per l’asse prodotto;· DA: requisito dimensione per l’asse acquisto;· DD: requisito dimensione per l’asse documento;· DT: requisito dimensione per l’asse temporale.


• tipo può assumere i seguenti valori:

· F: requisito funzionale;· V: requisito di vincolo;· Q: requisito di qualità.

• importanza può assumere i seguenti valori:

· M: requisito “Must”, obbligatorio;· D: requisito desiderabile;· O: requisito opzionale.

3.2.3 Tabelle dei requisitiRequisiti Funzionali

I requisiti funzionali individuati sono descritti in Tabella 3.1.

Requisito DescrizioneRFF01FM Il sistema deve poter considerare le righe degli ordini

aperti per la quantità non ancora evasaRFF02FM Il sistema deve poter considerare le righe di fatturaRFF03FM Il sistema deve poter considerare le righe delle bolle

per la quantità non ancora evasaRFF04FM Il sistema deve poter considerare le righe di note di

credito derivanti da fattureRFF05FM il sistema deve poter considerare le righe di note di

credito derivanti da ordiniRFF06FM Il sistema deve poter considerare le righe di note di

credito derivanti da bolleRFF07FM Il sistema deve poter calcolare il valore di listino della

rigaRFF08FM Il sistema deve poter memorizzare il numero del

documento in cui è contenuta la rigaRFF09FM Il sistema deve poter memorizzare il numero di linea

del documento cui si riferisce la rigaRFD10FM Il sistema deve poter memorizzare il tipo di

documento cui si riferisce la rigaRFD11FM Il sistema deve poter memorizzare la data del

documento in cui è contenuta la rigaRFD12FM Il sistema deve poter memorizzare l’articolo oggetto

della rigaRFD13FM Il sistema deve poter memorizzare il cliente di

consegna della riga, qualora fosse presenteRFD14FM Il sistema deve poter memorizzare il cliente di

fatturazione della riga, qualora fosse presenteRFD15FM Il sistema deve poter memorizzare il canale di vendita

per la rigaRFD16FM Il sistema deve poter memorizzare il gruppo di

acquisto per la riga


RFD17FM Il sistema deve poter memorizzare l’insegna diacquisto per la riga

RFD18FM Il sistema deve poter memorizzare la centrale diacquisto per la riga

RFD19FM Il sistema deve poter memorizzare il centro didistribuzione per la riga

RFM20FM Il sistema deve poter memorizzare la quantità (diprodotto) della riga

RFM21FM Il sistema deve poter memorizzare, qualora fossepossibile, la quantità in KG della riga

RFM22FM Il sistema deve poter calcolare il costo standard dellariga

RFM23FM Il sistema deve poter calcolare il costo effettivo dellariga

RFM24FM Se il fatto è una riga di fattura, il sistema deve potercalcolare la provvigione spettante al possibile agentecollegato al fatto

RFM25FM Se il fatto è una riga di fattura, il sistema deve po-ter calcolare la provvigione spettante al possibilecapoarea collegato al fatto.

RFM26FM Il sistema deve poter calcolare lo sconto canalederivante da CPG della riga

RFM27FM Il sistema deve poter calcolare lo sconto promozionalederivante da CPG della riga

RFM28FM Il sistema deve poter calcolare lo sconto aggiuntivoderivante da CPG della riga

RFM29FM Il sistema deve poter calcolare altri sconti derivantida CPG della riga

RFM30FM Il sistema deve poter calcolare lo sconto di testa dellariga

RFM31FM Il sistema deve poter calcolare il totale degli scontiapplicati alla riga

RFM32FM il sistema deve poter calcolare il valore lordo dellariga

RFM33FM Il sistema deve poter calcolare il valore netto dellariga

RFM34FM Il sistema deve poter calcolare il valore finale fatturatodella riga

RFM35FM Il sistema deve poter calcolare il margine standarddella riga

RFM36FM Il sistema deve poter calcolare il margine effettivodella riga

RDG37FM il sistema deve poter memorizzare le provinceRDG38FM il sistema deve poter memorizzare gli statiRDG39FM Il sistema deve poter memorizzare le aree NielsenRDG40FM Il sistema deve poter memorizzare le regioniRDG41FM Il sistema deve poter memorizzare la provincia e la

regione associata


RDG42FM Il sistema deve poter memorizzare la provincia e lostato associato

RDG43FM Il sistema deve poter memorizzare le aree geograficheRDG44FM Il sistema deve poter memorizzare se è Italia o EsteroRDG45FM Il sistema deve poter memorizzare la provincia e l’area

Nielsen associataRDG46FM Il sistema deve poter memorizzare l’area geografica

associando il flag Italia/EsteroRDG47FM Il sistema deve poter memorizzare lo stato e l’area

geografica associataRDG48FM Il sistema deve poter memorizzare il luogo di consegna

della merce tramite identificativo univocoRDS49FM Il sistema deve poter memorizzare le informazioni

legate al cliente di consegnaRDS50FM Il sistema deve poter memorizzare i gruppi com-

merciali a cui il cliente di consegna può essereassociato

RDS51FM Il sistema deve poter memorizzare le catego-rie economiche a cui il cliente di consegna puòappartenere

RDS52FM Il sistema deve poter memorizzare i tipi di mercato acui il cliente di consegna può essere associato

RDS53FM Il sistema deve poter memorizzare le informazionilegate al cliente di fatturazione

RDS54FM Il sistema deve poter memorizzare le informazionilegate all’agente di provvigione

RDS55FD Il sistema deve poter memorizzare le informazionilegate all’ispettore di provvigione

RDA56FM Il sistema deve poter memorizzare le informazionilegate al centro di distribuzione effettivo

RDA57FM Il sistema deve poter memorizzare le informazionilegate alla centrale di acquisto effettiva

RDA58FM Il sistema deve poter memorizzare le informazionilegate al gruppo di acquisto effettivo

RDA59FM Il sistema deve poter memorizzare le informazionilegate all’insegna di acquisto effettiva

RDD60FM Il sistema deve poter memorizzare i tipi di documentoche può gestire

RDT61FM Il sistema deve poter memorizzare i mesi dell’annoRDT62FM Il sistema deve poter memorizzare i semestri dell’annoRDT63FM Il sistema deve poter memorizzare i trimestri

dell’annoRDT64FM Il sistema deve poter memorizzare le date di cui si

riferiscono i fattiRDP65FM Il sistema deve poter memorizzare gli articoli

disponibiliRDP66FD Il sistema deve poter memorizzare il marchio degli

articoli


RDP67FD Il sistema deve poter memorizzare la destinazionedegli articoli

RDP68FM Il sistema deve poter memorizzare la linea diproduzione degli articoli

RDP69FM Il sistema deve poter memorizzare il gruppomerceologico degli articoli

RDP70FM Il sistema deve poter memorizzare la categoriamerceologica degli articoli

R71FM Il sistema deve poter valutare i fatti in base al tipodi documento

R72FM Il sistema deve poter valutare i fatti in base all’assegeografico

R73FM Il sistema deve poter valutare i fatti in base all’assetemporale

R74FM Il sistema deve poter valutare i fatti in base all’asseSoggetti

R75FM Il sistema deve poter valutare i fatti in base all’asseAcquisto

R76FM Il sistema deve poter valutare i fatti in base all’asseProdotto

R77FM Il sistema deve poter ricevere dalla base sorgente ifatti riguardanti un certo periodo di tempo

R78FM Il sistema deve poter valutare i fatti combinandoassieme dimensioni e misure

Tabella 3.1: Requisiti funzionali, data warehouse vendite

Requisiti di Vincolo

I requisiti di vincolo individuati sono descritti in Tabella 3.2.

Requisito DescrizioneR79VM Il sistema deve poter estrarre i dati da una base

sorgente SAP Business ONER80VM Il sistema deve gestire le funzionalità introdotte dalla

versione 9.0 di SAP Business ONE in particolare idocumenti di storno

R81VM Il sistema deve poter essere integrabile con QlikViewTabella 3.2: Requisiti di vincolo, data warehouse vendite


Requisiti di Qualità

I requisiti di qualità individuati sono descritti in Tabella 3.3.

Requisito DescrizioneR82QM Deve essere redatta la documentazione della struttura

del sistemaR83QM Deve essere redatta la documentazione degli script

ETLTabella 3.3: Requisiti di qualità, data warehouse vendite

Capitolo 4

Progettazione struttura deldata warehouse

Il seguente capitolo ha lo scopo di illustrare la progettazione della struttura del datawarehouse e le scelte progettuali che hanno portato ad ottenerla, partendo dal modelloconcettuale per arrivare alla progettazione logica con un grado di dettaglio maggiore.

4.1 DFM (Dimensional Fact Model)DFM è un formalismo grafico ad hoc pensato specificamente per supportare la mo-dellazione concettuale in progetti di data warehouse. È estremamente intuitivo e puòessere utilizzato sia da analisti che da utenti non tecnici. Aiuta a realizzare, in terminibrevi di lavoro, una chiara ed esaustiva rappresentazione di concetti multidimensionali,tipici in questo ambito. Può essere utilizzato già dai primi passi del ciclo di vita deldata warehouse per elaborare rapidamente un modello concettuale da condividere coni clienti.

4.1.1 Panoramica sul DFMÈ un modello concettuale grafico appositamente studiato per la progettazione multidi-mensionale, al fine di:

• fornire un sostegno efficace alla progettazione concettuale;

• rendere possibile la comunicazione tra progettisti e utenti finali con l’obiettivo diformalizzare le specifiche richieste;

• costruire una piattaforma stabile per la progettazione logica;

• fornire un chiaro ed espressivo documento di implementazione.

4.2 Fatti, Misure e DimensioniNella seguente sezione vengono individuati i dati necessari per rispondere ai requisitiindividuati al termine dell’analisi dei requisiti. In particolare vengono messi in luce ifatti che il data warehouse dovrà modellare, le misure di interesse per i fatti individuatie le dimensioni secondo cui poter effettuare analisi decisionali.

35

36 CAPITOLO 4. PROGETTAZIONE STRUTTURA DEL DATA WAREHOUSE

4.2.1 FattiI fatti che il data warehouse da realizzare doveva modellare e che per l’aziendarisultavano essere cruciali ai fini di analisi strategiche sono:

1. righe di fatture emesse;

2. righe di note di credito emesse;

3. righe di bolle aperte per la quantità non ancora evasa (ovvero che non ha originatofatture);

4. righe di ordini aperte, per la quantità non ancora evasa (ovvero che non haoriginato né bolle né fatture).

4.2.2 MisureLa Figura 4.1 mostra la tabella dei fatti popolata dalle misure individuate.

Figura 4.1: Misure individuate per rappresentare i fatti

Le misure che descrivono quantitativamente i fatti individuati e di particolare interesseper l’ambito vendite sono:

1. la quantità e la rispettiva quantità in KG (chilogrammi);

2. il prezzo di listino del prodotto;

4.2. FATTI, MISURE E DIMENSIONI 37

3. il valore dei diversi sconti previsti per il fatto in questione;

4. il prezzo netto del fatto in questione;

5. il valore dello sconto di testa del documento a cui appartiene il fatto;

6. il valore finale del fatto;

7. il valore delle provvigioni per agente e ispettore per i fatti che le prevedono;

8. il valore dei costi standard ed effettivo per il fatto;

9. i margini standard ed effettivo per il fatto.

4.2.3 Dimensioni PrimarieLa Figura 4.2 mostra la tabella dei fatti, con le relative misure, e le dimensioniindividuate.

Figura 4.2: Fatti con le dimensioni correlate

Le dimensioni primarie, che rappresentano una coordinata di analisi del fatto,individuate sono:

1. il tipo di documento da cui proviene il fatto;


2. la data in cui si è verificato il fatto;

3. il cliente di consegna e la sua provincia;

4. il cliente di fatturazione e la sua provincia;

5. il prodotto;

6. l’agente di provvigione;

7. l’ispettore di provvigione;

8. la centrale effettiva;

9. il gruppo effettivo;

10. il centro di distribuzione;

11. l’insegna effettiva;

12. il canale di vendita.

4.3 Gerarchie e dimensioni secondarieLe dimensioni primarie viste nella sezione precedente, sono direttamente collegateai fatti, e rappresentano le informazioni principali. Alcune di esse rappresentanoil livello base di una gerarchia che permette poi l’aggregazione delle misure; altreinvece sono legate alle dimensioni secondarie. Inoltre è possibile che alcune dimensioniprimarie/gerarchie interagiscano tra di loro. Vediamo ora nel dettaglio quanto appenaaccennato.

4.3.1 Gerarchia “Geografia”Rappresentata in Figura 4.3, è una gerarchia non direttamente collegata ai fatti, manon per questo meno importante, anzi, è una delle dimensioni più interessanti sottoil profilo dell’analisi decisionale in quanto permette di suddividere i fatti in base alterritorio, partendo da un livello informativo circoscritto per arrivare ad avere unavisuale mondiale.

Figura 4.3: Gerarchia legata alla geografia

4.3. GERARCHIE E DIMENSIONI SECONDARIE 39

Questa gerarchia è indirettamente collegata con i fatti attraverso le dimensioni primarie:

• cliente di consegna;

• cliente di fatturazione.

La granularità minima è la Provincia ed è possibile aggregare le informazioni (ovveroeseguire roll-up lungo la gerarchia) per:

• regione;

• area Nielsen1;

• stato;

• area geografica: le aree geografiche in cui suddividere gli stati è a discrezione epiacimento di chi ha interesse ad utilizzare il data warehouse.

fino al livello massimo di aggregazione Italia/Estero per valutare i fatti su baseNazionale/Internazionale.

4.3.2 Gerarchia “Tempo”Rappresentata in Figura 4.4, la gerarchia permette di navigare le informazioni in basealla data in cui si è verificato il fatto.

Figura 4.4: Gerarchia legata al tempo

La granularità minima è il giorno ed è possibile aggregare le informazioni(eseguendo roll-up lungo la gerarchia) per:

• mese;

• trimestre;

• semestre.

fino al livello massimo di aggregazione anno.1 Area geografica specifica in cui l’istituto di ricerca Nielsen suddivide un paese per effettuare

le rilevazioni e stime di mercato, copertura, quote di mercato, prezzi, e una serie di analisi per ilmarketing e la distribuzione.


4.3.3 Dimensioni secondarie: cliente di consegnaRappresentate in Figura 4.5, sono dimensioni legate esclusivamente al cliente di conse-gna.

Figura 4.5: Dimensioni secondarie per il cliente di consegna

Le dimensioni secondarie individuate per il cliente di consegna sono:

• zona in cui è localizzato;

• luogo di consegna della merce;

• categoria economica a cui appartiene;

• gruppo commerciale a cui appartiene;

• tipo di mercato a cui appartiene.

4.3.4 Dimensioni secondarie: prodottoRappresentate in Figura 4.6, sono dimensioni legate esclusivamente al prodotto.

Figura 4.6: Dimensioni secondarie per il prodotto

Le dimensioni secondarie individuate per il prodotto sono:

4.3. GERARCHIE E DIMENSIONI SECONDARIE 41

• destinazione;

• categoria merceologica a cui appartiene;

• gruppo merceologico a cui appartiene;

• linea di produzione;

• marchio.

4.3.5 Relazione tra dimensioni e gerarchieÈ possibile che alcune dimensioni primarie siano in relazione ad altre dimensioniprimarie o a gerarchie diverse. In particolare abbiamo:

1. cliente di fatturazione: in relazione con:

• gerarchia “Geografia”.

La relazione completa del cliente di consegna con la gerarchia “Geografia” èpresente in Figura 4.7.

Figura 4.7: Relazione del cliente di fatturazione con la gerarchia “Geografia ”

2. cliente di consegna: in relazione con:

• insegna;• gruppo;• centrale;• centri di distribuzione;• canale di vendita;• agente;


• ispettore;• gerarchia “Geografia”.

La relazione completa del cliente di consegna con le altre dimensioni primarie ele dimensioni secondarie a lui correlate è illustrata in Figura 4.8;

Figura 4.8: Relazione del cliente di consegna con dimensioni e gerarchia

4.4 Schema concettuale del data warehouse venditeDelineati: fatti, dimensioni e misure e aver individuato le relazioni tra le varie dimensionie gerarchie è stato possibile creare lo schema concettuale del data warehouse (Figura4.9) nel quale sono stati omessi gli attributi di ogni singola dimensione per mantenerelo schema chiaro ed evidenziare le informazioni cruciali e di rilievo.La tabella centrale, contiene le misure e gli attributi che identificano i fatti; rappresentadunque la tabella dei fatti.

4.5. PROGETTAZIONE LOGICA 43

Figura 4.9: schema concettuale del data warehouse vendite

4.5 Progettazione logicaIn questa sezione vengono illustrate le scelte progettuali che hanno guidato la rea-lizzazione della struttura logica per il data warehouse vendite e verrà mostrato ilmodello logico creato successivamente, con l’indicazione dettagliata degli attributi di


ogni dimensione.

Precisazioni

In questa piccola sezione, riporto alcune “dialettiche” con loro significato che sarannopresenti a partire da questo punto del testo.

• con il termine “CPG” si fa riferimento all’add-on CpgOne;

• non si parla propriamente di dimensioni, ma di assi: hanno un significato piùampio delle vere e proprie dimensioni e identificano un concetto astratto secondoil quale sono state suddivise le tabelle: non è detto dunque che alcune dimensionisecondarie appartengano allo stesso asse della dimensione primaria. Per semplicitàvengono di seguito identificati i vari assi e dimensioni che comprende.

· Asse Geografico: comprende tutta la gerarchia “Geografia ”e le dimensionisecondarie: zone e luogo di consegna del cliente di consegna;

· Asse Temporale: comprende tutta la gerarchia “Tempo”;· Asse Documento: comprende la sola dimensione primaria tipo di docu-mento;

· Asse Articolo: comprende la dimensione articolo e sue dimensioni secon-darie: destinazione, marchio, gruppo merceologico, categoria merceologica,linea di produzione;

· Asse Acquisto: comprende le dimensioni primarie: gruppo, insegna, canaledi vendita, centrale e centri di distribuzione;

· Asse Soggetti: comprende le dimensioni primarie: cliente di fatturazione,cliente di consegna, agente, ispettore, e le dimensioni secondarie collegateal cliente di consegna: tipo di mercato, gruppo commerciale e categoriaeconomica.

• il termine “DWH” è abbreviazione di data warehouse.

4.5.1 Scelte ProgettualiVengono di seguito descritte e motivate alcune scelte progettuali non sempre presentiin un data warehouse, ma che caratterizzano quanto da me realizzato.

Convenzioni: nomenclatura tabelle e campi dati

Il criterio con il quale sono stati scelti i nomi per tabelle e campi dati preferisce lacomprensione del significato alla brevità del nome. Questo per favorire una futuramanutenzione del codice da parte di persone diverse dallo sviluppatore iniziale.

• Nomenclatura tabelleOgni tabella che compone la struttura del data warehouse viene identificata conil suffisso:

· DWH_d_ se è una dimensione;· DWH_f_ se è la tabella dei fatti;· DWH_ se la tabella è di utilità del data warehouse.


seguito dal nome della tabella.

• Nomenclatura campi datiI nomi dei campi dati rispecchiano il seguente modello:

· c_nome identifica il campo come un codice; utilizzato principalmente perle chiavi primarie e per quei campi che sono chiavi esterne e dunque cheriferiscono chiavi primarie di altre tabelle;

· d_nome identifica il campo come descrizione; utilizzato principalmente perla descrizione del campo chiave e contiene dunque il valore associato allachiave. Per le tabelle che identificano le dimensioni, questo campo saràdi utilità con l’integrazione del data warehouse con QlikView in quantopermetterà all’utente di navigare facendo affidamento su nomi comprensibilie di facile intuizione rispetto a un codice identificativo;

· va_nome identifica la misura di valore attuale;· vs_nome identifica la misura di valore sconto;· vp_nome identifica la misura di valore provvigione;· vm_nome identifica la misura di valore margine;· v_nome identifica il valore;· nome identifica solitamente un valore, una misura, che non ha una strutturao un significato particolare.

No duplicazione di dimensioni

Innanzitutto, si è optato per non duplicare le dimensioni legate a più dimensioni o adimensione e fatti questo per non avere ridondanza di tabelle uguali anche se l’assenzadi ridondanza per un data warehouse non è base fondamentale per il suo funzionamentocorretto. In particolare, le tabelle “condivise” sono:

• quelle che rappresentano la gerarchia “Geografia”;

• quelle per l’agente e per l’ispettore;

• quelle dell’asse acquisto.

Tabella dei parametri

La struttura del DWH realizzata, presenta una tabella DWH_parametri nella qualesono stati inseriti alcuni parametri che potrebbero essere cruciali sia in termini diefficienza sia in termini di automatizzazione di alcune operazioni.

Si sono al momento identificati i seguenti parametri:

• Listino prezzi: questo parametro serve ad associare di default un listino prezziall’articolo; utile se associato alla distinta del prodotto non è presente un listino;

• CPG: questo parametro va ad indicare se il database sorgente utilizza anchel’add-on CPG o meno. Questo fa sì che, in mancanza della parte CPG, nonvengano eseguite istruzioni che ricadono in tabelle e campi dati di questo add-onevitando dunque possibili errori di mancanza di tabelle e campi dati, fornendoun valore alternativo.


Sarebbe però più corretto parlare di considerazione della parte CPG, in quanto,si potrebbe offrire la possibilità di non considerare CPG (anche se presente) adiscrezione del cliente che utilizzerà poi il DWH realizzato.I valori previsti per questo parametro sono:

· 0: non è previsto il CPG/non si considera la parte CPG;· 1: si vuole considerare CPG.

• Periodo non consolidato: questo parametro rappresenta la data dalla qualerigenerare i dati contenuti nella tabella dei fatti del DWH. Questa scelta è statafatta principalmente per una maggiore efficienza: la rigenerazione totale dellastruttura del DWH e del suo contenuto ogni volta che si vuole aggiornare ilcontenuto, ha un peso non poco indifferente sull’efficienza del processo in presenzadi database con dimensione elevata. Una volta che i dati di un determinatoperiodo vengono consolidati, e dunque non più modificabili, non ha senso andarea toccarli nuovamente anche perché, ad un certo punto della vita del database,sarà maggiore la quantità di dati consolidati rispetto a quelli del periodo ancoraaperto, e questo porterebbe un maggiore overhead, per lo più inutile;

• Inizio caricamento: questo parametro rappresenta la data dalla quale si vuolepopolare il data warehouse. Non è detto che si è interessati a voler i dati a partiredalla nascita del database sorgente;

• Database sorgente: Questo parametro rappresenta il database sorgente dalquale il DWH dovrà estrarre i dati necessari. Viene inizializzato dallo script dicreazione e utilizzato successivamente per indicare quale database usare. Questoper evitare che l’utilizzatore degli script debba modificare a mano il valore inogni script.

4.5.2 Schema logico del data warehouse venditeLa Figura 4.10 rappresenta lo schema logico del data warehouse vendite.


Figura 4.10: schema logico del data warehouse vendite


4.5.3 Tabelle del data warehouse venditeIn questa sezione vengono riportate le tabelle, suddivise per asse, del data warehouseper mettere in luce i campi dati di ognuna di esse con il relativo tipo.Viene tralasciata la descrizione testuale di ogni tabella e dei relativi campi dati inquesto capitolo in quanto molto verbosa, ma trova spazio in Appendice A.

Asse Geografico

Per l’asse geografico, oltre alle tabelle che rappresentano le dimensioni precedente-mente individuate che appartengono a quest’asse, sono state create alcune tabelle cherappresentano l’associazione tra due dimensioni. In particolare abbiamo:

• associazione tra provincia e regione;

• associazione tra provincia e area Nielsen;

• associazione tra regione e stato;

• associazione tra stato e area geografica;

• associazione tra area geografica e Italia/Estero.

In Figura 4.11 si possono vedere le tabelle e gli attributi che ne rappresentano le istanze.

Figura 4.11: Tabelle del data warehouse per l’asse geografico


Asse Temporale

Per l’asse geografico, sono state create le tabelle che rispecchiano le dimensioni diquest’asse. Le tabelle e relativi campi dati, sono contenute in Figura 4.12.

Figura 4.12: Tabelle del data warehouse per l’asse temporale

Asse Soggetti

Per l’asse soggetti, sono state create le tabelle che rispecchiano le dimensioni diquest’asse. Le tabelle e relativi campi dati, sono contenute in Figura 4.13.

Figura 4.13: Tabelle del data warehouse per l’asse soggetti


Asse Acquisto

Per l’asse acquisto, sono state create le tabelle che rispecchiano le dimensioni diquest’asse. Le tabelle e relativi campi dati, sono contenute in Figura 4.14.

Figura 4.14: Tabelle del data warehouse per l’asse acquisto

Asse Prodotto

Per l’asse prodotto, sono state create le tabelle che rispecchiano le dimensioni diquest’asse. Le tabelle e relativi campi dati, sono contenute in Figura 4.15.

Figura 4.15: Tabelle del data warehouse per l’asse prodotto


Asse Documento

Per l’asse documento, è stata creata la tabella che rispecchia la dimensione di quest’asse.La tabella e relativi campi dati, sono contenute in Figura 4.16.

Figura 4.16: Tabella del data warehouse per l’asse documento

Parametri

Per i parametri è stata creata una specifica tabella presente in Figura 4.17 con i relativicampi dati.

Figura 4.17: Tabella per i parametri del data warehouse vendite

Tabella dei fatti

Per i fatti, è stata creata una tabella specifica contenente le misure quantitative pervalutare i fatti, le dimensioni primarie e alcuni campi dati propri del fatto. La Figura4.18 mostra gli attributi della tabella dei fatti. In particolare i campi dati più importantipropri del fatto sono:

• numero del documento a cui appartiene;

• numero di riga che rappresenta all’interno del documento;

• tipo di riga che mi da informazioni relative alla tipologia della fonte che hascaturito il fatto.

I primi due assieme al tipo di documento (dimensione primaria per il fatto) identificanounivocamente ogni fatto.


Figura 4.18: Tabella dei fatti del data warehouse vendite

Capitolo 5

Implementazione dellastruttura e script ETL

Il seguente capitolo ha lo scopo di esporre il passo successivo alla progettazione deldata warehouse, in particolare: l’organizzazione del codice per la creazione del datawarehouse e le scelte implementative per la realizzazione degli script ETL.Vedremo dunque:

1. Creazione della struttura del data warehouse;

2. Scelte implementative per gli script ETL:

• Organizzazione del codice;• Estrazione e caricamento dei dati.

5.1 PremesseIl data warehouse nella realtà è un sistema esterno, staccato dalla base transazionalesorgente dal quale vengono recuperate le informazioni. Con il tutor aziendale è statodeciso, per semplicità, di realizzare il data warehouse internamente al database sorgente.Questo porta ad avere tabelle, funzioni e store procedure proprie del data warehouseassieme a quelle del sistema sorgente. Per poter individuare facilmente gli elementipropri del data warehouse si sono utilizzate delle convenzioni sulle nomenclature.Per quanto riguarda le tabelle, la nomenclatura segue le convenzioni illustrate prece-dentemente nella Sezione 4.5.1.

Convenzioni: nomenclatura funzioni e store procedure

• Ogni funzione del data warehouse deve essere identificata con la seguente sintassi:

[dbo].F_DWH_NOMEFUNZIONE

dove NOMEFUNZIONE utilizza il carattere maiuscolo e nessun carattere dipunteggiatura qualora il nome fosse composto da più parole (es: COUNTDAY);

53

54 CAPITOLO 5. IMPLEMENTAZIONE DELLA STRUTTURA E SCRIPT ETL

• Ogni store procedure del data warehouse deve essere identificata con la seguentesintassi:

[dbo].SP_DWH_NOMESTOREPRO

dove NOMESTOREPRO utilizza il carattere maiuscolo e nessun carattere dipunteggiatura qualora il nome fosse composto da più parole (es: NORMALIZ-ZAPROVINCIA).

Integrità referenziale

Per far si di accedere a tutti i valori legati ai fatti è necessario mettere in relazione i fatticon le relative dimensioni. Non sempre però, le dimensioni possono essere valorizzateall’interno di un fatto: per esempio, non è detto che sia sempre individuato il canaledi vendita utilizzato. Questo porterebbe a valorizzare a NULL il valore di quel campo.Mettendo poi in relazione la tabella dei fatti con la tabella dei canali (INNER JOIN) ilrecord relativo a quel fatto non verrà considerato in quanto non presente una chiaveNULL all’interno della tabella dei canali.Si è dunque deciso di inserire all’interno di ogni dimensione una riga di valori indefiniti:

• -1 come chiave primaria o come valore per foreing key;

• Non Definito come valore di campi NOT NULL;

• N come valore di campi NOT NULL la cui dimensione è piccola (es varchar(1)),qualora fosse presente;

• 0/0.0 come valore di campi NOT NULL di tipo numerico.

5.2 Script per la creazione della strutturaUna volta progettata la struttura che il data warehouse avrebbe dovuto avere (quinditabelle, campi dati e relazione tra le varie tabelle), ho innanzitutto realizzato lo scriptper la creazione delle tabelle. La struttura del data warehouse presenta un numeroconsiderevole di tabelle e molte di esse, con un numero importante di campi dati.Questo ha portato a non scrivere direttamente il codice, ma di avvalersi dell’interfacciauser-friendly messa a disposizione da SQL Server Management Studio: in modo sem-plice e veloce dà la possibilità di creare le tabelle e relativi campi dati con eventualirelazioni.

Inoltre dà l’opportunità, selezionando la tabella di interesse, di generare il codiceT-SQL per la tabella stessa: creazione, eliminazione, eliminazione e creazione, modifica.

Ho dunque creato tutte le tabelle con l’interfaccia e successivamente, per ognunadi esse, ho generato il codice “drop e create table” anziché “create table” in modo darendere più semplici le operazioni di rigenerazione in fase di test. Il codice ottenutoè stato composto in un unico script: quello per la creazione della struttura del datawarehouse. È stato poi incapsulato all’interno di una procedura per la struttura dataagli script ETL e per automatizzare il più possibile le operazioni dell’utente.

5.3. ORGANIZZAZIONE DEL CODICE 55

5.3 Organizzazione del codiceIl passo successivo alla creazione della struttura del data warehouse riguardava ilfulcro centrale del progetto: la realizzazione dei meccanismi di ETL per il recupero, latrasformazione e il caricamento dei dati, ma prima ancora, decidere quali fossero glistep da fare per aggiornare il data warehouse.

Essendo il sistema ERP sorgente già popolato, era necessario inserire anche i da-ti già presenti oltre al popolamento successivo per l’aggiunta di nuovi fatti.

Gli step che ho realizzato, una volta creata la struttura, sono stati i seguenti:

1. popolamento delle tabelle con valori predefiniti: questo riguardava principalmentemolte dimensioni dell’asse geografico, in quanto valori “statici” e che non avreb-bero mutato la loro natura. Porta dunque a meno interrogazioni ed estrazionidal sorgente;

2. inserimento dei dati presenti nel database sorgente fino al momento della creazionedel data warehouse, parametrizzando la data dal quale deve partire il caricamento;

3. rigenerazione dei dati contenuti nel data warehouse del periodo non consolidato.

Si può notare come gli ultimi 2 step si somiglino molto, differendo solo di alcuneparticolarità. Da qui è nata l’esigenza di realizzare un codice racchiuso il più possibilein store procedure eseguibili all’occorrenza da qualsiasi parte del codice. Questo portainnanzitutto ad evitare ripetizione di codice comune a entrambi gli ultimi 2 step ead avere un unico punto di accesso per le modifiche del codice, qualora fossero necessarie.

Come detto dalla teoria riguardante il data warehouse, l’aggiornamento dei datiè fatto “offline” ovvero al di fuori dell’orario operativo dei sistemi sorgenti (solitamentela notte). Per il terzo step è stato dunque realizzato un job il cui unico passo è appuntoquello di aggiornare il data warehouse.

Dovendo essere presenti dentro al sistema store procedure e funzioni per poter poi essereeseguite e non avendo trovato una possibile soluzione per far sì che uno script possaeseguire altri script .sql utilizzando SQL Server Management Studio, l’intero codicerealizzato è nello script principale. Questo porta però a trascurare completamentel’information hiding e la possibilità che l’utente possa modificare pezzi di codice equindi introdurre errori e di conseguenza malfunzionamenti del codice.Lo script principale dunque avrà il compito di:

• far impostare all’utente i valori dei parametri previsti per il data warehouse;

• aggiungere alla struttura del data warehouse funzioni e procedure contenenti ilcorpo del codice ETL;

• creare le tabelle del data warehouse;

• inserire i dati del database sorgente presenti al momento della creazione del datawarehouse;

• creare il job per l’aggiornamento del data warehouse.


Inoltre è stato creato uno script aggiuntivo per permettere all’utente di modificarealcuni dei parametri previsti per il data warehouse.

Ricapitolando dunque il codice è organizzato nel seguente modo:

• ogni macro operazione è stata racchiusa all’interno di store procedure, cheall’occorrenza viene eseguita;

• l’aggiornamento dei dati è fatto tramite un job;

• lo script generale contiene l’intero codice e ha il compito di aggiungere quantonecessario per il funzionamento del data warehouse e di popolarlo con i datipresenti fino al momento della creazione del data warehouse;

• uno script per la modifica dei parametri.

5.4 Recupero e caricamento dei datiPer quanto riguarda il reperimento dei dati e il successivo caricamento nel datawarehouse (qualora necessario, previa trasformazione di essi) si è deciso di utilizzare 2“tecniche” diverse:

• mediante la struttura dati cursor;

• mediante la semplice SELECT preceduta da INSERT INTO.

Utilizziamo la tecnica più semplice quando i dati da inserire nel data warehouse nonnecessitano di trasformazioni, ovvero l’operazione è un semplice recupero di valori daalcuni campi dati del database sorgente. Questo metodo è il più efficiente rispettoall’altra tecnica utilizzata.

Utilizziamo la struttura dati cursor quando necessitiamo di trasformare qualche valorerecuperato dal sorgente in base ad alcune regole che si sono stabilite sulla strutturache devono avere certi valori. Ma la scelta di questa struttura ha fondamento su unanecessità ancora più forte: evitare la ripetizione pesante di codice. Questo avvienequando dobbiamo alimentare la tabella dei fatti: i dati da recuperare sono sempregli stessi per ogni tipologia diversa di fatto, cambiano solamente le tabelle da cuiestrapolare i dati. Questo porta a un codice più snello e riduce l’introduzione di erroriqualora si dovesse modificare/aggiungere codice anche se a livello di performance èmeno efficiente. Trattandosi di un data warehouse e non di una base dati operativa, cisi può permettere di sacrificare l’efficienza (per salvaguardare chiarezza e compattezzadel codice evitando ripetizione di codice) in quanto non è un dettaglio cruciale.

5.4.1 ETL con il cursoreIl diagramma di attività presente in Figura 5.1 illustra il comportamento della parteETL con l’utilizzo del cursore. La seguente procedura è rispettata da tutti i cursoriutilizzati.

Descrizione testuale

L’ETL con l’uso del cursore prevede:

5.4. RECUPERO E CARICAMENTO DEI DATI 57

1. la dichiarazione delle variabili nelle quali verranno inserite le informazioniselezionate dal cursore;

2. la dichiarazione del cursore: ovvero la selezione delle informazioni necessarie (E);

3. l’apertura del cursore;

4. per ogni riga di informazioni correnti vengono dichiarate ulteriori variabili; ven-gono eseguite le opportune trasformazioni (T) e infine inserite dentro al datawarehouse (L);

5. una volta terminato il processo al passo precedente, viene chiuso il cursore esuccessivamente deallocato.

Figura 5.1: Diagramma di Attività: ETL con l’uso del cursore


Di seguito viene proposto un esempio di codice che implementa ETL con l’utilizzodel cursore, in particolare viene preso un caso semplice, ovvero quello riguardante ilcliente di consegna. Alcune sue informazioni riguardano la parte CPG: si potrà anchevedere la gestione dei due casi distinti./* *** DICHIARAZIONE COSTATI E VARIABILI *** */DECLARE @CUNDEF nvarchar (3) = ’−1 ’ ;DECLARE @DUNDEF nvarchar (12)= ’Non De f i n i t o ’ ;DECLARE @CPG nvarchar (100)= ( SELECT p. v_parametro FROM

DWH_parametri p WHERE p. c_parametro = ’CPG’ );DECLARE @INS nvarchar (12)= " 30 " ;DECLARE @CD nvarchar (12)= " 40 " ;DECLARE @GRU nvarchar (12)= " 20 " ;DECLARE @CEN nvarchar (12)= " 10 " ;

DECLARE @cod nvarchar (15); -- codice CLIENTEDECLARE @nome nvarchar (100); -- nome clienteDECLARE @addr nvarchar (100); -- indirizzo a cui spedireDECLARE @prov nvarchar (100); -- provincia del clienteDECLARE @luogo nvarchar (6); -- codice del luogo di consegnaDECLARE @agenteAnagr nvarchar (32); -- codice agente anagraficoDECLARE @insegnaA nvarchar (12); -- insegna anagraficaDECLARE @centroDisA nvarchar (12); -- centro di distribuzione

anagraficoDECLARE @gruppoA nvarchar (12); -- gruppo anagraficoDECLARE @centraleA nvarchar (12); -- centrale anagraficaDECLARE @country nvarchar (3); -- stato del clienteDECLARE @grpC int; -- gruppo commercialeDECLARE @catE int; -- categoria economicaDECLARE @catS nvarchar (12); -- categoria di sconto , costruito a

partire da @discountDECLARE @discount float; -- campo sap per lo scontoDECLARE @catP nvarchar (30); -- categoria provvigionaleDECLARE @canale nvarchar (30); -- canaleDECLARE @tipo nvarchar (30); -- tipo di mercatoDECLARE @zona nvarchar (32); -- zona del cliente di consegna

/* **** ESTRAZIONE **** */IF @CPG= ’ 1 ’ -- devo considerare CPGBEGIN

DECLARE dest_cursor CURSOR FORSELECT DISTINCTcl.CardCode ,cl. County ,cl.mailAddres ,cl.cardName ,cl.Country ,COALESCE (cl.slpCode , @CUNDEF ),COALESCE (ins.Code , @CUNDEF ),COALESCE (cd.Code , @CUNDEF ),COALESCE (gru.Code , @CUNDEF ),COALESCE (cen.Code , @CUNDEF ),COALESCE (cl.GroupCode , @CUNDEF ),COALESCE (cl.IndustryC , @CUNDEF ),cl.discount ,

5.4. RECUPERO E CARICAMENTO DEI DATI 59

CASE WHEN LEN(cl. U_O01_Canale )=2 THEN cl. U_O01_Canale ELSE@CUNDEF END ,

CASE WHEN cl. U_O01_TipMerc = ’ ’ THEN @CUNDEF ELSE COALESCE (cl.U_O01_TipMerc , @CUNDEF ) END ,

COALESCE (cl.Territory , @CUNDEF )FROM [dbo ]. OCRD clLEFT OUTER JOIN [dbo ]. OSLP os ON cl. slpCode =os. slpCodeLEFT OUTER JOIN [dbo ].[ @O01_CPGTREE ] ins ON (ins. U_O01_CPGL =

@INS AND cl. CardCode = ins. U_O01_CPGB AND GETDATE() BETWEENISNULL (ins.U_O01_CPGD , ’ 19000101 ’ ) AND ISNULL (ins.

U_O01_CPGA , ’ 29000101 ’ ))LEFT OUTER JOIN [dbo ].[ @O01_CPGTREE ] cd ON (cd. U_O01_CPGL =

@CD AND cl. CardCode = cd. U_O01_CPGB AND GETDATE() BETWEENISNULL (cd. U_O01_CPGD , ’ 19000101 ’ ) AND ISNULL (cd.

U_O01_CPGA , ’ 29000101 ’ ))LEFT OUTER JOIN [dbo ].[ @O01_CPGTREE ] gru ON (gru. U_O01_CPGL =

@GRU AND cl. CardCode = gru. U_O01_CPGB AND GETDATE() BETWEENISNULL (gru.U_O01_CPGD , ’ 19000101 ’ ) AND ISNULL (gru.

U_O01_CPGA , ’ 29000101 ’ ))LEFT OUTER JOIN [dbo ].[ @O01_CPGTREE ] cen ON (cen. U_O01_CPGL =

@CEN AND cl. CardCode = cen. U_O01_CPGB AND GETDATE() BETWEENISNULL (cen.U_O01_CPGD , ’ 19000101 ’ ) AND ISNULL (cen.

U_O01_CPGA , ’ 29000101 ’ ))WHERE cl. CardType = ’C ’ ;

ENDELSE -- non devo considerare il cpgBEGIN

DECLARE dest_cursor CURSOR FORSELECT DISTINCTcl.CardCode ,cl. County ,cl.mailAddres ,cl.cardName ,cl.Country ,COALESCE (cl.slpCode , @CUNDEF ),@CUNDEF ,@CUNDEF ,@CUNDEF ,@CUNDEF ,COALESCE (cl.GroupCode , @CUNDEF ),COALESCE (cl.IndustryC , @CUNDEF ),COALESCE (cl.Discount ,0.0) ,@CUNDEF , @CUNDEF ,COALESCE (cl.Territory , @CUNDEF )FROM [dbo ]. OCRD clLEFT OUTER JOIN [dbo ]. OSLP os ON cl. slpCode =os. slpCodeWHERE cl. CardType = ’C ’ ;

END

/* **** APERTURA DEL CURSORE **** */OPEN dest_cursor ;FETCH NEXT FROM dest_cursorINTO @cod , @prov , @addr , @nome , @country , @agenteAnagr , @insegnaA

, @centroDisA , @gruppoA , @centraleA , @grpC , @catE , @discount ,@canale , @tipo , @zona;


/* **** ITERATIVE **** */WHILE @@FETCH_STATUS = 0BEGIN/* **** TRASFORMAZIONE **** */

-- IMPOSTO IL LUOGO DI CONSEGNA --SET @luogo = COALESCE (( SELECT top 1 l. c_luogo_con FROM [dbo ].

DWH_d_luogocon l WHERE l. d_luogo_con LIKE @addr + ’%’ ),@CUNDEF );

-- IMPOSTO LA PROVINCIA invocando la store pro che normalizzala provincia --

EXEC [dbo ]. SP_DWH_NORMALIZZAPROVINCIA @pr=@prov OUTPUT ,@provincia = @prov , @nazione = @country ;

-- IMPOSTO IL NOME del cliente di consegna --SET @nome= COALESCE (@nome , @DUNDEF );

-- IMPOSTO L’ AGENTE E IL RELATIVO ISPETTORE --DECLARE @nomeAgA nvarchar (50)= @DUNDEF ;DECLARE @codIsA nvarchar (32)= @CUNDEF ;DECLARE @nomeIsA nvarchar (20)= @DUNDEF ;IF @agenteAnagr <> @CUNDEFBEGIN

SELECT @nomeAgA =age. slpName FROM [dbo ]. OSLP age WHERE age.SlpCode = @agenteAnagr ;

-- ISPETTORE NON IMPLEMENTATOENDSET @catS= ’C ’ + replace (cast( replace (rtrim( replace ( replace (

rtrim( replace ( coalesce (@discount ,0) , ’ 0 ’ , ’ ’ )), ’ ’ , ’ 0 ’ ), ’ . ’ , ’’ )), ’ ’ , ’ . ’ ) as nvarchar (12)), ’ . ’ , ’ , ’ );

/* **** CARICAMENTO (LOAD) *** */INSERT INTO [dbo ]. DWH_d_cliconVALUES (@cod , @prov , @nome , @CUNDEF , @luogo , @centroDisA ,

@insegnaA , @gruppoA , @centraleA , @agenteAnagr , @nomeAgA ,@codIsA , @nomeIsA , @grpC ,@catE , @catS , @CUNDEF , @tipo ,@canale );

FETCH NEXT FROM dest_cursorINTO @cod , @prov , @addr , @nome , @country , @agenteAnagr , @insegnaA

, @centroDisA , @gruppoA , @centraleA , @grpC , @catE , @discount ,@canale , @tipo , @zona;

END/* **** CHIUSURA CURSORE **** */CLOSE dest_cursor ;

/* **** DEALLOCAZIONE CURSORE **** */DEALLOCATE dest_cursor ; �

Codice 5.1: Esempio di ETL con uso di cursore: Cliente di consegna

5.5. DESCRIZIONE DI MASSIMA DEGLI SCRIPT T-SQL 61

5.5 Descrizione di massima degli script T-SQLNella seguente sezione verranno descritte: store procedure e funzioni con indicazionedello scopo e del loro contenuto principale.

5.5.1 FunzioniPer il data warehouse è stata realizzata una sola funzione.

dbo .F_DWH_COUTDAY (@year smallint, @month smallint, @day int)

ritorna un intero che, passati anno mese e giorno, rappresenta l’ordinale del giorno apartire dal primo dell’anno considerando anche se l’anno è bisestile o meno.

5.5.2 Store Procedure FunzionaliLe seguenti store procedure racchiudono le operazioni cruciali per la realizzazione deldata warehouse.

[dbo].SP_DWH_CREASTRUTTURA

dbo .SP_DWH_CREASTRUTTURA

SCOPO: creare la struttura di base dal DWH ovvero definire le tabelle presenti con iloro campi dati e tipi ad eccezione della tabella [dbo].DWH_parametri.COMPORTAMENTO:- rimuove tutte le tabelle che compongono il DWH eventualmente presenti (questo persemplificare le manovre di rigenerazione dell’intero DWH);- definisce le tabelle, definendo per ognuna i campi dati che contiene, il loro tipo, lachiave primaria ed eventuali chiavi esterne.

[dbo].SP_DWH_VALORIPREDEFINITI

dbo .SP_DWH_VALORIPREDEFINITI

SCOPO: Ha il compito di inserire i valori statici all’interno delle tabelle delle dimensioni:

• dell’asse temporale([dbo].DWH_d_semestre, [dbo].DWH_d_trimestre, [dbo].DWH_d_mese);

• dell’asse geografico( [dbo].DWH_d_ itaest, [dbo].DWH_d_ regioni, [dbo].DWH_d_ province,[dbo].DWH_d_ nielsen, [dbo].DWH_d_ provarea, [dbo].DWH_d_ provreg,[dbo].DWH_ d_ regstato, [dbo].DWH_ d_ areegeo, [dbo].DWH_ d_ areaie,[dbo].DWH_d_ areastati);

• dell’asse documento ([dbo].DWH_d_tipodoc).

[dbo].SP_DWH_CARICADATI

dbo .SP_DWH_CARICADATI

SCOPO: popolare gran parte delle tabelle delle dimensioni prelevando i dati da unasorgente SAP Business ONE.COMPORTAMENTO: la procedura popola


• la tabella [dbo].DWH_d_clifatt;

• la tabella [dbo].DWH_d_ageprovv;

• la tabella [dbo].DWH_d_ispprovv;

• la tabella [dbo].DWH_d_marchio;

• la tabella [dbo].DWH_d_destinaz;

• la tabella [dbo].DWH_d_linprod;

• la tabella [dbo].DWH_d_catmerc;

• la tabella [dbo].DWH_d_grpmerc;

• la tabella [dbo].DWH_d_articoli;

• la tabella [dbo].DWH_d_luogocon.

[dbo].SP_DWH_CARICADATI2

dbo .SP_DWH_CARICADATI2

SCOPO: popolare le tabelle delle dimensioni rimanenti e la tabella dei fatti prelevandoi dati da una sorgente SAP Business ONE.COMPORTAMENTO: la procedura popola

• la tabella [dbo].DWH_d_gruppo;

• la tabella [dbo].DWH_d_centrale;

• la tabella [dbo].DWH_d_centridistribuzione;

• la tabella [dbo].DWH_d_insegna;

• la tabella [dbo].DWH_d_grpcomm;

• la tabella [dbo].DWH_d_catecon;

• la tabella [dbo].DWH_d_tipi;

• la tabella [dbo].DWH_d_canale;

• la tabella [dbo].DWH_d_clicon;

• la tabella [dbo].DWH_f_rows.

[dbo].SP_DWH_CARICANEXT

dbo .SP_DWH_CARICANEXT

SCOPO: popolare le tabelle del data warehouse con i dati prelevati dalla base datidi SAP Business ONE a partire da una certa data, prima della quale si consideraconsolidato il contenuto del data warehouse e non più modificabile.COMPORTAMENTO:

5.5. DESCRIZIONE DI MASSIMA DEGLI SCRIPT T-SQL 63

• per garantire migliore affidabilità dei dati, ed essere sicuri di non tralasciareeventuali modifiche, vengono rimosse dalla tabella dei fatti ([dbo].DWH_f_rows)tutte le righe il cui valore per il campo dati dt_doc non ricade nel periodo giàconsolidato, ma è successiva;

• opera sulla falsa riga dello script precedente, principalmente per la parte riguardan-te il caricamento dei fatti. Prima di inserire una nuova riga in [dbo].DWH_f_rowscontrolla se i campi dati che riferiscono una chiave esterna sono presenti comevalori all’interno della tabella associata (per integrità referenziale). Qualora nonfosse presente, occorre inserire un nuovo record nella tabella della dimensione inesame prendendo tutti i valori necessari in modo da soddisfare i vincoli presenti(soprattutto quelli di NOT NULL);

• controllati tutti i valori che riferiscono chiavi esterne viene inserito un nuovorecord nella tabella dei fatti, dopo aver calcolato i valori mancanti.

[dbo].SP_DWH_MODIFICAPARAMETRI

dbo .SP_DWH_MODIFICAPARAMETRI @fromDate nvarchar(100), @cpg nvar-char(100), @listino nvarchar(100)

SCOPO: modificare il campo v_parametro della tabella [dbo].DWH_parametri in baseal parametro e al campo c_parametroCOMPORTAMENTO: la procedura:

• per ogni parametro, controlla se il valore è nel range di valori accettati per lamodifica;

• apporta la modifica al campo v_parametro in relazione al parametro in esameriferendosi al campo c_parametro La procedura riceve i parametri:

· @fromDate che conterrà la data da cui parte il periodo non consolidatoovvero da quando rigenerare i dati contenuti nel data warehouse. Se NULL ominore della data precedente, viene lasciato quello precedente;

· @cpg che conterrà il flag di considerare CPG o meno; se viene passato unvalore diverso da 0 o 1 allora viene impostato a 0. Se NULL viene lasciatoquello precedente;

· @listino che conterrà il valore del listino di default, se NULL viene lasciatoquello precedente.

5.5.3 Store Procedure AusiliarieLe seguenti store procedure racchiudono delle operazioni presenti più volte all’internodi una stessa procedura e che possono essere comuni a più store procedure funzionali.Rendono così il codice delle store procedure chiamanti, più leggero ed evitano ripetizionedi codice.

SP_DWH_NORMALIZZAPROVINCIA

dbo .SP_DWH_NORMALIZZAPROVINCIA @pr nvarchar(100) OUTPUT , @pro-vincia nvarchar(100), @nazione nvarchar(3)


SCOPO: normalizzare la provincia in modo da soddisfare l’integrità referenziale versola tabella: [dbo].DWH_d_province.

La procedura riceve i parametri:

• @pr che conterrà la provincia normalizzata e risultato della procedura;

• @provincia che conterrà la provincia da normalizzare;

• @nazione che conterrà lo stato in cui si trova la provincia.

In caso di nazione estera la provincia vera e propria non viene considerata, e vienepresa come provincia il codice della nazione.Se la nazione è Italia, non è detto che sia presente la provincia o sia presente nelformato corretto. La procedura copre entrambi i casi e qualora non riuscisse a trovareuna provincia valida imposta la provincia di default ovvero IT/IT.

SP_DWH_CALCOLACOSTI

dbo .SP_DWH_CALCOLACOSTI @cod nvarchar(20), @list int, @quantity int,@list2 int, @Lprice float, @Leval float, @costoE float OUTPUT, @costoS floatOUTPUT

ha il compito di calcolare costi standard e costi effettivi per l’articolo ricevuto in baseal listino di default, alla distinta all’ultimo prezzo o all’ultima valutazione.La procedura riceve i parametri:

• @cod che rappresenta il codice dell’articolo;

• @list che rappresenta il listino prezzi

• @quantity che rappresenta la quantità di prodotto da moltiplicare per il costounitario;

• @list2;

• @Lprice che rappresenta l’ultimo prezzo applicato al prodotto;

• @Leval che rappresenta l’ultima valutazione del prezzo;

• @costoE OUTPUT in cui verrà messo il costo effettivo della quantità di prodottodi riferimento calcolato dalla store procedure;

• @costoS OUTPUT in cui verrà messo il costo standard per il prodotto diriferimento calcolato dalla store procedure.

SP_DWH_CALCOLAKG

dbo .SP_DWH_CALCOLAKG@unitM nvarchar(20), @qt float, @saleU nvarchar(100),@saleP float, @buyU nvarchar(100), @buyP float, @pesoKG float OUTPUT

SCOPO: calcoloare la quantità passata come parametro (qt)in KG.COMPORTAMENTO: va a guardare l’unità di misura utilizzata dall’azienda molti-plicando qualora utilizzasse le misure in “grammi”. Controlla se l’unità di misura in@unitM è uguale all’unità di misura di vendita o di acquisto allora utilizza tale pesoper il calcolo della quantità in KG.La procedura riceve i parametri:

5.6. “HOW TO USE” DEL DATA WAREHOUSE 65

• @unitM che rappresenta l’unità di misura indicata nel documento;

• @qt che rappresenta la quantità di prodotto;

• @saleU che rappresenta l’unità di misura di vendita del prodotto;

• @saleP che rappresenta il prezzo di vendita del prodotto;

• @buyU che rappresenta l’unità di misura di acquisto del prodotto;

• @buyP che rappresenta il prezzo di acquisto del prodotto;

• @pesoKG OUTPUT in cui verrà messo il peso in KG calcolato dalla storeprocedure.

SP_DWH_NORMALIZZASCONTI

dbo .SP_DWH_NORMALIZZASCONTI @CAUCANALE nvarchar(15), @CAUAGGnvarchar(15), @CAUPROM nvarchar(15), @CAUALTRI nvarchar(15), @from-Date datatime, @toDate datatime

ha il compito di normalizzare gli sconti e suddividerli in base alla loro origine ovvero:

• sconto canale;

• sconto promozionale;

• sconto aggiuntivo;

• altri sconti.

La procedura riceve i parametri:

• @CAUCANALE che rappresenta il codice causale per lo sconto prodotto dalcanale di vendita;

• @CAUAGG che rappresenta il codice causale per lo sconto aggiuntivo;

• @CAUPROM che rappresenta il codice causale per lo sconto promozionale;

• @CAUALTRI che rappresenta il codice causale per altri sconti;

• @fromDate che rappresenta la data da cui considerare gli sconti;

• @toDate che rappresenta la data fino a cui considerare gli sconti.

5.6 “How to use” del data warehouseLa struttura data al codice permette, all’utente utilizzatore degli script, di operareseguendo pochi semplici passi. Sono stati realizzati alcuni diagrammi di attività inparticolare:

• Creazione data warehouse rappresentato in Figura 5.2;

• Modifica dei parametri rappresentato in Figura 5.3;

• Aggiornamento data warehouse rappresentato in Figura 5.4;


Figura 5.2: Diagramma di Attività: step di creazione del data warehouse

Figura 5.3: Diagramma di Attività: step di modifica dei parametri

5.6. “HOW TO USE” DEL DATA WAREHOUSE 67

Figura 5.4: Diagramma di Attività: step di aggiornamento del data warehouse

Capitolo 6

Test di quadratura

Il seguente capitolo illustra l’attività di testing effettuata sugli script. Verranno elencatii tipi di test effettuati, alcuni test significativi e i risultati ottenuti.

Preambolo

Essendo il data warehouse una rielaborazione di dati quantitativi aziendali, il primocriterio di misurabilità del progetto è la congruenza tra i dati macro di un periodo nelgestionale con il data warehouse (ES.:valore complessivo di una misura analizzata nellediverse dimensioni a livello complessivo deve coincidere numericamente con l’analogototale del database di produzione dell’ERP).

Per poter dunque valutare il raggiungimento dell’obiettivo occorre testare gli scriptrealizzati e confrontare i risultati prodotti dal data warehouse con quelli contenuti neldatabase sorgente.

6.1 Database sorgenti testatiPer realizzare gli script ETL ho utilizzato principalmente come database sorgente quellodi “ABAFoods”1 fornitomi dal tutor per poter prendere coscienza delle dimensioni chepuò avere un database aziendale di medie dimensioni e per poter controllare passo passoche il contenuto estratto e trasformato rispecchiava la situazione contenuta nel sorgente.

Il database ricevuto era abbastanza significativo e completo per le mie necessità,ma era carente su alcune parti, e per poter realizzare un data warehouse il più possibilestandard per tutti i clienti, verso la fine dello sviluppo degli script mi sono statiforniti altri due database, di dimensioni maggiori del primo, dai quali ho estratto leinformazioni che mi mancavano per completare gli script.

Il tempo che mi rimaneva a disposizione per terminare la realizzazione degli script e peragganciare il data warehouse al foglio di QlikView non era molto, di conseguenza hooptato per testare gli script per il primo database sorgente, e per quello con dimensioniminori tra i due che mi sono stati forniti successivamente. Gli script sono stati dunquetestati sui seguenti databsase sorgenti:

1 Un cliente di Soluzioni Software.

69

70 CAPITOLO 6. TEST DI QUADRATURA

1. ABAFoods in modo completo e preciso;

2. ZIEL in modo meno completo rispetto ad ABAFoods infatti non sono statieseguiti tutti i test fatti sul primo.

6.2 Tipologie di testI test che si sono eseguiti, non sono molti, in quanto si è puntato a testare che i valoritotali coincidessero. Le tipologie di test sono elevate in quanto se si vuole essere pignolioccorrerebbe testare ogni possibile combinazione di dati e valori che potrebbe venirciin mente. I primi test che solitamente si eseguono, come detto, sono quelli di testare ivalori totali prodotti da entrambi i sistemi. In particolare i valori complessivi che hotestato sono:

• le quantità totali per documento; Per quanto riguarda le fatture sono state testateanche per cliente di fatturazione;

• il numero di righe per ogni diversa tipologia di fatto (righe di: fatture, ordini,note di credito, bolle);

• gli importi per righe di fatture e note di credito. Questo test è stato eseguitoesclusivamente su ABAFoods;

• per il solo data warehouse, il numero di righe della tabella dei fatti deve coinciderecon il numero di righe della tabella dei fatti in JOIN con tutte le dimensioni.

Di seguito vengono riportati alcuni frammenti di codice dei test. In particolare i testche vengono presentati sono:

• Test sull’importo finale per le righe di fattura;

• Test sulle quantità totali per documento di fattura;

• Test sul data warehouse: fatti in relazione con tutte le dimensioni.

---- TEST VALORE FINALE RIGHE FATTURA ----SELECT i.DocEntry , i.lineNum ,

CASE WHEN i. U_O01Oma = ’ 1 ’ THEN 0 ELSE i. LineTotal END AS SAP ,f. va_t_fattfin AS DWH ,ABS (( CASE WHEN i. U_O01Oma = ’ 1 ’ THEN 0

ELSE (ABS(i.LineTotal -(i. LineTotal *o. discPrcnt /100)))END)- ABS(f. va_t_fattfin )) AS D IF F

FROM [dbo ]. DWH_f_rows f INNER JOIN [dbo ]. INV1 i ON f. c_num_doc =i.DocEntry AND f. c_num_riga =i. LineNum

INNER JOIN [dbo ]. OINV o ON o. DocEntry =i. DocEntryWHERE f. c_tipo_doc = ’F ’ORDER BY D IF F DESC;GO-- # righe nel dwh: ABAFOODS : 58.976-- # righe in sap: ABAFOODS : 58.976-- discostamento massimo valori dwh vs sap: 0 ,86680799...----- FINE TEST VALORE FINALE RIGHE FATTURA --- �

Codice 6.1: Test sul valore finale per righe di fattura

6.2. TIPOLOGIE DI TEST 71

/* *********************************************** *//* TEST SULLE QUANTITA ’ FATTURATE *//* *********************************************** *//* **** TEST PER DOCUMENTO ***** */GODROP TABLE tempDWH_DDROP TABLE tempSAP_D

-- fatture del sorgente con loro qta totaleCREATE TABLE tempSAP_D(

DocEntry int ,QtaSap float

)GOINSERT INTO tempSAP_DSELECT i.docentry , SUM(i. quantity )FROM [dbo ]. INV1 iGROUP BY i. DocEntry

-- fatture del dwh con loro qta totaleCREATE TABLE tempDWH_D(

DocEntry int ,QtaDWH float

)GOINSERT INTO tempDWH_DSELECT f.c_num_doc , SUM(f. qt_doc )FROM [dbo ]. DWH_f_rows fWHERE f. c_tipo_doc = ’F ’GROUP BY f. c_num_doc

---TESTSELECT d.Docentry , d. qtaDWH AS dwh ,

s. qtaSAP AS sap ,ABS(d.qtaDWH -s. qtaSAP ) AS diff

FROM tempDWH_D d INNER JOIN tempSAP_D s ON s. DocEntry =d. DocEntryORDER BY diff DESC;GO-- SELECT COUNT( DISTINCT f. c_num_doc ) FROM [dbo ]. DWH_f_rows f

WHERE f. c_tipo_doc =’F’-- # fatture nel dwh: ABAFoods 13.704 ZIEL: 25.221-- # righe test: ABAFoods 13.704 ZIEL: 25.221-- discostamento massimo valori dwh vs sap:

-- ABAFoods 5 ,4569...E -12 ZIEL: 0----- FINE TEST PER QUANTITA ’ TOTALE PER FATTURA --- �

Codice 6.2: Test sulle quantità totali per il documento fattura


-- numero di righe dei fattiSELECT COUNT (*) FROM [dbo ]. DWH_f_rows f;-- numero di righe dei fatti in join con tutte le dimensioniSELECT COUNT (*)FROM([dbo ]. dwh_d_province prINNER JOIN [dbo ]. dwh_d_clifatt clif ON clif. c_cli_fatt_pr =pr.

c_provinciaINNER JOIN [dbo ]. dwh_d_provarea pra ON pra. c_provincia =pr.

c_provinciaINNER JOIN [dbo ]. dwh_d_nielsen nie ON nie. c_nielsen =pra. c_nielsenINNER JOIN [dbo ]. dwh_d_provreg prg ON prg. c_provincia =pr.

c_provincia---- JOIN CON PROVREGINNER JOIN [dbo ]. dwh_d_regiONi reg ON reg. c_regione =prg. c_regioneINNER JOIN [dbo ]. dwh_d_regstato rs ON rs. c_regione =reg. c_regioneINNER JOIN [dbo ]. dwh_d_stati st ON st. c_nazione =rs. c_nazioneINNER JOIN [dbo ]. dwh_d_areastati ars ON ars. c_nazione =st.

c_nazioneINNER JOIN [dbo ]. dwh_d_areegeo geo ON geo. c_area_geo = ars.

c_area_geoINNER JOIN [dbo ]. dwh_d_areaie aie ON aie. c_area_geo =geo.

c_area_geoINNER JOIN [dbo ]. dwh_d_itaest ie ON ie. c_ita_est =aie. c_ita_est)INNER JOIN -- JOIN SUL CLIENTE DI FATTURAZIONE([dbo ]. DWH_f_rows fattiINNER JOIN [dbo ]. dwh_d_data dt ON fatti. dt_doc =dt. c_data-- JOIN SULL ’ASSE TEMPORALEINNER JOIN [dbo ]. DWH_d_mese mes ON mes. c_mese =dt.meseINNER JOIN [dbo ]. DWH_d_quarter q ON q. c_quarter =mes. c_quarterINNER JOIN [dbo ]. DWH_d_semestre sem ON sem. c_semestre =q.

c_semestre----INNER JOIN [dbo ]. DWH_d_tipodoc td ON td. c_tipo_doc =fatti.

c_tipo_docINNER JOIN [dbo ]. DWH_d_ispprovv isp ON isp. c_isp_provv = fatti.

c_isp_provvINNER JOIN [dbo ]. DWH_d_ageprovv age ON age. c_age_provv =fatti.

c_age_provvINNER JOIN [dbo ]. DWH_d_articoli art ON art. c_articolo =fatti.

c_articoloINNER JOIN [dbo ]. DWH_d_destinaz dest ON dest. c_destinaz =art.

c_destinaz-- JOIN SULL ’ ARTICOLOINNER JOIN [dbo ]. DWH_d_marchio mar ON mar. c_marchio =art. c_marchioINNER JOIN [dbo ]. DWH_d_catmerc cm ON cm. c_cat_merc =art. c_cat_mercINNER JOIN [dbo ]. DWH_d_grpmerc gm ON gm. c_grp_merc =art. c_grp_mercINNER JOIN [dbo ]. DWH_d_linprod lp ON lp. c_lin_prod =art. c_lin_prod---INNER JOIN [dbo ]. DWH_d_centridistribuzione cdf ON fatti.

c_cnt_dist =cdf. c_cnt_dist

6.3. RISULTATI OTTENUTI 73

INNER JOIN [dbo ]. DWH_d_insegna insf ON fatti. c_insegna = insf.c_insegna

INNER JOIN [dbo ]. DWH_d_gruppo gf ON fatti. c_gruppo = gf. c_gruppoINNER JOIN [dbo ]. DWH_d_centrale cf ON fatti. c_centrale = cf.

c_centraleINNER JOIN [dbo ]. DWH_d_canale caf ON fatti. c_can_vend = caf.

c_can_vend) ON clif. c_cli_fatt =fatti. c_cli_fatt AND clif. c_cli_fatt_pr =

fatti. c_cli_fatt_prINNER JOIN -- JOIN SUL CLIENTE DI CONSEGNA([dbo ]. DWH_d_clicon clicINNER JOIN [dbo ]. DWH_d_canale canc ON canc. c_can_vend =clic.

c_canaleINNER JOIN [dbo ]. DWH_d_luogocon lc ON lc. c_luogo_con =clic.

c_luogo_conINNER JOIN [dbo ]. DWH_d_zone z ON z. c_zona =clic. c_zonaINNER JOIN [dbo ]. DWH_d_catecon ce ON ce. c_cat_econ =clic.

c_cat_econINNER JOIN [dbo ]. DWH_d_grpcomm gc ON gc. c_grp_comm =clic.

c_grp_commINNER JOIN [dbo ]. DWH_d_tipi tipi ON tipi. c_tipo =clic. c_tipoINNER JOIN [dbo ]. DWH_d_centridistribuzione cdc ON clic. c_cnt_dist

=cdc. c_cnt_distINNER JOIN [dbo ]. DWH_d_insegna insc ON clic. c_insegna = insc.

c_insegnaINNER JOIN [dbo ]. DWH_d_gruppo grc ON clic. c_gruppo = grc. c_gruppoINNER JOIN [dbo ]. DWH_d_centrale cec ON clic. c_centrale = cec.

c_centrale) ON clic. c_cli_con =fatti. c_cli_con AND clic. c_cli_con_pr =fatti.

c_cli_con_pr ;-- # righe fatti nel dwh: ABAFOODS : 60.858 ZIEL: 185.782-- # righe fatti in sap: ABAFOODS : 60.858 ZIEL: 185.782---- FINE TEST NUMERO DI RIGHE TOTALI ----- �

Codice 6.3: Test sul numero di righe dei fatti mettendole in JOIN con le dimensioni

6.3 Risultati ottenutiOgni test eseguito è seguito dai risultati: uno ottenuto interrogando il data warehouse,l’altro semplicemente eseguendo il test creato. Nei test che non riguardano il conteggiodi righe, è presente anche il discostamento massimo ottenuto dalla differenza tra i duevalori (quello contenuto nel data warehouse e quello del database sorgente). Si nota,dai frammenti precedenti, che non tutti i discostamenti sono uguali a 0, o comunquemolto vicini alla precisione di macchina. Infatti, nel test che riguarda gli importi finalidelle righe di fattura, il massimo discostamento ottenuto è pari a o,8668..e ovvero aldi sotto di 1e.

Potrebbe essere visto come un non raggiungimento dell’obiettivo principale di va-lutazione misurabile del progetto, ma lavorando con numeri, è possibile che ci sianoerrori dovuti ad arrotondamenti vari. Inoltre, se guardiamo il fine di questi dati raccolti,ci accorgiamo che non siamo in una realtà che necessita di un valore preciso, esatto,


ma le informazioni servono per creare degli indici, per dare un’idea dell’andamentoattuale.

Possiamo dunque accontentarci di questo gap tra i valori prodotti dai due sistemi.

Capitolo 7

Interfacciamento a QlikView

Il seguente capitolo illustra l’ultimo step previsto per la mia attività di stage: l’inter-facciamento del data warehouse con il foglio di analisi di Qlikview.

7.1 Creazione ODBCLo strumento QlikView offre la possibilità di recuperare i dati da visualizzare da diversefonti: fogli excel, database engine, file XML ecc.

Nel nostro caso, il reperimento dei dati avviene da un database engine. Per po-ter interfacciarsi con il database engine occorre innanzitutto creare un ODBC. Gli stepseguiti per la creazione dell’ODBC per il data warehouse vendite realizzato sono:

• Pannello di controllo -> Strumenti di amministrazione -> Origini dati (ODBC)e aprire il collegamento;

• dalla finestra selezionare “Aggiungi”;

• selezionare il driver per l’origine dati: SQL Server;

• immettere il nome dell’origine dati: nel mio caso era dwhr11;

• immettere la descrizione dell’origine dati;

• selezionare il server di riferimento: nel mio caso STAGE-BI;

• proseguire con il widzard di creazione, e selezionare il sistema di autenticazioneutilizzato per SQL Server;

• proseguire e selezionare il database di riferimento dal quale Qlik preleverà poi idati: nel mio caso ABAFoods;

• eseguire la connessione;

• chiudere terminata la procedura.

75

76 CAPITOLO 7. INTERFACCIAMENTO A QLIKVIEW

ODBC

ODBC è una API (Application Programming Interface) standard per la connessionedal client al DBMS. Questa API è indipendente dai linguaggi di programmazione, daisistemi di database e dal sistema operativo.

ODBC è un’interfaccia nativa grazie alla quale si può accedere tramite linguaggiche siano in grado di chiamare funzioni di librerie native. Nel caso di Microsoft Win-dows, questa libreria è una DLL (Dynamic Link Library). La prima versione è statasviluppata su Windows; altre release sono state scritte per UNIX, OS/2 e Macintosh.In aggiunta al software ODBC, c’è bisogno di un driver specifico per poter accederead ogni diverso tipo di DBMS. ODBC permette ai programmi che lo usano di inviareai database stringhe SQL senza che ci sia bisogno di conoscerne le API proprietarie.Genera automaticamente richieste che il sistema di database utilizzato sia in gradodi capire. In tal modo, i programmi possono connettersi a diversi tipi di databaseutilizzando più o meno lo stesso codice.

7.2 Script QlikViewUna volta creato l’ODBC è stato creato lo script QlikView per il recupero dei datinecessari per le analisi.

Il foglio Qlik che doveva essere agganciato al data warehouse da me creato è sta-to riadattato modificando lo script che dichiara i campi dati e le tabelle in quanto nontutti i nomi corrispondenti erano gli stessi.

Per quanto riguarda i nomi dei campi diversi, si è optato per rinominarli dallo script“labeling” in modo da mantenere lo script di caricamento più pulito possibile e avere inun unico punto tutti i nomi ridefiniti. Sono stati comunque rinominati i campi datirecuperati in modo da rendere la lettura umanamente comprensibile e intuitiva.

I dati che Qlik mostra sono relativi a due anni consecutivi. L’anno di prelevamento èuna variabile che viene impostata dall’utente e può essere modificata ogni qualvolta losi desidera e successivamente dovrà essere rilanciato il comando per la rigenerazionedei dati di quel determinato periodo.

Vengono proposti gli script realizzati per QlikView, in particolare abbiamo:

• main contenente il codice per il prelevamento dei campi necessari;

• labeling per rinominare il nome dei campi.

7.2. SCRIPT QLIKVIEW 77

SET ThousandSep = ’ . ’ ;SET MoneyThousandSep = ’ . ’ ;SET MoneyDecimalSep = ’ , ’ ;SET TimeFormat = ’ hh :mm: s s ’ ;SET DateFormat = ’DD−MM−YYYY’ ;SET TimestampFormat = ’DD −MM −YYYY hh :mm: s s [ . f f f ] ’ ;SET MonthNames = ’ gen ; f eb ; mar ; apr ;mag ; g iu ; lug ; ago ; s e t ; o t t ; nov ; d i c ’ ;SET DayNames = ’ lun ; mar ; mer ; g i o ; ven ; sab ; dom ’ ;rem LET AC = Input(’Anno analisi ’,’ Estrazione dati anno di input

e anno precedente ’);

rem ODBC C ON NECT32 TO dwhr11 ;

ODBC C ON NECT32 TO dwhr11 ( XUserId is CcHVbZF ..., XP as sword is SJ..PYFMTbcOX .......) ;

SELECT c_tipo_doc , c_tipo_riga , d.anno , d.mese , convert ( nvarchar(10) ,d.anno)+ ’ / ’ + convert ( nvarchar (10) ,d.mese) as annomese ,

c_cli_con , c_articolo , qt_doc ,va_r_lordo , va_t_fattfin , vp_age +vp_isp as v_provvi , vc_std

FROM DWH_f_rows fIN NER JOIN DWH_d_data d ON f. dt_doc = d. c_dataWHERE c_tipo_doc IN ( ’F ’ , ’B ’ )AND anno BETWEEN$(AC) - 1 AND $(AC) AND va_t_fattfin >0;

SELECT c_articolo , d_articolo , c_cat_merc , c_lin_prod FROMDWH_d_articoli ;

SELECT c_can_vend , d_can_vend FROM DWH_d_canale ;SELECT c_tipo , d_tipo FROM DWH_d_tipi ;SELECT c_grp_merc , d_grp_merc FROM DWH_d_grpmerc ;SELECT c_cat_merc , d_cat_merc FROM DWH_d_catmerc ;SELECT c_lin_prod , d_lin_prod FROM DWH_d_linprod ;SELECT c_grp_comm , d_grp_comm FROM DWH_d_grpcomm ;SELECT c_cat_econ , d_cat_econ FROM DWH_d_catecon ;SELECT c_cli_con , d_cli_con , c_age_a , c_isp_a , d_age_a , d_isp_a ,

c_canale ,c_zona , c_tipo , c_grp_comm , c_cat_econ , c_cli_con_pr ,c_nazione , d_provincia

FROM DWH_d_clicon cIN NER JOIN DWH_d_province p ON p. c_provincia =c. c_cli_con_prIN NER JOIN DWH_d_provreg pr ON c. c_cli_con_pr =pr. c_provinciaIN NER JOIN DWH_d_regstato rs ON pr. c_regione =rs. c_regione ;SELECT s.c_nazione ,s.d_nazione , i. c_ita_estFROM DWH_d_stati sIN NER JOIN DWH_d_are as tati a ON s. c_nazione =a. c_nazioneIN NER JOIN DWH_d_areaie i ON a. c_area_geo =i. c_area_geo ; �

Codice 7.1: Script QlikView principale

RENAME FIELD c_cli_cons TO Cod. ClienteCons ;RENAME FIELD d_cli_cons TO Descr. ClienteCons ;RENAME FIELD c_age_anag TO Cod. AgenteAnag ;RENAME FIELD d_age_anag TO Descr. AgenteAnag ;RENAME FIELD c_isp_anag TO Cod. IspettoreAnag ;RENAME FIELD d_isp_anag TO Descr. IspettoreAnag ;RENAME FIELD c_canale TO Cod. Canale ;


RENAME FIELD d_canale TO Descr. Canale ;RENAME FIELD c_tipo TO CodTipoCliente ;RENAME FIELD d_tipo TO Descr. TipoCliente ;RENAME FIELD c_zona TO Cod.Zona;RENAME FIELD d_zona TO Descr.Zona;RENAME FIELD c_grp_comm TO Cod. GruppoCliente ;RENAME FIELD d_grp_comm TO Descr. GruppoCliente ;RENAME FIELD c_cat_econ TO Cod.Cat. Economica ;RENAME FIELD d_cat_econ TO Descr.Cat. Economica ;RENAME FIELD c_provincia TO Cod. Provincia ;RENAME FIELD d_provincia TO Descr. Provincia ;RENAME FIELD c_nazione TO Cod. Nazione ;RENAME FIELD d_nazione TO Descr. Nazione ;RENAME FIELD c_ita_est TO "I/E";RENAME FIELD c_articolo TO Cod. Articolo ;RENAME FIELD d_articolo TO Descr. Articolo ;RENAME FIELD c_grp_merc TO Cod. GruppoMerc .;RENAME FIELD d_grp_merc TO Descr. GruppoMerc .;RENAME FIELD c_cat_merc TO Cod. CategoriaMerc .;RENAME FIELD d_cat_merc TO Descr. CategoriaMerc .;RENAME FIELD c_lin_prod TO Cod. LineaProd ;RENAME FIELD d_lin_prod TO Descr. LineaProd ;

-- rename per coerenza con i nomi dei campi con cui sono statecreate le espressioni

RENAME FIELD c_tipo_riga TO c_tipo_mov ;RENAME FIELD va_t_fattfin TO v_imp_netto ;RENAME FIELD va_r_lordo TO v_imp_lordo ;RENAME FIELD d_lin_prod TO Descr. LineaProd ;RENAME FIELD vc_std TO v_costo ;RENAME FIELD qt_doc TO v_qta;RENAME FIELD anno TO c_anno ;RENAME FIELD mese TO c_mese ; �

Codice 7.2: Script QlikView per le etichette

7.3 Screenshot dell’applicazioneIn questa sezione vengono proposti alcuni esempi di analisi tipiche nel settore venditerealizzati con QlikView che mostra i dati contenuti nel data warehouse. Viene mostratoinoltre come l’utente può navigare tra i risultati, e vedere le informazioni desiderate.

7.3.1 Cruscotti e GraficiVengono di seguito inseriti alcuni screenshot che riguardano analisi i cui risultativengono mostrati all’utente sotto forma di grafici che possono essere i tipici graficiche siamo abituati a vedere o cruscotti che danno l’indicazione di dove ci si collocala misura analizzata rispetto a una dimensione. In Figura 7.1 è possibile vedere unesempio di finestra che rappresenta, nel nostro caso, il fatturato (di un anno) e relativomargine di guadagno tramite il tipo di grafico “cruscotto”. La lancetta indica dove sicolloca in base ai range che identificano 3 fasce: cattiva, buona, ottima. Nei riquadrisottostanti, è possibile visualizzare come, questo valore globale, è composto: nel caso

7.3. SCREENSHOT DELL’APPLICAZIONE 79

la Figura 7.1 sta analizzando gli agenti anagrafici (tramite il loro codice identificativo).

Per ognuno di essi, oltre ai dati numerici forniti, è presente un indicatore che di-ce in quale fascia si colloca quell’elemento. Grazie a questo indicatore è possibile vedereimmediatamente quali sono le voci che “vanno male” e poter dunque analizzare lanatura del valore ottenuto per attuare manovre correttive.

Figura 7.1: Screenshot dell’applicativo QlikView che mostra un cruscotto dove si possonoanalizzare gli agenti anagrafici


Spostandoci nel secondo tab presente nel foglio QlikView si ottiene la finestrain Figura 7.2. Sono presenti altre tipologie di grafico: l’istogramma e il diagramma alinee. Il primo mostra il fatturato suddiviso per mesi, per i due anni in analisi (piùprecisamente l’anno corrente e l’anno precedente) mentre il diagramma a linee, mostraper ogni agente anagrafico il fatturato a lui imputabile per ogni mese dei due anni inanalisi. Questi 2 diagrammi, a differenza del cruscotto, valutano i fatti su due assiovvero su due dimensioni messe in relazione tra di loro.

Figura 7.2: Screenshot dell’applicativo QlikView che mostra alcuni grafici del fatturato inbase al tempo e all’agente anagrafico


Un altro esempio tipo e interessante di cruscotto, è quello presente in Figura 7.3 ovveroil drill geografico: a partire dalla suddivisione geografica Italia/Estero è possibileselezionare una delle due voci e focalizza l’attenzione sugli stati contenuti in quellasuddivisione geografica e mostra il cruscotto specifico, di quella voce. È possibile prose-guire verso un grado di dettaglio maggiore. Questa possibilità è data dall’applicazionedi un filtro sul valore di certi campi. Per ritornare ad un livello meno specifico, bastaeliminare il filtro aggiunto precedentemente.

Figura 7.3: Screenshot dell’applicativo QlikView che mostra il cruscotto per analizzare ilfatturato su base geografica

Possiamo trovare altri esempi di analisi che rappresenta le informazioni mediantedei grafici nelle figure 7.4-7.5: la prima riguarda i cruscotti e la gerarchia prodotti, laseconda mostra l’andamento del fatturato imputabile ad ogni agente anagrafico in baseai canali di vendita.


Figura 7.4: Screenshot dell’applicativo QlikView che mostra il cruscotto per analizzare ilfatturato su base geografica

Figura 7.5: Screenshot dell’applicativo QlikView che l’andamento del fatturato degli agentianafrafici in base al canale di vendita


7.3.2 ReportingOltre ai risultati rappresentati mediante grafici di vario tipo, QlikView permette anchevisualizzazioni di informazioni particolari, o riassuntive utili poi per produrre deireport. Un primo esempio è presentato dalla Figura 7.6 e rappresenta una tabellapivot1 che mette in relazione il fatturato dell’anno corrente (AC) con quello del’annoprecedente(AP). La tabella in esame, considera per ogni canale di vendita, gli agentianagrafici che hanno seguito quel determinato canale, e mostra i fatturati dei due anni,oltre a dare una stima della differenza tra i due valori. Questo permette all’utente divedere in modo semplice, compatto e immediato i discostamenti ottenuti dai valoridell’anno corrente e quello precedente.

Figura 7.6: Screenshot dell’applicativo QlikView che mostra la tabella pivot per il canale eper l’agente anagrafico

Un altro esempio di rappresentazione delle informazioni è in Figura 7.7: a sinistramostra l’elenco dei primi 20 clienti, ovvero quei clienti che più hanno fatturato, mentrea destra si ha la tabella per l’analisi ABC 2. L’analisi nella figura citata poco soprapreleva solamente gli articoli con fatturato maggiore dell’80% ovvero appartenenti allacategoria A (elementi di importanza primaria con numerosità circa 20% del totale)esistono anche la categoria B (15% di fatturato generato ed elementi di importanzasecondaria con numerosità circa del 35% sul totale) e C (5% di fatturato generato edelementi con scarso impatto sul fenomeno e numerosità intorno al 45% sul totale).

1 Strumento analitico e di reporting per la creazione di tabelle riassuntive. Uno dei fini principalidi queste tabelle è l’organizzazione di dati complessi.

2 È un tipo di analisi statica che presuppone la suddivisione degli oggetti in 3 categorie.


Figura 7.7: Screenshot dell’applicativo QlikView che mostra la top 20 dei clienti di consegnae l’analisi ABC per gli articoli

Capitolo 8

Conclusioni

Il seguente capitolo ha lo scopo di illustrare quanto documentato durante lo stage, leproblematiche da me riscontrate nella realizzazione del progetto, gli obiettivi raggiuntie infine alcune considerazioni sull’attività di stage.

8.1 DocumentazioneLa documentazione realizzata durante il periodo di stage, è presente in diverse forme:

• all’interno degli script ETL, come commento, per permettere una chiara com-prensione del codice e del suo funzionamento;

• documenti in pdf in particolare era richiesto:

1. La descrizione della struttura del data warehouse ovvero delle tabelle che lacompongono e relativo significato dei campi dati individuati;

2. La descrizione degli script ETL realizzati: convenzioni utilizzate per lastesura del codice e nomenclature di tabelle e campi dati; procedimento perl’utilizzo del data warehouse dalla creazione all’aggiornamento dei dati;

3. La descrizione degli step per la l’aggancio del data warehouse al foglio diQlikView.

• presentazione del lavoro svolto durante l’attività di stage presso l’azienda.

Quanto realizzato potrebbe essere utilizzato, modificato, riadattato dall’azienda. Que-sto mi ha portato a creare una documentazione il più possibile esaustiva e chiara inmodo da rendere il lavoro di comprensione il più semplice possibile. A questo proposito,anche se non espressamente richiesto, ho realizzato una mappatura dei campi del datawarehouse con i campi dati del database sorgente e l’indicazione di quale parte dicodice si occupa di manipolarlo. Tale mappatura è riportata in Appendice B.

Come ultima richiesta per lo stage, è stata realizzata una presentazione per mostra-re il lavoro svolto durante l’attività di stage. Questa presentazione aveva lo scopoprincipale di illustrare ad alcune persone quanto fatto, e a ciascuno secondo il lorointeresse particolare su questo progetto. La presentazione prevedeva una prima partepiù tecnica ovvero quella che riguarda principalmente la progettazione della strutturadel data warehouse e una seconda parte più operativa che comprendeva la spiegazione

85

86 CAPITOLO 8. CONCLUSIONI

dell’implementazione degli script e le procedure di utilizzo (per chi poi dovrà “mettercimano”).Tale presentazione può dunque essere considerata come documentazione lasciata.

8.2 Problematiche incontrateNella realizzazione del progetto di stage ho incontrato alcune problematiche legateprincipalmente allo strumento SAP Business ONE, in particolare:

• I sistemi ERP Sap Business ONE offrono la possibilità di personalizzare il ge-stionale aggiungendo campi dati alle tabelle standard e ampliare la strutturacon l’inserimento di nuove tabelle. Per il progetto che mi è stato affidato, comegià detto a inizio documento, oltre alla parte standard di SAP Business ONE,ho utilizzato anche la parte standard dell’add-on CpgOne. Il primo problemaincontrato si trova proprio qui.

Non c’è documentazione sulla struttura dell’add-on CpgOne e sul significato chehanno tabelle e campi dati; questo vale anche per la parte personalizzata di SAP,che, unita alla poca chiarezza nella descrizione del significato di molti campi datidi SAP standard, mi hanno reso più difficile capire da quali campi dati avreidovuto estrarre le informazioni che mi servivano.

Il sistema da realizzare, doveva essere quanto più possibile standard in mo-do tale da dover poter applicare solo poche modifiche al cambiamento della basesorgente, che poteva avere o meno certi campi dati e/o tabelle. L’assenza didocumentazione di CpgOne ha reso difficile capire il significato dei campi dati:quali erano quelli standard e quali invece personalizzati portando dunque unrallentamento del lavoro per chiedere informazioni necessarie e capire concettinon sempre immediati e alle volte abbastanza complicati legati al contesto a cuisi faceva riferimento.

• Il gestionale sorgente non prevede vincoli di chiavi esterne e molte volte, l’utente,è lasciato libero di scrivere qualunque cosa all’interno di certi campi, senza peresempio, la forzatura da parte del sistema, di valori predefiniti (si pensi peresempio al caso in cui occorre inserire la provincia, più precisamente il codice, eviene inserito il nome per esteso).Ho realizzato alcune procedure di “normalizza-zione”per trasformare in valori buoni, dati sporchi che recuperati dal sorgentesarebbero andati contro i vincoli che il data warehouse impone. Questa libertàlasciata all’utente utilizzatore del database sorgente nell’inserimento dei valori,fa si che si possano trovare sempre più diverse casistiche di valori sporchi dovutiprincipalmente a persone diverse che inseriscono i dati nel database e che quindiintroducono nel sistema errori non gestiti e non prevedibili dal data warehouseallo stato attuale. Non è detto dunque, che il processo di trasformazione dei datisia completo.

Gli script sono stati realizzati a partire da database già popolati: sarà pos-sibile, testando gli script realizzati in tutti gli altri database, avere un processodi trasformazione completo inserendo le casistiche non previste. Questo nonsignifica che ad una nuova casistica mai riscontrata fino ad oggi, il sistema non

8.3. RAGGIUNGIMENTO DEGLI OBIETTIVI 87

vada più bene, ma verrà gestita con i valori di default e quindi apporterebbe unvalore informativo pressoché invariato rispetto alla situazione precedente.

8.3 Raggiungimento degli obiettiviAl termine del periodo di stage stabilito dal piano di lavoro, gli obiettivi prefissati sonostati raggiunti con successo. Non c’è stato tempo per la realizzazione delle attivitàfacoltative previste in caso di termine anticipato del oggetto vero e proprio dello stage.Le ore rimaste erano veramente poche per poter improntare nuovi lavori, sono statedunque utilizzate per poter testare gli script sul secondo database sorgente e apportareeventuali modifiche migliorative; inoltre sono state impiegate anche per migliorare ladocumentazione per offrire un buon grado di dettaglio cercando di non dimenticaretutte le informazioni necessarie all’utilizzo futuro.

La parte riguardante la realizzazione degli script ETL avrebbe potuto occupare menotempo di quello effettivamente utilizzato dovuto a fattori negativi che hanno portato adun utilizzo maggiore di ore. Questo a causa principalmente di assenza totale o parzialedella documentazione degli strumenti con cui ho lavorato e non sempre immediata lapossibilità di colmare le lacune.

8.4 Considerazioni finali sull’attività di stageReputo che l’esperienza di stage introdotta come attività obbligatoria per terminareil percorso accademico una valida opportunità ad un primo affaccio al mondo dellavoro dove non sono richieste particolari conoscenze o esperienze in cui ci si puòmettere in gioco e alla prova per uscire dall’ambiente accademico e addentrarsi nelmondo che ci aspetta: un’azienda reale della quale conoscere i processi, i meccanismi el’organizzazione aziendale, condizionata dal contesto sociale, economico e dal mercatoin continuo cambiamento in cui opera quotidianamente. Tutto questo non può essereinsegnato, tantomeno imparato da manuali, libri di testo o quant’altro, se non vivendoladi persona presso l’azienda stessa.

Essere entrata in una realtà aziendale come Soluzioni Software anche solo per un paio dimesi, mi ha dato l’opportunità di cimentarmi con nuovi strumenti che prima non sapevominimamente che esistessero, avere a che fare per la prima volta con la realizzazione diun prodotto software che si presta ad ottimizzare e migliorare progressivamente le variearee aziendali grazie ai risultati immediati che può offrire a chi deve prendere decisionistrategiche e questo fa sì, che l’azienda cresca sapendo dove principalmente è carentee attuare manovre correttive o dove sta avendo più successo per poter incrementaresempre più il suo operato.

Offrire prodotti informatici ad aziende che appartengono a diversi settori, portaa non apprendere solamente quanto riguarda strumenti e tecnologie informatiche, maanche ad ampliare il contesto e il proprio bagaglio culturale: scopri cosa è di fonda-mentale importanza per gli altri compartimenti aziendali, le loro necessità e calaredegli strumenti informatici che possano aiutarli a raggiungere i loro obiettivi in modosemplice, efficiente ed efficace.

88 CAPITOLO 8. CONCLUSIONI

Il percorso di studi che mi ha accompagnata a questa ultima tappa universitaria mi hadato la possibilità di apprendere da vari corsi di studio (nella fattispecie, ingegneria delsoftware) nozioni teoriche che rendono il processo di sviluppo del software di qualitàsotto tutti i punti di vista. Con questa esperienza, ho potuto vedere quanto di quellovisto nella teoria ha poi un risvolto pratico nella realtà attuale. Ho notato come moltevolte vengono messe da parte best practice di cruciale importanza come può essere ladocumentazione dei prodotti software realizzati o di quanto utile per i posteri o perpassaggi di consegna.Le cause principali che portano a non fare uso di questa best practice sono svariate:alcune mi sono state proposte, dalle persone con cui mi sono interfacciata durante lostage, come risposta alla mia richiesta di necessità di documentazione, altre invece miededuzioni e riflessioni personali.

• lo sviluppatore che ha realizzato il prodotto o parte di esso, vuole rendere lavita difficile a chi poi vorrà riutilizzarlo o dal quale vorrà prendere spunto peruna nuova soluzione: questo ragionamento è di chi mette in primo piano la suapresunta bravura anziché pensare ai benefici che la documentazione porta aglialtri e all’azienda in termini di efficienza ed efficacia;

• una volta realizzato il prodotto, si è iniziato a produrre la documentazione, maessendo un processo molto lungo, si è ben pensato di trascurarlo;

• credo che molte volte le soluzioni create sono by correction ovvero secondo ilpensiero: “metto assieme qualcosa sperando che funzioni” cioè creare a tentativianziché prediligere per soluzioni by construction secondo il paradigma: “conce-pisco, creo/costruisco sapendo che poi funziona”. L’attività di documentazionerisulta immediata se so cosa devo documentare: nel primo caso, non possodocumentare, perchè non so cosa mi ha portato a quello che ho;

• i clienti sono esigenti e vorrebbero che le loro richieste trovino concretezza intempi brevi. In un sistema in cui al cliente interessa solo il prodotto comeutilizzatore finale e dunque la parte puramente tecnica non è di sua competenza,la documentazione viene a mancare per poter rispondere ai cliente in tempi brevi.

In un contesto del genere, in cui ho sperimentato la mancanza di documentazione perpoter realizzare al meglio quanto mi era richiesto, mi sono sentita in dovere di portarequesta pratica in quanto da me realizzato, per mostrare come la documentazione portabenefici anche se non nell’immediato. Si pensi alla stesura del codice: commentare ilpiù possibile, porta a una perdita iniziale di tempo, ma avvantaggia lo sviluppatorestesso quando dovrà riprendere in mano quanto da lui scritto molto tempo prima eporta ad una facile manutenzione futura del codice da parte di soggetti diversi dallosviluppatore.

Questa esperienza è stata per me il primo approccio sia al mondo del lavoro in ambitoinformatico in una realtà distinta da quella universitaria sia ad un progetto di grandidimensioni (da portare a termine in modo individuale) nella quale mi sono potutamettere in gioco e dimostrare a me stessa che ho le capacità per fare un buon lavoro,che alla fine i passi fatti, anche se alle volte con fatica, hanno portato alla realizzazionedi un prodotto del quale andarne fiera.

8.4. CONSIDERAZIONI FINALI SULL’ATTIVITÀ DI STAGE 89

In conclusione, mi ritengo soddisfatta di questa esperienza di stage svolta pressoSoluzioni Software, per le opportunità ricevute di crescita personale, per le conoscenzeacquisite su nuove tecnologie, e per l’accrescimento del mio bagaglio di conoscenzagrazie alla disponibilità del tutor aziendale che pazientemente ha seguito il mio operato,dedicandomi settimanalmente parte del suo tempo, dandomi l’opportunità di sbagliaresenza correggermi per farmi arrivare alla soluzione corretta in modo ragionato e au-tonomo; dandomi una panoramica della “vita aziendale” che non si limitava al solocontesto del progetto; trasmettendomi spunti, conoscenze e informazioni delle qualine farò tesoro per il mio futuro lavorativo che mi aspetta dietro l’angolo. Mi ha fattoinoltre rivalutare il mio punto di vista su come le aziende vedono gli stagisti, dandomila possibilità di esporre il lavoro da me svolto ad altri dipendenti dell’azienda, segno diriconoscimento che l’attività di stage non è importante solo per lo stagista al fine diterminare il suo percorso di studi.

Ho trovato un ambiente amichevole, sereno e cordiale con persone sempre dispo-nibili con le quali ho stabilito un contatto positivo e la possibilità di confrontarmi sualcune questioni legate al mio progetto di stage dedicandomi un po’ del loro tempo peraiutarmi a comprendere maggiormente il contesto aziendale.

Ringraziamenti

Vorrei innanzitutto esprimere la mia gratitudine e il mio ringraziamento al Prof. MauroConti, relatore della mia tesi, che mi ha seguito in questi ultimi mesi del mio percorsoaccademico sia durante il periodo di stage sia nella stesura di questo elaborato dandomiprontamente aiuti e consigli per svolgere al meglio il lavoro.

Un sentito ringraziamento va all’azienda Soluzioni Software srl che mi ha dato l’oppor-tunità di fare questa esperienza presso la loro sede. In particolare vorrei ringraziareFabio Ballin, tutor aziendale che mi ha seguito in questi due mesi di stage, per la pro-fessionalità dimostratami, per il supporto e la sua disponibilità nel seguirmi, nel darmispunti di riflessione utili per il mio futuro lavorativo e per avermi dato l’opportunitàdi approfondire tematiche e acquisire nuove conoscenze. Inoltre un ringraziamento atutte le persone che ho incontrato durante questo periodo, per avermi fatto sentire partedell’ambiente, sempre gentili e disponibili nei miei confronti.

Desidero ringraziare i miei genitori e i miei fratelli, per avermi sopportato nei momentidi studio e di stress intenso. In particolare la mamma e il papà, che mi hanno datol’opportunità di essere qui a ringraziarli e festeggiare con loro questo traguardo final-mente raggiunto; che hanno sostenuto economicamente questo mio percorso di studi,senza oppressioni su tempistiche e risultati, accettando e supportando ogni mia scelta enonostante il mio carattere scontroso, non si sono mai stancati di starmi accanto.

Un doveroso ringraziamento va ai miei amici, che nonostante li abbia trascurati neiperiodi di full immersion nello studio, non si sono mai stancati di cercarmi, di pensarmie di starmi accanto soprattutto nei momenti difficili in cui le cose non andavano beneed erano sempre pronti a strapparmi un sorriso. Da oggi finalmente non si sentirannopiù rispondere con la fatidica frase “devo studiare!”.

Un grazie speciale va a tutte quelle persone che ho incontrato in questi quattro anni diuniversità. La carriera universitaria non è fatta solo di esami e di studio, ma anchedi relazioni interpersonali: mi ha dato l’opportunità di conoscere persone fantastichee che non avrei potuto incontrare in altri contesti. Con molte di loro si è creato unrapporto di amicizia che va al di là della semplice condivisione dei banchi universitarie che dura ormai da anni. Voglio ringraziarli per aver condiviso assieme a me questianni di studio; per aver allietato la vita da pendolare e i ritardi dei treni; per le lezionidi vita che mi hanno dato; per l’avermi sempre incoraggiata e fatto credere in me stessae nelle mie capacità; per aver percorso insieme questa strada fatta di grandi e piccolesoddisfazioni, ma anche di momenti tortuosi e difficili.

91

92 Ringraziamenti

Un affettuoso ringraziamento lo vorrei dedicare alle persone a me care, che hannocamminato affianco a me per un piccolo pezzo di strada, condividendo momenti felici eanche se oggi non potranno essere presenti, so che dall’alto mi staranno guardandoorgogliose di questo traguardo raggiunto.

Vorrei infine ringraziare tutte le persone che hanno incrociato la mia vita, donandomiun po’ di loro e rendendomi la persona che sono oggi; i miei familiari; le realtà, a cuiappartengo, che riescono sempre a tirare fuori il meglio di me e rendermi sempre piùuna persona migliore e attenta al prossimo; infine tutte quelle persone che oggi sonoqua per me e festeggiare questo mio traguardo raggiunto seppur con difficoltà, ma cheporta in sé tanta soddisfazione e gioia.

GRAZIE DI CUORE A TUTTI!

Padova, Dec. 2014 Beatrice Feltre

Appendice A

Appendice A: Descrizionetestuale delle tabelle

La seguente appendice contiene la descrizione testuale di ogni tabella e relativi campidati del data warehouse.

A.1 Descrizione delle DimensioniA.1.1 Asse Geografico[dbo].DWH_d_nielsen

Rappresenta le possibili aree Nielsen identificate; le aree Nielsen che si considererannosono:

• 1: Nord-Ovest;

• 2: Nord-Est;

• 3: Centro;

• 4: Sud;

• 5: Isole;

• 6: Estero.

Campi

• c_nielsen tipo: varchar(12) rappresenta il codice dell’area Nielsen (1-6).Identifica univocamente ogni record della tabella;

• d_nielsen tipo: nvarchar(20) rappresenta la descrizione dell’area Nielsen (Nord-Ovest, Nord-Est ecc.).

[dbo].DWH_d_province

Rappresenta tutte le province italiane.

93

94APPENDICE A. APPENDICE A: DESCRIZIONE TESTUALE DELLE TABELLE

Campi

• c_provincia tipo: nvarchar(100) rappresenta il codice della provincia italiana.Qualora si trattasse di un paese estero, verrà replicato il codice della nazione.Identifica univocamente ogni record della tabella. Il codice è normalizzato comesegue: codice_stato/codice_provincia

• d_provincia tipo: nvarchar(100) rappresenta il nome della provincia italiana.Qualora si trattasse di un paese estero, verrà inserita la descrizione della nazione.

[dbo].DWH_d_ provarea

Rappresenta l’associazione di ogni provincia all’area Nielsen a cui appartiene.

Campi

• c_provincia tipo: nvarchar(100) rappresenta il codice della provincia italiana.Qualora si trattasse di un paese estero, verrà replicato il codice della nazione.Identifica univocamente ogni record della tabella.Riferisce il campo c_provincia della Tabella A.1.1;

• c_nielsen tipo: nvarchar(12) rappresenta il codice della regione Nielsen a cui laprovincia è associata.Riferisce il campo c_nielsen della Tabella A.1.1.

[dbo].DWH_d_regioni

Rappresenta tutte le regioni italiane.

Campi

• c_regione tipo: nvarchar(3) rappresenta la sigla della regione italiana.Qualora si trattasse di un paese estero, verrà replicato il codice della nazione.Identifica univocamente ogni record della tabella;

• d_regione tipo: nvarchar(100) rappresenta il nome della regione italiana.Qualora si trattasse di un paese estero, verrà inserita la descrizione della nazione.

[dbo].DWH_d_provreg

Rappresenta l’associazione di ogni provincia alla regione a cui appartiene.

Campi

• c_provincia tipo: nvarchar(100) rappresenta il codice della provincia italiana.Qualora si trattasse di un paese estero, verrà replicato il codice della nazione.Identifica univocamente ogni record della tabella.Riferisce il campo c_provincia della Tabella A.1.1;

• c_regione tipo: nvarchar(3) rappresenta la sigla della regione a cui la provinciaè associata.Riferisce il campo c_nielsen della Tabella A.1.1.

A.1. DESCRIZIONE DELLE DIMENSIONI 95

[dbo].DWH_d_stati

Rappresenta tutti gli stati in cui ci sono rapporti commerciali di vendita.

Campi

• c_nazione tipo: nvarchar(3) rappresenta la sigla della nazione.Identifica univocamente ogni record della tabella;

• d_nazione tipo: nvarchar(100) rappresenta il nome della nazione per esteso.

[dbo].DWH_d_regstato

Rappresenta l’associazione di regione allo stato a cui appartiene.

Campi

• c_regione tipo: nvarchar(3) rappresenta la sigla della regione.Qualora si trattasse di un paese estero, verrà replicato il codice della nazione.Identifica univocamente ogni record della tabella.Riferisce il campo c_regione della Tabella A.1.1;

• c_nazione tipo: nvarchar(3) rappresenta la sigla dello stato a cui la regione èassociata.Riferisce il campo c_nazione della Tabella A.1.1.

[dbo].DWH_d_areegeo

Rappresenta l’area geografica in cui si è deciso di suddividere gli stati. Esiste comunquel’area geografica “Italia ”. Ogni stato appartiene ad una sola area geografica. Lasuddivisione degli stati nelle varie aree geografiche è a discrezione dell’utente in basealle azioni strategiche intraprese.

Campi

• c_area_geo tipo: nvarchar(12) rappresenta il codice dell’area geografica.Identifica univocamente ogni record della tabella;

• d_area_geo tipo: nvarchar(40) rappresenta il nome dell’area geografica peresteso.

[dbo].DWH_d_areastati

Rappresenta l’associazione di ogni stato ad un’area geografica tra quelle individuate.

Campi

• c_nazione tipo: nvarchar(3) rappresenta la sigla della nazione.Identifica univocamente ogni record della tabella.Riferisce il campo c_nazione della Tabella A.1.1;

• c_area_geo tipo: nvarchar(12) rappresenta la sigla dell’area geografica in cuilo stato è stato classificato.Riferisce il campo c_area_geo della tabella A.1.1.


[dbo].DWH_d_itaest

Rappresenta la un flag che mi individua se si sta parlando di Italia o di Estero

Campi

• c_ita_est tipo: nvarchar(1) rappresenta il codice del flag.Identifica univocamente ogni record della tabella;

• d_ita_est tipo: nvarchar(6) rappresenta la descrizione del flag. Assume valoreItalia o Estero.

[dbo].DWH_d_areaie

Rappresenta l’associazione di ogni area geografica con il flag italia/estero.

Campi

• c_area_geo tipo: nvarchar(12) rappresenta il codice dell’area geografica.Identifica univocamente ogni record della tabella.Riferisce il campo c_area_geo della Tabella A.1.1;

• c_ita_est tipo: varchar(1) rappresenta il flag che mi dice se è Italia o Estero .Riferisce il campo c_ita_est della Tabella A.1.1.

[dbo].DWH_d_luogocon

Rappresenta il luogo fisico della consegna e al momento rappresenta l’indirizzo delcliente di consegna.

Campi

• c_luogo_con tipo: nvarchar(6) rappresenta il codice del luogo di consegna.Il codice è costituito a partire dalla provincia del cliente di consegna seguito daun progressivo numerico (es: BL0014).Identifica univocamente ogni record della tabella;

• d_luogo_con tipo: nvarchar(254) rappresenta l’indirizzo per esteso al qualeviene aggiunto in coda il nome della provincia per esteso.

[dbo].DWH_d_zone

Rappresenta la zona a cui è associato il cliente di consegna.

Campi

• c_zona tipo: nvarchar(32) rappresenta il codice territoriale della zona di appar-tenenza del cliente di consegna.Identifica univocamente ogni record della tabella;

• d_zona tipo: nvarchar(200) rappresenta la descrizione della zona.


A.1.2 Asse Temporale[dbo].DWH_d_semestre

Rappresenta la definizione dei semestri ovvero della suddivisione dell’anno in dueblocchi di mesi di ugual numero di mesi.

Campi

• c_semestre tipo: int rappresenta il semestre a cui ci si riferisce (1-2).Identifica univocamente ogni record della tabella;

• d_semestre tipo: nvarchar(20) rappresenta la descrizione del semestre informato testuale (es: Gen-Giu ecc.).

[dbo].DWH_d_quarter

Rappresenta la definizione dei “quarter ”ovvero della suddivisione dell’anno in quattrotrimestri.

Campi

• c_quarter tipo: int rappresenta il trimestre a cui ci si riferisce (1-4).Identifica univocamente ogni record della tabella;

• d_quarter tipo: nvarchar(20) rappresenta la descrizione del trimestre in formatotestuale (es: Gen-Mar ecc.);

• c_semestre tipo: iny rappresenta il semestre in cui si trova il quarter in esame.Riferisce il campo c_semestre della Tabella A.1.2.

[dbo].DWH_d_mese

Rappresenta i mesi dell’anno.

Campi

• c_mese tipo: smallint rappresenta il mese in forma numerica.Identifica univocamente ogni record della tabella;

• c_quarter tipo: int rappresenta il trimestre in cui si trova il mese in esame.Riferisce il campo c_quarter della Tabella A.1.2;

• d_mese tipo: nvarchar(20) rappresenta la descrizione del mese in formatotestuale (es: Gennaio, Febbraio ecc.);

• numGG tipo: int rappresenta il numero di giorni che ha il mese in esame.Per il mese di Febbraio numGG conterrà comunque il valore 28.

[dbo].DWH_d_data

Rappresenta la data in cui il documento è stato emesso.


Campi

• c_data tipo: date rappresenta la data del documento nel formato aaaa/mm/gg.Identifica univocamente ogni record della tabella;

• c_mese tipo: smallint rappresenta il mese contenuto nella data.Riferisce il campo c_mese della Tabella A.1.2;

• anno tipo: smallint rappresenta l’anno contenuto nella data;

• giorno tipo: int rappresenta il giorno contenuto nella data;

• numGiorno tipo: int rappresenta il giorno nel formato ordinale a partire dalprimo giorno dell’anno (1-365/366).Occorre dunque gestire anche la bisestilità dell’anno.

A.1.3 Asse Prodotto[dbo].DWH_d_destinaz

Rappresenta le destinazioni del prodotto.

Campi

• c_destinaz tipo: nvarchar(12) rappresenta il codice della destinazione delprodotto.Identifica univocamente ogni record della tabella;

• d_destinaz tipo: nvarchar(50) rappresenta la descrizione della destinazione delprodotto per esteso.

[dbo].DWH_d_marchio

Rappresenta i dati riguardanti il marchio del prodotto.

Campi

• c_marchio tipo: nvarchar(12) rappresenta il codice del marchio.Identifica univocamente ogni record della tabella;

• c_proprietàMarchio tipo: nvarchar(7) rappresenta la proprietà del marchioovvero se è proprio o di terzi;

• d_marchio tipo: nvarchar(50) rappresenta la descrizione del marchio.

[dbo].DWH_d_linprod

Rappresenta i dati riguardanti le linee di produzione.

Campi

• c_lin_prod tipo: nvarchar(30) rappresenta il codice della linea del prodotto.Identifica univocamente ogni record della tabella;

• d_lin_prod tipo: nvarchar(30) rappresenta la descrizione della linea del pro-dotto.


[dbo].DWH_d_catmerc

Rappresenta i dati riguardanti le categorie merceologiche che possono essere associateal prodotto.

Campi

• c_cat_merc tipo: nvarchar(30) rappresenta il codice della categoria merceolo-gica collegata al prodotto.Identifica univocamente ogni record della tabella;

• d_cat_merc tipo: nvarchar(40) rappresenta la descrizione della categoriamerceologica.

[dbo].DWH_d_grpmerc

Rappresenta i dati riguardanti i gruppi merceologici che possono essere associate alprodotto.

Campi

• c_grp_merc tipo: nvarchar(30) rappresenta il codice del gruppo merceologicocollegato al prodotto.Identifica univocamente ogni record della tabella;

• d_grp_merc tipo: nvarchar(40) rappresenta la descrizione del gruppo merceo-logico.

[dbo].DWH_d_articoli

Rappresenta i dati del prodotto.

Campi

• c_articolo tipo: nvarchar(20) rappresenta il codice dell’articolo.Identifica univocamente ogni record della tabella;

• d_articolo tipo: nvarchar(100) rappresenta la descrizione dell’articolo;

• c_um tipo: nvarchar(100) rappresenta l’unità di misura del prodotto (kg, pezziecc.);

• c_cat_merc tipo: nvarchar(30) rappresenta la categoria merceologica a cui ilprodotto appartiene.Riferisce il campo c_cat_merc della Tabella A.1.3;

• c_grp_merc tipo: nvarchar(30) rappresenta il gruppo merceologico a cui ilprodotto appartiene.Riferisce il campo c_grp_merc della Tabella A.1.3;

• c_lin_prod tipo: nvarchar(30) rappresenta la linea di produzione a cui ilprodotto appartiene.Riferisce il campo c_lin_prod della Tabella A.1.3;

• c_tipo tipo: varchar(1) indica se l’articolo è un servizio o un prodotto;


• c_marchio tipo: nvarchar(12) rappresenta il codice del marchio del prodotto.Riferisce il campo c_marchio della Tabella A.1.3;

• c_destinaz tipo: nvarchar(12) rappresenta il codice della destinazione delprodotto.Riferisce il campo c_destinaz della Tabella A.1.3.

A.1.4 Asse Acquisto[dbo].DWH_d_canale

Rappresenta il canale di vendita del prodotto.

Campi

• c_canale tipo: nvarchar(30) rappresenta il codice del canale.Identifica univocamente ogni record della tabella;

• d_canale tipo: nvarchar(50) rappresenta la descrizione del canale.

[dbo].DWH_d_centriDistribuzione

Rappresenta il primo livello di gerarchia a cui il cliente di consegna può essere collegato.

Campi

• c_cnt_dist tipo: nvarchar(12) rappresenta il codice del centro di distribuzione.Identifica univocamente ogni record della tabella;

• d_cnt_dist tipo: nvarchar(50) rappresenta la descrizione del centro di distri-buzione.

[dbo].DWH_d_insegna

Rappresenta il secondo livello di gerarchia a cui il cliente di consegna può esserecollegato.

Campi

• c_insegna tipo: nvarchar(12) rappresenta il codice dell’insegna.Identifica univocamente ogni record della tabella;

• d_insegna tipo: nvarchar(50) rappresenta la descrizione dell’insegna.

[dbo].DWH_d_gruppo

Rappresenta il terzo livello di gerarchia a cui il cliente di consegna può essere collegato.

Campi

• c_gruppo tipo: nvarchar(12) rappresenta il codice del gruppo.Identifica univocamente ogni record della tabella;

• d_gruppo tipo: nvarchar(50) rappresenta la descrizione del gruppo.


[dbo].DWH_d_centrale

Rappresenta il quarto livello di gerarchia a cui il cliente di consegna può essere collegato.

Campi

• c_centrale tipo: nvarchar(12) rappresenta il codice della centrale.Identifica univocamente ogni record della tabella;

• d_centrale tipo: nvarchar(50) rappresenta la descrizione della centrale.

A.1.5 Asse Documento[dbo].DWH_d_tipodoc

Rappresenta il tipo di documento al quale si riferisce il fatto.

Campi

• c_tipo_doc tipo: nvarchar(5) rappresenta il codice del tipo di documento.Identifica univocamente ogni record della tabella;

• d_centrale tipo: nvarchar(50) rappresenta la descrizione del tipo di documento.

A.1.6 Asse Soggetti[dbo].DWH_d_ageprovv

Rappresenta l’agente della particolare vendita cui si riferisce il fatto. Potrebbe noncoincidere con l’agente anagrafico.

Campi

• c_age_provv tipo: nvarchar(32) rappresenta il codice dell’agente di provvigio-ne.Identifica univocamente ogni record della tabella;

• d_age_provv tipo: nvarchar(155) rappresenta la descrizione dell’agente diprovvigione.

[dbo].DWH_d_ispprovv

Rappresenta l’ispettore della particolare vendita cui si riferisce il fatto. Potrebbe noncoincidere con l’ispettore anagrafico anagrafico.

Campi

• c_isp_provv tipo: nvarchar(32) rappresenta il codice dell’ispettore di provvi-gione.Identifica univocamente ogni record della tabella;

• d_isp_provv tipo: nvarchar(155) rappresenta la descrizione dell’ispettore diprovvigione.


[dbo].DWH_d_clifatt

Rappresenta il cliente di fatturazione ovvero al quale verrà inviata la fattura. Potrebbenon coincidere con il cliente di consegna.

Campi

• c_cli_fatt tipo: nvarchar(15) rappresenta il codice del cliente di fatturazione.

• c_cli_fatt_pr tipo: nvarchar(100) rappresenta la sigla della provincia delcliente di fatturazione. Riferisce il campo c_provincia della Tabella A.1.1.Assieme al campo c_cli_fatt identifica univocamente ogni record della tabella.Viene fatta questa identificazione in quanto il data warehouse deve mantenerel’informazione storica e dunque, il solo codice del cliente non era sufficiente aidentificare in modo univoco un cliente qualora avesse modificato la sua posizionegeografica;

• d_cli_fatt tipo: nvarchar(100) rappresenta la descrizione del cliente di fattura-zione.

[dbo].DWH_d_catecon

Rappresenta le categorie economiche alle quali può essere associato il cliente.

Campi

• c_cat_econ tipo: int rappresenta il codice della categoria economica.Identifica univocamente ogni record della tabella;

• d_cat_econ tipo: nvarchar(15) rappresenta la descrizione della categoriaeconomica.

[dbo].DWH_d_tipi

Rappresenta i tipi di mercato che può essere associato il cliente.

Campi

• c_tipo tipo: nvarchar(30) rappresenta il codice del tipo di mercato.Identifica univocamente ogni record della tabella;

• d_tipo tipo: nvarchar(40) rappresenta la descrizione del tipo di mercato.

[dbo].DWH_d_grpcomm

Rappresenta i gruppi commerciali ai quali può essere associato il cliente.

Campi

• c_grp_comm tipo: int rappresenta il codice della categoria economica.Identifica univocamente ogni record della tabella;

• d_grp_comm tipo: nvarchar(15) rappresenta la descrizione della categoriaeconomica.


[dbo].DWH_d_clicon

Rappresenta il cliente di consegna ovvero il cliente al quale verrà inviata la merce.Potrebbe non coincidere con il cliente di fatturazione.

Campi

• c_cli_con tipo: nvarchar(15) rappresenta il codice del cliente di consegna.

• c_cli_con_pr tipo: nvarchar(100) rappresenta la sigla della provincia delcliente di consegna.riferisce il campo c_provincia della Tabella A.1.1.Assieme al campo c_cli_con identifica univocamente ogni record della tabella.Viene fatta questa identificazione in quanto il datawarehouse deve mantenerel’informazione storica e dunque, il solo codice del cliente non era sufficiente aidentificare in modo univoco un cliente qualora avesse modificato la sua posizionegeografica.

• d_cli_con tipo: nvarchar(100) rappresenta la descrizione del cliente di consegna;

• c_luogo_con tipo: varchar(6) rappresenta il luogo di consegna della merce.Riferisce il campo c_luogo_con della Tabella A.1.1;

• c_zona tipo: nvarchar(32) rappresenta la zona di appartenenza del cliente diconsegna.Riferisce il campo c_zona della Tabella A.1.1;

• c_cnt_dist tipo: nvarchar(12) rappresenta il centro di distribuzione a cui ilcliente di consegna è associato.Riferisce il campo c_cnt_dist della Tabella A.1.4;

• c_insegna tipo: nvarchar(12) rappresenta l’insegna a cui il cliente di consegnadi consegna è associato.Riferisce il campo c_insegna della Tabella A.1.4;

• c_gruppo tipo: nvarchar(12) rappresenta il gruppo a cui il cliente di consegnaè associato.Riferisce il campo c_gruppo della Tabella A.1.4;

• c_centrale tipo: nvarchar(12) rappresenta il canale di vendita a cui il clientedi consegna è associato.Riferisce il campo c_can_vend della Tabella A.1.4;

• c_canale tipo: nvarchar(30) rappresenta la centrale a cui il cliente di consegnaè associato.Riferisce il campo c_can_vend della Tabella A.1.4;

• c_tipo tipo: nvarchar(30) rappresenta il tipo di mercato a cui il cliente diconsegna appartiene.Riferisce il campo c_tipo della Tabella A.1.6;

• c_cat_econ tipo: int rappresenta la categoria economica a cui il cliente diconsegna appartiene.Riferisce il campo c_cat_econ della Tabella A.1.6;


• c_grp_comm tipo: int rappresenta il gruppo commerciale a cui il cliente diconsegna appartiene.Riferisce il campo c_grp_comm della Tabella A.1.6;

• c_cat_sco tipo: nvarchar(12) rappresenta la categoria di sconto del cliente diconsegna;

• c_cat_pro tipo: nvarchar(30) rappresenta la categoria provvigionale del clientedi consegna;

• c_age_a tipo: nvarchar(32) rappresenta il codice dell’agente anagrafico asso-ciato al cliente di consegna;

• d_age_a tipo: nvarchar(155) rappresenta la descrizione dell’agente anagraficoassociato al cliente di consegna;

• c_isp_a tipo: nvarchar(32) rappresenta il codice dell’ispettore anagraficoassociato al cliente di consegna;

• d_isp_a tipo: nvarchar(155) rappresenta la descrizione dell’ispettore anagraficoassociato al cliente di consegna.

A.2 Descrizione dei FattiLa tabella dei fatti rappresenta l’evento di interesse delle vendite. Nel nostro casopiù dettagliatamente delle righe di documenti di vendita, quali fatture, documenti diconsegna, ordini ecc.

A.2.1 [dbo].DWH_f_rowsCampi

• Dimensioni

· c_tipo_doc tipo: nvarchar(5) rappresenta il codice del tipo di documentoa cui si riferisce il fatto.Riferisce il campo c_tipo_doc della Tabella A.1.5;

· c_num_doc tipo: int rappresenta il numero del documento a cui si riferisceil fatto;

· c_num_riga tipo: int rappresenta il numero di riga del documento a cuisi riferisce il fatto.Assieme ai campi c_tipo_doc e c_num_doc identifica univocamente ognirecord della tabella;

· c_tipo_riga tipo: nvarchar(5) rappresenta il codice del tipo di riga a cuisi riferisce il fatto. In particolar modo identifica se la riga considerata èomaggio o sconto merce o ancora normale;

· c_dt_doc tipo: date rappresenta la data di emissione del documento a cuisi riferisce il fatto.Riferisce il campo c_data della Tabella A.1.2;

· c_articolo tipo: nvarchar(20) rappresenta il codice dell’articolo a cui siriferisce il fatto.Riferisce il campo c_articolo della Tabella A.1.3;

A.2. DESCRIZIONE DEI FATTI 105

· c_cli_con tipo: nvarchar(15) rappresenta il codice del cliente di consegnaa cui si riferisce il fatto.Riferisce il campo c_cli_con della Tabella A.1.6;

· c_cli_con_pr tipo: nvarchar(100) rappresenta il codice della provinciadel cliente di consegna a cui si riferisce il fatto.Riferisce il campo c_cli_con_pr della Tabella A.1.6;

· c_cli_fatt tipo: nvarchar(15) rappresenta il codice del cliente di fattura-zione a cui si riferisce il fatto.Riferisce il campo c_cli_fatt della Tabella A.1.6;

· c_cli_fatt_pr tipo: nvarchar(100) rappresenta il codice della provinciadel cliente di fatturazione a cui si riferisce il fatto.Riferisce il campo c_cli_fatt_pr della Tabella A.1.6;

· c_age_provv tipo: nvarchar(32) rappresenta il codice dell’agente di prov-vigione a cui si riferisce il fatto.Riferisce il campo c_age_provv della Tabella A.1.6;

· c_isp_provv tipo: nvarchar(32) rappresenta il codice dell’ispettore diprovvigione a cui si riferisce il fatto.Riferisce il campo c_isp_provv della Tabella A.1.6;

· c_cnt_dist tipo: nvarchar(12) rappresenta il codice del centro di distribu-zione a cui si riferisce il fatto.Riferisce il campo c_cnt_dist della Tabella A.1.4;

· c_insegna tipo: nvarchar(12) rappresenta il codice dell’insegna a cui siriferisce il fatto.Riferisce il campo c_insegna della Tabella A.1.4;

· c_gruppo tipo: nvarchar(12) rappresenta il codice del gruppo a cui siriferisce il fatto.Riferisce il campo c_gruppo della Tabella A.1.4;

· c_centrale tipo: nvarchar(12) rappresenta il codice della centrale a cui siriferisce il fatto.Riferisce il campo c_centrale della Tabella A.1.4;

· c_can_vend tipo: nvarchar(12) rappresenta il codice del canale di venditaa cui si riferisce il fatto.Riferisce il campo c_can_vend della Tabella A.1.4;

· f_bdg_cons tipo: varchar(1) rappresenta un flag che indica se i valorisono di consuntivo (C) o di budget (B).

• Misure

· qt_doc tipo: float rappresenta la quantità venduta nell’UM dell’articolocui si riferisce il fatto;

· qt_kg tipo: float rappresenta la quantità venduta in KG dell’articolo cuisi riferisce il fatto.Se l’articolo non è esprimibile in peso, questo valore è zero;

· va_list tipo: float rappresenta il valore di listino valido alla data dellafattura.Si esprime in EURO;


· va_r_lordo tipo: float rappresenta il valore lordo della riga ovvero il valoredi listino dell’articolo cui si riferisce il fatto moltiplicato per la quantità.Si esprime in EURO;

· vs_r_canale tipo: float rappresenta il valore di sconto riferito al canaledi vendita cui si riferisce il fatto.Qualora non fosse presente nel gestionale, viene impostato a “zero”.Si esprime in EURO;

· vs_r_agg tipo: float rappresenta il valore di sconto aggiunto per l’articolocui si riferisce il fatto.Qualora non fosse presente nel gestionale, viene impostato a “zero”.Si esprime in EURO;

· vs_r_prom tipo: float rappresenta il valore di sconto promozionale perl’articolo cui si riferisce il fatto.Qualora non fosse presente nel gestionale, viene impostato a “zero”;

· vs_r_altri tipo: float rappresenta il valore di altri sconti per l’articolo cuisi riferisce il fatto.Qualora non fosse presente nel gestionale, viene impostato a “zero”.Si esprime in EURO

· vs_r_tot tipo: float rappresenta il valore di sconto totale di riga cui siriferisce il fatto.Viene calcolato come somma degli sconti di riga visti sopra.Si esprime in EURO;

· va_r_netto tipo: float rappresenta il valore netto di riga cui si riferisce ilfatto.Si esprime in EURO;

· vs_t_tot tipo: float rappresenta il valore di sconto totale di testa cui siriferisce il fatto.Si esprime in EURO;

· va_t_fattfin tipo: float rappresenta il valore fatturato di riga finale, alnetto di tutti gli sconti, compresi quelli di testata cui si riferisce il fatto.Se sommato a tutti quelli delle altre righe, si ottiene l’importo di fattura.Si esprime in EURO;

· vp_age tipo: float rappresenta la provvigione assegnata all’agente ed èprevisto solo per i fatti legati alle fatture.Si esprime in EURO;

· vp_isp tipo: float rappresenta la provvigione assegnata all’ispettore ed èprevisto solo per i fatti legati alle fatture.Si esprime in EURO;

· vc_std tipo: float rappresenta il costo standard di riferimento del prodottocui si riferisce il fatto.Si esprime in EURO;

· vc_eff tipo: float rappresenta il costo effettivo (attuale) del prodotto cui siriferisce il fatto.Si esprime in EURO;

· vm_s tipo: float rappresenta il valore al netto di tutti i costi usando ilcosto standard cui si riferisce il fatto.Si esprime in EURO;

A.3. PARAMETRIZZAZIONE 107

· vm_e tipo: float rappresenta il valore al netto di tutti i costi usando ilcosto effettivo cui si riferisce il fatto.Si esprime in EURO.

A.3 ParametrizzazioneA.3.1 [dbo].DWH_parametriLa seguente tabella ha il compito di tenere traccia di tutti quei valori, che potrebberoessere parametrizzati in modo da far si che al variare di questi valori, non si porti a unamodifica del codice contenuto negli script di caricamento, e che quindi questi valorivengano prelevati da questa tabella.

Campi

• c_parametro tipo: nvarchar(100) rappresenta il codice del parametro.Identifica univocamente ogni record della tabella;

• d_parametro tipo: nvarchar(200) rappresenta la descrizione testuale estesa delcodice del parametro;

• v_parametro tipo: nvarchar(100) rappresenta il valore del parametro.Il valore del campo è il valore parametrizzato.

NoteLa tabella al momento è popolata da sole 5 entry:

• nomeDB che contiene il nome del database sorgente del quale si sta creando ildatawarehouse;

• inizio che contiene la data dal quale iniziare il caricamento dei dati per ilpopolamento iniziale;

• fromDate che viene utilizzato dagli script e indica da quale data estrarre i valoridal database sorgente per l’aggiornamento del periodo di consolidamento;

• CPG flag che ha il compito di individuare se occorre considerare anche la parteCPG per il popolamento del datawarehouse;

• priceList che viene utilizzato dagli script e indica a quale listino prezzi dei prodottifare riferimento per recuperare i costi del prodotto.

Appendice B

Appendice B: Mappaturacampi data warehouse

La seguente appendice contiene la mappatura di ogni campo dati del data warehouse:viene individuato il campo del database sorgente da quale prende il valore, e qualemeccanismo lo genera. Questo per dare una mappatura immediata di dove sono statereperite le informazioni contenute nel data warehouse e dove trovare il codice che logestisce. L’appendice è così organizzata:

• Asse Geografico: Tabella B.1;

• Asse Temporale: Tabella B.2;

• Asse Documento: Tabella B.3;

• Asse Prodotto: Tabella B.4;

• Asse Acquisto: Tabella B.5;

• Asse Soggetti: Tabella B.6;

• Tabella Fatti: Tabella B.7

B.1 Asse Geografico

Nome Tabella CampoDWH

Procedure o Fun-zione

Campo Sor-gente

Tabella Sorgen-te

N.I.

DWH_d_nielsen c_nielsen SP_DWH_VALORIPREDEFINITI

d_nielsen SP_DWH_VALORIPREDEFINITI

DWH_d_province c_provincia SP_DWH_VALORIPREDEFINITI

d_provincia SP_DWH_VALORIPREDEFINITI

DWH_d_regioni c_regione SP_DWH_VALORIPREDEFINITI

109

110APPENDICE B. APPENDICE B: MAPPATURA CAMPI DATA WAREHOUSE

d_regione SP_DWH_VALORIPREDEFINITI

DWH_d_stati c_nazione SP_DWH_VALORIPREDEFINITI

code OCRY

d_nazione SP_DWH_VALORIPREDEFINITI

code OCRY

DWH_d_areegeo c_area_geo SP_DWH_VALORIPREDEFINITI

d_area_geo SP_DWH_VALORIPREDEFINITI

DWH_d_areastati c_nazione SP_DWH_VALORIPREDEFINITI

code OCRY

c_area_geo SP_DWH_VALORIPREDEFINITI

territryID +trasformazio-ne

OTER

DWH_d_regstato c_regione SP_DWH_VALORIPREDEFINITI

c_nazione SP_DWH_VALORIPREDEFINITI

code OCRY

DWH_d_provarea c_provincia SP_DWH_VALORIPREDEFINITI

c_nielsen SP_DWH_VALORIPREDEFINITI

DWH_d_provreg c_provincia SP_DWH_VALORIPREDEFINITI

c_regione SP_DWH_VALORIPREDEFINITI

DWH_d_itaest c_ita_est SP_DWH_VALORIPREDEFINITI

d_ita_est SP_DWH_VALORIPREDEFINITI

DWH_d_areaie c_area_geo SP_DWH_VALORIPREDEFINITI

c_ita_est SP_DWH_VALORIPREDEFINITI

DWH_d_luogocon c_luogo_con SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

(County se sta-to IT, Coun-try se estero)+contatore

OCRD

d_luogo_con SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

MailAddres +d_provincia

OCRD +DWH_d_province

DWH_d_zone c_zona SP_DWH_VALORIPREDEFINITI

territryID OTER dove parent<> -1

d_zona SP_DWH_VALORIPREDEFINITI

descript OTER

Tabella B.1: origine campi DWH, asse geografico

B.2. ASSE TEMPORALE 111

B.2 Asse Temporale


Procedura o Fun-zione

Campo Sor-gente

Tabella Sorgen-te

N.I.

DWH_d_semestre c_semestre SP_DWH_VALORIPREDEFINITI

d_semestre SP_DWH_VALORIPREDEFINITI

DWH_d_quarter c_quarter SP_DWH_VALORIPREDEFINITI

d_quarter SP_DWH_VALORIPREDEFINITI

c_semestre SP_DWH_VALORIPREDEFINITI

DWH_d_mese c_mese SP_DWH_VALORIPREDEFINITI

d_mese SP_DWH_VALORIPREDEFINITI

c_quarter SP_DWH_VALORIPREDEFINITI

numGG SP_DWH_VALORIPREDEFINITI.sql

DWH_d_data c_date SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

DocDate a seconda del ti-po di documen-to: OINV (fat-tura) ODLN (bol-la) ORDR (ordine)ORIN(nota credi-to)

anno YEAR(DocDate) a seconda del ti-po di documen-to: OINV (fat-tura) ODLN (bol-la) ORDR (ordine)ORIN(nota credi-to)

mese MONTH(DocDate) a seconda del ti-po di documen-to: OINV (fat-tura) ODLN (bol-la) ORDR (ordine)ORIN(nota credi-to)


giorno DAY(DocDate) a seconda del ti-po di documen-to: OINV (fat-tura) ODLN (bol-la) ORDR (ordine)ORIN(nota credi-to)

numGiorno F_ COUNTDAYTabella B.2: origine campi DWH, asse temporale

B.3 Asse Documento



Campo Sor-gente

Tabella Sorgen-te

N.I.

DWH_d_tipodoc c_tipo_doc SP_DWH_VALORIPREDEFINITI

d_tipo_doc SP_DWH_VALORIPREDEFINITI

Tabella B.3: origine campi DWH, asse documento

B.4 Asse Prodotto



Campo Sor-gente

Tabella Sorgente N.I.

DWH_d_marchio c_marchio NId_marchio NIp_marchio NI

DWH_d_destinaz c_destinaz NId_destinaz NI

DWH_d_linprod c_lin_prod SP_DWH_CARICADATI eSP_DWH_CARICANEXT

se CPG = 1code

@O01_LINEA

d_lin_prod SP_DWH_CARICADATI eSP_DWH_CARICANEXT

se CPG= 1name

@O01_LINEA

B.4. ASSE PRODOTTO 113

DWH_d_catmerc c_cat_merc SP_DWH_CARICADATI eSP_DWH_CARICANEXT

se CPG = 1code

@O01_ SETTAR-TICOLO

d_cat_merc SP_DWH_CARICADATI eSP_DWH_CARICANEXT

se CPG= 1name

@O01_ SETTAR-TICOLO

DWH_d_grpmerc c_grp_merc SP_DWH_CARICADATI eSP_DWH_CARICANEXT

ItmsGrpCod OITB

d_grp_merc SP_DWH_CARICADATI eSP_DWH_CARICANEXT

ItmsGrpNam OITB

DWH_d_articoli c_articolo SP_DWH_CARICADATI eSP_DWH_CARICANEXT

ItemCode OITM

d_articolo SP_DWH_CARICADATI eSP_DWH_CARICANEXT

ItemName OITM

c_um SP_DWH_CARICADATI eSP_DWH_CARICANEXT

InvntryUoM OITM

c_marchio SP_DWH_CARICADATI eSP_DWH_CARICANEXT

NI

c_grp_merc SP_DWH_CARICADATI eSP_DWH_CARICANEXT

ItmsGrpNam OITB

c_cat_merc SP_DWH_CARICADATI eSP_DWH_CARICANEXT

se CPG = 1U_O01_SettArticolo

OITM

c_lin_prod SP_DWH_CARICADATI eSP_DWH_CARICANEXT

se CPG = 1U_O01_Linea

OITM

c_destinaz SP_DWH_CARICADATI eSP_DWH_CARICANEXT

NI


c_tipo SP_DWH_CARICADATI eSP_DWH_CARICANEXT

ItemClass OITM

Tabella B.4: origine campi DWH, asse prodotto

B.5 Asse Acquisto



Campo Sor-gente


DWH_d_canale c_can_vend SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1code

@O01_CANALI

d_can_vend SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1name

@O01_CANALI

DWH_d_ centri-distribuzione

c_cnt_dist SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1Code

@O01_CPGTREEdoveU_O01_CPGL=30

d_cnt_dist SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1Name


DWH_d_insegna c_insegna SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1Code


d_insegna SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1Name


DWH_d_gruppo c_gruppo SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1Code


c_gruppo SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1Name


B.6. ASSE SOGGETTI 115

DWH_d_centrale c_centrale SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1Code


d_centrale SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 1Name


Tabella B.5: origine campi DWH, asse acquisto

B.6 Asse Soggetti



Campo Sor-gente


DWH_d_ageprovv c_age_provv SP_DWH_CARICADATI eSP_DWH_CARICANEXT

slpCode OSLP

d_age_provv SP_DWH_CARICADATI eSP_DWH_CARICANEXT

slpName OSLP

DWH_d_ispprovv c_isp_provv SP_DWH_CARICADATI eSP_DWH_CARICANEXT

NI

d_isp_provv SP_DWH_CARICADATI eSP_DWH_CARICANEXT

NI

DWH_d_clifatt c_cli_fatt SP_DWH_CARICADATI eSP_DWH_CARICANEXT

CardCode OCRD dove Card-Type=’C’

d_cli_fatt SP_DWH_CARICADATI eSP_DWH_CARICANEXT

CardName OCRD dove Card-Type=’C’

c_cli_fatt_pr SP_DWH_ NOR-MALIZZAPRO-VINCIA

County seCountry è IT,Country sediverso

OCRD dove Card-Type=’C’


DWH_d_tipi c_tipo SP_DWH_CARICADATI eSP_DWH_CARICANEXT

SE CPG = 1code

@O01_TIPO MER-CATO

d_tipo SP_DWH_CARICADATI eSP_DWH_CARICANEXT

SE CPG = 1name

@O01_TIPO MER-CATO

DWH_d_catecon c_cat_econ SP_DWH_CARICADATI eSP_DWH_CARICANEXT

indCode OOND

d_cat_econ SP_DWH_CARICADATI eSP_DWH_CARICANEXT

indName OOND

DWH_d_grpcomm c_grp_comm SP_DWH_CARICADATI eSP_DWH_CARICANEXT

GroupCode OCRG

d_grp_comm SP_DWH_CARICADATI eSP_DWH_CARICANEXT

GroupName OCRG

DWH_d_clicon c_cli_con SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

CardCode OCRD dove Card-Type = ’C’

d_cli_con SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

CardName OCRD dove Card-Type = ’C’

c_cli_con_pr SP_DWH_ NOR-MALIZZAPRO-VINCIA


OCRD dove Card-Type = ’C’

c_zona SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

territory OCRD

d_luogo_con SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

c_luogo_con DWH_d_luogocondoved_luogo_con=MailAddres inOCRD

B.6. ASSE SOGGETTI 117


SE CPG = 1Code

@O01_CPGTREEdoveU_O01_CPGL=30e U_O01_CPGB=c_cli_con


SE CPG = 1Code


c_insegna SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

SE CPG = 1Code


c_centrale SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

SE CPG = 1Code


c_canale SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

SE CPG = 1U_O01

OCRD

c_grp_comm SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

GroupCode OCRD

c_cat_econ SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

IndustryC OCRD

c_cat_sco SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

discount + tra-sformazione

OCRD

c_cat_pro SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

NI

c_tipo SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

SE CPG = 1U_O01_ Tip-Merc

OCRD

c_age_a SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

SlpCode OCRD


d_age_a SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

Name OSLP dove Code=c_age_a

c_isp_a SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

SlpCode OCRD

d_isp_a SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

Name OSLP dove Code=c_isp_a

Tabella B.6: origine campi DWH, asse soggetti

B.7 Fatti

DWH_f_rows c_num_doc SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

DocEntry A seconda del fatto:OINV (fattura) OR-DR (ordine) ODLN(bolla) ORIN (notacredito)

c_num_riga SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

LineNum a seconda del fat-to: INV1 (fattu-ra) RDR1 (ordine)DLN1 (bolla) RIN1(nota credito)

c_ tipo_doc SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

ObjType +trasformazio-ne

A seconda del fatto:OINV (fattura) OR-DR (ordine) ODLN(bolla) ORIN (notacredito)

c_ tipo_riga SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

U_O01Oma +trasformazio-ne

A seconda del fat-to: INV1 (fattu-ra) RDR1 (ordine)DLN1 (bolla) RIN1(nota credito)

dt_doc SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

DocDate A seconda del fatto:OINV (fattura) OR-DR (ordine) ODLN(bolla) ORIN (notacredito)

B.7. FATTI 119

c_articolo SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

ItemCode a seconda del fat-to: INV1 (fattu-ra) RDR1 (ordine)DLN1 (bolla) RIN1(nota credito)

c_cli_fatt SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

CardCode A seconda del fatto:OINV (fattura) OR-DR (ordine) ODLN(bolla) ORIN (notacredito)

c_cli_fatt_pr SP_DWH_ NOR-MALIZZAPRO-VINCIA

OCRD cardCode=c_cli_fatt

c_cli_con SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

CardCode a seconda del fatto:ODLN (bolla)

c_cli_con_pr SP_DWH_ NOR-MALIZZAPRO-VINCIA

County seCountry è IT,Country sediverso o seNULL

OCRD CardCode=c_cli_con

c_age_provv SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

se CPG = 0SlpCode; conCPG = 1 ilprimo camponon nullo tra:U_O01aPr1,U_O01aPr2,U_O01aPr3 eSlpCode

OINV per SlpCodealtrimenti a se-conda del tipo didocumento INV1(fattura) DLN1(bolla) RDR1 (or-dine) RIN1 (notacredito) dove rispet-tivam U_O01lPr1o U_O01lPr2 oU_O01lPr3 =”AG”

c_isp_provv SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

NI


se CPG = 1Code



CPG = 1 Co-de



c_insegna SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

CPG = 1 Co-de


c_centrale SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

CPG = 1 Co-de


c_can_vend SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

CPG = 1U_O01_Canale

OCRD

f_bdg_cons SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

qt_doc SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

Quantity pertutti, altrimen-ti OpenQty (se diverso da0) per ordini econsegne

a seconda del fat-to: INV1 (fattu-ra) RDR1 (ordine)DLN1 (bolla) RIN1(nota credito)

qt_kg SP_DWH_ CAL-COLAKG

va_list SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

PriceBefDis a seconda del fat-to: INV1 (fattu-ra) RDR1 (ordine)DLN1 (bolla) RIN1(nota credito)

va_r_lordo SP_DWH_ NOR-MALIZZAPRO-VINCIA


OCRD cardCode=c_cli_fatt

vs_r_canale SP_DWH_ NOR-MALIZZASCONTI

se CPG =0allora 0

vs_r_agg SP_DWH_ NOR-MALIZZASCONTI

se CPG =0allora 0

vs_r_prom SP_DWH_ NOR-MALIZZASCONTI

se CPG =0allora 0

vs_r_altri SP_DWH_ NOR-MALIZZASCONTI

se CPG =0allora 0

B.7. FATTI 121

vs_r_tot SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

vs_r_altri+vs_r_prom+vs_r_agg+vs_r_canale+DiscPrcnt contrasformazio-ni

Per DiscPrcnt aseconda del fatto:OINV (fattura) OR-DR (ordine) ODLN(bolla) ORIN (notacredito)

va_r_netto SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

va_r_lordo–vs_r_tot

vs_t_tot SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

DiscPrcnt A seconda del fatto:OINV (fattura) OR-DR (ordine) ODLN(bolla) ORIN (notacredito)

va_t_fattfin SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

va_r_netto -vs_t_tot contrasformazio-ni

vp_age SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

Se non fat-tura, allora0 altrimentisomma degliU_O01ppr*totale di rigaal netto dellosconto di testa

Se fattura: INV1

vp_isp SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

NI

vc_std SP_DWH_ CAL-COLACOSTI

vc_eff SP_DWH_ CAL-COLACOSTI

vm_s SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

va_fattfin -vc_std

vm_e SP_DWH_CARICADATI2 eSP_DWH_CARICANEXT

va_fattfin -vc_eff

Tabella B.7: origine campi DWH, fatti

Glossario

Add-on Pprogramma non autonomo che interagisce con un altro programma perampliarne le funzioni. Ad esempio, un plugin per un software di grafica permettel’utilizzo di nuove funzioni non presenti nel software principale. Comunementeidentificato con il nome “Plugin” che a seconda dei programmi e delle piattaformesoftware viene chiamato con sinonimi diversi (come nel nostro caso).. 13, 123

API Application Programming Interface, letteralmente “Interfaccia di Programmazio-ne di un’applicazione”, è un insieme di procedure disponibili al programmatore,di solito raggruppate a formare un set di strumenti specifici per l’espletamentodi un determinato compito all’interno di un certo programma. Spesso con taletermine si intendono le librerie software disponibili in un certo linguaggio diprogrammazione. 125

Business Discovery È un modo tutto nuovo di fare le cose che mette l’utente alposto di comando. A differenza della Business Intelligence tradizionale, checoinvolge solo poche persone, la Business Discovery consente a tutti di creareanalisi approfondite. Gruppi di lavoro, reparti e intere business unit hannoaccesso ai dati di cui necessitano per adottare decisioni migliori.. 19, 123

Business Intelligence Insieme di processi per raccogliere e analizzare le informazionisul business aziendale, la cui finalità è il supporto alle decisioni e controllo delleprestazioni aziendali. I destinatari sono tutte quelle figure aziendali che possonoessere coadiuvate dall’analisi dei dati nel prendere decisioni o nel controllo difattori chiave del loro operare quotidiano. . 1, 123

Caso d’uso Tecnica usata nei processi di ingegneria del software per effettuare inmaniera esaustiva e non ambigua, la raccolta dei requisiti al fine di produrresoftware di qualità.Essa consiste nel valutare ogni requisito focalizzandosi sugli attori che interagi-scono col sistema, valutandone le varie interazioni. 26, 123

CRM Customers Relationship Management, letteralmente “gestione delle relazionicoi clienti” è legato al concetto di fidelizzazione dei clienti.In un’impresa "market-oriented" il mercato non è più rappresentato solo dalcliente, ma dall’ambiente circostante, con il quale l’impresa deve stabilire relazionidurevoli di breve e lungo periodo, tenendo conto dei valori dell’individuo/cliente,della società e dell’ambiente. Quindi l’attenzione verso il cliente è cruciale edeterminante. Per questo motivo il marketing management deve pianificare eimplementare apposite strategie per gestire una risorsa così importante.. 125

123

124 Glossario

Data warehouse Termine inglese traducibile con “magazzino di dati”, è un archivioinformatico contenente i dati di un’organizzazione, progettati per consentire diprodurre facilmente analisi e relazioni utili a fini decisionali-aziendali.Componenti essenziali di un sistema data warehouse sono anche gli strumentiper localizzare, estrarre, trasformare e caricare i dati, come pure gli strumentiper gestire un dizionario dei dati. Le definizioni di data warehouse consideranosolitamente questo ampio contesto.. 1, 123

DFM Dimensional Fact Model è un formalismo grafico specificatamente pensato persupportare la fase di modellazione concettuale in un progetto di data warehouse.Estremamente intuitivo e può essere utilizzato sia dagli analisti che utenti nontecnici.. 125

ERP Enterprise Resource Planning (letteralmente “pianificazione delle risorse d’impre-sa”, spesso abbreviato in ERP) è un sistema di gestione, chiamato in informaticasistema informativo, che integra tutti i processi di business rilevanti di un’azienda(vendite, acquisti, gestione magazzino, contabilità etc.).Con l’aumento della popolarità dell’ERP e la riduzione dei costi per l’ICT (In-formation and Communication Technology), si sono sviluppate applicazioni cheaiutano i business manager ad implementare questa metodologia nelle attivitàdi business come: controllo di inventari, tracciamento degli ordini, servizi per iclienti, finanza e risorse umane.. 125

ETL Espressione in lingua inglese che si riferisce al processo di estrazione, trasforma-zione e caricamento dei dati in un sistema di sintesi.I dati vengono estratti da sistemi sorgenti quali database transazionali, comunifile di testo o da altri sistemi informatici.. 125

In-memory Si intende che il sistema, nel nostro caso QlikView, gestisce i dati nellamemoria centrale. Garantisce maggior velocità rispetto ai sistemi che lavoranocon dati su memorie di massa(dischi rigidi), ma possono gestire moli di datimolto inferiori.. 12, 123

ODBC API standard per la connessione dal client al DBMS. È indipendente dailinguaggi di programmazione, dai sistemi di database e dal sistema operativo..125

SQL Structured Query Language è un linguaggio standardizzato per database basatisul modello relazionale (RDBMS) progettato per: creare e modificare schemidi database (DDL - Data Definition Language); inserire, modificare e gestiredati memorizzati (DML - Data Manipulation Language); interrogare i datimemorizzati (DQL - Data Query Language).Nonostante il nome, non si tratta dunque solo di un semplice linguaggio diinterrogazione, ma alcuni suoi sottoinsiemi si occupano della creazione, dellagestione e dell’amministrazione del database.. 125

Acronimi e Abbreviazioni

API Application Programming Interface. 76

CRM Customer Relationship Management. 9

DFM Dimensional Fact Model. 35

DLL Dynamic Link Library. 76

ERP Enterprise Resource Planning. 2

ETL Extract Transform Load. 9

IT Information Technology. 21

ODBC Open DataBase Connectivity. 15

PMI Piccole e Medie Imprese. 1

RDBMS Relational DataBase Management System. 15

SQL Structured Query Language. 3

125

Bibliografia

Riferimenti bibliograficiAgostino Lorenzi, Richelmo Giupponi. Informatica: sistemi operativi e reti per il

sistema informativo aziendale. Atlas.

Presentazione e Documentazione Aziendale. Soluzioni Software.

QlikTech, International. Cosa rende unico QlikView. QlikView White Paper, 2011.

Siti Web consultatiurl: http://www.runtime.it/it/soluzioni/sap-business-one.

url: http://technet.microsoft.com/it-it/sqlserver/.

url: http://en.wikipedia.org/wiki/Magic_Quadrant.

url: http://en.wikipedia.org/wiki/Dimensional_Fact_Model.

url: http://it.wikipedia.org/wiki/Enterprise_resource_planning.

url: http://it.wikipedia.org/wiki/Business_intelligence.

data warehouse. url: http://www.di.unipi.it/~giangi/CORSI/SISD/Lezioni/SISD2.pdf.

Soluzioni Software srl. url: http://www.soluzioni-sw.it.

127

http://www.runtime.it/it/soluzioni/sap-business-one

http://technet.microsoft.com/it-it/sqlserver/

http://en.wikipedia.org/wiki/Magic_Quadrant

http://en.wikipedia.org/wiki/Dimensional_Fact_Model

http://it.wikipedia.org/wiki/Enterprise_resource_planning

http://it.wikipedia.org/wiki/Business_intelligence

http://www.di.unipi.it/~giangi/CORSI/SISD/Lezioni/SISD2.pdf

http://www.di.unipi.it/~giangi/CORSI/SISD/Lezioni/SISD2.pdf

http://www.soluzioni-sw.it

Business Intelligence

Documents

Transcript of Business Intelligence