CAPITOLO 4 – CASO DI STUDIO
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.