Progettazione logica del data mart

Il modello concettuale finale di un data mart mette a disposizione tutti gli strumenti fondamentali per sviluppare il modello logico.

Nel nostro caso, come si osserva in Figura 4.2, il modello logico si pre- senta con uno schema a stella (star schema): al centro `e raffigurata la tabella del fatto in cui sono elencate le chiavi esterne, una per ogni di- mensione, e le misure. Collegata a questa sono presenti tante tabelle quante sono le dimensioni, ognuna delle quali, a loro volta, contiene la propria chiave primaria e gli attributi.

Capitolo 5

POPOLAMENTO DEL DATA

MART

La fase successiva prevede lo sviluppo dell’ ETL (Extract Transform Load) finalizzato a procurare i dati che popoleranno il data mart pro- gettato.

Come descritto nella documentazione [Golfarelli-06], l’ETL `e composto da tre processi:

• l’estrazione: consente di estrapolare i dati da una o pi`u sorgenti. Essa pu`o essere statica o incrementale: in linea teorica, l’estrazione statica viene effettuata quando il data mart deve essere popolato per la prima volta e consiste concettualmente in una fotografia dei dati operazionali; l’estrazione incrementale viene usata per l’aggior- namento periodico del data mart e cattura solamente i cambiamenti avvenuti nelle sorgenti dall’ultima estrazione;

• la trasformazione: si suddivide, in realt`a, in due sottofasi: la prima mira ad un processo di miglioramento della qualit`a dei dati e alla risoluzione di errori quali dati duplicati e/o mancanti, l’uso non previsto di un campo, valori impossibili o errati; la seconda punta

5 – POPOLAMENTO DEL DATA MART

alla modifica del formato per rendere omogenei dati provenienti da sorgenti differenti, dove necessario.

• il caricamento: consiste nell’inserimento dei dati nel data mart e pu`o avvenire secondo due modalit`a:

– Refresh, in cui i dati vengono riscritti integralmente, sostituen- do quelli precedenti. Questa tecnica viene solitamente utilizza- ta, in abbinamento all’estrazione statica, per popolare inizial- mente il data mart;

– Update, dove solo i cambiamenti occorsi nei dati sorgente ven- gono aggiungi nel data mart, tipicamente senza distruggere o alterare quelli esistenti. Questa tecnica viene utilizzata, in abbinamento all’estrazione incrementale, per l’aggiornamento periodico.

Sia SadasBI Manager che Qlik Sense estraggono i dati da un unico data mart, creato appositamente per le nostre analisi. SadasBI Ma- nager, per sua natura, sfrutta un collegamento diretto con la sorgente dati (mediante interrogazioni SQL), mentre Qlik Sense attua un’ulterio- re procedura per il caricamento e la creazione del modello dati.

Nei paragrafi successivi si descrivono il processo di ETL per la creazione e il popolamento del data mart e il procedimento aggiuntivo eseguito in Qlik Sense.

5 – POPOLAMENTO DEL DATA MART

5.1

Il processo di ETL

Il data mart proposto `e situato all’interno del Sadas Engine (il DBMS di Sadas) ed `e il risultato del processo di ETL dettagliato in questa se- zione.

La prima fase, l’estrazione dei dati, ha come unica sorgente il data ware- house gi`a esistente in Sadas Engine, a sua volta generato da varie fonti dati, che contiene tutte le informazioni connesse al sistema di controllo di gestione di Alba Leasing.

Per interagire con il DBMS `e stato ampiamente utilizzato il tool Sadas - Database Control Manager, sviluppato da Sadas, che permette, tra le varie funzionalit`a, di interfacciarsi con le basi di dati presenti mediante interrogazioni (guidate e non) di query SQL e di creare nuovi database. L’autenticazione al DBMS Sadas Engine `e mostrata in Figura 5.1.

Figura 5.1: Schermata di autenticazione

Per identificare le informazioni relative ai piani di ammortamento e ai contratti a reddito, si `e svolta un’analisi dettagliata sui dati che ha

5 – POPOLAMENTO DEL DATA MART

condotto all’individuazione di tabelle e campi utili. Questo processo ha interessato una buona parte (in termini di tempo) del progetto. Le difficolt`a principali si sono riscontrate nel significato di alcuni campi (spesso rinominati con nomi tecnici e/o privi di documentazione) e la loro applicazione nel contesto aziendale. A tal proposito, sono stati implementati vari cruscotti di analisi utilizzando la suite SadasBI al fine di comprendere meglio l’organizzazione dei dati nel DWH.

