Puntos clave
- Modela la relación de muchos a muchos entre la dimensión A y la dimensión B con una tabla bridge explícita o con una definición clara de la granularidad del hecho.
- Convierte las claves bridge en columnas de primera clase y valida en gold la unicidad y los huérfanos.
- Comparte la lógica de matching y de enriquecimiento entre las tablas de hechos para que las cifras principales sigan siendo honestas.
- Alinea los tipos de clave foránea en cada extremo de una relación de rol.
- Demuestra con fixtures que el remodelado se acepta antes de reconstruir las páginas de informe.
- Retira las vistas de conveniencia que ocultan la granularidad, con una fecha de eliminación real.
Las vistas de gold "útiles" que "simplemente unen la dimensión A y la dimensión B" ocultan una granularidad de muchos a muchos hasta que una página de informe se contradice a sí misma. Los filtros cuentan dos veces. Las dimensiones de rol se rompen. Dos páginas que deberían cuadrar nunca cuadran.
Despliega las claves bridge como un artefacto de primera clase y remodela la tabla de hechos antes de pulir los visuales. La lógica de matching tiene que compartirse entre todas las tablas de hechos que la usan o los números divergen por construcción. Las dimensiones de rol del modelo semántico necesitan tipos de clave foránea que coincidan. Primero el remodelado. Después el pulido visual.
Modelo con nombre: claves bridge antes que dashboards
- M:M de negocio: las filas de la dimensión A por cada dimensión B y las filas de la dimensión B por cada dimensión A son preguntas de primera clase, no accidentes de un join plano.
- Bridge / hecho explícito: una frase sobre la granularidad, claves bridge de primera clase, pruebas de unicidad y de huérfanos, matching compartido y tipos de FK alineados en gold.
- Páginas de confianza: los cortes por la dimensión A y por la dimensión B cuadran con los mismos filtros porque el modelo guarda la relación que ya existe en el negocio.
- Regla: las vistas de conveniencia no son una estrategia de granularidad. Los dashboards heredan la granularidad que dejes en gold.
Figura 1. Claves bridge antes que dashboards. Ponle nombre al muchos a muchos, guárdalo como bridge o como un hecho honesto y después pule. Las vistas de conveniencia no son una estrategia de granularidad.
Contexto y restricción
Un fallo habitual: una página construida sobre la dimensión A y otra construida sobre la dimensión B parecen plausibles las dos y se niegan a cuadrar en la misma semana. La capa gold tiene una vista de conveniencia que aplana una relación de muchos a muchos en algo que, en un buen día, parece de uno a muchos. Los dashboards no son el bug. La granularidad, sí.
Las claves bridge van en gold con validación, no en un DAX que "lo arregla en el informe". Compartir el matching entre tablas de hechos mantiene honestas las cifras principales. Las dimensiones de rol multiplican el coste de un solo tipo de clave incorrecto. Pulir un informe sobre una granularidad rota enseña a los usuarios a desconfiar de todos los números.
La figura 2 es la superficie de Learn sobre la cardinalidad de las relaciones. La granularidad de muchos a muchos se cuela en visuales vacíos o que cuentan doble cuando finges que basta con una vista plana.
Figura 2. La granularidad de muchos a muchos se cuela en visuales vacíos o que cuentan doble. Remodela el hecho antes de pulir las páginas. Fuente: Microsoft Learn: entender las relaciones.
La figura 3 es la dirección del filtro en la misma página de Learn. Las claves bridge y la dirección del filtro forman parte del remodelado. Los dashboards heredan la granularidad que dejes en gold.
Figura 3. Las claves bridge y la dirección del filtro forman parte del remodelado. Fuente: Microsoft Learn: entender las relaciones.
Diseño
1. Di la granularidad en voz alta
Escribe si una fila es un evento, una asignación, una línea de detalle o un bridge entre la dimensión A y la dimensión B. Si caben dos verdades en una tabla, sepáralas. La granularidad ambigua es la puerta trasera por la que entra el doble conteo mientras el diagrama de estrella sigue pareciendo limpio.
2. Convierte las claves bridge en columnas de primera clase
Las claves bridge, sean subrogadas o de negocio, deberían estar documentadas, probadas para la unicidad en la granularidad prevista y usarse de forma coherente en el modelo semántico. No dejes los bridges como "el join que hacemos en aquella vista". Las claves de primera clase sobreviven a los traspasos.
3. Comparte la lógica de matching entre las tablas de hechos
Si las claves del origen se resuelven contra una dimensión con un módulo compartido para el hecho A, el hecho B usa el mismo módulo. Un matching distinto garantiza cifras distintas. La lógica compartida sale más barata que las reuniones de conciliación. La figura 4 muestra ese reparto de responsabilidades.
Figura 4. Un módulo de matching para las dos tablas de hechos. Publica su versión junto al remodelado para que las cifras principales no puedan desviarse una semana después. Las FK de rol comparten tipos con gold.
4. Alinea los tipos de FK en las dimensiones de rol
Cada rol de una dimensión de rol necesita tipos que coincidan en cada extremo de la relación. Una clave int64 junto a un rol string es un visual vacío esperando a una demo. Corrige gold y TMDL a la vez.
5. Valida los bridges antes que las páginas
Pruebas de aceptación: unicidad del bridge, tasas de huérfanos y conciliación entre los cortes solo por la dimensión A y solo por la dimensión B sobre claves de fixture. No aceptes "la página se ve bien" como prueba de la granularidad. Los visuales pueden verse bien mientras cuentan dos veces la entidad equivocada.
6. Ordena el trabajo: primero el remodelado, después los visuales
Cuando los stakeholders pidan una página más bonita, comprueba si el hecho sigue mintiendo. Los tickets de remodelado desbloquean los tickets de informes. Mezclarlos produce errores muy bonitos.
Por qué las vistas de gold "útiles" fallan con filtros
Una vista de conveniencia que copia los atributos de la dimensión B en cada línea de la dimensión A se verá bien sin filtros. Añade a la vez un segmentador en cada lado y la cardinalidad explota o se hunde según la dirección de la relación. El modelo semántico no puede inventarse un bridge que te negaste a guardar. Si los product owners quieren tanto "filas de la dimensión B por clave de la dimensión A" como "filas de la dimensión A por clave de la dimensión B" como preguntas de primera clase, ya han pedido un bridge. Tu trabajo es dejar de fingir que una vista plana responde a las dos sin una definición de granularidad. La figura 5 muestra el contraste.
Figura 5. Las vistas de conveniencia planas ocultan el muchos a muchos hasta que dos segmentadores no coinciden. Un bridge explícito guarda la granularidad para que las dos direcciones puedan cuadrar.
Una checklist mínima de remodelado
Haz una lista de los consumidores actuales de la vista de conveniencia. Define la granularidad del bridge en una frase. Añade claves y pruebas. Apunta el modelo semántico al nuevo hecho o bridge. Reconstruye las páginas afectadas. Solo entonces borra o congela la vista de conveniencia. Congelarla sin fecha de borrado garantiza una ruta zombi. Publica la versión del módulo de matching junto al remodelado para que las demás tablas de hechos no se desvíen una semana después.
Pruebas semánticas que detectan regresiones del remodelado
Mantén un paquete de fixtures diminuto: una clave de la dimensión A con dos claves de la dimensión B, una clave de la dimensión B con dos claves de la dimensión A si el negocio lo permite, una clave de la dimensión A sin coincidencia y una clave de la dimensión B sin coincidencia. Comprueba los recuentos desde las dos direcciones después de cada cambio en gold. Añade un check de dimensiones de fecha de rol para que el rol de fecha A y el rol de fecha B no compartan en silencio un tipo incorrecto. Estas pruebas son aburridas. También son la forma de no redescubrir el mismo bug después de cada ajuste "pequeño" del enriquecimiento.
Errores comunes
Vistas de conveniencia en gold. El muchos a muchos aplanado hasta que falla.
Bridges en DAX. Reglas de negocio escondidas en medidas que no son de nadie.
Un matching distinto por tabla de hechos. Las cifras principales discuten para siempre.
Tipos de FK mezclados en los roles. Los visuales vacíos se achacan a que "Power BI es raro".
Entregar la página primero. El pulido consolida la granularidad equivocada.
Sin métricas de huérfanos. Las claves sin coincidencia desaparecen en silencio por cualquiera de los dos lados.
Úsalo tal cual o adáptalo
Úsalo tal cual
- La relación de muchos a muchos entre dos dimensiones se modela con un bridge explícito o con una definición clara de la granularidad del hecho.
- Las claves bridge se validan (unicidad, huérfanos) en los pipelines de gold.
- La lógica de matching y de enriquecimiento se comparte entre las tablas de hechos.
- Los extremos de las relaciones de rol comparten tipos con las FK de gold.
- El trabajo de informes en las páginas afectadas espera a las pruebas de aceptación del remodelado.
- Las vistas de conveniencia que ocultan la granularidad se retiran con una fecha de eliminación.
Adáptalo antes de usarlo
Los bridges explícitos añaden tablas y coste de formación. El muchos a muchos oculto añade coste de confianza. Los módulos de matching compartidos exigen disciplina de paquetes entre notebooks. El remodelado retrasa el progreso visible de la interfaz; evita rehacer esa interfaz. Un informe estricto de huérfanos puede sacar a la luz huecos incómodos en el origen. Sácalos a la luz; no los escondas en inner joins.
Referencias principales: relaciones en Power BI y la guía del esquema de estrella en Microsoft Learn, además de la práctica de modelado de la capa gold en Fabric. Acompaña los diagramas de la frase de granularidad en el repo.
Primero las claves bridge. Después el matching compartido. Tipos alineados. Luego pule la página. La conciliación deja de ser un misterio semanal cuando la granularidad es honesta.