Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Find everything you need to get certified on Fabric—skills challenges, live sessions, exam prep, role guidance, and more. Get started

Reply
Syndicate_Admin
Administrator
Administrator

Grupos de cálculo, relaciones y filtros

Estoy buscando una explicación de por qué ocurre esto y tal vez una solución, si la hay.

Arreglo:

Tengo dos tablas que están relacionadas entre sí y un grupo/elemento de cálculo. Utilizo una tabla como filtro para una segmentación de datos para restringir lo que se muestra. Utilizo la otra tabla para proporcionar información para su visualización en un objeto visual de tabla. Utilizo un elemento de cálculo para ajustar el valor de una columna a una referencia más visible (utilizando el elemento de cálculo, ya que hay un número de campos que tendrán la misma conversión necesaria). El elemento de cálculo simplemente realiza una instrucción switch para comprobar el valor de SELECTEDMEASURE y generar el valor adecuado.

Problema:

Mientras no se aplica el elemento de cálculo, el filtro funciona sin ningún problema. Tan pronto como se aplica el elemento de cálculo, muestra todas las filas, con traducciones aplicadas incorrectamente para el campo en el que se ajusta la visualización para las filas que aún deben estar ocultas debido a las selecciones de la segmentación.

Solución temporal:

Puedo fusionar las dos tablas en una sola y filtrar por esos valores. No es preferible, pero ayudó a demostrar que hay un problema entre las relaciones de tabla y la aplicación de elementos de cálculo.

Así que espero que alguien me pueda explicar claramente algo para lo que no he podido encontrar una explicación clara. ¿Cuál es el conflicto entre los elementos de cálculo y las relaciones de tabla? Además, ¿hay algún truco para sortear este conflicto?

Gracias de antemano por cualquier dirección

7 REPLIES 7
Syndicate_Admin
Administrator
Administrator

Gracias por esa @Aklys , que PBIX aclaró el problema 🙂

El problema inmediato es que, en algunos casos, los elementos de cálculo convierten valores en blanco en valores que no están en blanco.

Esta es una manera de reescribir dos de los elementos de cálculo para evitar este problema (script DAX del Editor tabular):

-------------------------------------------------
-- Calculation Item "KPIs__Direct_and_Simplified"
-------------------------------------------------
        VAR KPIDisplay = [KPI_Display]
        RETURN
            IF (
                NOT ISBLANK ( KPIDisplay ),
                SWITCH (
                    KPIDisplay,
                    9000, "High Risk",
                    9001, "At Risk",
                    9002, "On Track",
                    "Unknown"
                )
            )

-------------------------------------------------
-- CALCULATIONITEM "KPIs__Display"
------------------------------------------------- 
        IF (
            CONTAINSSTRING ( SELECTEDMEASURENAME ( ), "*KPI*Display*" ),
            VAR MeasureValue = SELECTEDMEASURE ( )
            RETURN
                IF (
                    NOT ISBLANK ( MeasureValue ),
                    SWITCH (
                        MeasureValue,
                        9000, "High Risk",
                        9001, "At Risk",
                        9002, "On Track",
                        "Unknown"
                    )
                ),
            SELECTEDMEASURE ( )
        )

La razón por la que se observaba un comportamiento diferente al filtrar por la búsqueda de tipo de artículo frente a la búsqueda de tipo de artículo es más complicada y se relaciona con la existencia automática, agravada por el problema principal de convertir los espacios en blanco en no blancos.

En este ejemplo, cuando la columna Tipo de elemento de la segmentación procede de una tabla diferente de las demás columnas utilizadas en el objeto visual, las combinaciones inexistentes de esas columnas no se eliminan automáticamente en la consulta de DAX generada por el objeto visual, por lo que los valores de medida que no están en blanco (que originalmente estaban en blanco) aparecen en el objeto visual.

En resumen, recomendaría agregar comprobaciones para asegurarse de que los valores en blanco devueltos por una medida subyacente no se conviertan en valores que no estén en blanco (dentro de los elementos de cálculo o de otro modo) a menos que haya una razón específica para hacerlo.

Saludos

Gracias @OwenAuger por la solución.