Grazie a questi cruscotti, inoltre, `e stata studiata la struttura detta- gliata del piano di ammortamento di ciascun contratto di leasing. Essa contiene la descrizione rateale del debito, distribuita nel tempo dal mese e anno di riferimento e dal mese e anno di proiezione. Nello specifico:

• i mesi e anni di riferimento presentano valori per l’intera durata del contratto, dalla data di stipula fino alla chiusura;

• identificato un mese e anno di riferimento, i mesi e anni proietti- vi contengono valori dal dicembre dell’anno precedente (rispetto a quello di riferimento) fino al mese e anno di chiusura del contratto; • identificato un mese e anno di riferimento, il mese e anno proiettivo pari a dicembre dell’anno precedente mostra i valori aggregati fino a quella data, mentre i successivi, dal mese di gennaio dell’anno di riferimento fino al mese e anno di termine del contratto, evidenziano, ad ogni riga, i dettagli della singola rata.

Ad esempio, dato un contratto, si suppone che la data di stipula sia gennaio 2016 e il termine del contratto `e previsto per dicembre 2020.

5 – POPOLAMENTO DEL DATA MART

Scegliendo un mese e anno di riferimento casuale, ma appartenente al periodo in cui il contratto `e a reddito, come marzo 2017, i mesi e anni proiettivi presentano valori nell’intervallo da dicembre 2016 a dicembre 2020 (data di chiusura del contratto). Per il mese e anno proiettivo pari a dicembre 2016, il piano di ammortamento mostra attributi aggregati, ad esempio il totale delle rate, della quota capitale e della quota interesse da gennaio a dicembre 2016; per i successivi, il piano di ammortamento evidenzia il dettaglio della specifica rata prevista in quel mese e anno proiettivo, cos`ı fino alla chiusura del contratto.

Ci`o implica una significativa ridondanza con conseguenze sulle dimen- sioni della tabella dei fatti in termini di righe. Non potendo eliminare tale ridondanza, in quanto gli importi delle rate, della quota capitale, degli interessi e di tutti i valori legati a questi potrebbero modificarsi nel tempo, l’unica soluzione `e la riduzione delle colonne, ossia individuare quelle indispensabili per le nostre analisi ed eliminare le superflue.

Individuate le tabelle e i campi funzionali per l’analisi, sono state ge- nerate delle tabelle di appoggio come “staging area” su cui poter svolgere la fase di trasformazione, senza modificare quelle originali. In partico- lare, la trasformazione dei dati ha riguardato la rimozione di attributi ritenuti irrilevanti, l’eliminazione di righe duplicate, la creazione di nuo- vi campi che rispettassero le dipendenze funzionali (ad esempio, mese e anno di riferimento o il numero di contratto e il relativo modulo) e la cancellazione di record che rappresentano contratti chiusi, dato che il

5 – POPOLAMENTO DEL DATA MART

nostro progetto ha lo scopo di analizzare soltanto i contratti attualmen- te redditizi. Per quest’ultimo si sono sfruttate le logiche utilizzate nel DWH di origine per distinguere i contratti a reddito da quelli chiusi o sospesi.

Successivamente alla fase di manipolazione e trasformazione, si `e giun- ti al caricamento dei dati. Create le entit`a rappresentanti la tabella del fatto e le dimensioni, specificando le relazioni con chiavi primarie ed esterne, il caricamento dei dati `e stato eseguito mediante query SQL, trasferendo le ennuple dalle tabelle di appoggio a quelle definitive.

Nella Figura 5.2 `e mostrata la query SQL per la creazione della tabella del fatto. Come si osserva, l’interrogazione `e composta da due parti principali: con la keyword CREATE TABLE si genera la tabella vuota e si definiscono le chiavi esterne e gli attributi della tabella indicando, per ognuno di essi, il tipo e la lunghezza del campo; con la keyword REWRITE TABLE la stessa tabella viene popolata estrapolando i dati dalle strutture di appoggio.

5 – POPOLAMENTO DEL DATA MART

Il data mart finale `e rappresentato in Figura 5.3.

5 – POPOLAMENTO DEL DATA MART