Tablas Puente (Bridge Tables)

La intermediaria que resuelve el caos N:N

Una tabla puente (también llamada bridge table, junction table o tabla de intersección) es una tabla que actúa de intermediaria entre dos tablas que tienen una relación muchos a muchos (N:N). Es como una lista de "quién está con quién" que permite que Power BI filtre correctamente sin duplicar datos ni crear ambigüedades.

En la teoría de bases de datos relacionales, las relaciones N:N no se pueden representar directamente: siempre se descomponen en dos relaciones 1:N a través de una tabla puente. Power BI introduce relaciones N:N nativas, pero con limitaciones importantes que veremos en la sección siguiente.

Por qué la relación N:N directa es problemática

Supón que tienes productos y categorías con una relación muchos a muchos: un producto puede pertenecer a varias categorías, y una categoría puede contener varios productos.

Sin tabla puente — relación N:N directa:

  'Productos'                       'Categorias'
  ┌──────────────────┐             ┌──────────────────┐
  │ IDProducto       │─────────────│ IDCategoria      │
  │ NomProducto      │  N        N │ NomCategoria     │
  └──────────────────┘             └──────────────────┘
         │
         │ 1:N
         ▼
  'Ventas'
  ┌──────────────────┐
  │ IDProducto (FK)  │
  │ Importe          │
  └──────────────────┘

  Problema: ¿cómo filtra Power BI?
  "Laptop Pro" pertenece a "Electrónica" Y a "Informática".
  El filtro puede propagar el contexto de forma ambigua.

El resultado incorrecto:

Si una venta de Laptop Pro tiene Importe = 1.000 € y el producto aparece en 2 categorías, al filtrar por categoría y sumar SUM(Ventas[Importe]) el motor puede — en determinados modelos y contextos — devolver 2.000 € en lugar de 1.000 €, porque la fila de ventas aparece "visible" desde ambas categorías al mismo tiempo.

El modelo correcto con tabla puente interpuesta

La solución es introducir una tabla intermedia que descomponga la relación N:N en dos relaciones 1:N, cada una perfectamente manejable por el motor VertiPaq.

  'Productos'       'ProductoCategorias'         'Categorias'
  ┌────────────┐    ┌────────────────────────┐    ┌────────────────┐
  │ IDProd  PK │─1─▶│ IDProducto  FK         │◀─N─│ IDCategoria PK │
  │ NomProd    │    │ IDCategoria FK         │  1 │ NomCategoria   │
  └────────────┘    └────────────────────────┘    └────────────────┘
        │
        │ 1:N
        ▼
  'Ventas'
  ┌────────────┐
  │ IDProducto │
  │ Importe    │
  └────────────┘

Flujo de filtros paso a paso:

1. El usuario filtra Categorias[NomCategoria] = "Electrónica"
2. El filtro pasa a ProductoCategorias (tabla puente) y devuelve los IDProducto que pertenecen a Electrónica
3. Esos IDProducto filtran la tabla Ventas a través de su relación con Productos
4. SUM(Ventas[Importe]) devuelve el resultado correcto, sin duplicados

Reglas de oro de la tabla puente:

• Contiene solo claves foráneas (FK), nunca métricas ni atributos descriptivos
• Se relaciona con cada dimensión en N:1 (muchos registros de puente → una dimensión)
• Se relaciona con la tabla de hechos de forma indirecta, pasando por la dimensión principal
• No se usa directamente en visuales — es infraestructura invisible del modelo

Tienda online con categorías múltiples por producto

Escenario: tienda online con 500 productos, donde cada producto puede pertenecer a 1, 2 o 3 categorías. Se necesita analizar las ventas por categoría sin duplicar los importes.

Crear la tabla puente en Power Query (M)

Cuando el origen tiene las categorías como texto separado por comas, Power Query puede generar la tabla puente automáticamente:

// Origen: columna "Categorias" contiene "Electrónica, Informática"
// Queremos generar una fila por cada categoría asignada al producto

