Medidas implícitas versus explícitas

Un usuario Pregunto ✅

Trabaja duro

Estoy leyendo y viendo tutoriales y mucha gente menciona que debe evitar usar las medidas implícitas que Power BI le permite usar convenientemente, como esta:

biimplicitvsexplicit.PNG

Sin embargo, nadie menciona por qué. ¿Es esto algo que la gente simplemente repite o es una cosa de conveniencia? Entiendo que una medida explícita se puede reutilizar en otras partes de los informes, pero si empiezo a crear una medida para cada tarjeta de recuento que tengo, tendré un mar de medidas.

Alguien dijo:

«Cuando diseña cualquier informe de Power BI, todas las medidas deben ser explícitas, es decir, no debe permitir que los usuarios finales creen medidas implícitas porque les permite hacer cosas que no deberían, por ejemplo, la suma del precio unitario».

¿Qué pasa con la suma del precio unitario?

parry2k

@WorkHard, la única razón podría ser mantener la lógica en un solo lugar y no hacer el mismo cálculo una y otra vez. por ejemplo

si desea calcular la suma de la fecha anterior y el año anterior, agregará dos medidas como esta

Prev Day Sum = CALCULATE ( SUM ( Table[Amount] ), PREVIOUSDAY ( DateTable[Date] ) ) 

Prev Year Sum = CALCULATE ( SUM ( Table[Amount] ), PREVIOUSYYEAR ( DateTable[Date] ) ) 

or you can create explicit measure for sum and then use it

Base Measure = SUM ( Table[Amount] )

Prev Day Sum = CALCULATE ( [Base Measure], PREVIOUSDAY ( DateTable[Date] ) ) 

Prev Year Sum = CALCULATE ( [Base Measure], PREVIOUSYYEAR ( DateTable[Date] ) ) 


en este ejemplo, si se cambia cualquier lógica a la medida base, cambiará automáticamente las medidas dependientes, pero en el primer caso, debe cambiarla manualmente, en la mayoría de los modelos / cálculos complejos se vuelve realmente útil y fácil de trabajar. Por cierto, el ejemplo de medida anterior fue muy simple, pero solo para mostrar por qué es útil.

me gustaría Prestigio si mi solución ayudó. 👉 Si puede dedicar tiempo a publicar la pregunta, también puede hacer esfuerzos para felicitar a quien ayudó a resolver su problema. ¡Es una muestra de agradecimiento!

Visitanos en https://perytus.com, su ventanilla única para proyectos, capacitación y consultoría relacionados con Power BI.

Edhans

