En Power BI, una columna calculada añade un valor a cada fila; una medida obtiene un resultado dentro del contexto en que se consulta. Elegir entre ambas afecta a cómo se utiliza el cálculo, cuándo se evalúa y qué ocurre al aplicar filtros.
La decisión no consiste en declarar que una opción siempre es más rápida. Primero hay que saber si el resultado describe una fila o responde a una pregunta sobre un conjunto de datos.
Los ejemplos siguientes utilizan un modelo de importación con líneas de pedido. Otros modos, como DirectQuery, tienen restricciones y comportamiento propios que deben comprobarse en el diseño concreto.
Un cálculo de fila: importe de una línea
Supongamos que una tabla de ventas contiene cantidad y precio unitario. Una columna calculada ilustrativa puede expresar:
LineAmount = Sales[Quantity] * Sales[UnitPrice]
Cada fila tiene su importe. Esta simplificación no incluye descuentos, impuestos ni conversiones de moneda; el modelo real necesita definir esos conceptos antes de utilizar el resultado como métrica de negocio.
La columna puede servir a operaciones que requieren un atributo por fila. Sin embargo, si solo necesitas sumar el importe visible en un informe, no es obligatorio materializar esa columna dentro del modelo.
Una medida puede realizar la multiplicación durante la evaluación:
SelectedAmount =
SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])
Esta medida recorre las filas de ventas que permanecen en el contexto correspondiente y agrega el resultado. Elegir entre almacenar el importe o calcularlo al consultar requiere medir el modelo y considerar si ese valor se reutiliza en otras operaciones.
Una clasificación que debe aparecer en un segmentador
Imagina que el ejemplo necesita clasificar líneas por cantidad. Una regla ficticia distingue “cantidad alta” a partir de un umbral acordado para la demostración.
Si quieres utilizar esa clasificación como categoría en un segmentador, necesitas un campo adecuado para representar las categorías. Una columna o una dimensión preparada durante la transformación puede resolverlo.
Una medida numérica que cambia con los filtros no se convierte por sí sola en una columna de categorías para ese segmentador. Existen otros patrones de diseño para clasificaciones dinámicas, pero requieren definir su interacción y no son equivalentes a añadir una columna estática.
La comparación oficial de opciones de cálculo de Power BI distingue precisamente el cálculo por fila, su almacenamiento y el comportamiento de las medidas ante la interacción del informe.
Una medida responde al conjunto que se está mirando
Al mostrar ventas por producto, la medida se evalúa para cada producto. En una tarjeta sin ese desglose, se evalúa para el conjunto permitido por los filtros de la tarjeta, la página, el informe y el modelo.
Esto explica por qué el total no debe interpretarse siempre como una suma mecánica de los valores visibles. Una medida de clientes distintos se vuelve a evaluar para el total: un cliente que compró dos productos no necesariamente debe contarse dos veces.
Antes de corregir un total que “no cuadra”, escribe qué debería representar. Si el negocio pide clientes únicos del conjunto, sumar los clientes únicos de cada producto puede ser incorrecto. Si pide relaciones cliente-producto, se trata de otra métrica.
Preguntas para elegir el lugar del cálculo
| Necesidad | Opción inicial a evaluar | Comprobación necesaria |
|---|---|---|
| Categorizar cada fila con una regla fija | Columna o transformación previa | La regla no depende de la selección del usuario |
| Calcular un total sujeto a filtros | Medida | El contexto y las relaciones son los previstos |
| Construir una clave o normalizar texto | Transformación previa cuando sea posible | Consistencia con otras tablas y consumidores |
| Obtener un porcentaje de un conjunto seleccionado | Medida | Numerador y denominador usan el contexto acordado |
| Reutilizar un atributo de negocio en varios sistemas | Modelo o transformación compartida | Una única definición mantenible fuera del informe |
La tabla orienta la primera decisión; no elimina la necesidad de revisar volumen, cardinalidad y consultas reales.
El coste se reparte entre actualización y consulta
En un modelo de importación, añadir columnas incrementa los datos almacenados y exige calcular sus valores durante la actualización correspondiente. El efecto depende de su tipo y cardinalidad: no todas las columnas tienen el mismo coste.
Una medida evita almacenar un resultado por cada fila, pero puede requerir trabajo durante las consultas. Una expresión compleja que recorre muchas filas repetidamente puede afectar a la interacción. Tampoco todas las medidas tienen el mismo comportamiento.
Mide una página representativa con los filtros y visualizaciones que utilizará el equipo. Observa actualización, tamaño del modelo y tiempos de consulta. Optimizar solo la primera tarjeta puede desplazar el problema a otra parte del informe.
Valida con una muestra que revele errores
Prepara líneas de varios pedidos, productos y clientes. Incluye un cliente compartido entre productos, una selección sin filas y valores ausentes que el origen pueda producir.
Comprueba detalle, subtotales y total. Después cambia un filtro y confirma qué resultados deberían variar y cuáles describen atributos estáticos. Si la interpretación no está clara en esta muestra, aumentar el volumen solo hará más difícil investigar el error. Documenta la definición compartida en la capa semántica de métricas para que otros informes mantengan el mismo criterio.
La elección queda bien documentada cuando otra persona puede explicar por qué el cálculo vive en una columna, una medida o una transformación anterior.
Si estás revisando un modelo de Business Intelligence o cuadro de mando, comparte con Nexeus Big Data la pregunta que debe responder cada cálculo y cómo se utiliza en el informe. Ese contexto permite simplificar el modelo sin alterar el significado de sus resultados.