let
    Origen           = TablaProductos,
    SplitCategorias  = Table.TransformColumns(
                         Origen,
                         {{"Categorias",
                           each Text.Split(_, ", "),
                           type list}}
                       ),
    Expand           = Table.ExpandListColumn(
                         SplitCategorias, "Categorias"
                       ),
    SeleccionarCols  = Table.SelectColumns(
                         Expand,
                         {"IDProducto", "Categorias"}
                       ),
    Renombrar        = Table.RenameColumns(
                         SeleccionarCols,
                         {{"Categorias", "IDCategoria"}}
                       )
in
    Renombrar

RRHH con empleadas que tienen más de un rol

Escenario: el equipo de RRHH necesita analizar costes de personal por departamento y rol. Algunas personas tienen más de un rol asignado (por ejemplo, Analista de BI y Scrum Master). El objetivo es que el coste mensual de cada persona no se duplique al filtrar por rol.

Diagrama del modelo completo:

  'Empleadas' ──1:N──▶ 'EmpleadaRoles' ◀──N:1── 'Roles'
       │              (tabla puente)
       │ 1:N
       ▼
  'CostesPersonal'
  ┌──────────────────┐
  │ IDEmpleada (FK)  │
  │ Mes              │
  │ ImporteCoste     │
  └──────────────────┘

A) Medidas estándar — funcionan automáticamente

Con la tabla puente en su sitio y las relaciones correctamente definidas, las medidas básicas funcionan sin código DAX adicional. Power BI propaga el filtro a través de la cadena de relaciones de forma transparente.

// Esta medida es suficiente. No necesitas nada especial.
Total Ventas = SUM(Ventas[Importe])
// Al filtrar por Categorias[NomCategoria]:
//   1. Filtro → ProductoCategorias (puente)
//   2. → Productos (relación 1:N)
//   3. → Ventas (relación 1:N)
// Resultado: correcto, sin duplicados.

// Para verificar que no hay duplicación:
Productos Únicos en Categoría =
DISTINCTCOUNT(ProductoCategorias[IDProducto])
// Compara este número con lo esperado en cada categoría.

B) DAX explícito — casos avanzados

A veces necesitas filtrar la propia tabla puente o navegar la relación de forma explícita.

// Ventas de productos que tienen AL MENOS UNA categoría
// cuyo nombre empieza por "Elec" (ej: "Electrónica"):
Ventas Electro =
CALCULATE(
    [Total Ventas],
    FILTER(
        ProductoCategorias,
        LEFT(RELATED(Categorias[NomCategoria]), 4) = "Elec"
    )
)

// Categorías únicas representadas en las ventas del mes actual:
Categorias Vendidas Este Mes =
CALCULATE(
    DISTINCTCOUNT(ProductoCategorias[IDCategoria]),
    FILTER(
        Ventas,
        Ventas[Fecha] >= DATE(YEAR(TODAY()), MONTH(TODAY()), 1)
    )
)

C) Tabla puente calculada en DAX (sin Power Query)

Si no puedes generar la tabla puente en el origen, puedes crearla como tabla calculada en DAX. Úsalo solo como último recurso.

// Tabla calculada que reconstruye la puente desde una tabla de mapeo:
ProductoCategorias_Calc =
SELECTCOLUMNS(
    FILTER(
        CROSSJOIN(
            VALUES(Productos[IDProducto]),
            VALUES(Categorias[IDCategoria])
        ),
        // Mantener solo las combinaciones válidas según tabla de mapeo:
        NOT ISBLANK(
            LOOKUPVALUE(
                MapeoCategoria[IDCategoria],
                MapeoCategoria[IDProducto], [IDProducto],
                MapeoCategoria[IDCategoria], [IDCategoria]
            )
        )
    ),
    "IDProducto", [IDProducto],
    "IDCategoria", [IDCategoria]
)

Los cuatro tropiezos clásicos con tablas puente

Los 4 puntos que debes llevarte