Fundamentos de DAX en un modelo semántico

Escribe cálculos para agrupar y analizar tus datos.

En esta serie, compartimos consejos para crear de forma eficaz un modelo semántico (antes, un Dataset) en Power BI o Analysis Services. En el artículo anterior, describimos cómo validar las relaciones del modelo, que son los vínculos entre tablas y la base de tu lógica de negocio. Una vez que hayas creado y validado tus relaciones, ya deberías tener lista la base de tu modelo para poder pasar al siguiente paso.

En este artículo, describimos ese siguiente paso para crear un modelo semántico: crear cálculos escribiendo DAX. Para definir estos cálculos para Reports, haces referencia a las tablas, columnas y relaciones que añadiste al modelo en los pasos anteriores. Estos cálculos son los que usarás en los Visuales del Report o en tablas dinámicas de Excel para analizar tus datos.

El objetivo de este artículo es ofrecer una visión general de lo básico: cuándo escribes DAX y cómo puedes hacerlo en Power BI Desktop, Tabular Editor o Microsoft Fabric.

¿Qué es DAX?

Data Analysis Expressions (DAX) es un lenguaje de programación funcional y de consultas que se usa en Power BI y otras aplicaciones para analizar datos. Tú escribes expresiones DAX para definir cálculos o lógica personalizados dentro de un modelo, y Power BI usa consultas DAX para consultar el modelo desde tu Report. DAX es la forma en que tus Visuales se comunican con el modelo semántico para recuperar los datos que necesitas. El DAX funcional que escribes es como un conjunto de instrucciones que le indican al modelo qué tablas y columnas usar y qué hacer con ellas. Cuando escribes DAX, haces referencia a tablas, relaciones, columnas y otros cálculos (medidas), y luego usas funciones como SUM o AVERAGE para agregar o filtrar datos.

El ejemplo anterior se puede entender así:

• La primera imagen muestra una medida [Selling Margin (Value)]. Calcula la suma de cada fila de la tabla ‘Invoices’, restando el valor de la columna ‘Invoices'[Net Invoice Cost] al valor de la columna ‘Invoices'[Net Invoice Value]. Como el margen de venta solo debe calcularse para documentos de tipo factura (y no para otros tipos de documento), una función CALCULATE filtra el resultado para dejar solo las facturas usando la columna relacionada ‘Invoice Document Type'[Invoice Type], que es una tabla de dimensión relacionada con la tabla de hechos ‘Invoices’. Las medidas suelen usarse en consultas DAX, donde pueden producir resultados distintos según qué filtros estén activos en ese momento.
• La segunda imagen muestra una consulta DAX de líneas de factura por mes. La consulta define la medida [Invoice Lines] (que, por tanto, solo existe en la consulta) y la usa en la consulta (después de EVALUATE) para calcular las líneas por mes. Un desarrollador podría ejecutar periódicamente una consulta como esta para validar el modelo o los datos subyacentes. Una consulta también puede hacer referencia a medidas definidas dentro del modelo.

DAX aparece en toda una solución de Power BI. La siguiente imagen muestra una visión general básica de los distintos lugares en los que podrías escribir DAX en modelos y Reports de Power BI.

DAX existe en todo Power BI

1. Modelo semántico: Escribes DAX en un modelo para definir medidas que se evalúan al vuelo, o tablas y columnas calculadas que se evalúan durante la actualización del modelo. Las expresiones DAX también se usan para definir reglas de seguridad a nivel de filas (RLS), llamadas permisos de tabla. DAX también se usa en objetos de modelo más avanzados, como elementos de grupo de cálculo, cadenas de formato dinámicas y filas de detalle.
2. Consultas: Las consultas DAX son la forma en que Power BI recupera datos del modelo para rellenar Visuales en Reports. También puedes escribir consultas tú mismo en Power BI Desktop y en otras herramientas como Tabular Editor, DAX Studio y cuadernos de Fabric con Semantic Link.
3. Report: Puedes escribir medidas DAX en Reports “thin” que están conectados a un modelo semántico publicado. Normalmente, esto solo se hace para medidas específicas de ese Report, y no para cálculos (que es mejor colocar en el modelo).
4. Visuales: Puedes escribir un tipo especial de DAX llamado cálculos visuales en los Visuales de Power BI. Los cálculos visuales no forman parte del modelo y solo usan los datos de ese Visual para producir el resultado del cálculo.

“DAX es simple, pero no es fácil”

DAX es un lenguaje simple en su sintaxis y estructura, pero es bien sabido que DAX no es fácil de aprender. A primera vista, DAX recuerda a la simplicidad del lenguaje de fórmulas de Excel, pero esto puede engañar: DAX es más sofisticado para poder cubrir más escenarios de los que te encontrarías en Excel. Como DAX se apoya en un Data model en lugar de en posiciones de celdas en una hoja, los autores tienen que “pensar en términos del Data model”, algo que resulta difícil para quien se inicia en el modelado de datos. Estos son conceptos típicos que un desarrollador con experiencia da por sentado, pero que un desarrollador nuevo tiene que aprender con la práctica:

• Un modelo contiene varias tablas conectadas mediante relaciones.
• Los filtros se propagan por las relaciones en una dirección, de una tabla a otra.
• Los atributos del lado “Uno” de una cadena de relaciones pueden agrupar valores que están en el lado “Varios”.

Otra razón por la que DAX es difícil es que funciona de forma distinta a otros lenguajes de programación. Algunas convenciones en DAX son exclusivas de DAX; “piensa” de una forma particular. Esto significa que algunos desarrolladores con experiencia en otros lenguajes pueden aplicar convenciones o prácticas que no funcionan —o peor— funcionan, pero dan un resultado subóptimo.

• Un ejemplo en Python: No deberías usar un “bucle” en DAX, como usarías un for loop o un while loop en Python.
• Un ejemplo en SQL: No deberías hacer agregación condicional en DAX usando IF/THEN, como harías con CASE/WHEN en SQL.

Estos son algunos ejemplos adicionales de convenciones o reglas específicas de DAX que cuesta entender cuando empiezas a escribir en este lenguaje.

• Modificas cálculos usando funciones como CALCULATE o CALCULATETABLE. Con estas funciones, aportas dos tipos de argumentos: filtros (que filtran el resultado) y modificadores de CALCULATE (que cambian el modo en que funcionan).
  • Los modificadores de CALCULATE te permiten ajustar el resultado del cálculo, pero requieren que entiendas el resultado intermedio que estás modificando.
  • Los filtros en realidad son tablas, un concepto que a los usuarios nuevos les cuesta entender.
• DAX se evalúa en un contexto que define el resultado. Hay dos contextos principales que debes conocer cuando escribes DAX: el contexto de filtro y el contexto de fila.