Algunas razones:

  1. No se puede controlar lo que hace una medida implícita más allá de lo básico. Suma, recuento, etc.
  2. No se puede reutilizar una medida implícita. Supongamos que desea tener una medida de ventas, una medida de COGS y una medida de margen. Si escribe medidas explícitas de la siguiente manera:
    1. Ventas = SUM (Tabla[Sales])
    2. COGS = SUM (Tabla[COGS])
    3. Margen = [Sales] – [COGS]
    4. Ahora está reutilizando medidas explícitas en el paso 3. Si no los había creado, tendría que escribir esto:
    5. Margen = SUMA (Tabla[Sales]) – SUM (Tabla[COGS])
    6. Lo crea o no, # 3 y # 5 no son lo mismo. El n. ° 3 incluye un cálculo implícito alrededor de cada medida, el n. ° 5 no, por lo que para ser exactos, el n. ° 5 tiene que ser el n. ° 7 para producir los resultados deseados.
    7. Margen = CALCULATE (SUM (Tabla[Sales])) – CALCULAR (SUMA (Tabla[COGS]))
  3. Si se toma la molestia de agregar formato condicional u otras configuraciones de campo, como un formato de número personalizado con una medida implícita, entonces decide que desea modificar la fórmula para esa medida, no puede. Ahora debe crear una medida explícita con su fórmula correcta (digamos que desea cambiar un número de presupuesto a un presupuesto + 10% y redondear a cero lugares, muy simple en una medida: REDONDEAR (SUMA (Tabla[Budget) * 1.1,0). Then you have to remove the implicit measure, and add the explicit measure. Now you have to redo all of the conditional formatting and other field level custom formatting that the visual allows.

There are other reasons, but those hit the highlights.

 

And one caveat: if you want to use the new Personal Visuals setting, actually implict measures are better as it allows the end consumer to make changes easier. However, I would specifically do this for only those visuals but not for the model itself, and that is still not a reason to use them in general. I would call this an edge case.

edhans

In response to WorkHard

#1 and #3 are the same thing.

#2 is not. 

 

Often they will produce the same results in a simple model, but #1/3 go through context transition because CALCULATE (both implicit and explicit) trigger it. You can read more about it here.

 

Where this becomes a big deal is in their last example:

DEFINE
    MEASURE Product[TotalSales] = SUM (Ventas[Quantity] ) VAR SalesOfAllProducts = [TotalSales]
FILTRO DE EVALUACIÓN (COLUMNAS ADICIONALES (VALORES (Producto[Product Code] ), "SalesOfProduct", [TotalSales]  <---- Esta línea),
    [SalesOfProduct] > = SalesOfAllProducts * 0.01)

No es lo mismo que esto:

DEFINE
    MEASURE Product[TotalSales] = SUM ( Sales[Quantity] )
    VAR SalesOfAllProducts = [TotalSales]
EVALUATE
FILTER (
    ADDCOLUMNS (
        VALUES ( Product[Product Code] ),
        "SalesOfProduct", SUM(Sales[Quantity])
    ),
    [SalesOfProduct] >= SalesOfAllProducts * 0.01
)

Pero es lo mismo que esto:

DEFINE
    MEASURE Product[TotalSales] = SUM ( Sales[Quantity] )
    VAR SalesOfAllProducts = [TotalSales]
EVALUATE
FILTER (
    ADDCOLUMNS (
        VALUES ( Product[Product Code] ),
        "SalesOfProduct", CALCULATE(SUM(Sales[Quantity]))
    ),
    [SalesOfProduct] >= SalesOfAllProducts * 0.01
)

Edhans

Algunas razones:

  1. No se puede controlar lo que hace una medida implícita más allá de lo básico. Suma, recuento, etc.
  2. No se puede reutilizar una medida implícita. Supongamos que desea tener una medida de ventas, una medida de COGS y una medida de margen. Si escribe medidas explícitas de la siguiente manera:
    1. Ventas = SUM (Tabla[Sales])
    2. COGS = SUM (Tabla[COGS])
    3. Margen = [Sales] – [COGS]
    4. Ahora está reutilizando medidas explícitas en el paso 3. Si no los había creado, tendría que escribir esto:
    5. Margen = SUMA (Tabla[Sales]) – SUM (Tabla[COGS])
    6. Lo crea o no, # 3 y # 5 no son lo mismo. El n. ° 3 incluye un cálculo implícito alrededor de cada medida, el n. ° 5 no, por lo que para ser exactos, el n. ° 5 tiene que ser el n. ° 7 para producir los resultados deseados.
    7. Margen = CALCULAR (SUMA (Tabla[Sales])) – CALCULAR (SUMA (Tabla[COGS]))
  3. Si se toma la molestia de agregar formato condicional u otras configuraciones de campo, como un formato de número personalizado con una medida implícita, entonces decide que desea modificar la fórmula para esa medida, no puede. Ahora debe crear una medida explícita con su fórmula correcta (digamos que desea cambiar un número de presupuesto a un presupuesto + 10% y redondear a cero lugares, muy simple en una medida: REDONDEAR (SUMA (Tabla[Budget) * 1.1,0). Then you have to remove the implicit measure, and add the explicit measure. Now you have to redo all of the conditional formatting and other field level custom formatting that the visual allows.

There are other reasons, but those hit the highlights.

 

And one caveat: if you want to use the new Personal Visuals setting, actually implict measures are better as it allows the end consumer to make changes easier. However, I would specifically do this for only those visuals but not for the model itself, and that is still not a reason to use them in general. I would call this an edge case.

WorkHard

In response to edhans

Appreciate the knowledge, do you mind explaining a bit more about the difference in these 3? To me, they look like they will all produce the same result.

Say: Sales = 100 and COGS = 30

 

1. Margin = [Sales] – [COGS] = 70?

2. Margen = SUMA (Tabla[Sales]) – SUM (Tabla[COGS]) = 70?

3. Margen = CALCULAR (SUMA (Tabla[Sales])) – CALCULAR (SUMA (Tabla[COGS])) = 70?

¿Dónde puedo leer más sobre esto?

Edhans

En respuesta a Trabaja duro

# 1 y # 3 son lo mismo.

# 2 no lo es.

A menudo, producirán los mismos resultados en un modelo simple, pero el # 1/3 pasa por la transición de contexto porque CALCULATE (tanto implícito como explícito) lo activa. Puedes leer más sobre esto aquí.

Donde esto se convierte en un gran problema es en su último ejemplo:

DEFINE
    MEASURE Product[TotalSales] = SUM ( Sales[Quantity] )
    VAR SalesOfAllProducts = [TotalSales]
EVALUATE
FILTER (
    ADDCOLUMNS (
        VALUES ( Product[Product Code] ),
        "SalesOfProduct", [TotalSales]  <---- This line
    ),
    [SalesOfProduct] >= SalesOfAllProducts * 0.01
)

No es lo mismo que esto:

DEFINE
    MEASURE Product[TotalSales] = SUM ( Sales[Quantity] )
    VAR SalesOfAllProducts = [TotalSales]
EVALUATE
FILTER (
    ADDCOLUMNS (
        VALUES ( Product[Product Code] ),
        "SalesOfProduct", SUM(Sales[Quantity])
    ),
    [SalesOfProduct] >= SalesOfAllProducts * 0.01
)

Pero es lo mismo que esto:

DEFINE
    MEASURE Product[TotalSales] = SUM ( Sales[Quantity] )
    VAR SalesOfAllProducts = [TotalSales]
EVALUATE
FILTER (
    ADDCOLUMNS (
        VALUES ( Product[Product Code] ),
        "SalesOfProduct", CALCULATE(SUM(Sales[Quantity]))
    ),
    [SalesOfProduct] >= SalesOfAllProducts * 0.01
)

Trabaja duro

En respuesta a Edhans

¡Gracias! Esto tiene mucho sentido ahora. Sí, en ese ejemplo que le dio, calculará la SUMA en «ese» contexto que podría ser diferente de la SUMA que se calcularía fuera de ese contexto / filtro.

¡Gracias por la leccion!.

parry2k

En respuesta a Edhans

@edhans gran detalle pero no estoy de acuerdo con seguir

Y una advertencia: si desea utilizar la nueva configuración de Visual Personal, en realidad las medidas implícitas son mejores, ya que permite al consumidor final hacer cambios más fácilmente. Sin embargo, haría esto específicamente solo para esos elementos visuales, pero no para el modelo en sí, y todavía no es una razón para usarlos en general. Yo llamaría a esto un caso límite.

Si hay una necesidad de lógica empresarial para implementar en las medidas, el usuario final no debe trabajar fuera de esa lógica y crear imágenes usando sus propios cálculos / medidas que conduzcan a alguna discrepancia, y entonces todos sabemos lo que sucede. Permitiría que los usuarios finales solo usen medidas explícitas. Solo mis 2 centavos.

edhans

En respuesta a parry2k

@ parry2k: no estoy abogando por el uso de medidas implícitas, pero hacen que la función visual personalizada sea más poderosa para el usuario final si desea jugar y explorar los datos. Vea este artículo.

La información clave:

edhans_0-1593653322494.png

Es como todo lo demás en Power BI. A menudo no hay una respuesta correcta / incorrecta, solo una respuesta mejor / peor, y cada lado tiene sus pros y sus contras.

parry2k

En respuesta a Edhans

@edhans @ Nunca dije que lo defendieras, solo estaba compartiendo mis pensamientos. Gracias por la información adicional que compartiste.

parry2k

@WorkHard, la única razón podría ser mantener la lógica en un solo lugar y no hacer el mismo cálculo una y otra vez. por ejemplo

si desea calcular la suma de la fecha anterior y el año anterior, agregará dos medidas como esta

Prev Day Sum = CALCULATE ( SUM ( Table[Amount] ), PREVIOUSDAY ( DateTable[Date] ) ) 

Prev Year Sum = CALCULATE ( SUM ( Table[Amount] ), PREVIOUSYYEAR ( DateTable[Date] ) ) 

or you can create explicit measure for sum and then use it

Base Measure = SUM ( Table[Amount] )

Prev Day Sum = CALCULATE ( [Base Measure], PREVIOUSDAY ( DateTable[Date] ) ) 

Prev Year Sum = CALCULATE ( [Base Measure], PREVIOUSYYEAR ( DateTable[Date] ) ) 


en este ejemplo, si se cambia cualquier lógica a la medida base, cambiará automáticamente las medidas dependientes, pero en el primer caso, debe cambiarla manualmente, en la mayoría de los modelos / cálculos complejos se vuelve realmente útil y fácil de trabajar. Por cierto, el ejemplo de medida anterior fue muy simple, pero solo para mostrar por qué es útil.

me gustaría Prestigio si mi solución ayudó. 👉 Si puede dedicar tiempo a publicar la pregunta, también puede hacer esfuerzos para felicitar a quien ayudó a resolver su problema. ¡Es una muestra de agradecimiento!

Visitanos en https://perytus.com, su ventanilla única para proyectos, capacitación y consultoría relacionados con Power BI.

Deja un comentario

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