Staging Area

Le tabelle delle sorgenti vengono copiate nell’area di Staging. La ragione per la quale esiste un’area di staging è che in questo modo si riesce a identifi- care il sotto-insieme di informazioni utili del Source System, isolandole prima del caricamento nel data warehouse, ed evitando di appesantire troppo il siste- ma delle sorgenti con le elaborazioni complesse del DWH. L’area di staging è implementata sulle istanze di zona, quindi è presente un’area di staging per i sistemi regionali appartenenti alla zona 1 e una per quelli di zona 2. Lo staging è formato da due livelli, i quali non sono altro che schemi diversi nello stesso database. Nel primo livello i dati vengono caricati dal sistema sorgente in moda- lità full-load, senza considerare i vincoli di chiave primaria presenti sulle tabelle sorgenti, e in questo livello le tabelle vengono troncate e ricaricate ogni giorno. Per ogni zona considerata sono presenti tanti aree di staging di livello 1 quanti sono i siti produttivi per quella zona. Nel secondo livello di staging viene invece adottata una logica di update-insert-delete, considerando le chiavi primarie del- le tabelle. Lo scopo è quello di individuare e storicizzare le cancellazioni fatte sui dati del sistema sorgente secondo la seguente logica: nello staging di livello 1 abbiamo dati provenienti dai sistemi sorgenti ricaricati giornalmente, mentre nello staging di livello 2 i dati non vengono troncati, ma vengono inseriti nuovi record o aggiornati quelli esistenti. Per individuare quali sono i record che non sono più presenti nel sistema sorgente, viene fatto un merge dei dati tra il livello 1 e il livello 2 dello staging. I record appartenenti al secondo livello di staging che non trovano corrispondenza con i record dello staging di livello 1 vengono marcati a delete, e ne viene fatta la cancellazione logica.

Lo staging di livello 2 è unico per tutti i siti produttivi di quella zona, e quindi i dati presenti nelle varie aree di staging di livello 1 confluiscono tutti nella stessa area di staging di livello 2 (per zona). Allo scopo di parametrizzare le tabelle di staging, affinché siano generali e non ad hoc per un determinato sito produttivo, si è reso necessario l’inserimento di alcuni campi tecnici in aggiunta agli attributi originariamente previsti dalle tabelle. Per le tabelle di staging di primo i livello i campi tecnici aggiunti sono i seguenti:

• FACILITY_CD: è il codice che identifica il sito produttivo dal quale si stan- no caricando i dati nello staging;

• SRC_INST_CD: codice di installazione nel sito produttivo. Viene usato nel caso in cui ci siano più installazioni all’interno di un sito produttivo, ad esempio nel caso in cui nello stabilimento di Sesto ci fossero due sistemi sorgenti PMX, grazie a questo campo si potrebbero distinguere;

• OPERATION_CD: è un campo che viene valorizzato al termine del carica- mento dello staging di primo livello per decidere quale sarà l’operazione che andrà poi fatta nello staging di secondo livello. Nello specifico, se un

6.2. ARCHITETTURAGMDM 59 record della tabella di primo livello non trova corrispondenza con nessun record della tabella di secondo livello, allora il campo OPERATION_CD verrà settato ad ‘I’,per indicare che nella tabella di secondo livello si an- drà ad inserire un nuovo record. Nel caso in cui ci sia corrispondenza tra le chiavi, ma almeno uno degli altri campi della tabella di secondo livello è diverso da quello di primo livello, il campo OPERATION_CD verrà settato a ‘U’, per indicare che si andranno ad aggiornare i campi della tabella di livello 2;

• CHECK_ERR_CD: è stato previsto questo campo per gestire gli errori già a livello di staging e non di data warehouse. Tuttavia, l’implementazione di tali controlli è prevista per release future del software, e quindi non verrà trattata in questo lavoro di tesi.

Invece, per le tabelle di staging di secondo livello sono stati aggiunti i seguenti campi tecnici:

• FACILITY_CD e SRC_INST_CD con significato analogo alle tabelle di pri- mo livello;

• RCRD_STS_CD: identifica lo stato di un record. Un record può essere attivo, e in questo caso il campo verrà valorizzato con ‘A’ o cancellato ‘D’; A questi campi fanno seguito altri tre campi tecnici di tipo data, e sono: • INS_TMSTMP: è la data in cui è stato inserito per la prima volta quel

record con una determinata chiave primaria;

• UPD_TMSTMP: indica la data di aggiornamento del record. Coincide con INS_TMSTMP se la storicizzazione è attiva, altrimenti è la data di ultimo aggiornamento del record;

• END_TMSTMP: è la data di cancellazione del record, quando non è più presente nel sistema sorgente;

A differenza delle tabelle di staging di primo livello che vengono caricate in full, per implementare la logica di update-insert-delete delle tabelle di secondo livello è necessario che queste abbiano definite le chiavi primarie. Tuttavia, le chiavi primarie delle tabelle di secondo livello comprendono anche i campi tecnici FACILITY_CD, SRC_INST_CD, RCRD_STS_CD, END_TMSTMP oltre ai campi di business che formavano la chiave primaria a livello di sorgente. Si è resa necessaria l’aggiunta di questi campi tecnici alla chiave di business poiché bisogna distinguere i dati di un determinato sito/installazione dagli altri.

60 6. ARCHITETTURA DIDATA WAREHOUSING