• Un contexto de filtro filtra los datos. Ejemplos de contexto de filtro:
  • Cuando un filtro o segmentador está activo en un Report, o un usuario ha aplicado filtros de otras formas, como el filtrado cruzado, los desgloses (drilldown) o el drillthrough, y una expresión DAX se evalúa en un Visual de ese Report.
  • Cuando una expresión DAX se evalúa para un punto de datos concreto en un Visual (como una categoría o una combinación de categorías).
  • Cuando un cálculo aporta un contexto de filtro como argumento de CALCULATE (por ejemplo, ‘Date'[Month] = “January”). Este contexto de filtro reemplaza otros filtros sobre la columna referenciada, salvo que se use el modificador de CALCULATE KEEPFILTERS.

• Un contexto de fila itera tablas. Ejemplos de contexto de fila:
  • Cuando evalúas una expresión DAX en una columna calculada. Por ejemplo, si evalúas ‘Invoices’[Sales] – ‘Invoices’[Cost] en la tabla ‘Invoices’ en una columna calculada, se usa un contexto de fila para la tabla ‘Invoices’ y así se obtiene un resultado para cada fila.
  • Cuando evalúas una expresión DAX en una función iteradora. Por ejemplo, si evalúas SUMX( ‘Invoices’, ‘Invoices’[Sales] – ‘Invoices’[Cost] ) en una medida DAX, también se usa el contexto de fila para la tabla ‘Invoices’
• El concepto de transición de contexto, que es cuando un contexto de fila se transforma en un contexto de filtro equivalente mediante la función CALCULATE. La transición de contexto puede ser una fuente de problemas de rendimiento para muchos cuando empiezan a escribir DAX.

¿Necesito escribir DAX en mi modelo?

Puedes crear un modelo sin DAX y usar este Data model para crear un Report. Por ejemplo, si solo vas a usar el Report para mostrar datos con atributos descriptivos o datos sin agregar, no hace falta escribir DAX. Un ejemplo sería un Report para un catálogo de productos, o uno diseñado para explorar documentos de pedido por línea; transacciones sin agregar que no se suman entre sí con SUM. Sin embargo, este tipo de Report no son habituales, ya que la ventaja de los Report de Power BI (y del motor VertiPaq que utiliza) es agregar y visualizar de forma eficiente grandes volúmenes de datos complejos.

También puedes usar medidas implícitas para analizar datos sin escribir DAX.

Medidas implícitas

Una medida implícita es el nombre que recibe la agregación de una columna numérica en Power BI sin escribir DAX. En su lugar, agregas la columna y se aplica una agregación predeterminada (por ejemplo, SUM) para agrupar los datos por una dimensión. Puedes cambiar esta agregación desde un conjunto de opciones predeterminadas (por ejemplo, SUM). Se llama medida implícita porque, entre bastidores, Power BI crea la medida sobre la marcha en la consulta DAX que genera el Visual.

La siguiente imagen muestra un ejemplo de una medida implícita SUM de cantidad a partir de la columna Cantidad, agrupada por la columna de texto Categoría en el Visual.

Las medidas implícitas pueden ser una buena opción para usuarios de negocio o para quienes se inician en Power BI, especialmente si no tienen experiencia previa escribiendo código. Además, incluso los desarrolladores con experiencia pueden usar medidas implícitas al hacer un análisis rápido ad hoc (por ejemplo, al explorar datos o analizar un modelo de corta duración).

Si tienes pensado usar medidas implícitas, ten en cuenta los siguientes puntos.

• Establece la propiedad “Resumen predeterminado” en la agregación adecuada. Establécela en Ninguno para las columnas que no se deben agregar, como ‘Orders’[Order Number].
• Usa carpetas de visualización para organizar las columnas numéricas que se pueden agregar, separándolas de otras columnas que no.
• Establece una descripción de columna para aclarar qué agregaciones se deben usar.
• No uses medidas implícitas si no van a aportar un valor claro. Evita especialmente usar medidas implícitas de columnas calculadas, por ejemplo como una forma de esquivar escenarios DAX complicados.

Las medidas implícitas pueden ser problemáticas y tienen algunos puntos a tener en cuenta.

• Las opciones se limitan a las agregaciones más usadas.
• Como no puedes controlar el DAX (por ejemplo, el uso de CALCULATE), no tienes forma de modificar el cálculo.
• Los cálculos no aparecen en la lista de campos, lo que dificulta que un desarrollador entienda cómo se está usando el modelo o logre coherencia entre Report.
• Agregar grupos de cálculo desincentiva las medidas implícitas en el modelo, lo que significa que los usuarios no podrán crear y usar nuevas medidas implícitas. Las medidas implícitas existentes en los Report siguen funcionando.

Medidas explícitas

Aunque las medidas implícitas tienen algunos casos de uso válidos, en general es preferible que crees medidas explícitas. Las medidas explícitas son simplemente las medidas DAX que defines tú explícitamente (DEFINE) en el modelo (o en el Report “ligero” conectado). El siguiente ejemplo es la versión con medida explícita de la medida implícita de la imagen anterior.

Medidas, columnas calculadas y tablas calculadas

Cuando escribes expresiones DAX, lo haces en distintos tipos de objeto: medidas, columnas calculadas o tablas calculadas.

1. Medidas: Contienen la definición de una expresión (en DAX) y propiedades (como descripción, carpeta de visualización y formato). Una medida es simplemente metadatos y se asocia a una tabla con fines organizativos. Una medida solo se evalúa cuando se consulta (EVALUATE) (directamente o mediante otra medida que la referencia). Un ejemplo de medida es Importe de ventas, que calcula la función SUM de todas las ventas.
2. Columnas calculadas: Contienen la definición de una expresión (en DAX) y propiedades (como descripción, tipo de datos y formato), además del resultado de los datos. El resultado de datos de una columna calculada hace que tu modelo consuma más memoria. Las columnas calculadas se crean en una tabla y evalúan el DAX (EVALUATE) para cada fila de la tabla. Solo se evalúan al actualizarse (no mediante EVALUATE). Un ejemplo de columna calculada podría ser un indicador que identifique nuevos clientes con ventas en el mes actual, que luego uses en otros cálculos.
3. Tablas calculadas: Como una columna calculada, pero evaluada de forma independiente de cualquier tabla y columna existentes, salvo las que se referencian en su expresión DAX (por ejemplo, con CALCULATE), y cuyo resultado puede consultarse con EVALUATE. Una tabla calculada genera un resultado independiente de una o varias columnas mediante una expresión DAX (por ejemplo, CALCULATE). Al igual que una columna calculada, también solo se evalúa al actualizarse (no mediante EVALUATE ni por el uso de CALCULATE). Un ejemplo de tabla calculada podría ser una tabla de fechas que creas con la función DAX CALENDAR (y, si hace falta, CALCULATE).

Según el tipo de modelo que estés creando, es posible que no puedas crear columnas calculadas o tablas. Si tienes casos de uso específicos que requieren uno de estos objetos, eso puede influir en tu decisión de usar un modo de almacenamiento u otro.

La siguiente figura ofrece una vista general de qué objetos DAX puedes crear en los diferentes modos de almacenamiento de modelo semántico disponibles hoy en Power BI.

En resumen, las siguientes restricciones se aplican a algunos tipos de modelos semánticos. Ten en cuenta que el modo de almacenamiento se establece por tabla, excepto en Direct Lake, que no admite combinar tablas con diferentes modos de almacenamiento (todo el modelo usa el modo de almacenamiento Direct Lake).

1. Import: Los modelos que importan los datos en memoria son el modo de almacenamiento predeterminado (y el más común). Puedes crear cualquier objeto DAX en estos modelos.
2. DirectQuery: Modelos que se conectan directamente a un Data source compatible, convirtiendo consultas DAX sobre la marcha en consultas SQL equivalentes. Estos modelos no admiten columnas calculadas ni tablas.
3. Hybrid: Los modelos que combinan modos de almacenamiento o tablas híbridas no permiten columnas calculadas en tablas DirectQuery o Hybrid del modelo.
4. Direct Lake: Los modelos que se conectan a tablas Delta en un Lakehouse o un Warehouse de Fabric no admiten columnas calculadas, y solo admiten tablas calculadas si no hacen referencia a tablas Direct Lake ni a columnas de esas tablas. Direct Lake solo está disponible si tienes una capacidad de Fabric y si los datos están disponibles en elementos de datos de OneLake como tablas Delta.

DAX es una parte fundamental de la mayoría de los modelos semánticos. Es un lenguaje sencillo y potente, aunque tiene algunos conceptos complejos que requieren una comprensión teórica para sacarle el máximo partido. Usas expresiones DAX o consultas con tu modelo semántico en distintas partes de tu solución de Power BI. En el próximo artículo, compartiremos consejos y orientación para que puedas escribir DAX de forma eficaz en tus modelos semánticos de Power BI.