Salta al contenuto

Lost in Translation!

Cambiare istantaneamente la lingua utilizzata in una dashboard si può?

Ovviamente sì! Basta modellare i dati con attenzione e un po’ di DAX (neanche troppo, per la verità) farà il resto.

Vediamo come!

Sviluppo

In uno scenario di questo tipo, il Data Model è l’elemento più importante.

Se correttamente implementato, consentirà di raggiungere il risultato in modo molto “pulito” e sobrio.

Si immagini di avere una tabella dei Fatti, per esempio si potrebbe pensare ad un Conto Economico, in cui ogni riga sia stata identificata rispetto ad un Concetto di Business.

Un Concetto di Business potrebbe essere, ad esempio, quello di “Ricavi di vendita dei prodotti e delle merci o di prestazione dei servizi relativi alla gestione“.

Tale tipo di Concetto di Business si manifesterà nel corso del tempo e tali eventi verranno registrati nella tabella dei Fatti.

La relazione che sussiste tra le tabelle che, rispettivamente, rappresentano i Concetti e i Fatti è del tipo “1 a molti” come mostrato graficamente nella figura seguente (figura 1):

figura 1

Si può facilmente riconoscere che ogni singolo Fatto è sempre abbinabile ad un solo Concetto di Business mentre un Concetto di Business si verificherà molte volte.

Procedendo nel ragionamento, si può affermare che ogni lingua è in grado di esprimere molteplici concetti.

Questo tipo di considerazione conduce a riconoscere l’esistenza di una relazione del tipo “molti a molti” tra le entità “Lingua” e “Concetto“.

La “bridge table” da introdurre per gestire questo tipo di relazione avrà un numero di righe pari al prodotto tra il numero di Concetti presi in considerazione e il numero di Lingue che si vorranno mettere a disposizione dell’utenza per una traduzione immediata.

In altre parole la “bridge table” sarà il risultato di un “prodotto cartesiano” tra la tabella delle Lingue e la tabella dei Concetti.

La figura numero 2 mostra chiaramente questo tipo di soluzione:

figura 2

Il modello dei dati, nella sua interezza, assume la configurazione mostrata dalla figura numero 3:

figura 3

Stabilita la struttura del Data Model, per avere un’idea dei dati presi in considerazione, si possono osservare le figure che seguono, relative al contenuto delle singole tabelle utilizzate nell’esempio:

1. Tabella “Concetto” (figura numero 4)

figura 4

2. Tabella “Fatti” (figura numero 5)

figura 5

3. Tabella “Lingua” (figura numero 6)

figura 6

4. Tabella “Concetti Espressi in Lingua” (figura numero 7)

figura 7

Giunti a questo punto, occorre immaginare come si potrebbe ottenere una rappresentazione dei Concetti di Business espressa nella lingua che l’utente avrà selezionato.

In sostanza, si vorrà poter ottenere i seguenti effetti:

Selezione della lingua “italiano” (figura 8)

figura 8

Selezione della lingua “inglese” (figura 9)

figura 9

Tutto ciò utilizzando un’unica misura “Importo“.

Per prima cosa occorre notare che i Fatti sono stati caricati in un’unica versione che prescinde dalla lingua selezionata e, invece, è basata sui Concetti Economici sottostanti (si torni alla figura 5 e si potrà verificare che ogni riga riporta un importo e un identificativo che fa riferimento ad un “Concetto” di Business).

Occorre anche porre l’attenzione sul dettaglio che un’eventuale condizione di filtro posta sulla Tabella “Lingua” non avrà, di per sé, alcun impatto sulla Tabella “Fatti”.

Lo stesso vale per un qualunque filtraggio effettuato sulla tabella “Concetti Espressi in Lingua”.

Osservando le impostazioni adottate per le direzioni di filtraggio (cross filter direction), infatti, si può verificare che l’unica tabella che filtra la Tabella “Fatti” è la Tabella “Concetto” e che la Tabella “Lingua” è in grado di filtrare esclusivamente la Tabella “Concetti Espressi in Lingua” (figura numero 10):

figura 10

Com’è possibile, allora, che una selezione effettuata su un valore della Tabella “Lingua” e, volta per volta, su un valore della Tabella “Concetti Espressi in Lingua” si ripercuota sulla Tabella “Fatti” consentendo un’aggregazione “sensata” dei valori in essa contenuti e astrattamente riferibili alle singole voci della Tabella “Concetti Espressi in Lingua”?

figura 11

