Qlik Sense, pur non offrendo un tool ufficiale dedicato all’ETL, pro- pone due soluzioni alternative per simulare ed approssimare le tre fasi: il data manager, mediante procedure manuali, oppure l’editor di carica- mento dei dati, tramite lo sviluppo di script. La scelta della soluzione migliore varia principalmente in base alla mole dei dati - `e preferibile scegliere la seconda alternativa nel caso in cui la quantit`a dei dati sia considerevole - e alle competenze tecniche dell’utente che possiede i di- ritti per la creazione di app, da qui chiamato sviluppatore.
Il procedimento da seguire cambia a seconda dell’approccio selezionato. Se si opta per il data manager, tutte le operazioni vengono svolte manualmente dallo sviluppatore. Per la descrizione di questa soluzione si fa riferimento alla documentazione ufficiale [DataManager-18], dove sono definiti tutti i passaggi utili per creare il modello dati. La prima fase, l’estrazione, inizia scegliendo la sorgente da cui estrapolare i dati. La figura 5.4 mostra i vari tipi di origine dati: file locali, sorgenti di dati esterne, inserimento manuale. Inoltre, `e possibile specificare delle condizioni di filtro per estrarre solamente dati specifici.
La fase di trasformazione e manipolazione dei dati riguarda opera- zioni svolte a discrezione dello sviluppatore, come la modifica del tipo e del formato dei valori di un campo, l’aggiunta di un campo calcolato, la concatenazione di due tabelle in una unica con campi combinati. In que- sta fase `e prevista anche la gestione delle associazioni delle tabelle dati.
5 – POPOLAMENTO DEL DATA MART
Figura 5.4: Origine dati - Qlik Sense
Quest’attivit`a `e fondamentale per la creazione del modello dati. Si pos- sono creare associazioni in base a dei suggerimenti proposti da Qlik Sense oppure associazioni personalizzate. Precisamente, lo strumento genera una relazione tra due o pi`u tabelle basandosi sui campi che presentano nomi identici in ognuna di esse. Quando due o pi`u tabelle possiedono due o pi`u campi con lo stesso nome, Qlik Sense crea automaticamente delle relazioni utilizzando le chiavi composte (risultanti dalla concatena- zione dei valori dei campi in comune), dette chiavi sintetiche. Il risultato ultimo `e il data model definitivo dell’app.
Infine, la fase di caricamento dei dati combacia con quella di estrazio- ne. I dati estratti vengono caricati su tabelle che, salvo eliminazioni o concatenazioni, apparterranno al modello finale.
Per quanto riguarda l’editor di caricamento dei dati, facciamo riferi- mento alla documentazione ufficiale [LoadScript-18]. Tutte le fasi del- l’ETL vengono eseguite per mezzo di script sviluppati nel linguaggio proprietario di Qlik Sense. Uno script `e costituito da un certo numero
5 – POPOLAMENTO DEL DATA MART
di istruzioni che vengono eseguite consecutivamente. Come affermato nella documentazione [SyntaxScript-18], le istruzioni possono essere di controllo o regolari: le prime vengono sfruttate per controllare il flusso di esecuzione mentre le seconde vengono generalmente utilizzate per la manipolazione dei dati.
Per la fase di estrazione, innanzitutto `e indispensabile definire una con- nessione alla sorgente da cui estrapolare i dati. In Qlik Sense non possono coesistere connessioni parallele: ogniqualvolta si apre una connessione, questa resta aperta fino a quando se ne apre una nuova o l’esecuzione dello script termina. Successivamente, si utilizzano gli script per con- nettersi e recuperare le informazioni, specificando i campi e le tabelle. All’interno dello script `e possibile attuare la fase di trasformazione e manipolazione ma anche quella di caricamento, mediante delle specifi- che istruzioni che verranno descritte in seguito. Durante il caricamento dei dati, cos`ı come nel data manager, vengono identificate le relazioni tra le tabelle, effettuando un controllo semantico sui campi e generando l’associazione tra due o pi`u tabelle quando queste presentano campi co- muni (con lo stesso nome).
Una volta caricati in Qlik Sense, i dati vengono memorizzati nell’app. Nel progetto ci siamo serviti dell’editor di caricamento dei dati. In particolare, il nostro ETL `e stato suddiviso in due parti: la prima ha l’obiettivo di estrarre i dati dalla sorgente e creare i file QVD, la seconda estrapola le informazioni dai file QVD e genera il data model dell’appli- cazione e il relativo file QVF.
5 – POPOLAMENTO DEL DATA MART
Prima di procedere alla descrizione, `e doveroso chiarire il concetto di file QVD e i motivi che hanno portato a questa scelta.
Un file QVD, come descritto in [FileQVD-18], contiene esattamente una tabella dati ed `e composto da due parti:
• l’intestazione, che presenta un formato XML accuratamente strut- turato in cui vengono descritti i campi della tabella, il layout delle informazioni e altri metadati;
• le tabelle dei simboli e i dati reali della tabella in formato compresso. I dati compressi ottimizzano il tempo impiegato per la lettura dei dati dai file QVD. Questi ultimi possono essere utilizzati per molti scopi, tra cui migliorare la velocit`a di caricamento e il caricamento incrementale dei dati, aggiornando i record esistenti nell’applicazione con quelli nuovi o modificati.
Figura 5.5: Origine dati ODBC
Nel lavoro svolto anzitutto `e stata definita una connessione ODBC, mostrata in Figura 5.5, che ha permesso il collegamento al data mart
5 – POPOLAMENTO DEL DATA MART
illustrato nel paragrafo 5.1. Ottenuta la connessione, si `e proceduto all’implementazione degli script per la prima e seconda parte con l’o- biettivo, rispettivamente, di estrazione e caricamento dei dati. La fase di trasformazione `e pressoch`e assente in quanto i dati estratti hanno gi`a sub`ıto tale procedimento.
Sia nella prima che nella seconda parte dell’ETL sono stati definiti tanti script quante sono le tabelle coinvolte (la tabella del fatto e delle dimen- sioni) e uno script principale, il main. Questa scelta d`a allo sviluppatore maggior chiarezza sul flusso di esecuzione connesso ad ogni tabella, ren- dendole, in un certo modo, indipendenti tra loro. Inoltre, in caso di modifica, rimozione o aggiunta di attributi alle tabelle esistenti, non `e necessario eseguire l’ETL dell’intero data mart, ma solo di quelle sog- gette alla variazione e specificate nel main della prima parte. Si precisa che i caricamenti avvengono in maniera sequenziale, per cui nell’editor di caricamento dei dati `e definito l’ordine di esecuzione degli script.
Nelle Figure seguenti si illustrano esempi di script sviluppati in Qlik Sense. Nel dettaglio, in Figura 5.6 `e esposto lo script del main della prima fase dell’ETL, mentre la Figura 5.7 mostra gli script rispettivamente della prima e della seconda fase connesse ad una tabella. Gli script sviluppati per la creazione delle altre tabelle assumono pressappoco la stessa forma.
5 – POPOLAMENTO DEL DATA MART
Figura 5.6: Il main della prima fase dell’ETL
(a) ETL prima fase (b) ETL seconda fase
Figura 5.7: ETL della tabella Piano Ammortamento
Negli script relativi alle tabelle vengono utilizzate le istruzioni re- golari, elencate e dettagliate in [ComandScript-18], come LOAD, SQL, STORE e DROP Table: il LOAD permette il caricamento dei campi da un file, da una tabella caricata in precedenza, da una pagina Web, dal ri- sultato di un’istruzione SELECT; l’SQL consente di inviare un comando arbitrario SQL tramite una connessione ODBC o OLE DB; lo STORE crea un file CSV o QVD; il DROP Table elimina una o pi`u tabelle interne di Qlik Sense dal data model.
5 – POPOLAMENTO DEL DATA MART
Procediamo con la descrizione della prima parte attinente alla fase di estrazione dei dati. Sono stati sviluppati diversi script a seconda della finalit`a:
• per il main: include la connessione alla sorgente dati, il path asso- luto della cartella in cui memorizzare i file QVD e le variabili per gestire l’esecuzione degli script corrispondenti alle tabelle;
• uno per ogni singola tabella: contiene la definizione dei campi ad essa associati.
Gli script relativi alle tabelle hanno lo stesso flusso di esecuzione che avviene in maniera sequenziale: se la condizione, rappresentata dall’i- struzione di controllo if..then che forza l’esecuzione o meno in base alla variabile settata nel main, `e soddisfatta si procede. Si assegna un nome alla tabella interna contenente le informazioni che verranno estratte. A questo punto si dovrebbe eseguire l’istruzione LOAD. In realt`a si parla di preceding LOAD, come meglio descritto in [PrecedingLoad-18]: se si estraggono i dati mediante un’istruzione SELECT, questa non permette l’uso delle funzioni fornite dallo strumento per manipolare i dati. La soluzione consiste, quindi, nell’aggiungere un’istruzione LOAD, antece- dente alla SELECT, in cui viene eseguita la fase di trasformazione dei dati come concatenazioni, applicazione di funzioni specifiche di Qlik Sen- se ed introduzione di alias. Nell’esempio `e stata utilizzata la funzione NUM per risolvere problemi di formattazione dei campi numerici. L’e- secuzione dello script, perci`o, prevede che venga dapprima valutata la
5 – POPOLAMENTO DEL DATA MART
SELECT, eseguendo la query, e in seguito il risultato viene elaborato ed esplicitato dal comando LOAD. Pertanto le informazioni vengono salvate (con lo STORE) nel file QVD e, poich`e i dati sono gi`a stati memorizzati, la tabella risultante viene eliminata (tramite il DROP Table).
La seconda parte riguarda invece la fase di caricamento vero e pro- prio dei dati, al fine di creare il data model dell’applicazione. Il numero degli script generati `e il medesimo della prima fase, ma cambiano i con- tenuti: nel main `e presente la variabile corrispondente al path assoluto della cartella da cui prelevare i file QVD; negli altri script, invece, l’u- nica istruzione adottata `e il LOAD: si estraggono i dati dai file QVD precedentemente creati e si caricano nell’applicazione. E compito di` Qlik Sense generare le relazioni tra le tabelle, con lo stesso procedimen- to descritto in precedenza, e dar vita al modello dati, che viene salvato all’interno dell’app ed `e visibile nella sezione Sistema di visualizzazione modello dati.
5 – POPOLAMENTO DEL DATA MART
La Figura 5.8 illustra il data model della nostra applicazione.
Figura 5.8: Modello dati dell’app - Qlik Sense
La dimensione Data
Confrontando il data model presente in Qlik Sense (Figura 5.8) con lo schema logico del data mart posto nel DBMS Sadas Engine (Figura 5.3) si pu`o osservare come, nel primo, la tabella Data subisca uno sdop- piamento. Il motivo `e legato all’impossibilit`a di inserire nella tabella del fatto (Piano Amm Fin) due chiavi esterne (connesse rispettivamente a mese/anno di riferimento e mese/anno proiettivo) che siano entrambe in relazione con la chiave primaria della tabella della dimensione Data. Il problema pu`o essere risolto seguendo una delle due alternative descritte di seguito:
– creare un’unica tabella Data che contenga tutte le combinazioni di mese/anno di riferimento e mese/anno proiettivo, e, come chiave,
5 – POPOLAMENTO DEL DATA MART
la concatenazione dei valori dei due attributi. Ci`o comporta la creazione di un’entit`a di dimensioni notevoli con una ridondanza dei mesi e degli anni;
– scindere la tabella Data in due entit`a separate, in cui la prima raccoglie i mesi/anni proiettivi, la seconda include i mesi/anni di riferimento.
Per motivi di semplicit`a e per non sovraccaricare il data model, la soluzione adottata `e la seconda alternativa esposta.
Le chiavi sintetiche
Come affermato in precedenza, le chiavi sintetiche vengono generate da Qlik Sense quando, durante il caricamento dei dati, si presentano, in almeno due tabelle, pi`u di un campo con lo stesso nome.
Figura 5.9: Chiave sintetica nel data model - Qlik Sense
Facendo riferimento a [SyntheticKey-13] e all’esempio riportato in Fi- gura 5.9 si osserva come le chiavi sintetiche modificano il data model.
5 – POPOLAMENTO DEL DATA MART
Per ognuna di esse viene creata un’ulteriore tabella (nell’esempio $Syn 1 Table) che contiene tutte le combinazioni dei valori relativi ai cam- pi comuni. Una soluzione efficiente adottata da Qlik Sense per gestire una chiave unica piuttosto che chiavi multiple. A questo punto, i campi in comune (Year, Month, Day) vengono sostituiti da un identificatore ($Syn 1 ) che individua univocamente la combinazione dei valori delle chiavi originali.
La presenza di chiavi sintetiche non rappresenta un problema ma esiste l’eventualit`a che possa diventarlo. Esse vengono gestite automaticamen- te da Qlik Sense per cui, man mano che aumentano, lo sviluppatore potrebbe perderne il controllo. Inoltre, nella maggior parte dei casi, so- no tabelle aggiuntive irrilevanti che contengono informazioni gi`a presenti in altre tabelle del modello dati. Infine, in molte occasioni, sono sinto- mo di errori nella progettazione, un allarme che pone lo sviluppatore a rivedere le proprie decisioni.
La generazione di chiavi sintetiche pu`o essere evitata attuando una delle soluzioni seguenti:
• rinominare i campi;
• applicare un join tra le tabelle, formandone una unica contenente i campi in comune;
• generare una chiave concatenata: relativamente all’esempio in Figu- ra 5.9, la chiave potrebbe esser composta da Year Month Day che conterr`a i valori concatenati e rappresenter`a quindi un unico campo
5 – POPOLAMENTO DEL DATA MART
chiave tra Facts e Dates. `E il medesimo principio che utilizza Qlik Sense per le chiavi sintetiche ma, in questo caso, senza l’ausilio di una tabella.
Capitolo 6
I DUE STRUMENTI DI BI A
CONFRONTO
Il lavoro di tesi prevede lo sviluppo di diverse dashboard, progettate con l’ausilio di strumenti di BI quali la piattaforma Qlik Sense e la suite SadasBI.
Le dashboard, anche dette cruscotti, consentono di monitorare ed ana- lizzare i dati significativi per l’utente.
Prima di presentare i risultati finali `e opportuno delineare un confron- to delle caratteristiche e dei principali punti di forza e debolezza delle due tecnologie. In particolare, abbiamo analizzato alcuni punti cruciali, elencati di seguito:
• l’accesso ai dati;
• il tempo di caricamento dei dati;
• l’utilizzo delle componenti hardware;
6 – I DUE STRUMENTI DI BI A CONFRONTO
6.1
L’accesso ai dati
Qlik Sense e SadasBI Manager prevedono una connessione alla sor- gente dati per poter estrapolare le informazioni.
In Qlik Sense i dati estratti vengono poi memorizzati all’interno di un file QVF che costituisce l’app. Ogni qualvolta l’utente apre un’app pu`o visualizzare il suo contenuto senza il bisogno di collegarsi alla fonte ini- ziale. Quindi Qlik Sense crea un’applicazione autonoma e distaccata dalla sorgente.
Nella suite SadasBI, invece, le informazioni visualizzate nelle dashboard sono i risultati delle interrogazioni SQL eseguite direttamente sull’origine dati. Per tale motivo il collegamento al database sorgente `e indispensa- bile e inevitabile.
Se da una parte questo approccio appare uno svantaggio per la suite Sa- dasBI, vedremo nella prossima sottosezione che, da un altro punta vista, si rivela essere un vantaggio.