Università di Pisa
Facoltà di Economia
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea Specialistica in
Informatica per l'Economia e per l'Azienda
TESI DI LAUREA
ANALISI DEI COSTI, DEI VOLUMI E DELLE
TEMPISTICHE SUI TRASPORTI ATTRAVERSO
DASHBOARD QLIKVIEW
RELATORI
Prof. Antonio FRANGIONI
Dott. Luca CATTERMOL
CONTRORELATORE
Prof. Mirco NANNI
CANDIDATO
Francesco ISETTO
ii
RIASSUNTO
Nel seguenti lavoro di tesi, si presentano le fasi di progettazione e realizzazione di un data warehouse al fine di creare una reportistica di dati a consuntivo per l’analisi, il supporto e le future decisioni aziendali inerenti i costi, i volumi e le tempistiche dei trasporti di componentistica di motori diesel.
L’azienda che ha commissionato tale lavoro è la VM MOTORI, azienda facente parte del gruppo FIAT, costruttrice di motori diesel per autovetture.
Nel lavoro vengono mostrati l’analisi dei requisiti, la progettazione del data warehouse, l’analisi degli strumenti software utilizzati, le fasi del processo ETL (estrazione, trasformazione e caricamento) dei dati e i report creati per il caso di studio.
Il lavoro si conclude con un’analisi dei dati estrapolati dai report creati e degli eventuali sviluppi futuri.
iii
Indice
1. INTRODUZIONE 1
1.1. Rassegna della letterature 2
1.2. Contenuto della tesi 2
2. ETL 4 2.1. Extract 7 2.2. Trasform 7 2.3. Load 8 2.4. Data Warehouse 9 3. QLIKVIEW 13 4. CASI DI STUDIO 15 4.1. Daxo S.R.L 15 4.2. VM Motori S.P.A 16
4.3. Requisiti ed analisi del data base 16
4.3.1. Analisi sul processo dei trasporti 16
4.3.2. Data base operazionale 18
4.4. ETL e creazione del Data Warehouse 30
4.4.1. Specifica dei requisiti 31
4.4.2. Progettazione concettuale iniziale 33
4.4.3. Progettazione concettuale dei dati operazionali 33
4.4.4. Progettazione concettuale finale 36
4.4.5. Progettazione logica 36
4.5. Creazione dei dashboard 37
5. CONCLUSIONI E SVILUPPI FUTURI 48
Capitolo 1
INTRODUZIONE
Al giorno d’oggi, nell’attuale contesto sociale, economico e culturale, prendere decisioni corrette in tempi brevi, per le aziende di tutte le dimensioni, risulta essere un criterio sempre più fondamentale per avere successo ed essere competitivi.
L’aumento esponenziale delle informazioni a disposizione e le esigenze di prodotti e servizi di qualità spingono le aziende a riprogettare i processi; in quest’ottica la gestione e l’analisi delle informazioni diventano sempre più due fasi fondamentali.
Queste moli di dati che vengono elaborate e gestite, devono essere trasformate in informazioni e conoscenze chiare ed efficaci per la valutazione delle prestazioni di un determinato processo, da parte dei manager.
In queste fasi, le soluzioni e le tecnologie informatiche danno un aiuto allo sviluppo di indicatori chiari ed efficaci; il data warehouse è la tecnologia che permette di riorganizzare e sintetizzare le informazioni reperite dai sistemi operazionali, permettendo così di condurre analisi sui processi.
Il lavoro svolto presenta l’analisi, lo sviluppo e la progettazione di un data warehouse, attraverso i processi di Extract-Trasform-Load, e la creazione di dashboard per l’analisi sui costi, sui volumi e sulle tempistiche dei trasporti di parti di motori diesel.
Lo sviluppo di dashboard è servito a monitorare le due tipologie di trasporti presenti in azienda, la milk run e la fornitura standard; la prima riguarda l’ordine
CAPITOLO 1 - INTRODUZIONE
2
e la spedizione di componentistica bloccante per la catena di montaggio, per cui molto urgente, mentre la seconda riguarda l’ordine e la spedizione di componentistica non facente parte della milk run.
Scopo della creazione del data warehouse e del dashboard, è quello di dare a VM Motori S.P.A. uno strumento finalizzato all’analisi dei dati e delle informazioni in modo da poter riorganizzare o ristrutturare tutti i processi aziendali, dalla gestione del magazzino fino alla ricezione della componentistica ordinata.
1.1 Rassegna della letteratura
Per lo svolgimento della tesi si sono resi necessari richiami a dispense, articoli e forum. In particolare [Albano 08] e [Ruggieri 13] grazie ai quali è stato possibile creare logicamente il data warehouse e i dashboard attraverso un susseguirsi di passaggi chiari e lineari.
I forum della community di QlikView e [QlikView 14] hanno reso possibile la creazione fisica del data warehouse e dei dashboard; in particolare [QlikView 14] si è reso utile durante la procedura di E.T.L attraverso il linguaggio di scripting.
1.2 Contenuto della Tesi
Il progetto formativo commissionato da VM Motori S.P.A., riguarda la progettazione e lo sviluppo di un data warehouse con la creazione di alcuni dashboard per l’analisi dei costi, volumi e ritardi di spedizione di componentistica per la creazione di motori diesel.
Nella Tesi qui proposta, dopo un’analisi del data base di test consegnatomi, è stata affrontata la fase di progettazione del data warehouse, che ha rispettato le specifiche delineate in [Albano 08], a partire dalla progettazione concettuale iniziale dei data mart, corrispondente al processo da analizzare, fino alla produzione dello schema logico del data warehouse.
CAPITOLO 1 - INTRODUZIONE
3
Dopo la fase di progettazione è stato necessario, attraverso il linguaggio di script di QlikView, creare delle query SQL che permettessero di effettuare il processo di E.T.L. per il riempimento del data warehouse.
L’ultima fase è stata la creazione di più dashboard che permettessero di analizzare i dati del data warehouse, riguardanti costi, volumi e ritardi di consegna.
I capitoli successivi descrivono più dettagliatamente le varie fasi di progettazione e analisi dei dati reperiti del data base di test:
Capitolo 2 – viene presentata l’importanza del data warehouse e le fasi per la sua progettazione e caricamento di dati atti all’analisi
Capitolo 3 – viene presentato lo strumento utilizzato per la creazione dei dashboard utilizzati per le analisi
Capitolo 4 – vengono presentate le due società che hanno permesso lo svolgimento della tesi, oltre a tutte le procedure per il suo raggiungimento che vanno dalla progettazione del data warehouse alla creazione dei dashboard.
Capitolo 5 – viene effettuata un’analisi dei risultati ottenuti ed specificati eventuali sviluppi futuri.
Capitolo 2
E.T.L. E DATA WAREHOUSE
Ai giorni d’oggi l’informazione è un bene sempre più a valore crescente, necessario per pianificare e controllare le attività produttive; per questo motivo sistemi per l’estrazione, l’analisi e l’organizzazione automatica dei dati possono fornire un valido nonché fondamentale supporto nei processi decisionali umani.
Figura 2.1 Valore dell’informazione in funzione della quantità
I sistemi di supporto alle decisioni (Decision Support System) nascono proprio per la crescente esigenza di gestire questa mole di dati per scopi che vanno oltre l’elaborazione giornaliera; questi sono nati per aiutare l’uomo a prendere decisioni operative e strategiche a lungo termine.
I sistemi informativi hanno lo scopo di convertire dati in informazioni e di collezionarle, trasformarle e distribuirle.
CAPITOLO 2 – E.T.L. E DATA WAREHOUSE
5
Per poter fornire dati ed informazioni migliori e più utili ai soggetti decisori, è necessario comprendere i processi aziendali operativi e direzionali e la loro differenza; i primi utilizzano dati non aggregati e sono automatizzati, mentre i secondi utilizzano dati storici, non aggregati e non sono automatizzati.
I dati prodotti dai vari processi aziendali, possono essere classificati in base a ciò che rappresentano:
Operativi: informazioni necessarie per svolgere le attività operative quotidiane.
Controllo: informazioni di sintesi per il controllo delle attività da parte della direzione intermedia ed operativa.
Pianificazione: informazioni di sintesi e storiche per i processi decisionali di pianificazione strategica dell’alta direzione.
In base all’elaborazione effettuata sui dati operativi o di pianificazione, si può parlare di sistemi informativi On Line Transaction Processing (OLTP) e On Line Analytical Processing (OLAP); i primi utilizzano data base tradizionali e permettono di eseguire le semplici attività giornaliere quali la modifica o la lettura di dei dati; i secondi utilizzano i data warehouse e supportano l’analisi sui dati e i processi decisionali.
OLTP OLAP
Scopi Supporto operativo Supporto alle decisioni
Utenti Impiegati o tecnici Dirigenti ed analisti
Organizzazione Per settore Per soggetti
Usi 90% predefiniti 90% estemporanei
Dati Attuali, dettagli,
relazionali, specifici
Storici, sintetici, multidimesionali, integrati
Tipi di accesso Brevi transazioni con
letture e scritture
Letture con ricerche complesse
Numero utenti Alto Basso
Quantità di dati per attività Bassa Alta
Ottimizzazione Per transazioni Per analisi dati
Tabella 2.2 Differenze tra sistemi OLTP e OLAP
Secondo Bill Inmon il data warehouse è una raccolta di dati storici integrati, non volatili, organizzata per soggetti e finalizzata al recupero di informazioni di
CAPITOLO 2 – E.T.L. E DATA WAREHOUSE
6
supporto ai processi decisionali; per questo come scritto in [Albano 08], il data warehouse deve essere:
Tempificato: i dati hanno un interesse storico e quindi contengono una informazione sul tempo in cui si verificano certi eventi per consentire analisi di tendenza storica.
Integrato: i dati memorizzati nel data warehouse non provengono in genere da un’unica sorgente, ma sono il risultato di un lungo e costoso processo di integrazione di dati eterogenei
Statico: i dati vengono usati per operazioni di ricerca e non di modifica; la collezione viene aggiornata periodicamente con l’aggiunta di nuovi dati o con la rimozione di quelli ritenuti obsoleti.
Organizzato per soggetti: i data warehouse non contengono tutti i dati necessari per svolgere i processi, ma sono organizzati attorno ai dati che rappresentano aspetti quantitativi di soggetti di interesse per le analisi. Per il supporto alla decisioni: i data warehouse sono progettati in
funzione dell’analisi dei processi aziendali per valutare le prestazioni e per identificare possibili aree di intervento.
Il processo di data warehousing inizia dal recupero dei dati dalle sorgenti che possono essere interne, se derivanti dai processi aziendali, ed esterne se derivanti dall’ambiente esterno dove l’azienda opera. In seguito questi dati verranno normalizzati, trasformati e ripuliti da errori ed inconsistenze.
Tale processo di E.T.L. comporta un miglioramento della qualità e dell’integrazioni dei dati che popoleranno il data warehouse e che serviranno ad eseguire migliori analisi da parte dei soggetti decisori.
Una volta costituito il data warehous, attraverso strumenti specifici, sarà possibile effettuare analisi attraverso tabelle, report e/o dashboard di supporto alle decisioni aziendali future.
Il processo sopra descritto, è parte della business intelligence mostrata nell’immagine sotto (Fig. 2.3), rappresentante un tipica architettura.
CAPITOLO 2 – E.T.L. E DATA WAREHOUSE
7
Figura 2.3 Tipica architettura della Business Intelligence
2.1 Extract
La fase di estrazione è concettualmente la fase più semplice tra tutte, ed ha come obiettivo l’identificazione della corretta sotto-sequenza di dati che deve essere consegnata al processo.
Sulla base della tecnologia utilizzata e del volume dei dati considerati, questa fase risulta essere la più lunga per i seguenti aspetti.
1. Possibilità di estrarre dati duplicati
2. Per motivi politici e tecnologici di non investimento
In questa fase si deve scegliere se estrarre tutti i dati e processarli come se fossero stati precedentemente elaborati, o selezionare un’istanza di dati e successivamente confrontarla con un’istanza precedentemente estratta, cercando di evidenziare solo gli aggiornamenti dei dati.
Un’altra possibile soluzione è quella di andare a recuperare i file di log della sorgente, in modo che tutte le modifiche di transazioni vincolate vengano rilevate e possano essere riprodotte nel data warehouse.
Un punto finale nella fase di estrazione comporta la necessità di crittografare e comprimere i dati che vengono trasferiti dalla sorgente al data warehouse, per motivi di sicurezza e prestazioni di rete.
2.2 Trasform
La fase di trasformazione comporta la manipolazione e la pulizia dei dati precedentemente estratti, cercando di risolvere i conflitti e i problemi che si
CAPITOLO 2 – E.T.L. E DATA WAREHOUSE
8
possono essere presentati. I problemi che possono essere riscontrati possono essere di tre tipologie:
1. Problemi a livello di schema, 2. Problemi a livello di record 3. Problemi di valore delle istanze.
A livello di schema, fondamentalmente esistono due tipi di problemi da dover affrontare:
1. Conflitto dei nomi, dove uno stesso nome è usato per due oggetti differenti o viceversa.
2. Conflitto strutturale, dove differenti rappresentazioni di uno stesso oggetto sono in differenti sorgenti.
A livello di record, il tipico problema è quello di cercare di eliminare i record duplicati o i record che si contrappongono; oppure si può riscontrare granularità dei dati o problematiche della consistenza a livello temporale, creando ambiguità sul riconoscimento del record più aggiornato..
A livello di valore abbiamo il maggior numero di problematiche poichè fanno riferimento ai dati stessi delle istanze; in particolare:
1. Mancanza di dati che comporta ad avere il valore NULL.
2. Gestione delle chiavi e delle chiavi surrogate per la creazione del data warehouse.
3. Creazione di dati derivanti da aggregazioni.
4. Gestione della diversa formattazione dei dati, per esempio della data e dell’ora.
5. Gestione dello split e del merge dei dati 6. Codifica e normalizzazione dei dati
2.3 Load
E’ l’ultima fase, e fa riferimento al caricamento dei dati trasformati nel data warehouse.
La problematica riscontrabile riguarda il modo con cui caricare i dati; è possibile infatti, caricarli in massa attraverso le funzioni di un DBMS oppure caricarli
CAPITOLO 2 – E.T.L. E DATA WAREHOUSE
9
come una sequenza di righe. La prima soluzione è la più conveniente a livello economico e per questo la più usata.
Una seconda problematica riguarda il riconoscimento di un record come “nuovo” (inserimento per la prima volta) o se si tratta di un aggiornamento di dati di record già inseriti in precedenza; in questo caso, esistono funzioni specifiche per l’eliminazione, per esempio l’istruzione MERGE presente in Oracle.
2.4 Data Warehouse
Il data warehouse è un data base ottimizzato per contenere dati utili ai processi decisionali; si tratta di un database separato dal quello gestionale che serve per gestire il quotidiano.
Il data warehouse gestisce dati provenienti da sorgenti diverse e diventa una sorta di raccolta di dati storici, fondamentale per un soggetto decisore. Principalmente è composto da:
Fatti: che sono degli eventi di interesse per il processo decisore, per esempio le vendite. Un singolo fatto corrisponde ad un singolo record della tabella dei fatti, ognuno dei quali è composto da chiavi esterne verso le tabelle delle dimensioni e attributi che rappresentano le misure.
Misure: che denotano una proprietà numerica di un fatto e ne descrivono un aspetto di interesse per l’analisi, per esempio il valore del venduto. Dimensioni: che sono proprietà di un fatto che ne descrive una coordinata
di analisi, per esempio tipo del prodotto.
La sua progettazione, che parte dall’analisi delle specifiche operazionali di supporto alle decisioni, stabilisce:
1. una progettazione concettuale, in cui si decide quali informazioni devono essere raccolte e come devono essere organizzate;
2. una progettazione logica in cui si decide come rappresentare le informazioni attraverso il modello dei dati di un sistema che gestisce i data warehouse;
3. una progettazione fisica in cui si decide quali strutture di memorizzazione prevedere per agevolare le operazioni di analisi;
CAPITOLO 2 – E.T.L. E DATA WAREHOUSE
10
4. modalità di inserimento dei dati, cercando di risolvere i problemi derivanti dalla eterogeneità delle sorgenti e cercando di mantenerlo più aggiornato possibile.
Esistono fondamentalmente due modi per progettare un data warehouse:
il primo definisce il data warehouse a partire dai dati operazionali in modo che la raccolta dei requisiti venga fatta solo sulla struttura dei dati a nostra disposizione; questo modalità produce un risultato immediato, ma allo stesso tempo rischia di sacrificare dei requisiti di analisi che potrebbero essere necessari
il secondo definisce il data warehouse a partire dai requisiti di analisi corrispondenti alle esigenze del committente e successivamente si considerano le informazioni a nostra disposizione; questa modalità comporta il rischio di far immaginare al committente delle soluzioni che alla fine, per mancanza di dati, non sono attuabili
Entrambe queste modalità presentano, quindi, vantaggi e svantaggi, e per questo motivo una terza modalità di progettazione, detta ibrida, può essere implementata poichè definisce i data warehouse considerando allo stesso tempo sia i requisiti di analisi sia i dati operazionali a nostra disposizione.
La soluzione ibrida, utilizzataanche nel seguente progetto di tesi, si basa su cinque punti fondamentali:
1. Raccolta e analisi dei requisiti
2. Progettazione concettuale iniziale dei data mart
3. Progettazione concettuale dei data mart dai dati operazionali 4. Progettazione concettuale finale dei data mart
5. Progettazione logica dei data mart e del data warehouse
La raccolta e l’analisi dei requisiti comporta l’analisi dei processi aziendali e dei dati operazionali a nostra disposizione, e permetterà di ottenerne una descrizione.
Un data mart contiene un'immagine dei dati che permette di formulare strategie sulla base degli andamenti passati e normalmente si colloca a valle di un data
CAPITOLO 2 – E.T.L. E DATA WAREHOUSE
11
warehouse; proprio nella seconda fase vengono creati degli schemi concettuali iniziali dei data mart utili ad avere una descrizione formale dei requisiti.
Nella terza fase si cerca di analizzare lo schema dei dati operazionali per poter definire degli schemi concettuali candidati; questi, nella quarta fase di progettazione, vengono confrontati con gli schemi iniziali e vengono definiti i così detti schemi concettuali definitivi.
L’ultima fase della progettazione, comporta la creazione dello schema relazionale del data warehouse a partire dagli schemi finali dei data mart; questa fase si divide in due sottofasi non disgiunte, nella prima si crea per ogni singolo data mart, lo schema relazione corrispondente, decidendo se realizzarlo come schema a stella e a fiocco di neve, nella seconda fase si deve decidere se combinare le tabelle dei fatti con le stesse dimensioni o combinare le tabelle delle dimensioni comuni per creare un unico schema del data warehouse.
CAPITOLO 2 – E.T.L. E DATA WAREHOUSE
12
Capitolo 3
QLIKVIEW
QlikView è un software di Business Intelligence sviluppato dall’azienda svedese QlikTech, fondata nel 1993.
Attraverso questo tool è possibile ottenere una panoramica di dati ampi e complessi e scoprire le relazioni tra essi poiché utilizza una tecnologia associativa che consente di creare un’interfaccia unica per le presentazioni interattive e l’analisi di dati.
QlikView gestisce i dati in maniera del tutto simile ai processi umani di elaborazione dei problemi matematici eseguendo connessioni graduali nelle informazioni che vengono successivamente elaborate.
La semplice interfaccia utente di QlikView, visuale e interattiva, permette agli utenti di aver accesso istantaneo sia a misure aggregate al massimo livello che ai dati di dettaglio, scoprendo informazioni inattese e strategiche nascoste nei sistemi gestionali.
La tecnologia brevettata QlikTech, permette manipolazioni istantanee di grandi moli di dati in memoria su hardware a basso costo, rendendo possibile, economicamente e in pochi giorni, lo sviluppo di estese, puntuali e sofisticate applicazioni analitiche con i relativi report.
Con QlikView è possibile:
Creare un’interfaccia utente flessibile per un data warehouse Ottenere un’istantanea che rispecchia le relazioni tra i dati Realizzare presentazioni basate sui dati
CAPITOLO 3 – QLIKVIEW
14
Creare grafici e tabelle dinamiche Eseguire analisi statistiche
Collegare descrizioni e applicazioni multidimensionali ai propri dati Costruire un sistema personalizzato
Creare nuove tabelle, che uniscono informazioni da molte origini dati Creare sistemi di business intelligence personalizzati
QlikView è in grado di gestire l’integrazione di tutti i formati di dati, dalle connessioni ODBC, ai dati esportati in formato testo, ai dati MS Excel, a quelli XML, a quelli acceduti in modalità FTP o http.
Una funzionalità molto potente di QlikView, è la sua capacità di combinare dati provenienti da diverse sorgenti in un unico documento, oltre che alle lettura di dati da diverse sorgenti ODBC o dati provenienti da Internet e contenuti di altri file.
Attraverso un editor di Script, è possibile recuperare i dati da una o più sorgenti, selezionando i campi e le tabelle da caricare. Inoltre, durante il caricamento, è anche possibile modificare la struttura dei dati utilizzando istruzioni ed espressioni specifiche.
Durante l’esecuzione dello script, QlikView identifica i campi comuni provenienti dalle diverse sorgenti in modo da associarli; alla fine del caricamento è possibile visualizzare la struttura formatasi attraverso il visualizzatore tabellare. Una volta caricati i dati, questi vengono salvati nel documento QlikView; questa operazione rappresenta il fulcro delle funzionalità ed è caratterizzata dal modo illimitato in cui vengono associati i dati, da un vasto numero di dimensioni possibili, dalla sua velocità di analisi e dal suo formato compatto. Quando viene aperto il documento QlikView, i dati vengono gestiti dalla RAM.
Altro punto di forza di QlikView è la semplicità con cui è possibile creare report e dashboard per l’analisi di dati precedentemente caricati o aggregati durante il processo di inserimento di grafici.
Capitolo 4
CASO DI STUDIO
Una volta definito il processo standard per la creazione del data warehouse e una panoramica generale del software utilizzato per la creazione dei report, si presentano le aziende che hanno permesso questo progetto formativo e il caso di studio.
4.1 Daxo SRL
Daxo Mobile & Rfid è una società operante nel settore delle Information and Communication Technologies (ICT), specializzata nella realizzazione di piattaforme software per soluzioni Mobile, RFID e Wireless.
L'RFID, Radio Frequency IDentication, con l'ausilio di palmari industriali offre un valido aiuto per l'identificazione, la tracciabilità e la rintracciabilità di merci, attività, mezzi e asset lungo l’intera catena del valore, permettendo al personale operativo di una azienda di interagire con i dati aziendali in qualsiasi momento, attraverso connessioni via cavo, Wi-Fi e GPRS.
Tra i vari software sviluppati, Daxo ha supportato il miglioramento dei processi, per VM Motori, in ambiente Supply Chain proponendo una soluzione WEB based in grado di:
snellire richieste di prenotazione sia da parte del fornitore (mezzi di terzi) che da parte di VM (mezzi propri),
bilanciare, tramite un calendario e turni di lavoro, le fasce orarie disponibili per il ritiro o la consegna del materiale,
CAPITOLO 4 – CASO DI STUDIO
16
organizzare, tramite invio di mail o sms, solleciti ed avvertimenti sullo stato della prenotazione e possibili ritardi sull’attività del giorno,
automatizzare tutti i flussi comunicativi con i fornitori, eliminando errori e quasi tutte le attività su carta.
4.2 VM Motori SPA
VM Motori è una società nata a Cento nel 1947 e facente parte del gruppo Fiat Group Automobiles (FGA) dal 2014; l’azienda è leader nel settore della motoristica, specializzata nella creazione di motori diesel.
VM Motori gestisce tramite la piattaforma Daxo il riordino dei componenti necessari all’assemblaggio dei motori che vende ai suoi clienti per vari modelli di auto, garantendo la tracciabilità, in produzione, di ogni singolo componente. La piattaforma DAXO acquisisce i dati di produzione del giorno precedente ed in base ai consumi reali emette in automatico ordini ai suoi fornitori.
I fornitori accedono ad un’area a loro dedicata della piattaforma web Daxo tramite la quale possono preparare il materiale da etichettare con TAG RFID, prenotare uno slot di consegna e utilizzare altre funzionalità propedeutiche alla consegna.
4.3 Requisiti ed analisi del database
4.3.1 Analisi sul processo dei trasporti
In una catena di montaggio il tempestivo rifornimento, riordino di componenti atti alla costruzione di motori diesel è un punto fondamentale, se non principale, per il corretto funzionamento dell’intera supply chain.
Grazie alla piattaforma Daxo ed alla ricerca di in continuo miglioramento aziendale e procedurale, ha portato l’azienda VM Motori ad individuare nei trasporti dei componenti un punto chiave, nonché punto dove poter apportare migliorie; questo visti i costi che incidono in maniera importante sulla redditività aziendale, circa 2.000.000 € annui.
CAPITOLO 4 – CASO DI STUDIO
17
Costi relativi al milk run
Costi relativi alle forniture standard
La prima tipologia di costi si riferisce ai trasporti interni di materiale, per esempio dal magazzino alla catena di montaggio; questa tipologia di trasporto deve essere molto veloce infatti il materiale ordinato il giorno “x”, deve essere consegnato il giorno “x+1”.
La fornitura standard è definita come l’insieme di tutti i componenti non facenti parte del trasporto milk run.
Ogni volta che si necessità di componenti per mantenere attiva la catena di montaggio, viene fatto un ordine di materiale, ed una volta che è disponibile viene creata un documento di trasporto con casuale “Acquisti Lista Carico” contenente tutti i dati necessari al nostro studio.
Il documento di trasporto è suddiviso da una testata contente tutti i dati inerenti a volumi, costi e date di spedizione, e da un corpo dove è possibile vedere la tipologia di componente ordinato.
La necessità effettiva di VM Motori è quella di monitorare i costi effettivi e presunti delle due tipologie di trasporti, in modo da poter verificare se intervenendo su determinati aspetti questi costi posso calare.
I parametri che sono stati presi in considerazione per lo studio, sono dati presenti nel database di VM Motori, che fanno capo ai dati presenti nella testata e nel corpo dei documenti di trasporto; questi sono:
I volumi del materiale trasportato I costi dei trasporti presunti I costi dei trasporti effettivi La data di spedizione presunta La data di spedizione effettiva
1 Volumi effettivi di spedizione in base al corriere, al mese e alla tipologia di spedizione
2 Costi effettivi e presunti di spedizione in base al corriere, al mese, alla tipologia di spedizione ed al componente
CAPITOLO 4 – CASO DI STUDIO
18
3 Date effettive e presunte di spedizione in base al corriere, al , alla tipologia di spedizione ed al componente
Tabella 4.1 Requisiti di analisi del processo dei trasporti
4.3.2 Database operazionale
Il database operazione complessivo di VM Motori è composto da oltre 100 tabelle, ma di seguito verranno mostrate solamente quelle relative alle analisi previste dai requisiti; verranno evidenziate le chiavi primarie e le chiavi esterne, in particolare quelle verso le altre tabelle riferite ai requisiti ed alcune di aspetti particolari.
In ogni tabella descritta sotto, la chiave primaria è identificata dal campo con nome “ID”.
Tabella Article:
Contiene tutti i componenti per la creazione dei motori diesel e le relative informazioni sulle quantità a stock, la descrizione la data di inserimento del pezzo etc.
CAPITOLO 4 – CASO DI STUDIO
19
I campi della tabella sono:
ID, chiave primaria che identifica l’articolo;
EXTERNAL_CODE, codice di identificazione esterno;
CREATION_DATE, data di inserimento dell’articolo nel database; UPDATE_DATE, data di modifica dei dati dell’articolo;
CODE, codice identificativo dell’articolo; COLOR, colore del pezzo;
DESCRIPTION, descrizione del componente;
LABELLING_TYPE, tipologia di cartellino da attaccare al componente; MAX_STOCK_QUANTITY, quantità massima per essere stoccata; MIN_REORDER_LOT, quantità minima da riordinare;
MIN_STOCK_QUANTITY, quantità minima da essere stoccata; NOTE, note aggiuntive;
QTY_CONF, quantità confezionata;
REORDER_POINT, punto minimo per il riordino dell’articolo; ARTICLE_SIZE, dimensione dell’articolo;
STYLE, stile dell’articolo;
TYPOLOGY, tipologia dell’articolo;
COMPANY_ID, chiave esterna alla tabella company;
CREATION_WORKER_ID, chiave esterna verso la tabella worker che identifica il lavoratore che ha inserito l’articolo;
UPDATE_WORKER_ID, chiave esterna verso la tabella worker che identifica il lavoratore che ha modificato l’articolo;
LOT_TYPE_ID, chiave esterna verso la tabella lot type che identifica il tipo del lotto;
MERCHANDISING_GROUP_ID, chiave esterna verso merchandising group;
UM_CONF_ID, chiave esterna verso la tabella delle unità di misura; UM_STOCK_ID, chiave esterna verso la tabella delle unità di misura; UM_DOC_ID, chiave esterna verso la tabella delle unità di misura; MODEL_ID, chiave esterna verso la tabella dei modelli;
CAPITOLO 4 – CASO DI STUDIO
20
ARTICLE_TYPE, tipologia dell’articolo;
STATISTICAL_GROUP_ID, chiave esterna verso la tabelle delle statistiche.
Tabella Doc_causal:
Contiene tutte le possibili causali dei documenti, per esempio “Lista di Prelievo”, “Acquisti Lista Carico” o “Bolla di Acquisto”.
Figura 4.3 Tabella Doc_Causal
I campi della tabella sono:
ID, chiave primaria che identifica la causale del documento; EXTERNAL_CODE, codice di identificazione esterno;
CREATION_DATE, data di inserimento della causale nel database; UPDATE_DATE, data di modifica dei dati della causale;
CODE, codice identificativo della causale del documento; DESCRIPTION, descrizione della causale del documento;
ERASABLE, identifica se il documento è cancellabile oppure no; VISIBLE, dice se un documento è visibile oppure no;
COMPANY_ID, chiave esterna alla tabella company;
CREATION_WORKER_ID, chiave esterna verso la tabella worker; UPDATE_WORKER_ID, chiave esterna verso la tabella worker;
DOC_NUMBER_TYPE_ID, chiave esterna verso la tabella Doc_number_type;
CAPITOLO 4 – CASO DI STUDIO
21
Tabella Doc_header:
Contiene la testata del documento con tutti i dati inerenti ai costi, volumi e date di trasporto oltre ad un insieme di informazioni tipo il centro di costo, il mittente il destinatario e i pesi del materiale spedito.
CAPITOLO 4 – CASO DI STUDIO
22
I campi della tabella sono:
ID, identificativo della testata del documento;
EXTERNAL_CODE, codice esterno di identificazione; CREATION_DATE, data di creazione della testata; UPDATE_DATE, data di modifica delle testata; BOOKING_TYPE, tipologia di prenotazione; CODE, codice identificativo;
CONVERSION_FACTOR, corrisponde al fattore di conversione; DOC_DATE, contiene la data del documento;
DOC_NUMBER, corrisponde al numero del documento; DOC_VERSION, corrisponde alla versione del documento;
EFFECTIVE_DELIVERY_DATE, corrisponde alla data effettiva di spedizione;
END_TIME, corrisponde alla data finale del documento;
EXPECTED_DELIVERY_DATE, corrisponde alla data presunta di spedizione;
EXPORTED, dice se il materiale è esportabile oppure no;
EXTERNAL_DOC_DATE, corrisponde alla data esterna del documento; EXTERNAL_DOC_NUMBER, identifica il numero esterno del
documento;
NOTE, sono note aggiuntive;
PACKS_NUMBER, corrisponde al numero di pacchetto per spedizioni multiple;
PRODUCTION_LINE, identifica la linea di produzione;
PROGRESSIVE_NUMBER, è il numero progressivo delle pagine; PROTOCOL, corrisponde al protocollo del documento;
REGISTRATION_NUMBER, corrisponde al numero di registrazione del documento;
REGISTRATION_NUMBER_TIME, identifica la data in cui il documento è stato registrato;
CAPITOLO 4 – CASO DI STUDIO
23
URGENT, dice se la spedizione è urgente oppure no; YEARS, corrisponde all’anno
COMPANY_ID, chiave esterna alla tabella company;
CREATION_WORKER_ID, chiave esterna verso la tabella worker; UPDATE_WORKER_ID, chiave esterna verso la tabella worker; CDC1_ID, chiave esterna alla tabella centro di costo;
CDC2_ID, chiave esterna alla tabella centro di costo; CURRENCY_ID, chiave esterna alla tabella delle valute;
DEPARTMENT_ID, chiave esterna verso la tabelle delle partenze
DOC_CAUSAL_ID, chiave esterna verso la tabella delle causali dei documenti;
DOC_HEADER_REFERENCE_ID, chiave esterna verso la stessa tabella doc_header per identificare il documento successivo alla causale attuale, per esempio da ordine di lavoro a lista di prelievo;
DOC_OPERATOR_ID, chiave esterna per identificare l’operatore; FOR_ADDRESS_ID, chiave esterna verso la tabella indirizzo;
FOR_INTERLOCUTOR_ID, chiave esterna verso la tabella interlocutore; FROM_ADDRESS_ID, chiave esterna verso la tabella indirizzo;
FROM_INTERLOCUTOR_ID, chiave esterna verso la tabella interlocutore;
INVENTORY_PERIOD_ID, chiave esterna verso la tabella inventory; LAYOUT1_ID, chiave esterna verso la tabella del layout;
LAYOUT2_ID, chiave esterna verso la tabella del layout;
MISSION_HEADER_REFERENCE_ID, chiave esterna verso la tabella della testata della missione;
MODEL_ID, chiave esterna verso la tabella del modello; PACK_ID, chiave esterna verso la tabella del tipo pacchetto; ROUTE_ID, chiave esterna verso la tabella della rotta; TO_ADDRESS_ID, chiave esterna verso la tabella indirizzo;
TO_INTERLOCUTOR_ID, chiave esterna verso la tabella interlocutore; ADDRESS_ID, chiave esterna verso la tabella indirizzo;
CAPITOLO 4 – CASO DI STUDIO
24
EXPECTED_TRASPORT_COST, corrisponde ad i costi attesi del trasporto;
EFFECTIVE_TRANSPORT_COST, corrisponde a i costi effettivi del trasporto;
VOLUME, contiene il volume in m3
delle componenti trasportate
TRASPORT_CAUSAL_ID, chiave esterna verso la tabella delle causali di trasporto;
PORT_ID, chiave esterna verso la tabella port;
NET_WEIGHT, corrisponde al peso netto della spedizione; JOB_ID, chiave esterna verla la tabella delle commesse; GROSS_WEIGHT, corrisponde al peso lordo della spedizione;
EXPECTED_COURIER_ID, chiave esterna verso le tabella interlocutor per identificare il corriere presunto;
DELIVERY_NOTE_1, note sulla spedizione; DELIVERY_NOTE_2, note sulla spedizione;
DELIVERY_CASH_AMOUNT, corrisponde all’importo in contanti della spedizione;
DELIVERY_CASH_TYPE, corrisponde alla tipologia di contanti della spedizione.
Tabella Doc_row:
Contiene il corpo del documento di trasporto, in particolare gli articoli che sono stati spediti, le quantità ed altri dati.
CAPITOLO 4 – CASO DI STUDIO
25
Figura 4.5 Tabella Doc_row
I campi della tabella sono:
ID, chiave primaria che identifica la riga;
EXTERNAL_CODE, codice esterno di identificazione; CREATION_DATE, data di creazione del record; UPDATE_DATE, data di modifica del record;
CAPITOLO 4 – CASO DI STUDIO
26
CONVERSION_FACTOR, fattore di conversione; DISCOUNT1, sconto da poter applicare;
DISOCUNT2, sconto da poter applicare; DISCOUNT3, sconto da poter applicare; DISOCUNT4, sconto da poter applicare; DISCOUNT5, sconto da poter applicare;
DISCOUNT_VALUE, valore delle sconto da poter applicare; DOC_DATE, data del documento;
DOC_ROW_NUMBER, numero di righe del documento; EFFECTIVE_DELIVERY_DATE, data effettiva di spedizione; EXPECTED_DELIVERY_DATE, data presunta di spedizione; EXPORTED, flag per dire se un articolo è esportabile o no; EXTERNAL_DOC_ROW_NUMBER, numero di righe esterno; LOT_CODE, codice del lotto;
LOT_EXPIRY_DATE, data di scadenza del lotto; NOTE, note aggiuntive;
PACK_CODE, codice del pacco;
PACK_NOTE, note aggiuntive del pacco;
PRICE_CURRENCY, campo che si riferisce al costo della riga;
PRICE_CURRENCY_DOC, campo che si riferisce al costo del doumento; PRIORITY, priorità dell’articolo;
PROTOCOL, protocollo del documento; QTY_DELIVERED, quantità spedita; QTY_ORDERED, quantità ordinata; QTY_RESERVED, quantità riservata; QTY_TRANSFER, quantità trasferita;
QTY_UM_DOC, quantità della riga del documento che deve essere processata;
QTY_UM_STOCK, quantità utilizzata per il calcolo delle giacenze COMPANY_ID, chiave esterna verso la tabella company;
CAPITOLO 4 – CASO DI STUDIO
27
UPDATE_WORKER_ID, chiave esterna verso la tabella worker;
ALTERNATIVE_ARTICLE_ID, chiave esterna verso la tabella articolo, per identificare un articolo alternativo rispetto a quello richiesto;
ARTICLE_ID, chiave esterna verso la tabella articolo; CDC1_ID, chiave esterna alla tabella centro di costo; CDC2_ID, chiave esterna alla tabella centro di costo;
DOC_HEADER_ID, chiave sterna verso la testata del documento;
DOC_HEADER_REFERENCE_ID, chiave sterna verso la testata del documento che fa riferimento ad un’altra testata precedente;
DOC_ROW_REFERENCE_ID, chiave sterna verso la stessa tabella doc_row;
DOC_ROW_TYPE_ID, chiave esterna verso la tabella che identifica la tipologia della riga;
DOC_STATUS_ID, chiave esterna verso lo status del documento; FOR_ADDRESS_ID, chiave esterna verso la tabella indirizzo; FROM_ADDRESS_ID, chiave esterna verso la tabella indirizzo; LAYOUT1_ID, chiave esterna verso la tabella del layout;
LAYOUT2_ID, chiave esterna verso la tabella del layout; LOT_ID, chiave esterna verso la tabella dei lotti;
ORDER_DOC_ROW_ID, chiave esterna che identifica l’ordine; PACK_ID, chiave esterna che identifica un pacchetto;
PARENT_DOC_ROW, riga "padre" dalla quale è stata generata la riga attuale
ROUTE_ID, chiave esterna verso la tabella rotta;
TO_ADDRESS_ID, chiave esterna verso la tabella indirizzo; UM_DOC_ID, unità di misura del documento;
UM_STOCK_ID, unità di modifica dello stock;
VEHICLE_ID, chiave esterna che identifica il veicolo che effettuerà la spedizione;
WAREHOUSE1_ID, chiave esterna per identificare il magazzino; WAREHOUSE2_ID, chiave esterna per identificare il magazzino;
CAPITOLO 4 – CASO DI STUDIO
28
WH1_CAUSAL_ID, chiave esterna che identifica la causale di richiesta del magazzino;
WH2_CAUSAL_ID, chiave esterna che identifica la causale di richiesta del magazzino;
WORK_CYCKE_ID, chiave esterna che serve ad identificare il ciclo produttivo di riferimento che ha richiesto il componente;
SERIAL_NUMBER, serial number dell’articolo spedito; LOCKED, flag per identificare se l’articolo è bloccata o no;
PRINTED, flag per vedere se il documento è stato stampato oppure no; JOB_ID chiave esterna verso la tabella commessa.
Tabella Interlocutor:
Contiene li interlocutori dei vari cicli produttivi e i corrieri che gestiscono le spedizioni milk run e standard; inoltre contiene informazioni generali tipo e-mail, indirizzo, codice fiscale e fax dei corrieri o degli interlocutori.
CAPITOLO 4 – CASO DI STUDIO
29
I campi presenti nella tabella sono:
ID, identificativo del record interlocutore/corriere;
EXTERNAL_CODE, codice esterno che identifica l’interlocutore/corriere; CREATION_DATE, data in cui è stata inserito il record;
UPDATE_DATE, data in cui è stato modificato il record;
BIRTH_DATE, data di inizio collaborazione con l’interlocutore/corriere; BIRTH_PLACE, sede operativa dell’interlocutore/corriere;
CODE, codice parlante che identifica l’interlocutore/corriere; CUSTOMER, flag per identificare se si tratta di un cliente; DESCRIPTION, descrizione dell’interlocutore/corriere;
E-MAIL, e-mail da utilizzare per contattare dell’interlocutore/corriere; FAX, fax da utilizzare per contattare dell’interlocutore/corriere;
FISCAL_CODE, codice fiscale o partita iva dell’interlocutore/corriere; HOME_PHONE, numero fisso da utilizzare per contattare
dell’interlocutore/corriere;
MOBILE_PHONE, numero di cellulare da utilizzare per contattare dell’interlocutore/corriere;
NATIONALITY, nazionalità dell’interlocutore/corriere; NOTE, note aggiuntive;
OFFICE_PHONE, numero dell’ufficio da utilizzare per contattare dell’interlocutore/corriere
OPERATOR, flag che identifica se si tratta di un operatore; PRINT_CODE, codice stampato;
PROVIDER, flag per identificare se si tratta di un fornitore; VAT_CODE, partita iva
WEB_SITE, sito web dell’interlocutore/corriere;
COMPANY_ID, chiave esterna verso la tabella compagnia;
CREATION_WORKER_ID, chiave esterna verso la tabella worker; UPDATE_WORKER_ID, chiave esterna verso la tabella worker;
INTERLOCUTOR_CATEGORY_ID, chiave esterna verso la categoria di interlocutore/corriere;
CAPITOLO 4 – CASO DI STUDIO
30
MASTER_INTERLOCUTOR_ID, id del cliente di riferimento, utilizzato per dare una gerarchia agli interlocutori
COURIER, flag per definire se si tratta di un corriere oppure no;
PRINT_ENABLE, flag per l’interlocutore/corriere è abilitato a stampare i documenti;
ZIP_CODE, cap della sede legale dell’interlocutore/corriere;
STREET_NUMBER, numero civico della sede legale dell’interlocutore/corriere;
SALE_CAUSAL_ID, chiave esterna verso la tabella che corrisponde alla causale della vendita;
PROVINCE, provincia della sede legale dell’interlocutore/corriere; PRICE_LIST_ID, chiave sterna verso la tabella del listino prezzi; MINIMUM_TAXABILITY, valore minimo tassabile;
COURIER_ITERLOCUTOR_ID, chiave sterna verso la stessa tabella interlocutore
COURIER_CUSTOMER_RATE, prezzo del corriere verso il cliente;
COURIER_CUSTOMER_CODE, a quale tipologia di spedizione appartiene il corriere;
COUNTRY, paese della sede legale dell’interlocutore/corriere; CITY, città della sede legale dell’interlocutore/corriere;
ADDRESS, indirizzo della sede legale dell’interlocutore/corriere.
4.4 ETL e creazione di un Data Warehouse
Una volta noti i requisiti di analisi e presa in considerazione le tabelle della base di dati operazionale, può essere progettato e realizzato il data warehouse. Di seguito, verranno descritti tutti i relativi passi necessari.
Partendo dall’analisi dei requisiti alla progettazione concettuale iniziale e passando dalla progettazione concettuale dai dati operazionali, e dalla progettazione concettuale finale si arriverà alla progettazione logica corrispondente al data warehouse.
CAPITOLO 4 – CASO DI STUDIO
31
4.4.1 Specifica dei requisiti
Dall’analisi dei requisiti esposti nel capitolo precedente, si producono le specifiche iniziali sotto riportate per evidenziare la granularità dei fatti, le dimensioni e le misure di interesse; in particolare il fatto che prenderemo in considerazione riguarda il trasporto dei componenti.
Fatto Trasporti N° Requisito di Analisi Dimensioni Misure
1
Volumi effettivi di spedizione in base al corriere, al mese, alla tipologia di spedizione per una determinata causale di spedizione Corriere (descrizione, tipo), Causale (descrizione) Volume 2 Costi effettivi e presunti di spedizione in base al corriere, al mese, alla tipologia di spedizione ed al componente per una determinata causale di spedizione Corriere (descrizione, tipo), Articolo (descrizione), Causale (descrizione)
Costi effettivi, costi presunti
3
Date effettive e
presunte di spedizione in base al corriere, al mese, alla tipologia di spedizione ed al componente per una determinata causale di spedizione Corriere (descrizione, tipo), Articolo (descrizione), Causale (descrizione) Data effettiva di spedizione, data presunta di spedizione
CAPITOLO 4 – CASO DI STUDIO
32
La granularità del fatto e delle relative dimensioni, corrispondono rispettivamente al singolo trasporto, ai singoli corrieri, al mese in cui è stata effettuale la spedizione e la tipologia di spedizione.
Dopo questa prima analisi andiamo a descrivere le dimensioni relative al fatto di nostro interesse
Dimensioni di interesse Nome dimensione Descrizione della dimensione
Corriere Nome del corriere che effettua la spedizione
Corriere Tipologia di spedizione, milk run o standard
Articolo Nome del componente che è stato spedito
Causale Tipologia di richiesta effettuata
Una volta definite le dimensioni andiamo ad analizzare gli attributi di ognuna di esse.
Attributi delle dimensioni Dimensione Attributo Descrizione
Corriere Descrizione Corrisponde al nome dello spedizioniere Corriere Tipo Corrisponde alla tipologia di spedizione
milk run o standard
Articolo Descrizione Corrisponde al nome dell’articolo
Causale Descrizione
Corrisponde alla tipologia di richiesta che specifica l’operazione del documento
Dopo aver definito gli attributi delle dimensioni, passiamo a descrivere le misure del fatto trasporto.
CAPITOLO 4 – CASO DI STUDIO
33
Misure del fatto Misura Descrizione Aggregabilità Derivata Volume Volume della merce
spedita Additiva NO
Costi presunti Costi presunti della
spedizione Additiva NO
Costi effettivi Costi effettivi della
spedizione Additiva NO
Data presunta di spedizione
Data in cui si presume che il materiale venga spedito
Nessuna NO
Data effettiva di spedizione
Data effettiva in cui il
materiale è stato spedito Nessuna NO
4.4.2 Progettazione concettuale iniziale
Dall’analisi effettuata sui requisiti si definisce lo schema concettuale iniziale del data mart, senza avere nessuna pretesa di completezza; infatti questo schema è una semplice riscrittura con un modello dimensionale dei fatti dei requisiti.
Figura 4.7 Schema concettuale iniziale del data mart Trasporti
4.4.3 Progettazione concettuale dei dati operativi
Dati i requisiti di analisi dei dati ed esaminando lo schema concettuale della base di dati operazionale, dal quale avevamo considerato solo le tabelle di nostro interesse, andiamo a decidere quali attributi posso essere utili per il proseguo della progettazione.
CAPITOLO 4 – CASO DI STUDIO
34
Tabella Article: di questa tabella manteniamo solo il campo “description” che identifica il nome del pezzo.
Tabella Doc_causal: di questa tabella manteniamo solo il campo “description” che identifica la descrizione della causale di spedizione. Tabella Doc_header: è la tabella dove sono presenti la maggior parte dei
campi di nostro interesse, infatti di questa tabella vengono mantenuti i campi:
o “effective_delivery_date” che corrisponde alla data effettiva di spedizione;
o “effective_transport_cost” che corrisponde al costo effettivo del trasporto;
o “expected_delivery_date” che identifica la data effettiva di spedizione;
o “expected_transport_cost” che identifica il costo effettivo del trasporto;
o “volume” che è la grandezza in
m
3 del materiale spedito. Tabella Doc_row: questa è l’unica tabella da cui non prendiamo nessun campo, ma si mantiene solo i riferimenti per i campi delle tabelle doc_header e article.
Tabella Interlocutor: di questa tabella vengono mantenuti i campi “description” e “courier_customer_code” che rispettivamente identificano il nome dello spedizioniere e la tipologia a cui appartengono, se al trasporto milk run o allo standard .
La progettazione continua con la classificazione delle entità in cui si individuano i possibili fatti, le dimensioni, le misure e le relazioni tra le tabelle dello schema relazionale.
In questa fase si identificano tre tipologie di entità:
l’entità evento, sono le tabelle che rappresentano eventi potenzialmente interessanti per i processi aziendali; questi descrivono eventi che si verificano nel tempo e contengono attributi numeri che rappresentano possibili misure;
CAPITOLO 4 – CASO DI STUDIO
35
l’entità componente, sono le tabelle in relazione con un’entità evento con un’associazione (1:N); definiscono i dettagli di un evento e quindi rappresentano informazioni utili per rispondere a domande del tipo “chi”, “cosa”, “quando”, “dove”, “come” e “perché” relative all’entità evento; l’entità classificazione, sono le tabelle in relazione con le entità
componente con l’associazione (1:N); queste scaturiscono da gerarchie nei dati e possono essere combinate con le entità minimali per definire attributi dimensionali.
La tabella Doc_header corrisponde ad una entità evento in quando rappresenta il verificarsi dell’evento del trasporto della componentistica che si ripete più volte; inoltre in questa tabella sono presenti misure che rappresentano i volumi del trasporto, le data effettiva e presunta di spedizione e i costi presenti ed effettivi della spedizione.
Le tabelle Doc_row, Doc_causal, Interlocutor sono entità componente in quanto sono in relazione (1:N) con l’entità evento definendone i dettagli.
La tabella Article è un’entità classificazione in relazione (1:N) con l’evento componente Doc_row.
Una volta definite le entità si passa alla definizione dello schema concettuale candidato, partendo dall’entità evento come rappresentato nell’immagine sotto (Fig. 4.8).
Per semplificare la comprensione dello schema concettuale candidato identificherò la tabella Doc_header con il nome “Trasporti”, la tabella Doc_row con il nome “Corpo DDT”, la tabella Doc_causal con il nome “Causale”, la tabella Interlocutor con il nome “Corriere” e la tabella Article con il nome “Articolo”.
CAPITOLO 4 – CASO DI STUDIO
36
4.4.4 Progettazione concettuale finale
Confrontando lo schema concettuale iniziale e candidato si definisce lo schema concettuale finale del data mart che rappresenta cosa si può analizzare dai dati a nostra disposizione.
In questo progetto formativo, il data mart finale coincide per il 90% con quello presentato nella progettazione concettuale iniziale, l’unica differenza è che è inserita una sorta di gerarchia tra la dimensione “Corpo DDT” e “Articolo”.
Figura 4.9 Schema concettuale finale del data mart Trasporti
Una volta che è stato trasformato lo schema concettuale in schema relazionale, tale modello rappresenterà il data warehouse su cui potremmo andare ad eseguire tutte le operazioni ed analisi per il supporto alle decisioni future.
4.4.5 Progettazione logica
Dallo schema concettuale finale siamo passati alla progettazione logica del data mart, il cui scopo è quello di ottenere uno schema logico relazionale.
Fig.4.10 Schema relazionale del data mart Trasporti
Lo schema che otteniamo, ha una struttura a Fiocco di Neve che consiste in una tabella dei fatti che referenzia più tabelle delle dimensioni che, a differenza dello schema a stella, hanno ramificazioni con altre tabelle normalizzate.
CAPITOLO 4 – CASO DI STUDIO
37
Avendo un solo schema relazionale del data mart, questo sarà lo schema a fiocco di neve del nostro data warehouse.
4.5 Creazione dei dashboard
Una volta progettato logicamente il data warehouse abbiamo cercato di replicarlo sullo strumento Qlikview che ci avrebbe permesso di creare i dashboard richiesti.
Come prima cosa è stata caricata una istanza del data base di test sulla mia macchina attraverso le linee di comando mostrate sotto (Fig. 4.11).
Figura 4.11 Linea di comando per caricare una istanza del data base
Una volta caricata l’istanza, attraverso il software Sql Developer è stato creato un utente che potesse andare ad analizzare i dati del data base con accesso completo. Questo è stato possibile attraverso lo script sql sotto riportato (Fig. 4.12).
Figura 4.12 Sql per creazione di un utente
Passo successivo è stato quello di creare una sorgente ODBC che puntasse alla istanza del data base precedentemente caricato (Fig. 4.13).
CAPITOLO 4 – CASO DI STUDIO
38
Figura 4.13 Creazione sorgente ODBC
Finito anche questa passaggio, è stato aperto il tool Qlikview per iniziare la creazione dei dashboard.
Una volta aperto il tool, come prima cosa è stata aperta la finestra dello script che permette di caricare la sorgente dati ed eseguire il processo ETL.
La finestra dello script, imposta di default alcuni settaggi di formattazione dei dati, formattazione delle date e formattazione dei decimali e migliaia; questi possono essere modificati in base alle esigenze dell’utente.
Figura 4.14 Settaggi impostati di default da Qlikview
Come si può vedere dall’immagine (Fig. 4.14), il sistema in automatico esegue i seguenti dieci settaggi:
La divisione delle migliaia avviene con il punto; La divisione dei decimali avviene con la virgola;
CAPITOLO 4 – CASO DI STUDIO
39
La divisione dei decimali nelle valute avviene con la virgola; Il formato delle valute è € #.##0,00;
Il formato dell’ora è hh:mm:ss;
Il formato della data è italiano DD:MM:YYYY;
Il formato del timestamp è DD:MM:YYYY hh:mm:ss[.fff];
Il formato del mese è l’unico che è stato modificato, infatti invece di avere il nome del mese per esteso, era settato con i valori gen, feb, mar, apr, mag, giu, lug, ago, set, ott, nov e dic;
Il formato del giorno è settato con le prime tre lettere del nome del giorno in lingua italiana.
Dopo aver controllato e modificato il settaggio dei formati, sono stati inseriti i comandi per accedere alla sorgente dei dati per poi selezionare i campi per ricreare il data warehouse; questo è avvenuto attraverso la procedura guidata per la selezione del data base “ODBC” e della sorgente dati.
Figura 4.15 Connessione alla sorgente dati
Il risultato ottenuto è la creazione della linea di comanda sotto riportata (Fig. 4.16).
Figura 4.16 Linea di comando per la connessione alla sorgente dati
Una volta appurato che la connessione alla sorgente dati è avvenuta con successo, attraverso comandi Sql sono stati selezionati i campi di interesse.
CAPITOLO 4 – CASO DI STUDIO
40
Per quanto riguarda la tabella “Article” sono stati selezionati tutti gli identificativi e tutte le descrizioni dell’articolo senza nessun tipo di restrizione.
Figura 4.17 Query di selezione Selezione dei campi ID e Description
Della tabella “Doc_header”, sono stati selezionati i campi che identificano la testata del DDT, il corriere che effettuerà la spedizione, la causale della richiesta; inoltre sono state selezionate le misure delle date effettive e presunte di spedizione, i costi presunti ed effettivi della spedizione ed i volumi delle spedizioni.
A differenza della precedente query, in questo caso è stata eseguita una restrizione per selezionare solo ed esclusivamente i record che si riferivano alla causale con identificativo “352”.
Figura 4.18 Query per la selezione dei campi dalla tabella Doc_header
Della tabella “Doc_row” sono selezionati gli identificativi della riga, alla testata del documento e all’articolo.
CAPITOLO 4 – CASO DI STUDIO
41
Figura 4.19 Query di selezione dalla tabella Doc_row
Della tabella “Interlocutor” attraverso la query, sotto riportata (Fig. 4.20), sono stati selezionati gli identificativi dei corrieri, la descrizione del corriere e la tipologia di spedizione a cui appartiene.
Anche in questo caso, come per la query sulla tabella “Doc_header”, c’è una restrizione, infatti vengono selezionati solo i record che hanno il flag vero sul campo courier.
Figura 4.20 Query di selezione campi dalla tabella Interlocutor
Dalla tabella “Causal” come per la tabella “Article” vengono selezionati gli identificativi e la descrizione.
Figura 4.20 Query di selezione campi dalla tabella Causal
In tutte le query possiamo notare due aspetti che si ripetono:
1. Prima del query abbiamo un nome seguito dalla punteggiatura “:”; questo sarà il nome della tabella che verrà mostrato nel data warehouse in Qlikview;
CAPITOLO 4 – CASO DI STUDIO
42
2. Quasi tutti i campi vengono rinominati attraverso il comando “AS”, questo perché la relazione tra due tabelle in Qlikview avviene attraverso i nomi dei campi.
Una volta scritto lo script, questo viene mandato in esecuzione in modo da creare una istanza del data warehouse all’interno del tool Qlikview; alla fine dell’esecuzione il tool mostra una finestra di riepilogo (Fig. 4.21) dove è possibile visualizzare il risultato della connessione ed il numero di record caricati per ogni select dello script.
Fig.4.21 Avanzamento dell’esecuzione dello script
Al termine dell’esecuzione dello script è possibile visualizzare la struttura creata (Fig. 4.22), attraverso il “visualizzatore tabelle” di Qlikview.
CAPITOLO 4 – CASO DI STUDIO
43
Come si può vedere dall’immagine, questa struttura corrisponde perfettamente alla struttura del data warehouse che avevamo ottenuto dallo studio logico effettuato in precedenza.
A questo punto del progetto formativo, sono stati creati i dashboard per il supporto alle decisioni future, come richiesto dall’azienda.
Il primo dashboard creato è quello che mostra i volumi effettivamente spediti suddivisi per spedizioniere.
Figura 4.23 Volumi spediti
In questo dashboard sono presenti tre oggetti chiamati “caselle di elenco” e un grafico ad istogrammi.
Tra le tre caselle di elenco, solamente quella che identifica i corrieri è una semplice selezione del campo descrizione del corriere, le altre due sono derivate da due espressioni calcolate direttamente in Qlikview.
Per la casella di elenco “Tipologia Spedizione” è stata utilizzata l’espressione:
=if(TYPE='STD','STANDARD','MILK')
questa permette di sostituire il valore del campo type a seconda che si tratti della tipologia di spedizione standard o milk run.
Per la casella di elenco “Mese” è stata utilizzata l’espressione:
=Month(EFFECTIVE_DELIVERY_DATE)
questa preleva il mese dalla data effettiva di spedizione, nel formato gg:mm:yyyy, e me lo converte nel formate settato all’inizio dello script.
CAPITOLO 4 – CASO DI STUDIO
44
Il grafico è stato creato partendo dalla selezione della dimensione descrizione corriere ed è stata utilizzata la funzione SUM per aggregare i volumi di spedizione in base al corriere.
Grazie a Qlikview è possibile interagire con i dati nelle caselle di elenco per andare a modificare il grafico in tempo reale; questo fa si che si possa vedere quello che attualmente interessa.
Figura 4.24 Esempio di utilizzo delle caselle di elenco
Il secondo dashboard mostra i costi effettivi e presunti delle spedizione in base al mese e in base al corriere.
CAPITOLO 4 – CASO DI STUDIO
45
In questo dashboard sono presenti le tre caselle di selezioni presenti nel precedente, ma con la differenza che nei due grafici è stata utilizzata la funzione di aggregazione SUM sui costi.
Altra differenza dal precedente dashboard è il fatto che in questo sono state inserite due funzioni di aggregazione su due misure diverse nello stesso grafico, permettendo un confronto in tempo reale.
Anche in questo, la selezione di un valore nelle caselle di selezione comporta la modifica in tempo reale del grafico.
E’ possibile creare anche grafici di sola lettura senza l’inserimento, nel dashboard, di caselle di selezione; questo è il caso del terzo dashboard creato (Fig. 4.26).
Figura 4.26 Andamento dei costi effettivi
In questo caso il grafico è di tipo linea ed in base al mese, calcolato con l’espressione =Month(EFFECTIVE_DELIVERY_DATE), viene utilizzata la funzione di
aggregazione SUM per calcolare la somma dei costi effettivi.
Il quarto dashboard creato mostra i volumi spediti ed i costi effettivi di spedizione, non in base al corriere, ma alla tipologia di spedizione.
CAPITOLO 4 – CASO DI STUDIO
46
Figura 4.26 Costi e volumi in base alla tipologia di spedizione
In questo caso è stato utilizzato un grafico a torta per mostrare, oltre ai volumi e costi totali, l’incidenza che questi hanno rispetto al totale.
L’ultimo dashboard creato è quello che mostra i ritardi di consegna in base all’articolo selezionato.
Figura 4.27 Ritardi di consegna
In questo dashboard oltre alle tre caselle di selezione ne è stata inserita una quarta per identificare il componente spedito; i cui valori sono stati calcolati attraverso l’espressione:
=if(DOC_CAUSAL_ID=352,DESCRIPTION_ARTICLE)
che ha permesso di selezionare solo i componenti che fanno capo al documento di trasporto con valore della causale “352”.
CAPITOLO 4 – CASO DI STUDIO
47
Il grafico mostra i giorno di ritardo, ottenuti con l’espressione:
EFFECTIVE_DELIVERY_DATE - EXPECTED_DELIVERY_DATE
Utilizzando la casella di selezione “Articolo” è possibile vedere in tempo reale se ci sono state spedizioni con ritardo, da chi è stata eseguita la spedizione e in quale mese.
Utilizzando anche le altre caselle di selezione, il grafico mostra in modo più specifico la data a cui si fa riferimento, infatti selezionano solamente l’articolo vengono mostrati tutti i corrieri che hanno spedito quel componente e tutti i mesi in cui è stato spedito quel componente.
Figura 4.28 Esempio di grafico con selezione del solo articolo
Grazie a tutti questi dashboard è possibile fare delle supposizioni e prendere delle decisioni per il futuro.