Per comprendere la soluzione bisogna dare un’occhiata al codice DAX relativo alla Misura “Importo“:

Importo =
IF (
    HASONEVALUE ( Lingua[Lingua] ),
    SUMX ( ‘Concetti Espressi In Lingua’, CALCULATE ( SUM ( Fatti[Imp] ) ) )
)

La funzione “IF” si occupa di fare in modo che la misura “Importo” restituisca un valore solo nel caso in cui, per effetto della selezione operata dall’utente, sia visibile un unico valore nella colonna “Lingua” della Tabella “Lingua“.

In caso contrario, il test fallirebbe e, di proposito, si otterrebbe un valore BLANK in quanto il secondo argomento della funzione “IF” è stato volontariamente omesso.

Questo tipo di accorgimento assicura che nella tabella compaiano sempre voci riferite ad un’unica lingua, quella scelta dall’utente.

A parte questo piccolo accorgimento implementato tramite la funzione “IF”, tutto il grosso del lavoro è affidato alla funzione “SUMX“.

Nella sua apparente semplicità, questa implementazione sfrutta un concetto molto importante, il concetto di “Expanded Tables“.

Andando con ordine, si può notare che il primo argomento di “SUMX” è la Tabella “Concetti Espressi in Lingua” e ciò significa che l’iterazione avverrà su questa tabella.

Per ogni riga della tabella iterata verrà valutata l’espressione specificata al secondo argomento, vale a dire CALCULATE ( SUM ( Fatti[Imp] ) ).

Si inizia ad intravedere il legame con la Tabella dei Fatti e, tuttavia, le cose non sono ancora così chiare.

La funzione racchiusa in CALCULATE è una “SUM” che si limita ad aggregare con una somma algebrica i valori della colonna “Imp” (valori da sommare) della Tabella “Fatti”.

Come fare in modo che SUM prenda in esame solo i valori pertinenti, in astratto, la specifica voce della Tabella “Concetti Espressi in Lingua”?

L’utilizzo di CALCULATE nell’ambito di un’iterazione provoca una Context Transition il che, si ricorda, equivale a trasformare in un filtro equivalente ogni valore riferibile alle singole colonne che compongono la riga corrente di ogni eventuale iterazione in corso.

Apparentemente ciò non dovrebbe sortire alcun effetto per le ragioni esposte sopra: la Tabella “Concetti Espressi in Lingua“, oggetto di iterazione e della successiva Context Transition, non filtra la tabella dei fatti.

Ciò che non bisogna dimenticare per comprendere, finalmente, come l’effetto della Context Transition si sia opportunamente propagato fino alla Tabella “Fatti” è il concetto di “Expanded Tables“.

Ogni tabella, infatti, possiede una versione “espansa” che contiene tutte le colonne della tabella stessa e tutte quelle delle tabelle costituenti il “lato 1” di una catena ininterrotta di relazioni “molti a 1“.

Inoltre, la Context Transition avviene sulla versione espansa della tabella iterata.

Rimettendo insieme questi concetti, si può verificare che la versione espansa della Tabella “Concetti Espressi in Lingua” contiene tutte le colonne della tabella “Concetto” e, pertanto, una Context Transition durante un’iterazione produrrà un filtro sulle colonne della tabella “Concetto”, tabella che si trova sul “lato 1” di una relazione con la Tabella “Fatti“.

La valutazione della funzione SUM ( Fatti[Imp] ) avverrà in questo nuovo Filter Context e, pertanto, le righe della Tabella “Fatti” che risulteranno visibili saranno solo quelle compatibili con lo specifico Concetto inerente la Voce della Tabella “Concetti Espressi in Lingua” presa in esame.

Conclusioni

Un buon modello può consentire la riduzione delle operazioni di ETL e, in generale, l’adozione di soluzioni più o meno “cervellotiche” tese a facilitare l’indagine dei dati ma che finiscono, molto spesso, per produrre modelli più ingombranti e difficili da mantenere.

Un’attenta analisi del modello e la scrittura di un DAX più “ragionato”, nella maggior parte dei casi, consentono anche di evitare pratiche discutibili come, ad esempio, l’attivazione dei cosiddetti filtri “bidirezionali”.

Acquisire sempre maggiori competenze ed allenare la mente a ragionamenti che sfruttano appieno il potenziale offerto dal linguaggio DAX può essere faticoso, va ammesso, ma consente di ottenere una potenza di calcolo veramente importante e, perché no, entusiasmante.

Autore del Post

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *