Porcentaje del total

En teoría sería algo como lo siguiente (como medida):

= SUMA([Quantity]) / SUMX([Quantity],TODO(tabla))

La idea es que la primera SUMA debe filtrarse por el contexto de la fila, pero está incluyendo específicamente TODAS las filas en la segunda SUMA (X). SUMX agrega la capacidad de modificar el contexto del filtro al sumar.

@Greg_Deckler, creo que querías usar CALCULATE() o cambiar el orden allí.

TotalQuantity =
SUM( 'Table'[Quantity] )

% Total =
[TotalQuantity]
    / CALCULATE(
        [TotalQuantity]
        ,ALL( 'Table' )
    )


***OR***

TotalQuantity =
SUM( 'Table'[Quantity] )

% Total =
[TotalQuantity]
    / SUMX(
        ALL( 'Table' )
        ,'Table'[Quantity]
    )

Cualquier construcción funcionaría, pero me inclinaría por el idioma anterior.

Muchas gracias por esto, fue sorprendentemente difícil encontrar un escrito conciso sobre cómo hacer esto. Creo que es la quinta vez que utilizo uno de sus enfoques DAX, por lo que sus contribuciones son muy apreciadas.

Hola comunidad, saludos desde Lima!.

Estoy usando esta fórmula propuesta por usted:

Sobre la base de esto: estoy intentando un enfoque similar (usando su misma fórmula) y no obtengo la respuesta que espero.

Efectivamente, estoy creando un gráfico de barras apiladas en el que espero determinar el % del negocio total en cada año y mes calendario (por lo que año + mes es una barra en el gráfico). Solo muestro para nuestros 15 clientes principales, por lo que, por construcción, el % total debe ser < 100 para un período determinado. Actualmente, el total supera los 100 en cada período, por lo que algo está definitivamente mal con el cálculo (es decir, el numerador es probablemente para datos de más que solo el período de la barra que se muestra).

¿Tiene algún consejo sobre cómo solucionar esto? Específicamente, estoy conectado a la base de datos de una empresa, por lo que solo puedo agregar medidas, no columnas calculadas. ¡Muchas gracias de antemano por su ayuda!

Sí, descarté por completo esa fórmula DAX, lo que buscaba era:

= SUMA([Quantity])/SUMX(‘tabla’,ALL(‘tabla'[Quantity]))

Sin embargo, me gusta que lo dividas en medidas separadas, lo hace más limpio y más fácil de entender.

Eso es lo que me pasa pensando que a veces puedo hacer estas cosas de memoria en lugar de encender Desktop y hacerlo.

@Greg_Deckler@greggyb Sugeriría usar siempre la función DIVIDE, ya que no devuelve errores en valores cero y, en la mayoría de los modelos de datos, es más rápido. A menos que tenga otra opinión, me encantaría escucharla.

¡Y ustedes son súper rápidos y con respuestas bien explicadas!

@konstantinos, ese es un gran punto, siempre me olvido de DIVIDE.

@Greg_Deckler demasiado modelado en las primeras versiones de powerpivot/ssas

@konstantinos, ¿perfiló DIVIDE() para que sea más rápido que el operador de división? Esto va en contra de más de lo que he visto. Normalmente uso DIVIDE() cuando no estoy seguro de los datos de alguien. Básicamente, se garantiza que el denominador en este ejemplo devolverá datos a menos que el modelo esté vacío, por lo que no veo ninguna razón para usar DIVIDE().

Trato de usar las abstracciones mínimamente poderosas siempre que sea posible, y dejo que mis funciones actúen como indicadores sobre mi conocimiento de los datos.

Por ejemplo, TOPN() y SAMPLE() devolverán el mismo número de filas si no hay empates. Usaría TOPN() si supiera que un empate no debería ser posible, y dejaría que la medida explote si esa suposición es incorrecta y depende de un número estricto de filas devueltas (por ejemplo, para TOPN(1, …) esperando conversión implícita a un valor escalar). Usar SAMPLE() sería «más seguro», pero implica que espero empates.

De manera similar, DIVIDE() indica que no entiendo bien los datos/medida, o que espero denominadores = 0 en el uso normal.

@greggyb No, no he perfilado la función DIVIDE, pero lo pensé según el artículo de SQLBI en el que confío.

https://www.sqlbi.com/articles/divide-performance/

Creo que la afirmación de que el uso de Divide (o similar) en lugar del operador sugiere que una medida o modelo de datos no es muy conocido o comprensible para el autor. A veces es una cuestión de estilo (como AND() en lugar de && o lo contrario) u otras veces las fuentes no son SQL/DB con validación de datos sino simples archivos de Excel que los usuarios agregan manualmente datos propensos a errores.

Y, por supuesto, una sugerencia sobre una fórmula no implementa nada sobre mi conocimiento (de cualquier manera limitado) de DAX.

@konstantinos, ese artículo trata específicamente sobre el rendimiento de DIVIDE() frente a la construcción:

IF(
    [Denominator] <> 0
    ,[Numerator] / [Denominator]
    ,<what to do for [Denominator] = 0>
)

@greggyb Tienes razón..