Espero que no te importe que busque más aclaraciones sobre el por qué. Todavía estoy un poco confundido por la conversión de espacios en blanco a no espacios en blanco, ya que siento que me estoy perdiendo la comprensión de algún comportamiento fundamental del dax. No hay valores nulos o valores no alineados con la relación de la tabla para el ejemplo de la segunda página, por lo que solo quiero entender qué está generando los valores en blanco. ¿Los registros que no se muestran debido a filtros que generan valores en blanco son de la naturaleza de no mostrarse?

Todavía hay un problema que crea la solución y es que a veces un registro puede contener un valor que debe mostrarse como desconocido porque es un valor nulo. La solución que proporcionó en realidad no los trata adecuadamente (se muestra en la tabla con valores nulos). ¿Cómo corregiría esto más allá de reemplazar los valores nulos con un nuevo valor (ya que esto no es factible de ajustar ya que null desafortunadamente tiene un propósito particular de sus datos de origen, al igual que el -1, terrible lo sé, pero no hay control sobre la fuente)?

Tendré que leer más sobre la autoexistencia ya que no entendí el artículo proporcionado, pero gracias por dirigirme a ese poco de conocimiento.

Gracias de nuevo por la solución parcial y la explicación.

Claro 🙂

De hecho, ¡hay algunas cosas bastante poco intuitivas que suceden aquí!

Una forma de explicar el comportamiento de las "filas inesperadas" es olvidarse del grupo de cálculo (por el momento) y hacer lo siguiente:

1. Cree una medida que siempre devuelva 1 (independientemente de los filtros):

One = 1

2. En la página Tabla sin valores nulos, elimine KPI_Display__without de la tabla y, en su lugar, agregue la nueva medida Uno.

3. Añade también Book2[Item_Type] a la tabla.

Tenemos los resultados extraños que

  • Type_ID = 1 se empareja con Item_Type = 1-3
  • Type_ID = 2 se empareja con Item_Type = 1-3

En otras palabras, tenemos una especie de unión cruzada entre las dos tablas relacionadas.

¡Admito que esto es bastante poco intuitivo!

SlicerNoEffect2.gif

Una breve explicación es que la aplicación de un filtro a las columnas de una tabla en un lado de una relación (por ejemplo, una tabla de dimensiones) no "elimina" filas de una tabla en el otro lado de la relación (por ejemplo, una tabla de hechos) de la consulta DAX que genera el objeto visual.

Sin embargo, la característica de existencia automática elimina las filas cuando las columnas de la misma tabla se filtran simultáneamente.

Este comportamiento normalmente se oculta cuando las medidas "normales" agregan filas de una tabla de hechos, ya que tales medidas producen resultados en blanco para combinaciones no existentes.

El comportamiento del elemento de cálculo fue similar al de la medida Uno , en el sentido de que siempre produce un resultado de "Desconocido" si no existen filas en el Libro1 para una combinación determinada de filtros.

En cuanto al segundo punto, en realidad no había considerado el caso de un resultado en blanco "válido" de la(s) medida(s) KPI_Display , que como bien dices puede ocurrir cuando hay un valor en blanco en la columna que se está agregando.

Para manejar esta situación, creo que sería mejor reemplazar

NOT ISBLANK ( KPIDisplay )

con

NOT ISEMPTY ( Book1 )

