L’aggiornamento della dimensione Originatore

Di seguito `e mostrato il job che esegue il passo S sulla dimensione Originatore (Figura 4.1). In questo passo viene gestito l’aggiornamento della dimensione e la generazione delle chiavi surrogate. Il flusso dati ha origine a sinistra del processo e termina a destra con l’aggiornamento dei dati, l’orientamento delle frecce definisce in verso del flusso di dati.

Lo stage Oracle T ACQ ORIGINATORE seleziona i record dalla tabella T A- CQ ORIGINATORE contenente i dati trasformati nello step precedente T. Lo sta- ge S ACQ ORIGINATORE LKP seleziona i record dalla tabella S ACQ ORIGI-

54 CAPITOLO 4. I PROCESSI DI CARICAMENTO DATI NATORE utilizzati per eseguire la funzione di look-up (dettagliata in seguito). Nello stage Transformer al centro della figura vengono eseguite le operazioni di look-up per la creazione delle chiavi surrogate e l’aggiornamento della tabella S ACQ ORIGINATORE. Infine lo stage Oracle S ACQ ORIGINATORE aggior- na la tabella S ACQ ORIGINATORE in modalit`a update/insert. Lo stage Hash- File S ACQ ORIGINATORE H viene utilizzato esclusivamente per velocizzare le operazioni di look-up, ed `e ininfluente per quanto riguarda la logica di caricamento.

Figura 4.1: Job Datastage per l’aggiornamento della dimensione Originatore. Il cuore del job `e lo stage Transformer centrale. Nella parte sinistra dello stage (Figura 4.2) sono rappresentati i tracciati record dei flussi di input, nella parte de- stra quelli di output. Ci sono due flussi di input (LKIN e LK10) e uno di output (LKOUT), il flusso principale `e quello tra LKIN e LKOUT, mentre LK10 `e il flusso secondario che permette di eseguire la look-up. LKIN rappresenta i record di input provenienti dalla tabella T ACQ ORIGINATORE, LKOUT rappresenta i record di output verso la tabella S ACQ ORIGINATORE e LK10 rappresenta i record di input dalla tabella S ACQ ORIGINATORE. Da notare il fatto che i flussi TR10 e TROUT hanno per oggetto la stessa tabella S ACQ ORIGINATORE. La differen- za sta nel fatto che TR10 legge i record in modo da discriminare quali sono gi`a presenti in tabella e quali invece vanno scritti (con una nuova chiave surrogata), successivamente TROUT scrive i record aggiornando la tabella.

Il campo ORIGINATORE COD `e la chiave naturale, mentre ORIGINATO- RE ID `e la chiave surrogata della tabella dimensionale. L’operazione di look-up viene definita nella parte di sinistra dello stage tra LKIN e LK10. In particolare,

4.5. IL SOFTWARE UTILIZZATO: IBM INFOSPHERE DATASTAGE 55 per ogni record in ingresso nel flusso LKIN viene controllato se esiste un record nel flusso di input LK10 tale che LKIN.ORIGINATORE COD = LK10.ORIGINATO- RE COD. Se esiste allora LK10.ORIGINATORE ID assumer`a il valore della chia- ve surrogata associata al record, se non esiste LK10.ORIGINATORE ID assumer`a il valore null. Questa operazione `e equivalente ad eseguire il join tra i due flussi utilizzando come condizione i due campi codice (chiavi naturali) e selezionando il campo id del flusso LK10 (chiave surrogata).

Figura 4.2: Stage Transformer che esegue l’operazione di look-up sulla dimensione Originatore.

La trasformazione in uscita (vedi colonna Derivation) per campo ORIGINATO- RE ID nel flusso LKOUT `e:

if isNull(LK10.ORIGINATORE ID) then SetNextValConcurrent(DSJobName) else LK10.ORIGINATORE ID

Se LK10.ORIGINATORE ID `e nullo significa che il record non `e presente nella tabella dimensionale, quindi viene generata una nuova chiave surrogata utilizzando la funzione DataStage SetNextValConcurrent(param) la quale gestisce la concor- renza tra i processi ETL in esecuzione per l’assegnamento univoco nelle chiavi surrogate. Se LK10.ORIGINATORE ID non `e nullo allora viene riassegnata al record la sua chiave surrogata.

Come descritto precedentemente i dati per l’alimentazione delle tabelle dimen- sionali vengono estratti dal sistema sorgente in maniera statica, mediante una scan- sione completa dei dati. Si rende necessario quindi eseguire un’operazione di mer- getra i nuovi e i vecchi dati. Il flusso in uscita TROUT viene infine utilizzato per aggiornare la tabella S ACQ ORIGINATORE. In Figura 4.3 `e mostrato lo stage Oracle di output che definisce la modalit`a di scrittura dei record in modalit`a up- data/insert: i record gi`a presenti vengono aggiornati, mentre quelli nuovi vengono inseriti.

56 CAPITOLO 4. I PROCESSI DI CARICAMENTO DATI

Figura 4.3: Stage Oracle che esegue l’aggiornamento della dimensione Originatore.

