Cualquiera puede arrastrar un campo numérico a un visual y obtener una suma. El verdadero valor de un modelo de datos aparece cuando alguien pregunta algo un poco más complejo: cuánto creció esta cifra frente al año anterior, qué porcentaje representa cada producto sobre el total, o cuál sería el resultado si se excluyera un cliente específico del cálculo. Responder ese tipo de preguntas es exactamente para lo que existe DAX.
DAX, abreviatura de Data Analysis Expressions, es el lenguaje de fórmulas detrás de Power BI. A primera vista se parece a las fórmulas de Excel —usa funciones con nombres reconocibles, paréntesis, referencias a columnas— pero su forma de evaluar los datos es distinta, y esa diferencia es justo lo que permite construir, dentro de un modelo de Power BI, cálculos que en una hoja de cálculo tradicional requerirían fórmulas larguísimas o simplemente no serían posibles.
Muchos equipos usan Power BI durante meses limitándose a sumas y promedios simples, sin saber que el mismo modelo podría responder preguntas mucho más específicas con las fórmulas correctas. No es un problema de la herramienta, es que DAX tiene una curva de aprendizaje real, y pocas veces alguien se sienta a explicar cómo piensa este lenguaje antes de empezar a escribir fórmulas. En ITD Consulting nos encontramos este escenario con frecuencia al revisar un modelo por primera vez.
En ITD Consulting dedicamos buena parte de cada proyecto a construir las medidas de DAX que realmente responden las preguntas del negocio, no solo las que se pueden resolver arrastrando un campo a un gráfico.
La diferencia central está en cómo cada herramienta entiende «dónde está parado» un cálculo. En Excel, una fórmula vive en una celda específica y sabe exactamente qué fila y qué columna la rodean. En DAX, una fórmula puede evaluarse en decenas de contextos distintos al mismo tiempo —una fila de una tabla, un total general, una celda de una matriz filtrada por tres criterios distintos— y el resultado cambia según ese contexto, sin que la fórmula en sí tenga que reescribirse.
Esto explica por qué preguntas como estas son naturales en DAX, pero incómodas de resolver en una hoja de cálculo tradicional:
Cada una de estas preguntas depende de que la fórmula entienda el contexto en el que se está evaluando, que es precisamente la idea central que hay que entender para escribir buen DAX.
Invertir en construir bien el modelo desde Desktop, antes de pensar en cómo se va a compartir después dentro de Microsoft 365, evita ese tipo de fragilidad. Un modelo bien construido permite:
El tiempo que se dedica a modelar bien casi siempre se recupera más adelante, en forma de menos correcciones urgentes y menos reportes que dejan de funcionar apenas algo en la empresa cambia.
La mayoría de las veces no se trata de una fórmula que arroje un mensaje de error. El problema aparece cuando calcula algo, pero ese algo no es lo que realmente se necesitaba, y detectar por qué puede ser complicado si no se entiende bien cómo evalúa DAX cada cálculo.
Son dos formas distintas de crear un cálculo en DAX, y elegir la equivocada genera resultados incorrectos o un modelo innecesariamente pesado. Una columna calculada guarda un valor fijo por cada fila; una medida se recalcula dinámicamente según el contexto del reporte. Usar una donde correspondía la otra es, por mucho, el error más común entre quienes empiezan con DAX.
Es fácil escribir una fórmula que técnicamente funciona, pero que ignora los filtros de fecha, región o categoría que el usuario aplicó en el reporte, devolviendo siempre el mismo número sin importar qué se esté explorando. Esto suele pasar cuando no se entiende bien cómo interactúan los filtros con el cálculo.
Una fórmula que funciona rápido con mil filas puede volverse muy lenta con un millón, si no está escrita pensando en cómo procesa internamente el motor de Power BI. Este tipo de problema suele pasar desapercibido hasta que el modelo crece lo suficiente como para que la lentitud se vuelva evidente.
Cuando un cálculo se construye a base de prueba y error, sin entender del todo por qué funciona, suele terminar siendo una fórmula larguísima y difícil de leer. Si esa persona se va o simplemente olvida su propia lógica, nadie más puede ajustarla con confianza. Por ejemplo:
Detectar y corregir estos cuatro problemas suele requerir revisar no solo la fórmula en sí, sino todo el modelo de relaciones que la rodea, porque en DAX el resultado de un cálculo depende tanto de la fórmula como del contexto en el que se evalúa.
Antes de escribir fórmulas complejas, ayuda tener claros algunos conceptos que explican por qué DAX se comporta como se comporta.
Es el contexto que existe cuando una fórmula se evalúa fila por fila, como ocurre naturalmente en una columna calculada. En este contexto, la fórmula «conoce» los valores de esa fila específica, similar a como funciona una fórmula arrastrada en Excel.
Es probablemente la función más importante de todo el lenguaje, porque permite modificar el contexto de filtro dentro de un cálculo: por ejemplo, ignorar el filtro de año para comparar contra un periodo distinto, o aplicar una condición adicional que no viene directamente de los filtros visuales del reporte. Entender bien esta función es lo que separa a quien apenas empieza de quien ya piensa en DAX con soltura.
Es el conjunto de filtros activos en el momento de evaluar un cálculo: lo que el usuario seleccionó en un slicer, lo que define una fila o columna de una tabla visual, o lo que impone otro cálculo relacionado. Una misma medida puede devolver resultados distintos según qué contexto de filtro esté activo cuando se evalúa.
Funciones como las que terminan en X —sumar el resultado de multiplicar dos columnas fila por fila, por ejemplo— permiten cálculos que no se resuelven con una simple agregación, evaluando una expresión para cada fila de una tabla antes de combinarla en un resultado final.
Comparar el desempeño actual contra un periodo anterior es, probablemente, el tipo de cálculo más solicitado en cualquier proyecto de reportería, y DAX incluye funciones específicamente pensadas para resolverlo sin tener que construir la lógica desde cero cada vez.
Con estas funciones es posible construir, entre otros, cálculos como:
Estas funciones dependen de que exista una tabla de fechas bien construida y correctamente relacionada con el resto del modelo. Sin esa base, incluso una fórmula de inteligencia de tiempo técnicamente correcta puede arrojar resultados equivocados, algo que se nota especialmente una vez que el reporte se comparte dentro de Microsoft 365 y varias personas lo consultan al mismo tiempo con distintos filtros.
El tipo de cálculo que más se necesita cambia bastante según el área que va a usar el reporte.
Suele requerir comparaciones de periodos, cálculo de cuotas alcanzadas, y medidas que respondan a filtros cruzados entre vendedor, producto y zona sin perder velocidad al combinarlos.
Aquí los cálculos exigen más precisión: márgenes exactos, acumulados fiscales, comparaciones contra presupuesto que deben coincidir centavo a centavo con lo que ya valida el área contable, sin margen para una fórmula aproximada.
Requiere con frecuencia cálculos de rotación en periodos móviles y comparaciones de plantilla entre distintos cortes de tiempo, donde las funciones de inteligencia de tiempo también resultan útiles, aunque con una lógica distinta a la de ventas o finanzas.
Suele necesitar cálculos de eficiencia que combinan varias tablas relacionadas —producción, inventario, tiempos de entrega— donde el rendimiento de las fórmulas importa especialmente por el volumen de datos que suele manejar esta área.
No empezamos escribiendo fórmulas sueltas. Empezamos entendiendo qué pregunta de negocio debe responder cada cálculo dentro del modelo de Power BI, y solo después decidimos qué construcción de DAX es la más adecuada, la más rápida y la más fácil de mantener.
Antes de escribir una sola fórmula, aclaramos exactamente qué debe representar cada cálculo: si un porcentaje se calcula sobre el total general o sobre el subtotal filtrado, si una comparación debe incluir o excluir ciertos casos específicos. Esta definición evita ambigüedades que después son difíciles de corregir.
Desarrollamos las fórmulas como medidas centralizadas dentro del modelo, evitando que cada visual tenga su propio cálculo suelto, para que corregir algo en un solo lugar se refleje automáticamente en todo el reporte.
Probamos cómo se comportan las fórmulas con volúmenes de datos reales, no solo con una muestra pequeña, para detectar cálculos lentos antes de que se conviertan en un problema una vez que el reporte está en uso diario.
En cada proyecto de ITD Consulting, dejamos registrado qué hace cada medida y por qué se construyó de esa forma, para que cualquier persona del equipo pueda entenderla y ajustarla más adelante sin depender de quien la escribió originalmente.
Un modelo de datos maduro no tiene fórmulas sueltas resolviendo cada necesidad puntual; tiene un conjunto de medidas base —ventas totales, costos totales, unidades vendidas— sobre las cuales se construyen cálculos más complejos, reutilizando esas piezas en lugar de repetir la misma lógica una y otra vez.
Este enfoque tiene una ventaja práctica clara: si algún día cambia la definición de qué cuenta como una venta válida, ese ajuste se hace en un solo lugar, y todos los cálculos que dependen de esa medida base se actualizan automáticamente, en lugar de tener que revisar fórmula por fórmula en todo el archivo.
Construir el modelo pensando en esta reutilización desde el principio, en lugar de ir agregando fórmulas sueltas conforme surgen necesidades, es lo que distingue un archivo de Power BI que sigue siendo manejable después de un año de otro que se vuelve cada vez más frágil con cada cálculo nuevo que alguien agrega.
Estas prácticas ayudan a que las fórmulas sigan siendo confiables y comprensibles conforme el modelo crece.
Las medidas se calculan solo cuando se necesitan y no ocupan espacio permanente en el modelo, a diferencia de las columnas calculadas, que se almacenan fila por fila. Usar medidas en lugar de columnas, cuando el caso lo permite, mantiene el archivo más liviano.
Empezar por las medidas simples y fundamentales —totales, conteos básicos— antes de construir comparaciones o porcentajes más elaborados, evita reconstruir la lógica desde cero cuando se necesita un cálculo relacionado.
Un cálculo llamado «Medida final v2» no comunica nada. Nombrar cada fórmula según lo que realmente representa facilita que cualquier persona entienda el reporte sin tener que abrir la fórmula para descifrar qué hace.
Un cálculo puede verse correcto sin ningún filtro aplicado y comportarse de forma inesperada apenas alguien filtra por una categoría específica. Revisar varias combinaciones antes de dar por cerrado el desarrollo evita sorpresas una vez que el reporte está en uso.
Los reportes empiezan a responder preguntas que antes requerían exportar datos a otra herramienta o pedirle a alguien un análisis aparte. Comparar contra el año anterior, calcular una proyección o descomponer un resultado por distintas variables se vuelve algo que cualquier usuario puede explorar por su cuenta, incluso desde el mismo panel que consulta dentro de Microsoft 365, sin depender de un análisis especial cada vez.
También cambia la velocidad con la que se puede confiar en un número nuevo: cuando las medidas base ya están bien construidas, agregar un cálculo relacionado toma minutos en lugar de requerir revisar todo el modelo desde el principio.
Nada de esto depende de tener memorizada la lista completa de funciones del lenguaje. Depende de entender bien los conceptos de contexto que sostienen cómo se comporta cualquier fórmula, que es precisamente donde más tiempo invertimos al capacitar equipos en ITD Consulting.
No hace falta que todo un equipo domine DAX a fondo para que un proyecto de reportería funcione bien. Lo habitual es que una o dos personas dentro de la empresa desarrollen un nivel más profundo, mientras el resto aprende a interpretar los resultados y a identificar cuándo algo no cuadra.
Un usuario que solo consulta reportes se beneficia de entender la lógica general de un cálculo, sin necesidad de poder escribirlo. Un analista que construye reportes propios necesita manejar medidas básicas y algo de inteligencia de tiempo. Quien mantiene el modelo completo de la empresa necesita un dominio más profundo de contexto y optimización.
Practicar sobre las preguntas reales que el negocio necesita responder acelera bastante el aprendizaje frente a seguir tutoriales con datos de ejemplo que no representan la complejidad real de los datos de la empresa.
Llevar un registro simple de qué hace cada fórmula nueva, aunque sea informal, ayuda tanto a consolidar el aprendizaje como a dejar una base útil para quien se una al equipo más adelante y necesite entender el modelo desde cero.
En los proyectos de capacitación que acompaña ITD Consulting, procuramos que este aprendizaje quede dentro de la empresa, integrado con las herramientas que el equipo ya usa a diario dentro de Microsoft 365, en lugar de depender permanentemente de soporte externo para cualquier ajuste menor a una fórmula.
DAX son las siglas de Data Analysis Expressions, el lenguaje de fórmulas que permite crear cálculos dentro de un modelo de Power BI: desde sumas simples hasta comparaciones de periodos, porcentajes dinámicos y proyecciones basadas en el comportamiento histórico de los datos.
Se parecen en la sintaxis y en muchos nombres de función, pero DAX evalúa los cálculos de forma distinta: una misma fórmula puede comportarse diferente según el contexto de filtro en el que se evalúa, algo que no ocurre de la misma manera en una hoja de cálculo tradicional.
Depende de qué tan profundo se quiera llegar. Los conceptos básicos —sumas, promedios, cálculos simples— se aprenden relativamente rápido. Entender bien el contexto de filtro y funciones como CALCULATE, que permiten construir cálculos más sofisticados, suele tomar más tiempo y práctica constante.
Una columna calculada guarda un valor fijo por cada fila del modelo, ocupando espacio de forma permanente. Una medida se calcula dinámicamente en el momento de consultarse, según el contexto de filtro activo. Elegir correctamente entre una y otra afecta tanto el resultado como el rendimiento del modelo.
Casi siempre se debe al contexto en el que se evalúa cada una: filtros aplicados, relaciones entre tablas, o el uso de funciones que modifican ese contexto, como CALCULATE. Revisar el contexto suele ser el primer paso para entender por qué dos cálculos aparentemente similares no coinciden.
No en el sentido tradicional de programación, aunque ayuda tener lógica estructurada para pensar en condiciones y relaciones entre datos. Es más parecido a dominar bien las fórmulas de una hoja de cálculo avanzada que a aprender un lenguaje de programación completo.
Casi siempre se puede optimizar revisando cómo está construida: evitando cálculos innecesarios fila por fila, aprovechando mejor las relaciones del modelo, o reescribiendo la lógica de una forma que el motor de Power BI procese con más eficiencia.
Sí. Una vez que el modelo con sus medidas se publica, los cálculos se comportan de la misma manera dentro de la plataforma en la nube y dentro de Microsoft 365, incluyendo las actualizaciones automáticas de datos que mantienen esos resultados vigentes.
Aprender lo básico ayuda a interpretar mejor los reportes existentes y a detectar cuándo algo no cuadra. Para modificar o ampliar cálculos ya construidos por otra persona, especialmente en modelos complejos, suele ser más eficiente contar con experiencia especializada que aprender sobre la marcha.
Revisamos el modelo completo, no solo la fórmula que parece estar fallando, porque en DAX el resultado depende tanto del cálculo como del contexto y las relaciones que lo rodean. A partir de ese diagnóstico, corregimos la lógica necesaria y dejamos las medidas documentadas para que el equipo pueda confiar en ellas y mantenerlas con el tiempo. Cabe destacar que te ofrecemos soporte en español para clientes en países como Argentina, Bolivia, Chile, Colombia, Costa Rica, Ecuador, El Salvador, España, Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, Uruguay y Venezuela.
EN 
ES