Esto garantiza que se devuelva un resultado para los espacios en blanco "válidos" (u otros valores válidos) resultantes de la agregación de la tabla de hechos, pero no de situaciones en las que no hay filas en la tabla de hechos (como cuando Tipo de elemento Tabla = Tipo 1 y Item_Type = Type_2.

¡Espero que esto ayude!

Saludos

Estoy muy agradecido por la explicación. Me da una mejor comprensión de lo que está pasando. Especialmente con la creación de esa medida fuera del grupo de cálculo.

Una última pregunta. La fórmula que estoy usando es más dinámica, ya que es para ahorrar tiempo al abordar varias columnas en varias tablas. Por lo tanto, la fórmula original usa SELECTEDMEASURE, pero como ISEMPTY requiere una tabla, ¿hay alguna equivalencia para la tabla? Con el propósito de que estoy usando el grupo de cálculo, no puedo codificar de forma rígida el nombre de la tabla de SELECTEDMEAUSRE.

Muchas gracias de nuevo por darme la explicación, fue muy útil.

De nada 🙂

Planteas un buen punto. La comprobación básica ISEMPTY sólo funciona si se sabe qué tabla se está agregando dentro de SELECTEDMEASURE ().

No hay una forma integrada de determinar qué tabla agrega o hace referencia una medida, ya que una medida determinada podría hacer referencia a varias tablas, o incluso a ninguna tabla.

Una posible solución sería seguir una convención de nomenclatura de medida que incluya el nombre de la tabla en los nombres de medida.

En los elementos de cálculo, puede usar SELECTEDMEASURENAME() para identificar la tabla y determinar si la tabla de hechos relevante no está vacía.

Por ejemplo, si incluyó el nombre de la tabla entre corchetes en los nombres de las medidas, podría tener el siguiente aspecto:

-- Calculation Item: KPIs__Display
VAR MeasureName =
    SELECTEDMEASURENAME ()
VAR FactTableNonEmpty =
    SWITCH (
        TRUE (),
        CONTAINSSTRING ( MeasureName, "(Book1)" ), NOT ISEMPTY ( Book1 ),
        CONTAINSSTRING ( MeasureName, "(Book1_without_Nulls)" ), NOT ISEMPTY ( Book1_without_Nulls )
    )    
RETURN
    IF (
        CONTAINSSTRING ( SELECTEDMEASURENAME ( ), "*KPI*Display*" ),
        VAR MeasureValue = SELECTEDMEASURE ( )
        RETURN
            IF (
                FactTableNonEmpty,
                SWITCH (
                    MeasureValue,
                    9000, "High Risk",
                    9001, "At Risk",
                    9002, "On Track",
                    "Unknown"
                )
            ),
        SELECTEDMEASURE ( )
    )

Esto es solo una idea, ¡podría haber un método mejor! 🙂

Syndicate_Admin
Administrator
Administrator

Hola @Aklys

¿Podría compartir más detalles sobre su modelo, la definición de las medidas que muestra junto con el elemento de cálculo y la forma en que aparece el objeto visual con y sin el elemento de cálculo aplicado?

En función de la descripción, una corazonada inicial es que el elemento de cálculo no maneja valores en blanco de SELECTEDMEASURE () como se esperaba (que se habrían ocultado automáticamente cuando no se aplicó el cálculo).

No puedo darte el modelo de datos exacto o las funciones. Pero tengo una maqueta que demuestra el comportamiento que estoy viendo. Que se puede encontrar aquí https://we.tl/t-2b4T1u63t9

Cuando se aplica el filtro que no es una búsqueda, sino de una tabla relacionada (tabla de tipo de elemento) que se muestra en las segmentaciones de datos a la tabla, se puede ver que funcionan correctamente. También puede utilizar los elementos de cálculo por sí solos sin los filtros y ver que funcionan bien. Pero cuando se aplican ambos, ya no se aplica el filtro y el elemento de cálculo no proporciona el resultado esperado para los elementos que el filtro debería eliminar y que ahora muestra.

Pero si utiliza el filtro para el elemento en la propia tabla (Búsqueda de tipo de elemento), aplica tanto el filtro como el elemento de cálculo sin ningún problema.

También he creado para la comparación una tabla que no tiene valores nulos y también he creado un elemento de cálculo que está en el campo directo y simplificado del proceso original que he estado tratando de usar.

Esperemos que esto te ayude a tener una idea de lo que se está experimentando. Para repetir el problema, al aplicar un filtro de una tabla relacionada y aplicar el elemento de cálculo que traduce los valores de un campo mostrado en particular, las filas ocultas se muestran con valores inesperados. Estoy buscando una explicación de por qué y si hay un método que pueda utilizar para evitar este suceso.

Helpful resources

Announcements
Europe Fabric Conference

Europe’s largest Microsoft Fabric Community Conference

Join the community in Stockholm for expert Microsoft Fabric learning including a very exciting keynote from Arun Ulag, Corporate Vice President, Azure Data.

July 2024 Power BI Update

Power BI Monthly Update - July 2024

Check out the July 2024 Power BI update to learn about new features.

July Newsletter

Fabric Community Update - July 2024

Find out what's new and trending in the Fabric Community.

Top Solution Authors
Top Kudoed Authors