Puntos clave
- Los tipos de los extremos de una relación tienen que coincidir; si no coinciden, se bloquea el release.
- Gold y TMDL (o los metadatos del modelo) cambian juntos para los tipos de clave, con un contrato de actualización.
- Los estándares de tipo para claves de fecha y dimensiones degeneradas están por escrito y son obligatorios para los hechos nuevos.
- La CI valida los tipos de los extremos de las relaciones en las definiciones del modelo.
- Las dimensiones de rol se inventarían en la documentación del repo con una fila por tipo de FK.
- Las consultas de fixture demuestran después de publicar que las relaciones críticas filtran sin dejar resultados vacíos.
Los visuales vacíos suelen ser tipos que no coinciden, no la prueba de que "DAX es difícil". Una clave int64 en el hecho junto a una clave string en la dimensión falla en silencio. Las dimensiones de rol multiplican el radio de impacto: un solo tipo de FK incorrecto rompe varias relaciones que en el diagrama parecían correctas.
Alinea el SQL de gold y TMDL a la vez. Las claves de fecha y las dimensiones degeneradas merecen estándares de tipo explícitos. Añade un check de CI para los tipos de los extremos de las relaciones. Que los tipos coincidan sale más barato que otra tarde mirando tarjetas vacías.
Modelo con nombre: extremos que coinciden
- Tipo de la FK del hecho: la clave del hecho tal como la escribe gold (int64, clave de fecha o string según el contrato).
- Tipo de la PK de la dimensión: la clave correspondiente en la dimensión, del mismo tipo de principio a fin, también en los roles.
- Inventario de roles: cada rol (rol A, B, C, D) indica en el repo la dimensión, la FK del hecho y el tipo.
- Control: gold y TMDL cambian como un solo conjunto con un contrato de actualización o republicación; la CI comprueba los tipos de izquierda y derecha; los fixtures demuestran que los filtros funcionan.
Figura 1. Extremos que coinciden. Las líneas de relación del diagrama no bastan. Los tipos de clave del hecho y de la dimensión tienen que coincidir, también entre roles, o las tarjetas se quedan vacías.
Contexto y restricción
Un fallo habitual: todas las líneas de relación están dibujadas y aun así varias no hacen nada útil en el momento de la consulta. La solución no es una medida ingeniosa. Es conseguir que la clave del hecho y la dimensión de rol compartan el tipo de principio a fin. Los visuales se llenan como si hubieran estado esperando con educación.
Corrige los tipos de las columnas de gold y el TMDL (o los metadatos del modelo) en un mismo conjunto de cambios. Editar solo los archivos TMDL sin un contrato de actualización deja los tipos antiguos en el modelo efectivo hasta que terminas el trabajo. Los estándares para claves de fecha y dimensiones degeneradas evitan la creatividad local. La CI debería fallar con extremos que no coinciden igual que falla con pruebas rotas.
La figura 2 es el planteamiento de Learn sobre las relaciones. Las líneas pueden aparecer aunque los tipos de los extremos no coincidan.
Figura 2. Los visuales vacíos suelen ser extremos de relación int64 frente a string, no la prueba de que DAX es difícil. Fuente: Microsoft Learn: entender las relaciones.
La figura 3 explica por qué las tablas del lake y las columnas del modelo tienen que tiparse juntas cuando Direct Lake o gold alimentan el modelo.
Figura 3. Alinea a la vez los tipos del SQL de gold y el TMDL, y después controla en la CI los tipos de los extremos de las relaciones. Fuente: Microsoft Learn: almacenamiento Direct Lake.
Diseño
1. Trata primero los visuales vacíos como un misterio de tipos
Antes de reescribir DAX, revisa los tipos de los extremos de la relación y una muestra de claves. Confirma si los valores coincidirían con los tipos alineados. Muchas madrigueras de "contexto de filtro" empiezan como int frente a string. Deja la arqueología de DAX para cuando los tipos sean aburridos.
2. Inventaría las dimensiones de rol como multiplicadores
Cada rol duplica el riesgo. Haz una lista. Revisa cada FK que apunte a ellas. Un solo rol de fecha tipado como string puede dejar vacía una familia entera de páginas. Los roles son potentes e implacables. La figura 4 es la forma de checklist que merece estar junto al TMDL.
Figura 4. Inventario de tipos de FK por rol. Un rol nuevo es una fila nueva. Cuando falla la CI, la checklist muestra qué rol se desvió.
3. Cambia gold y TMDL a la vez
Si gold convierte una clave a int64, la columna del modelo también tiene que ser int64 y la dimensión tiene que coincidir. Entrega el SQL y los metadatos del modelo en un solo PR cuando puedas. Documenta los pasos de actualización o republicación cuando el entorno los exija. Los metadatos actualizados a medias son una bomba de relojería. La figura 5 compara el camino seguro con la actualización a medias.
Figura 5. Cambia gold y TMDL a la vez y después sigue el contrato de actualización. Las correcciones solo en TMDL o solo en gold dejan el modelo efectivo sin coincidir.
4. Estandariza las claves de fecha y las dimensiones degeneradas
Elige una regla: int yyyymmdd, date o datetime, y mantenla para las claves que se usan en relaciones. Las dimensiones degeneradas de los hechos necesitan la misma honestidad. Escribe el estándar en la guía de modelado para que los hechos nuevos no inventen un cuarto enfoque.
5. Añade CI para los tipos de los extremos de las relaciones
Analiza los archivos TMDL o de definición del modelo y comprueba que los tipos de las columnas de izquierda y derecha coinciden en cada relación. Haz fallar el build si no coinciden. Las personas no lo ven en la revisión cuando el diagrama queda bonito. A las máquinas lo bonito les da igual.
6. Mantén un fixture que demuestre que la relación filtra
Las pruebas automatizadas del modelo o un pequeño paquete de consultas DAX deberían mostrar resultados no vacíos para claves conocidas después de publicar. Los tipos pueden coincidir y las claves seguir sin coincidir en el contenido; con el tiempo, los fixtures detectan las dos clases de fallo.
Una secuencia práctica de reparación
Identifica la relación que gobierna el visual vacío. Saca los tipos de los extremos y cinco valores de muestra de cada lado. Alinea los tipos en gold. Alinea los metadatos del modelo. Actualiza o republica según las reglas de tu etapa. Vuelve a ejecutar el fixture. Solo entonces plantéate cambios en DAX. Apunta la secuencia en el runbook del equipo para que el próximo visual vacío no vuelva a empezar desde cero con un pánico nuevo.
Las claves degeneradas merecen la misma disciplina
Las dimensiones degeneradas suelen empezar como strings "porque viene así del origen". Si participan en relaciones o roles, elige un tipo y documéntalo. Cambiar de string a int más tarde reescribe la historia de formas dolorosas. Mejor alinearse pronto con el contrato del origen, con conversiones explícitas solo en la frontera de tipado que ya elegiste para las claves de bronze o gold.
El riesgo en una demo es un riesgo de producto
Los visuales vacíos en una demo para stakeholders destruyen la confianza más rápido que una funcionalidad que llega tarde. Los tipos que no coinciden son especialmente crueles porque la vista del modelo parece completa. Un check de cinco minutos de los tipos de los extremos antes de las demos no es paranoia. Es higiene de release. Ponlo en la checklist de la demo junto a los smoke tests de recuento de filas.
Errores comunes
Depurar empezando por DAX. Días perdidos; los tipos siguen mal.
Confiar en el diagrama. Líneas dibujadas, tipos que no coinciden.
Corregir solo el TMDL. El archivo cambió; el modelo efectivo no se actualizó.
Corregir solo gold. El SQL está bien; el modelo sigue tipado como string.
Estilos improvisados de claves de fecha. Cada hecho inventa una convención.
Sin CI. Las regresiones vuelven con la siguiente dimensión "rápida".
Úsalo tal cual o adáptalo
Úsalo tal cual
- Los tipos de los extremos de una relación tienen que coincidir; si no coinciden, se bloquea el release.
- Gold y TMDL/metadatos del modelo cambian juntos para los tipos de clave, con un contrato de actualización.
- Los estándares de tipo para claves de fecha y dimensiones degeneradas están por escrito y son obligatorios para los hechos nuevos.
- La CI valida los tipos de los extremos de las relaciones en las definiciones del modelo.
- Las dimensiones de rol se inventarían en la documentación del repo con una fila por tipo de FK.
- Las consultas de fixture demuestran después de publicar que las relaciones críticas filtran sin dejar resultados vacíos.
Adáptalo antes de usarlo
Los estándares estrictos de tipos limitan la flexibilidad. Aquí la flexibilidad sobre todo produce visuales vacíos. Analizar TMDL en la CI añade trabajo al pipeline; elimina misterios en producción. Coordinar los PR de gold y del modelo puede parecer más lento que "retocar el archivo y ya". Más lento está bien cuando la alternativa es un fallo silencioso de los filtros. Mantener los fixtures cuesta tiempo y evita demos con visuales vacíos.
Referencias principales: la guía de relaciones y tipos de datos de Power BI y la documentación de TMDL en Microsoft Learn. Combina la documentación con la CI para que el estándar se aplique donde la gente cambia los modelos de verdad.
Cierre
Haz que coincidan los tipos de los extremos. Alinea gold con el modelo. Estandariza las claves. Compruébalo en la CI. Los roles dejan de estar embrujados y el tiempo de depuración vuelve a la lógica de negocio de verdad.
Relacionado
- Tipado en bronze: ¿es buena idea ingerir todo como cadenas? (tipar una vez y pronto para que las claves coincidan por defecto)
- Remodelar hechos: ¿dimensiones compartidas o hechos separados para modelos más limpios? (tablas puente cuando dos dimensiones se encuentran en una relación de muchos a muchos)