QlikSense e il problema delle date (parte seconda)

Nel post precedente, ho descritto la “soluzione” proposta da Qlik al problema della gestione delle date fino a febbraio 2015. Dopo questa data, con la versione 1.1 di QlikSense, è stata introdotto un nuovo modo di gestire i campi data, eliminando la necessità di creare il Master Calendar.

Fine di tutti i problemi connessi con le date? Non esattamente.
Capiamo per prima cosa come funziona la nuova gestione delle date.

Mediante la procedura guidata di importazione dei dati, tutti i campi riconosciuti come date vengono derivati, vengono cioè dotati di attributi che permettono una gestione più semplice, senza aggiungere ulteriori campi o tabelle.
Non è più necessario preoccuparsi dei buchi di calendario nel front-end, basterà utilizzare la scala continua (presente però solamente negli istogrammi!).

In questo modo, viene risolto il problema relativo alla riduzione dei dati.
Volendo riproporre l’esempio del post precedente, se le colonne della serie in figura fossero le vendite di viti e bulloni di un’azienda, selezionando solo le viti il grafico non “perde” il mese di Agosto.

Quindi sono stati risolti tutti i problemi? Non esattamente.
E’ molto comune voler confrontare dati di un periodo (es. anno corrente) con quelli del periodo precedente (es. anno precedente), a questo scopo si utilizzano set analysis e set expressions, vincolando i dati visualizzati al periodo corrente o a quello precedente, il risultato è il seguente:

I valori in blu sono vincolati al periodo corrente, mentre quelli in rosso al periodo precedente, questo si può ottenere tranquillamente sia con il vecchio Master Calendar che con la più recente derivazione dei campi.

Se il risultato è il medesimo, il modo per ottenerlo è completamente diverso:

1. Sum({<Year={$(=max(Year)-1)}>} Valore)
2. Sum({<[Date.autoCalendar.YearsAgo]={1}>} Valore)

La prima riga di codice riguarda il Master Calendar, la formula è flessibile e restuisce l’anno precedente rispetto al più recente anno selezionato, in pratica si adatta a qualsiasi selezione effettuata dinamicamente.

La seconda riga invece si riferisce alla soluzione implementata con la versione 1.1 e successive di QlikSense, non vi è alcuna flessibilità, la scelta degli anni passati è fissa rispetto all’anno più recente presente nella serie di dati caricati (se l’anno più recente è il 2017, la formula vincola i dati al 2016).

Per chi proviene da Qlikview, abituato ai selettori di anni, mesi, trimestri in bella vista sui cruscotti, non si tratta di una limitazione di poco conto.

Attendiamo le future versioni per vedere risolta questa frustrante limitazione.

QlikSense e il problema delle date

Sto usando da qualche tempo QlikSense, l’evoluzione di QlikView, il più famoso tra i software di business intelligence (o data visualization come si dice ora). In Italia indiscutibilmente leader.

I punti di forza sono molteplici e ben noti ma, se ne conoscono anche i limiti?

Uno dei principali, a mio parere, è rappresentato dalla gestione delle date (i campi formattati come data).

Se ci si limita ad importare dati, andandoli a rappresentare in un semplice grafico ci si accorge che le date non vengono affatto gestite. Ecco un esempio.

Ingrandendo l’immagine, si nota che mancano alcuni giorni alla sequenza, in pratica i dati sono caricati così come sono, senza interporre i giorni del calendario mancanti dai record caricati.

Rappresentando gli stessi dati raggruppandoli per mese, si espone in maniera più chiara il problema di una tale “non gestione”: un anno con 11 mesi.

Prima della versione 1.1 (uscita ad inizio 2015) la soluzione proposta ufficialmente da Qlik era il Master Calendar, uno script da includere nel back-end in modo da creare una tabella aggiuntiva con tutte le date, collegata opportunamente alle altre tabelle in modo da risolvere il problema dei buchi.

Purtroppo la soluzione è parziale e funziona solo se non vengono limitati i dati, se ad esempio le colonne della serie in figura fossero le vendite di viti e bulloni di un’azienda, selezionando solo le viti ci si ritroverebbe nuovamente con un anno di 11 mesi.

Per ovviare a questo problema, esistono soluzioni efficaci ma piuttosto bizzarre (e mai risolutive), che implicano la creazione di record dummy al solo scopo di riempire i buchi tra le date (tipo questa, o questa).

Insomma, quelli di Qlik non hanno minimamente pensato a gestire le date e di fronte ai problemi degli utenti se ne sono usciti con soluzioni posticce e per nulla risolutive.

Se si pensa ai casi (e sono molti) in cui devono essere gestite più date differenti nella medesima base dati, la soluzione di Qlik è a dir poco discutibile: denormalizzare i dati.

https://community.qlik.com/blogs/qlikviewdesignblog/2012/08/30/master-table-with-multiple-roles

Non è certo il consiglio che mi aspetterei di ricevere da chi mi vende un prodotto di data visualization.