Comportamento anomalo di una misura in presenza di filtro L’argomento è risolto

[Ryo-Saeba]

Buongiorno,
Vorrei segnalarvi un'anomalia che non riesco a spiegare.
Ho creato un database di esempio per generare questa anomalia, definendo due misure:
1. La prima misura conta gli elementi in modo univoco correlando il codice e la relativa versione:

Conta Codici =
COUNTX(
'DB',
'DB'[Codice]&"_"&'DB'[Versione]
)

2. La seconda misura implementa lo stesso conteggio, ma rimuovendo il filtro dall'attributo Tipo:

Conta Codici No Tipo =
CALCULATE(
[Conta Codici],
ALL('DB'[Tipo])
)

Ho rappresentato queste due misure in una matrice, e inizialmente tutto funziona correttamente:
• In assenza di filtri, la seconda misura restituisce un valore costante.
• Lo stesso accade applicando un filtro sull'attributo Appartenenza.
• Anche applicando un filtro su Tipo e Appartenenza contemporaneamente, il valore della seconda misura rimane costante.
Tuttavia, applicando un filtro sulla Data di Rilascio emerge l'anomalia.
Senza filtrare per Tipo, la seconda misura dà un risultato coerente con i precedenti, ovvero un valore costante. Ma se filtro per Tipo, il valore della seconda misura cambia inaspettatamente. Nell'esempio, il valore dovrebbe rimanere 2511, ma applicando il filtro su Tipo diventa 51.








i file sono disponibili a questo link

https://www.dropbox.com/scl/fo/4e0gnkwe ... 30n2a&dl=0

[Andrea90]

Vorrei segnalarvi un'anomalia che non riesco a spiegare.

Più che anomalia direi comportamento in linea con la misura e con il modello che hai creato....

Crea un modello dati che segua una logica Star Schema e utilizza le Lookup Table per poter legare in maniera corretta i campi dimensionali con la tua tabella dei fatti.

Andrea

[Ryo-Saeba]

Ciao Andrea, grazie per la risposta.

Il modello che ho creato è piuttosto semplice e consiste in un'unica tabella dei fatti.

Nel modello reale da cui deriva quello allegato, pensavo che ci fosse qualche interazione con altri filtri in relazione con la tabella che generasse quella che a me pare un'anomalia. Quindi ho semplificato il modello mantenendo un'unica tabella dei fatti, ottenendo comunque il risultato scorretto.

Come puoi vedere dall'esempio, la penultima immagine mostra correttamente il risultato per la riga dove è presente il tipo MG1 con valori 14 e 2511.

Nel momento in cui applico il filtro esterno, però, inspiegabilmente ottengo 14 e 51.

Questo accade solo quando è attivo il filtro esterno "Data Rilascio".

Necessariamente il motivo è da ricondursi al campo Data Rilascio, infatti se applico altri filtri come l'appartenenza tutto funziona correttamente. Ma essendo che Data Rilascio è nella stessa tabella non mi spiego perché.

Inoltre non riesco a spiegarmi da dove derivi il 51. Guardando la tabella e applicando i passaggi, non capisco come si generi quel numero.

Grazie,
Stefano

[Andrea90]

@Ryo-Saeba,

Il motivo è nel modello dati, per come è stato realizzato si genera questo errore. Se tu avessi un modello dati a Star Schema, ed utilizzassi i giusti campi per creare i tuoi report e le tue misure il conteggio "errato" non si verificherebbe.

L'esempio che hai preso tu contiene troppi valori quindi ne prendo un altro per spiegarti cosa succede con la misura che hai creato.

Filtra per [Appartenenza] = G08
Filtra per [Date Rilascio] da 07/02/2023 a 01/07/2024

Otterrai una tabella con due righe:


Ora se dal filtro [Tipo] selezioni solo "MZ0" vedrai che da 82 che erano ottieni 14 e sembrerebbe cosa strana visto che questo [Tipo] aveva inizialmente solo 8 codici duplicati....

Il motivo è che per come è il modello (tutto dentro una stessa tabella), quando fai quel conteggio rimuovi l'effetto filtro del campo [Tipo], ma gli altri rimangono attivi.... Quindi se tu vai nella base dati e filtri per:

1) Tipo --> MZ0
2) Appartenenza --> G08
3) Data Rilascio --> il range che ho indicato sopra

Ottieni una tabella di 8 righe... che sono quelle che stavi contando inizialmente.
Ottieni anche una lista di date possibili, questa qui:

24/02/2023
27/03/2023
25/10/2023
13/12/2023
15/12/2023
01/02/2024
28/03/2024
21/06/2024

Ora se prendi la tabella completa e la filtri per gli unici filtri che dovrebbero rimanere attivi (escludi quindi [Tipo]) avrai che se cerchi per:

1) Appartenenza --> G08
2) Data Rilascio --> solo le date che risultavano dal filtro applicato precedentemente (le 8 che ti ho evidenziato)....

Otterrai questa tabella che contiene le 14 righe incriminate


P.s. La misura che hai creato per calcolare i duplicati è sbagliata, se togli tutti i filtri ottieni 84.844 righe, ma ci sono alcuni duplicati che non stai eliminando, perché per le combinazioni [Codice] [Versione] i valori univoci dovrebbero essere 84.796

Andrea

[Ryo-Saeba]

Grazie per la risposta Andrea,
grazie al tuo contributo ho risolto il problema spezzettando il modello, ora le misure funzionano correttamente.
Per meglio comprendere il meccanismo ho inizialmente rimosso i duplicati [Codice]_[Versione] dalla tabella DB riscontrando comunque il problema.
Ho quindi creato due tabelle:

La prima: Gruppo|Tipo|Codice|Versione|Appartenenza
La seconda: Codice|Versione|Stato|Data Stato|Data Programmazione|Data Rilascio

per entrambe le tabelle ho creato una chiave: Codice+Versione

Ho creato la relazione 1:1 tra le due tabelle

Quindi ho ottenuto il risultato

Detto questo non capisco comunque il perché di questo comportamento, ovvero col modello errato (la tabella unica) io specifico con un filtro esterno che la data deve essere compresa tra 07/02/2023 e 01/07/2024

Quindi nella misura:

Conta Codici No Tipo =
CALCULATE(
[Conta Codici],
ALL('DB'[Tipo])
)

chiedo di calcolare la misura [Conta Codici] rimuovendo il filtro dalla colonna [Tipo]

quindi, mi aspetterei che il nuovo contesto sia:

- la colonna [Data Rilascio] deve essere compresa tra "07/02/2023" e "01/07/2024"
- la colonna [Appartenenza] deve essere uguale a "G08"
- la colonna [Tipo] non deve essere filtrata

perché invece:

la colonna [Data Rilascio] si setta sui singoli valori validi nel contesto in cui la misura si troverebbe se non ci fosse ALL('DB'[Tipo]):

24/02/2023
27/03/2023
25/10/2023
13/12/2023
15/12/2023
01/02/2024
28/03/2024
21/06/2024

Ti ringrazio,
Stefano

[Andrea90]

- la colonna [Tipo] non deve essere filtrata

Perché ?

Guarda che il CALCULATE agisce dopo che sia stato creato il contesto filtro originale.... Tu hai impostato i tuoi filtri tramite gli oggetti filtro e la misura che crei agisce sull'intera tabella DB (cosa da evitare e che ti genera l'errore nel calcolo che ti ho evidenziato nel p.s.).

Quindi inizialmente, per ciascuna cella di quella matrice, la misura considera il contesto filtro del campo [Data], [Appartenenza] e [Tipo]... e quindi si crea la lista dei valori per ciascuno di questi campi visibili nel contesto filtro. Poi tu chiedi, tramite CALCULATE, di non considerare la lista dei valori [Tipo], ma tutti gli altri rimangono.

Ecco perché quella lista di date continua a produrre effetti andando a "sfalsare" il calcolo.

Andrea

[Ryo-Saeba]

Grazie Andrea,

mi hai chiarito un concetto che non avevo compreso correttamente. Pensavo erroneamente che la condizione di filtro "tra due date" venisse mantenuta e aggiornata automaticamente.

Immaginavo che l'algoritmo di calcolo gestisse i dati nello stesso ordine con cui applico i filtri in una tabella. Ora ho capito che non è così: gli elementi filtrati nel contesto originale rimangono invariati e i filtri sugli attributi specificati all'interno di Calculate vengono rimossi.

Grazie per la pazienza e la rapidità nella risposta!

Stefano

[Andrea90]

Pensavo erroneamente che la condizione di filtro "tra due date" venisse mantenuta e aggiornata automaticamente.

Vorrei ribadire un concetto per gli utenti futuri, in quel modello, così come lo avevi pensato, non può essere "mantenuta" la condizione del campo filtro sulle date, perché il campo data è preso dalla stessa tabella. Mentre in una condizione normale il campo data, essendo un campo dimensionale, dovrebbe essere salvato all'interno di una tabella dedicata (appunto chiamata tabella Calendario).

E così via per le altre dimensioni, come appartenenza, Tipo, ecc...

A livello teorico, la tabella dei fatti dovrebbe contenere solamente i campi che andrai ad aggregare e i campi chiave che utilizzi per legare la tabella dei fatti a tutte le altre tabelle dimensionali.

Se fai così, quel ALL(tab_anagrafica[Tipo]) avrà effetto solo sulla tabella dimensionale, e non influenzerà anche le altre dimensioni.

Andrea