Dimensional Table: Depot

I capitoli seguenti tratteranno della raccolta ed estrazione delle informazioni e della successiva creazione delle tabelle dimensionali e Fact Table che costituiranno il Data Mart per l’area dell’Affidabilità.

N.B. Si precisa che per ogni tabella descritta nei capitoli successivi è implicita la definizione di una procedura PL/SQL che effettua i vari controlli di chiave e la seguente costruzione e popolamento della stessa.

Ogni tabella presentata in questa sezione ha subìto una o più lavorazioni, descritte di seguito:

• Staging: nella prima fase i dati vengono semplicemente inseriti dalle sorgenti alla tabella in que- stione, senza che siano effettuati controlli di alcun tipo. Questa fase serve essenzialmente per avere tutte le informazioni d’interesse in un’unica struttura, dalla quale partire nelle fasi successive per la pulizia e la modifica della stessa. Inoltre questo tipo di tabelle viene popolato attraverso le opera- zioni di DROP - CREATE - INSERT ogni qualvolta viene eseguita la procedura PL/SQL che genera la tabella. In questo modo le tabelle staging per ogni ciclo del flusso ETL vengono sistematicamente eliminate, per poi essere ricreate e popolate con i dati più recenti;

• Working Tables: dopo la fase di Staging occorre modificare ed eventualmente pulire i dati all’in- terno della tabella appena creata. Questo è possibile attraverso una serie di operazioni a cascata che vadano a modificare la tabella di partenza creandone una nuova, ripetendo tutto ciò per il numero di volte che si ritiene necessario. A differenza della fase di Staging, in cui viene creata sempre e solo una tabella in grado di contenere tutte le informazioni utili, le Working Tables re- lative possono essere una o più di una, a seconda delle necessità e del numero di operazioni da effettuare; infine anche le working tables vengono popolate in DROP - CREATE - INSERT;

• Enterprise Data Warehouse: l’ultima fase prevede la definizione vera e propria della tabella che sarà utilizzata nel Data Warehouse. In questa fase sono stati effettuati i controlli di: chiave esterna, chiave primaria, indicizzazione dei campi di join, creazione delle statistiche della tabella, sostitu- zione dei campi nulli con fittizi, inserimento del record fittizio, ovvero una riga con tutti i campi aventi valori fittizi anziché nulli. Questi ultimi due controlli sono di fondamentale importanza poiché nel caso venisse effettuato un join tra due campi fittizi non ci sarebbe la perdita di nessuna riga, cosa che accadrebbe invece in caso di valore nullo. Infine le tabelle in questione non vengono eliminate ogni volta ma vengono aggiornate qualora siano presenti record modificati o aggiuntivi.

Inoltre è necessario approfondire la logica della nomenclatura adottata per identificare le varie tabelle create:

• Il primo blocco della nomenclatura ha l’obiettivo di mostrare la fase di lavorazione della tabella in questione: STG (Staging), WKn (Working Table, con numero n di lavorazioni) ed EDW (Enterprise Data Warehouse);

• Il secondo blocco evidenzia l’origine dei dati all’interno della tabella: in questo ORA indica i dati provenienti da Oracle e FW i dati provenienti da Formwork;

• Il terzo blocco mostra il tipo di tabella creata: nello specifico L indica una lookup (o dimensione) mentre F indica una fact;

• Infine viene inserito un nome per identificare correttamente la tabella su cui eseguire operazioni.

Per fare un esempio: nel caso in cui ci fosse la tabella WK2_ORA_L_TAB, il nome indica che la tabella TAB è una lookup con dati provenienti da Oracle che ha subìto una seconda lavorazione.

La prima dimensione trattata è quella relativa al Depot Repair, chiamata per brevità Depot, che ha l’o- biettivo di inglobare in un’unica struttura tutte le informazioni riguardanti le sole riparazioni effettuate dall’Azienda.

La prima parte del paragrafo sarà dedicata alla tabella del DR relativamente ai dati provenienti da Oracle, mentre la seconda parte tratterà dei dati aventi sorgente Formwork.

Per quanto riguarda la fase di Staging per la parte Oracle molte delle informazioni di partenza per le riparazioni sono state ottenute dalla tabella CSD_REPAIRS, fornita dalla committenza, che contiene i dati quali il seriale dell’elettromandrino riparato, data di spedizione, descrizione e tipo di guasto. Sono state inoltre integrate informazioni sul codice dell’articolo e dell’etichetta, campo che indica il rientro di un componente interno all’elettromandrino. In questo caso l’Azienda inserisce nel campo Etichetta il seriale dell’elettromandrino a cui il componente appartiene.

SELECT [...] lista campi Staging FROM APPS.CSD_REPAIRS CR

LEFT JOIN APPS.CS_INCIDENTS_ALL CS ON CR.INCIDENT_ID = CS.INCIDENT_ID LEFT JOIN ST_DIM_ARTICOLO ART

ON CR.INVENTORY_ITEM_ID = ART.INVENTORY_ITEM_ID LEFT JOIN APPS.CSD_REPAIR_FLOW_STATUSES CRFS

