Cómo crear una bridge table en un Data Warehouse

João Barros 06 de July de 2026 4 min de lectura

Una bridge table (tabla puente) es la forma correcta de representar una relación muchos-a-muchos en un data warehouse con esquema en estrella, sin duplicar valores ni inflar los totales. El ejemplo clásico es una cuenta bancaria que pertenece a varios clientes: si enlazas la cuenta directamente a cada cliente, el saldo se cuenta una vez por titular. La solución es una tabla intermedia con un factor de ponderación que reparte cada valor de forma justa.

Requisitos previos

Un servidor de base de datos relacional (los ejemplos usan SQL Server / T-SQL, pero se adaptan a cualquier motor).
Un data warehouse con, al menos, una tabla de hechos y una dimensión en esquema en estrella.
Conocimientos básicos de SQL: CREATE TABLE, INSERT y JOIN.

Paso 1: Entender el problema muchos-a-muchos

Imagina una tabla de hechos fact_saldo_diario al grano de cuenta: cada fila guarda el saldo de una cuenta en un día. El problema aparece cuando una cuenta tiene varios titulares y quieres analizar el saldo por cliente. No puedes poner el cliente en la dimensión de la cuenta (la cuenta tendría que repetirse por cada titular), ni duplicar la fila de hechos (el saldo se sumaría varias veces). La bridge table lo resuelve situándose entre la cuenta y el cliente, guardando cada par cuenta–cliente en una fila.

Paso 2: Crear las dimensiones y la bridge table

Crea primero la dimensión de clientes y la dimensión de cuentas, ambas con claves subrogadas. Después crea la bridge table, que enlaza ambas e incluye la columna fator_peso — la fracción del valor que corresponde a cada titular.

CREATE TABLE dim_cliente (
    cliente_sk   INT IDENTITY(1,1) PRIMARY KEY,
    nome         VARCHAR(100)
);

CREATE TABLE dim_conta (
    conta_sk     INT IDENTITY(1,1) PRIMARY KEY,
    numero_conta VARCHAR(20)
);

CREATE TABLE bridge_conta_cliente (
    conta_sk    INT NOT NULL REFERENCES dim_conta(conta_sk),
    cliente_sk  INT NOT NULL REFERENCES dim_cliente(cliente_sk),
    fator_peso  DECIMAL(5,4) NOT NULL,
    CONSTRAINT pk_bridge PRIMARY KEY (conta_sk, cliente_sk)
);

La clave primaria compuesta (conta_sk, cliente_sk) impide pares repetidos y garantiza que cada titular aparece una sola vez por cuenta.

Paso 3: Rellenar la bridge con el factor de ponderación

La regla de oro es simple: para cada cuenta, la suma de los fator_peso de sus titulares debe dar 1. Una cuenta con dos titulares reparte el saldo en 0,5 + 0,5; con un único titular, el peso es 1. El ejemplo siguiente asume que la cuenta 1 tiene dos titulares y la cuenta 2 solo uno.

INSERT INTO bridge_conta_cliente (conta_sk, cliente_sk, fator_peso) VALUES
    (1, 10, 0.5),   -- cuenta 1, titular 10
    (1, 11, 0.5),   -- cuenta 1, titular 11
    (2, 12, 1.0);   -- cuenta 2, titular unico

El fator_peso también se conoce como allocation factor. Guardarlo en la bridge, y no en la consulta, garantiza que todos apliquen la misma regla de reparto.

Paso 4: Consultar los hechos con el factor de ponderación

Para obtener el saldo por cliente sin inflar los totales, une la tabla de hechos a la bridge y, luego, a la dimensión de clientes, multiplicando siempre la medida por fator_peso. Esa multiplicación es la que evita el doble conteo.

SELECT
    c.nome,
    SUM(f.saldo * b.fator_peso) AS saldo_alocado
FROM fact_saldo_diario AS f
JOIN bridge_conta_cliente AS b
    ON b.conta_sk = f.conta_sk
JOIN dim_cliente AS c
    ON c.cliente_sk = b.cliente_sk
GROUP BY c.nome;

Verificar el resultado

Haz dos comprobaciones rápidas. Primero, confirma que los pesos de cada cuenta suman exactamente 1 — ninguna cuenta puede quedar de menos ni de más:

SELECT conta_sk, SUM(fator_peso) AS total_peso
FROM bridge_conta_cliente
GROUP BY conta_sk
HAVING SUM(fator_peso) <> 1;

Si esta consulta no devuelve filas, todos los pesos son correctos. Segundo, compara el total asignado por cliente (con fator_peso) con el total original de las cuentas: los dos valores deben ser iguales. Si coinciden, no hay doble conteo.

Conclusión

Con una bridge table y un factor de ponderación ya puedes analizar relaciones muchos-a-muchos sin inflar los totales — una técnica esencial en el modelado dimensional. A partir de aquí, prueba pesos distintos (por ejemplo, un titular principal con 0,7 y uno secundario con 0,3) o añade fechas de inicio y fin para tratar la bridge como una relación que cambia con el tiempo. Y si un cliente tiene varias cuentas, ¿cómo resolverías el análisis en sentido inverso?