Lo scopo dei job `e quello di definire le trasformazioni dei dati tra una fonte dati e un file o tabella target. Per definire l’ordine di esecuzione dei job vengono utilizzati appositi oggetti chiamati Sequence. I sequence sono raggruppamenti logici di job che, messi in sequenza, definiscono l’ordine di esecuzione dei job e permettono l’orchestrazione del processo ETL. A loro volta un Sequence pu`o contenere altri Sequence, permettendo di suddividere ed organizzare il processo di caricamento in unit`a gerarchiche. Dal momento che il processo di caricamento dei quattro data mart `e composto da un centinaio di job, l’organizzazione gerarchica dei Sequence `e stata molto utile per gestire e mantenere l’intero processo ETL.

In Figura 4.4 `e mostrato il Sequence che aggiorna le dimensioni (qui chiamate anagrafiche) dei data mart. Per ogni dimensione, prima viene eseguita l’estrazione dei dati (step W), poi le trasformazioni (step T) ed infine l’aggiornamento (step S).

4.6. RIASSUNTO 57

4.6

Riassunto

Data la complessit`a, l’elevato numero di operazioni di trasformazione e la gran- de quantit`a di informazioni movimentate, la progettazione dei processi ETL deve essere fatta in modo accurato e valutando con precisione la suddivisione di que- sti processi in pi`u fasi al fine di diminuirne la complessit`a di gestione e avere un maggiore controllo sui prodotti intermedi delle trasformazioni. In questo capitolo `e stata descritta l’organizzazione della staging area adottata del progetto. Il processo di caricamento `e suddiviso in tre fasi: nella prima i dati vengono copiati all’inter- no della staging area, nel secondo vengono opportunamente trasformati al fine di aderire alle regole del data warehouse ed infine nella terza fase vengono eseguite le funzioni di look-up per l’aggiornamento del data warehouse. Questa soluzione prende spunto dalla metodologia proposta da Kimball in [Kimball 02]. L’azienda adott`o fin dalla prima implementazione del data warehouse aziendale questa me- todologia, che con il tempo `e diventata lo standard di sviluppo per tutti i progetti successivi.

Nel capitolo inoltre `e presentato brevemente il software utilizzato per realizzare il processo, insieme ad un esempio di implementazione del job per il caricamento della dimensione Originatore.

Capitolo 5

LA REPORTISTICA

Il sistema di reportistica `e lo strumento con il quale gli utenti finali interagiscono con il data warehouse. Esso ha lo scopo di presentare i dati nel modo pi`u efficace possibile utilizzando tabelle e grafici. Gli utenti della reportistica sono essenzial- mente di due categorie: gli sviluppatori e gli utenti finali. Lo sviluppatore `e quel- la figura che predispone l’ambiente e crea i report, l’utente finale `e il cosiddetto “utente di business” il quale consulta i report.

Il sistema di reportistica di questo progetto `e stato realizzato mediante lo stru- mento Microstrategy, ma in questo capitolo non viene mostrato il sistema di re- portistica realizzato per il cliente, bens`ı si vuole mostrare come lo strumento a partire dalla selezione degli oggetti del data warehouse crea il codice SQL utiliz- zato per interrogare la base di dati. A tal fine `e stato predisposto un ambiente di test contenente un piccolo data mart con dati di esempio ed `e stato creato un pro- getto Microstrategy ex-novo. Di seguito viene presentata una breve panoramica sull’architettura del software poi viene mostrata la selezione degli oggetti del da- ta warehouse nello strumento e vengono presentati i report, sia nel loro formato grafico che mostrando il codice SQL generato per la loro creazione. Le analisi sono presentate in ordine di difficolt`a dal punto di vista delle query necessarie per eseguire i report1.

5.1

Il software utilizzato: Microstrategy

L’architettura Microstrategy `e schematizzata in Figura 5.12.

1

Approccio tratto da [Albano 12], Cap.3.

2

Immagine tratta da [Albano 12]

60 CAPITOLO 5. LA REPORTISTICA

Figura 5.1: Schema dell’architettura del software Microstrategy. Il sistema si divide essenzialmente nelle seguenti componenti:

• OLAP Client: l’architettura Microstrategy possiede due OLAP Client. Mi- crostrategy chiama questi due client Microstrategy Desktop e Microstrategy Web. Microstrategy Desktop `e un’applicazione Microsoft Windows / Li- nux dal quale `e possibile sviluppare i report. Tutti gli esempi mostrati in questo capitolo e le immagini riportate sono relative al client Microstrategy Desktop. Microsoft Web invece, `e un’applicazione web accessibile dal bro- wser con quale gli utenti finali interagiscono per la consultazione dei report, inoltre anche da Microstrategy Web `e possibile definire nuovi report. • OLAP Server: in Microstrategy viene chiamato Intelligence Server. Il si-

stema fornisce una visione multidimensionale a cubo dei dati contenuti nel Data Server, inoltre contiene un motore analitico per il calcolo delle funzioni analitiche.

• RDBMS: La versione 9.2 di Microstrategy supporta i seguenti Data Server. – Aster nCluster. – Composite. – IBM DB2. – Greenplum. – Hive. – HP Neoview.

– Hyperion and Essbase. – IBM Cognos.

– Infobright. – Informix IDS. – MetaMatrix. – Microsoft Access.

– Microsoft Analysis Services. – Microsoft SQL Server. – MySQL. – Netezza. – Oracle. – PostgreSQL. – Red Brick. – Salesforce. – SAP BW. – Sybase. – Teradata. – Vertica.

5.2. SELEZIONE DEGLI OGGETTI DEL DATA WAREHOUSE 61