ON CR.FLOW_STATUS_ID = CRFS.FLOW_STATUS_ID

LEFT JOIN APPS.CSI_ITEM_INSTANCES CP <-- tabella contenente l’Etichetta ON CS.CUSTOMER_PRODUCT_ID = CP.INSTANCE_ID

WHERE CR.CREATION_DATE >= DATE ’2014-01-01’ AND CRFS.FLOW_STATUS_MEANING <> ’Cancelled’

La query mostrata estrae tutti i DR dal 2014 in poi che non sono stati cancellati. Una volta definita e popolata la tabella di Staging STG_ORA_L_DEPOT è necessario effettuare un’ulteriore integrazione di informazioni all’interno della tabella. La WK1_ORA_L_DEPOT si popola dunque a partire dalla staging precedente, con l’integrazione di diverse strutture:

• WK1_LOGISTICA_RMA: tabella ottenuta tramite l’unione e l’ottimizzazione di query fornite dal- l’azienda committente e creata appositamente per recuperare dati riguardanti i rientri in Azienda;

• WK1_LOGISTICA_SPEDIZIONE: stesso discorso per la tabella precedente, ma riguardante le spedizioni di prodotti effettuate dall’Azienda;

• EDW_L_ALBERO_GUASTI: anagrafica che contiene i tipi di guasti riscontrati ad elettromandrini (dettagliata in seguito);

• EDW_L_STATO_GAR: anagrafica che contiene i tipi di garanzia in essere per ogni componente (dettagliata in seguito);

• EDW_ORA_L_SR: anagrafica delle Service Request, che contiene le informazioni necessarie per ogni richiesta di riparazione. La tabella in questione è stata già creata dall’Azienda in precedenza ed i campi d’interesse saranno indicati nei seguenti capitoli;

• WK1_ODL: working table di supporto per il recupero dei dati relativi agli ordini di lavoro di mon- taggio e smontaggio.

Il codice seguente mostra l’integrazione con le tabelle menzionate:

SELECT [...] lista campi Depot FROM STG_ORA_L_DEPOT D

LEFT JOIN WK1_LOGISTICA_RMA B

ON D.REPAIR_LINE_ID = B.REPAIR_LINE_ID LEFT JOIN EDW_L_ALBERO_GUASTI F

ON TRIM(REGEXP_SUBSTR(D.FAULT1, ’[^-]+$’)) = F.ID_FAULT1 LEFT JOIN EDW_L_STATO_GAR E1

ON D.WARRANTY_STATUS_CODE = E1.STATO_GAR_ID LEFT JOIN WK1_LOGISTICA_SPEDIZIONE S

ON D.REPAIR_NUMBER = S.REPAIR_NUMBER LEFT JOIN EDW_ORA_L_SR SR

ON D.INCIDENT_ID = SR.INCIDENT_ID LEFT JOIN (

SELECT * FROM

( SELECT REPAIR_LINE_ID, ENTITY_NAME, TIPO_ODL

PIVOT (

MAX(ENTITY_NAME)

FOR TIPO_ODL IN (’MONTAGGIO’ ODL_MONTAGGIO, ’SMONTAGGIO’ ODL_SMONTAGGIO)) ORDER BY REPAIR_LINE_ID

)

A ON D.REPAIR_LINE_ID = A.REPAIR_LINE_ID;

La tabella è stata integrata attraverso più LEFT JOIN, poiché è di fondamentale importanza non perdere alcuna riga durante tutta la fase di trasformazione ed integrazione (tranne nei casi di filtraggi tramite clausola WHERE); in questo modo nella tabella finale EDW saranno presenti comunque tutti i records, aventi i campi settati a null in caso di join fallito con le altre working tables. Il modus operandi in questione è stato adottato per tutte le tabelle create e descritte in questo capitolo.

Terminate le varie integrazioni è stata ottenuta la tabella WK1_ORA_L_DEPOT, contenente la totalità delle informazioni per le riparazioni Oracle.

Successivamente è stata costruita una seconda working table, chiamata WK2_ORA_L_DEPOT, avente stesso tracciato della precedente ma con l’aggiunta per ogni campo nella clausola SELECT delle funzioni TRIM e NVL, in modo da sostituire valori nulli con valori fittizi e rimuovere qualsiasi carattere che possa creare inconsistenza in caso di join tra più tabelle. Di seguito sono elencati i valori fittizi utilizzati per ogni tipo di dato:

• Stringa: fittiziata ad ’N/A’;

• Data: fittiziata a ’1° Gennaio 1900’ per le date nulle ma sicuramente inferiori ad oggi; ’31 Dicembre 2099’ per le date nulle ma sicuramente posteriori alla data odierna;

• Number: fittiziato a -1.

In seguito alla creazione della WK2 è stata definita la EDW_ORA_L_DEPOT, con medesimo tracciato della tabella da cui si popola, con le aggiunte dei controlli di chiave e del record fittizio. La tabella in questione è la tabella finale per quanto riguarda le riparazioni provenienti da Oracle e quindi per tutte le riparazioni avvenute nella sede italiana dell’Azienda.

È stato inoltre ritenuto opportuno costruire un’ulteriore tabella che salvasse tutte le informazioni sulle riparazioni delle filiali, in quanto informazioni non presenti a sistema ma salvate unicamente su fogli Excel. A tal proposito è stata costruita una maschera in Formwork che prendesse in input i dati inseriti manualmente dalle filiali dell’Azienda riguardanti le riparazioni e li inserisse automaticamente all’interno della tabella FW_L_DEPOT_FILIALI, che contiene sia tutti i dati riguardanti le riparazioni delle filiali e sia campi utili per l’area relativa ai Costi in Garanzia (Ore di viaggio, Costi di trasporto, eccetera).

Figura 4.8: Administration Console Forwmork: Affidabilità

Lo screenshot mostra l’Administration Console di Formwork contenente le tabelle importate da ge- stionale ed i legami tra le stesse. Le tabelle che saranno popolate manualmente dalle filiali dell’Azienda attraverso il client Excel sono le seguenti:

• FW_L_DEPOT_FILIALI: riparazioni delle filiali; • FW_L_SR_FILIALI: interventi tecnici delle filiali;

• FW_F_INT_TECNICI_ITALIA: interventi tecnici della sede italiana.

Queste tabelle sono state create in Oracle senza nessuna riga ed importate nell’Administration Con- sole, così da essere popolate tramite l’inserimento manuale nelle maschere Formwork. Nel caso specifico dell’anagrafica del depot, la tabella che conterrà le informazioni sulle riparazioni delle filiali è chiamata FW_L_DEPOT_FILIALI e possiede i collegamenti con le tabelle riguardanti stato della garanzia e tipo di guasto (Figura 4.8), ricavando attraverso l’ID di queste le informazioni su stato di garanzia e tipo di guasto per ogni riparazione. A partire dalle tabelle logiche presenti nell’Administration Console, la maschera finale visibile ad ogni utente per le riparazioni delle filiali è la seguente:

Figura 4.9: Maschera Formwork: Riparazioni filiali

La maschera Excel appare a ciascun utente come una sheet Excel, dove ognuno di essi può inserire un numero n di records all’interno della stessa per tenere traccia di una o più riparazioni effettuate dalla filiale di riferimento (identificata attraverso il campo ITEM ENTITY); inoltre ogni utente può eventual- mente modificare solamente le righe da lui inserite, evitando così la modifica erronea di records non inseriti da quest’ultimo. Una volta inseriti i records delle riparazioni è possibile scriverli nella tabella FW_L_DEPOT_FILIALI utilizzando il pulsante Write situato nella parte alta della maschera Formwork.

Da quest’ultima tabella dunque sarà popolata la struttura EDW_FW_L_DEPOT, che possiede la mede- sima struttura della sua controparte in Oracle, con la differenza che la tabella Oracle del Depot contiene dati con sorgente Oracle, mentre l’ultima solamente dati provenienti da Formwork.

Infine ottenute le tabelle aventi da una parte le riparazioni della sede italiana e dall’altra le riparazioni delle Filiali è stata eseguita una operazione di UNION tra le due tabelle, ottenendo come output la tabella EDW_L_DEPOT, avente al suo interno i dati di tutte le riparazioni eseguite dall’Azienda stessa. Quest’ul- tima costituisce dunque la tabella dimensionale che farà parte del Data Warehouse.

Nome Campo Descrizione Campo

SOURCE_SYSTEM_ID Dato Oracle o Formwork REPAIR_NUMBER (PK) Identificativo Depot

INCIDENT_ID Identificativo SR SR_INCIDENT_DATE Data del guasto SR_CREATION_DATE Data di creazione SR WARRANTY_STATUS* ID e descrizione stato garanzia

FAULT1* ID e descrizione guasto REPAIR_LINE_ID Linea riparazione CREATION_DATE Data creazione Depot

DATE_CLOSED Data chiusura Depot ETICHETTA Seriale del componente DAMAGE_DESCRIPTION Descrizione del danno NOTES_FOR_CUSTOMER Note cliente

SERIAL_NUMBER_RMA Matricola pezzo rientrato COD_MATRICOLA_SPEDIZIONE Matricola pezzo spedito

INVENTORY_ITEM_ID ID nell’inventario del pezzo COD_ENTITY Codice filiale o sede Italia ODL_MONTAGGIO ID ODL Montaggio ODL_SMONTAGGIO e Smontaggio

Tabella 4.1: (*) è presente oltre al campo ID anche il campo descrittivo

Lo screenshot seguente mostra i dati della EDW_L_DEPOT, relativi a tutte le riparazioni effettuate dall’Azienda con alcuni dei campi elencati in precedenza. Da notare la presenza nella prima riga del record fittizio che, come già accennato, presenta diversi valori fittizi a seconda della tipologia del campo in questione.

Figura 4.10: Screenshot tabella EDW_L_DEPOT