Imagina que pasas dos horas escribiendo una medida DAX perfecta. La lógica es impecable, la sintaxis es correcta, los contextos de filtro están controlados. La ejecutas… y el resultado es incorrecto.
Esto no es un problema de DAX. Es un problema del modelo que hay debajo.
El motor de Power BI está optimizado para el modelo en estrella: una tabla central de hechos conectada con dimensiones mediante relaciones simples y unidireccionales. Cuando esa arquitectura tiene grietas, el DAX más sofisticado no puede compensarlas. La metáfora es sencilla: un modelo roto es como un chasis torcido. Puedes ponerle el mejor motor del mundo, pero el coche no va a ir recto.
Estos son los cuatro errores que aparecen una y otra vez en los modelos de Power BI, independientemente del nivel del autor.
Las relaciones bidireccionales parecen útiles —»con esto puedo filtrar desde cualquier tabla»— pero crean caminos de filtro múltiples que generan resultados ambiguos y degradan el rendimiento.
Cuándo sí usarlas: relaciones muchos-a-muchos sin tabla puente posible, o tablas de seguridad dinámica (RLS). En el resto de casos, unidireccional y usar CROSSFILTER en DAX cuando necesites filtrado bidireccional puntual.
¿Tu tabla de ventas tiene columnas de FechaVenta, Importe, NombreCliente, CiudadCliente y CategoríaProducto juntas? Es el error más frecuente al importar directamente desde Excel.
El resultado: duplicación de datos en cada fila de venta, medidas como DISTINCTCOUNT que devuelven valores incorrectos, y dificultad para reutilizar dimensiones en otros modelos.
La solución: separar en Ventas (hechos) + DimCliente + DimProducto + DimFecha. Power Query lo hace en minutos.
La granularidad es el nivel de detalle de cada fila. Si cada fila representa un pedido pero quieres analizar por línea de producto, nunca tendrás los datos correctos: tendrías que agregar productos en la misma fila, lo que rompe cualquier medida que intente desglosar por producto.
Regla de oro: si dudas entre granularidad alta o baja, elige siempre alta. Siempre puedes agregar hacia arriba; nunca puedes desagregar hacia abajo si los datos no están.
La tabla automática de Power BI tiene año, trimestre, mes y día. Y nada más. Sin una tabla de calendario propia, los cálculos de inteligencia de tiempo (DATEADD, SAMEPERIODLASTYEAR, TOTALYTD…) fallan o dan resultados inconsistentes.
Una tabla de fechas correcta debe incluir: columna Date continua que cubra todo el rango, año / trimestre / mes / semana / día de la semana, indicador de día laborable, y debe estar marcada como tabla de fechas en Power BI.
Ojo también con las fechas almacenadas como texto: el motor las trata como categorías y toda la inteligencia de tiempo se rompe.
No necesitas revisar cada tabla y columna. Con esta secuencia rápida detectas los problemas más críticos:
Si encuentras alguno de estos problemas, corrígelo antes de escribir más medidas.
Un modelo limpio no es un lujo; es el requisito previo para que el DAX funcione como se espera. Los cuatro errores que hemos visto son fáciles de corregir si se detectan a tiempo.
El siguiente paso: abre un informe de Power BI que tengas en producción y dedícale 10 minutos a la auditoría de la vista de modelo. Probablemente encuentres algo.
¿Cuál de los cuatro errores es el que más has visto en tu entorno? Cuéntamelo en los comentarios.
¿Qué te ha parecido? Comparte tu experiencia o cuéntanos qué proceso repetitivo te gustaría automatizar. Estaré encantado de leer tu comentario.