Hola a todos,
Tengo un archivo pbix ContosoSales-Excerpt.pbix siendo sólo la tabla 'Producto' del ejemplo de ventas de Contoso. A continuación, hice una consulta de Dax por Dax Studio que calcula el total acumulado de 'Producto' [UnitPrice] por el orden ascendente de 'Product' [ProductSubCategoryKey].
La consulta es bastante simple como se muestra a continuación.
Esto funciona muy bien como se esperaba. Vuelve a continuación como salida
Pero si comentara la línea #7 de la consulta,
AccUnitPrice de todas las filas devuelven los mismos valores.
Parece que los valores devueltos son la suma del precio unitario de todos excepto el cuyo ProductSubCategoryKey es máximo (en este caso #35 ) en el filtro [NombreDeAMbre]"Contoso" && [ClassName]"Regular".
No puedo entender lo que está pasando en esta consulta. Me gustaría saber en qué tipo de contexto Se evalúa AccUnitPrice de cada fila y cómo se calcula así.
Cualquier sugerencia sería apreciada.
Gracias de antemano.
Hay @AllisonKennedy
Una cosa que hice para pensar en este tema.
Probé varios patrones de condiciones de filtro y ejecuté la consulta.
Permítanme compartir el resultado como se muestra a continuación.
Con la línea #7 , 'Product'[BrandName] ), todos los resultados son naturales y fáciles de entender.
Pero sin #7 de línea, siento que hay algunas regularidades en los cálculos, pero no puedo expresarlo en una oración.
AA) cambiar a "'Producto'[ProductSubcategoryKey] - CurrentSubKey"
<<Sin línea #7>>
<<Con línea #7>>
BB) cambiar a "'Product'[ProductSubcategoryKey] <> CurrentSubKey"
<<Sin línea #7>>
<<Con línea #7>>
CC) cambiar a "'Producto'[ProductSubcategoryKey] - CurrentSubKey + 10"
<<Sin línea #7>>
<<Con línea #7>>
DD) cambiar a "'Producto'[ProductSubcategoryKey] á 11"
<<Sin línea #7>>
<<Con línea #7>>
Lo siento, pero no estoy seguro de que sea significativo...
saludos
Hola @AllisonKennedy otra vez,
Muchas gracias por su comentario.
Por ahora, me gustaría compartir con los espectadores el resultado del senario revisado en el que amablemente agrega elementos en su publicación anterior.
Esto muestra sin duda bien el contraste entre Countrows y Countx.
<<Con línea #7>>
<<Sin línea #7>>
Atentamente
No @Payeras_BI,
Lo siento. No entendí totalmente lo que dijiste.
Incluso si sumamos una columna de otra tabla en lugar de 'Product'[UnitPrice], es posible que no podamos deshacernos de este problema.
El problema puede provenirse del hecho de que más de dos filtros están en una tabla.
La consulta para dos tablas ( 1 Dimension ( Product ) + 1 Fact ( Sales ) pero lo mismo sucede así.
saludos
No @Usagi_Nakamura ,
Responder a su última pregunta:
No es que esté seguro de que esto sea Auto-Exist más, pero en el ejemplo anterior, donde intercambiaste Product[UnitPrice] por Sales[UnitPrice] todavía tenías todos los ingredientes para activarlo de acuerdo con esto:
https://docs.microsoft.com/en-us/dax/all-function-dax
"Un ejemplo en el que auto-exist y ALL() proporcionan resultados inesperados es cuando se filtran en dos o más columnas de la misma tabla (como cuando se usan segmentaciones de datos), y hay una medida en esa misma tabla que utiliza ALL()."
En el último ejemplo ProductSubcategoryKey (ALL), ClassName y BrandName (SLICERS) siguen siendo de la misma tabla. Ahora, mientras que mover ClassName y BrandName a una tabla diferente podría ordenar el problema, todavía queremos saber por qué está sucediendo esto.
Lo dejo a los expertos, pero esperando que esto sea de alguna ayuda, he reproducido el escenario en PBI con la tabla más simple posible (sólo dos filas, sólo una marca / clase y sin duplicados) para descartar posibles causas:
La medida que se rompe:
SUMX =
VAR CurrentKey = SELECTEDVALUE('Table'[Key])
RETURN
SUMX(
FILTER(
ALL('Table'[Key]);
'Table'[Key]<CurrentKey
);
[Sum of UnitPrice]
)
Una medida que funciona:
With Calculate =
VAR CurrentKey = SELECTEDVALUE('Table'[Key])
RETURN
CALCULATE(
[Sum of UnitPrice];
'Table'[Key]<CurrentKey
)
En PBI:
- Una visualización de tabla con sólo una de las columnas utilizadas para cortar se muestra:
- Ok para cortar por el que no está presente en la visualización:
- Pero tan pronto como se corta por ambos de la medida con roturas SUMX:
saludos
No @Payeras_BI
Muchas gracias por su último post que es muy útil para mí y lamento por responder tarde.
Intenté asignar los casos en su publicación para correspondientes a mi consulta dax y resumir el resultado.
<<En su caso 1>>
En este caso, una columna de agrupación (clase) + Ningún archivador > SUMX está bien
La consulta dax correspondiente es
<<En su caso 2>>
Una columna de agrupación ( Clase ) + 1 Columna de filtro ( Marca ) > Aceptar
La consulta dax correspondiente es
<<En su caso 3>>
Una columna de agrupación ( Clase ) + 2 Columna de filtro ( Clase, Marca ) > NG
La consulta dax correspondiente es
Intenté algunos otros casos y resumir el resultado como se muestra a continuación.
Gracias Saludos amables,
Hola de nuevo @Usagi_Nakamura ,
Para ser honesto, también me cuesta entender por qué el 51.663,53 por cada fila, hágamelo saber si usted se entera.
Pero, al menos, si sigues el consejo al final del artículo te des haces del problema:
"En modelos de datos más simples con una sola tabla y con una distribución de datos elegante de valores, podría ser posible encontrarse con problemas de existencia automática. Cuando esto sucede, la solución más fácil es evitar el uso de una sola tabla y crear un esquema de estrella adecuado en su lugar."
Exactamente la misma consulta, pero ahora cortando en columnas que pertenecen a las tablas de dimensiones:
saludos
No @AllisonKennedy ,
¡Muchas gracias por sus amables sugerencias!
En realidad sabía que con tu consulta, funcionaba bien.
Además, la consulta, incluso si no hay #63 de línea, puede obtener el mismo resultado.
De hecho, mi consulta era originalmente visual de matriz y SumUnitPrice y AccUnitPrice se calcularon medidas y el filtro BrandName provenía de un objeto visual Slicer. La consulta se realiza a partir de estos objetos visuales, utilizando el analizador de perfomance power bi.
Además, para mi consulta, intenté cambiar SUMX a CONCATENATEX y encontré que con o sin #7 de línea, se devuelve el mismo valor en cada fila. Estos valores deben ser elementos que se calcularán en la versión SUMX. Pero si cambio de nuevo a Sumx, los valores devueltos son diferentes entre con #7 de línea y sin #7 de línea.
<< Con línea #7>>
<<Sin línea #7>>
Traté de averiguar por qué es posible, pero en vano durante tres meses...
Gracias.
Helpful resources
Join us at the Microsoft Fabric Community Conference
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!
A Year in Review - December 2024
Find out what content was popular in the Fabric community during 2024.
