Contando los valores distintos del atributo de la dimensión

Un usuario Pregunto ✅

Anónimo

Hola tios,

Necesito tu ayuda. Tengo que contar los distintos proveedores a los que realicé al menos una compra, dado un determinado contexto de filtro.

Dado que la relación entre la tabla de dimensiones de los proveedores (‘Fornitori intestatari’) y la tabla de hechos de las compras (‘Acquisti’) se establece como una dirección de filtro unidireccional estándar, uno a muchos:

Imagen.png

Estaba bastante seguro de que era necesaria una fórmula dax como esta, aprovechando una función CROSSFILTER() o similar para obtener el recuento distinto de proveedores, filtrado por la tabla de hechos de compras:

Fornitori con fatturato =
VAR DatiFatturato = CALCULATETABLE(‘Adquisición’;’Adquisición'[Flag fatturato]=1)
REGRESO
CUENTAS(
CALCULABLE (
VALORES(‘Fornitori intestatari'[Fornitore – Descrizione]);
DatiFatturato;

FILTRO CRUZADO (‘Adquisi'[K_CodCli]; Fornitori intestatari[K_CodCli]; AMBOS)
))

y funciona, efectivamente.

Lo que no puedo explicarme a mí mismo es que esta versión ultrasimplificada de la expresión también parece funcionar bien:

Fornitori con fatturato =
VAR DatiFatturato = CALCULATETABLE(‘Adquisti’;’Adquisti'[Flag fatturato]=1)
REGRESO
CALCULATE(DISTINCTCOUNT(‘Fornitori intestatari'[Fornitore – Descrizione]); DatiFatturato)

¿Alguien puede explicarme por qué? Mi hipótesis es que DISTINCTCOUNT está trabajando en lo que aquí (https://www.sqlbi.com/articles/expanded-tables-in-dax/) se denomina ‘la versión ampliada’ de la tabla de hechos ‘Acquisti’, en lugar de la tabla de dimensiones ‘físicas’ ‘Fornitori intestatari’, es decir, una especie de SELECT * FROM ‘Aquisti’ LEFT JOIN ‘Fornitori intestatari’, si entendí correctamente.

Si es así, ¿es segura esta sintaxis o es mejor la primera?

¡Gracias!

En respuesta a mariusz

Hola tios,

La versión ampliada de Acquisti en realidad contiene la tabla Fornitori completa.

Por lo tanto, si usa Acquisti como argumento de filtro en CALCULATE, también está filtrando Fornitori. CROSSFILTER es inútil en este caso. Podría obtener lo mismo realizando un DISTINCTCOUNT, use CROSSFILTER evitando la variable en absoluto.

Dicho esto, usaría algo más fácil de leer, como:

CUENTAS ( RESUMEN ( Adquisti, Fornitori[Fornitore – Descrizione] ) )

No verifiqué el rendimiento, pero no debería ser tan malo y definitivamente más fácil de leer.

Anónimo

Es bastante simple. Cuando haces una cuenta distinta (hecho[DimKey] ), solo está calculando la cantidad de DimKey diferentes en su tabla de hechos en las filas que son visibles en el contexto actual. sin magia Esta simple medida aplicada a su modelo hace exactamente lo que desea:

Tengo que contar los distintos proveedores a los que realicé al menos una compra, dado un determinado contexto de filtro.

Mejor
D

Anónimo

En respuesta a Anónimo

No soy. estoy haciendo DISTINCTCOUNT( Dimensión[DimAttribute] ), sobre una relación unidireccional, y funciona igual que la versión CROSSFILTER() de la fórmula.

Anónimo

En respuesta a Anónimo

En este caso (que me perdí) las tablas expandidas están en funcionamiento.

Mejor
D

Anónimo

En respuesta a Anónimo

Pero no debe usar esta técnica, ya que puede ser lenta y requerir muchos recursos. Usa lo que hice arriba.

Mejor
D

Anónimo

En respuesta a Anónimo

Bien, pero puede que tenga que contar el número distinto de atributos dim que no tienen la misma granularidad de la clave de la dimensión, por ejemplo, el país del proveedor. El punto es que la propagación del filtro en DAX todavía no me queda del todo clara.

Gracias

¡Chau!

greg_deckler

¿Puedes simplemente cambiar la relación a Ambos?

Anónimo

En respuesta a greg_deckler

La relación tiene que ser unidireccional. El punto es que esperaría que la segunda expresión de la fórmula funcione solo después de establecer el tipo de relación en ‘ambos’, mientras que funciona correctamente incluso con la relación establecida en ‘único’…

mariusz

En respuesta a Anónimo

hola @anonimo

La razón por

VAR DatiFatturato = CALCULATETABLE('Acquisti';'Acquisti'[Flag fatturato]=1) 

no poder propagar los filtros a ‘Fornitori intestatari’ es que ‘Adquisti’ dentro de CALCULATETABLE ya no se expande, por lo que no incluye ‘Fornitori intestatari’.

Puede probar lo siguiente si la granularidad de ‘Fornitori intestatari'[Fornitore – Descrizione] es diferente a ‘Fornitori intestatari'[K_CodCli]

Fornitori con fatturato =
CALCULATE(
    DISTINCTCOUNT( 'Fornitori intestatari'[Fornitore - Descrizione] );
    CROSSFILTER( 'Acquisti'[K_CodCli]; 'Fornitori intestatari'[K_CodCli]; BOTH );
    'Acquisti'[Flag fatturato] = 1
)

@AlbertoFerrari Corrija si me equivoco o elabore para que podamos entender.

Atentamente,
mariusz

Si esta publicación ayudaentonces por favor considere Aceptarlo como la solución.

Por favor, siéntase libre de conectarse conmigo.
LinkedIn

En respuesta a mariusz

Hola tios,

La versión ampliada de Acquisti en realidad contiene la tabla Fornitori completa.

Por lo tanto, si usa Acquisti como argumento de filtro en CALCULATE, también está filtrando Fornitori. CROSSFILTER es inútil en este caso. Podría obtener lo mismo realizando un DISTINCTCOUNT, use CROSSFILTER evitando la variable en absoluto.

Dicho esto, usaría algo más fácil de leer, como:

CUENTAS ( RESUMEN ( Adquisti, Fornitori[Fornitore – Descrizione] ) )

No verifiqué el rendimiento, pero no debería ser tan malo y definitivamente más fácil de leer.

Anónimo

En respuesta a albertoferrari

@AlbertoFerrari, sería un simple DISTINCTCOUNT( Hecho[DimKey] ) no es suficiente?

Mejor
D

En respuesta a Anónimo

Sólo si estás contando las llaves. Si un atributo de la dimensión no es único (piense en la ciudad, el nombre, el género), entonces debe usar RESUMEN o la tabla expandida. O filtrado bidireccional… pero ya sabes, el filtro cruzado bidireccional es como abrir la puerta del infierno para decir «Hola». Fascinante… pero mejor aléjate 🙂

Anónimo

En respuesta a albertoferrari

Sé todo esto. Pero la tarea original era calcular el número de proveedores distintos que realizaron al menos una compra.

Mejor
D

En respuesta a Anónimo

Sí, tienes razón. Me pareció que el objetivo era comprender lo que sucede debajo, y no solo hacer que la medida funcionara.

De todos modos, buena charla, esto es lo que realmente importa. Aparentemente, no hubo problema, pero pasamos un buen rato discutiéndolo. 🙂

Anónimo

En respuesta a albertoferrari

Sí, tal vez el ejemplo fue engañoso, pero el propósito era entender un poco más lo que sucede detrás de la cortina…

¡Gracias a todos, chicos!

mariusz

En respuesta a albertoferrari

Hola @AlbertoFerrari

Gracias por saltar y aclarar.

Gracias

mariusz

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *