Diseñar una base de datos no se trata solo de crear tablas y columnas, sino de entender cómo se conectan entre sí. La clave está en hacerse dos preguntas simples que revelan el tipo de relación y, con ello, dónde colocar cada clave foránea. A continuación se explica la técnica que permite clasificar cualquier conexión y tomar decisiones de diseño sólidas.
¿Cómo funciona la técnica de las dos preguntas?
La técnica de las dos preguntas consiste en tomar dos tablas y preguntar en cada dirección: ¿puede un registro del lado A tener más de un registro del lado B? Y luego al revés [0:37]. Con las respuestas se determina el tipo de relación.
Usando el ejemplo de País y Sucursales:
- ¿Puede un país tener más de una sucursal? Sí, Colombia tiene sucursales en Bogotá, Medellín y Cali [0:48].
- ¿Puede una sucursal estar en más de un país? No, la tienda de Bogotá solo está en Colombia [0:59].
Una respuesta sí y una respuesta no indican una relación uno a muchos (1 a N): un país puede tener muchas sucursales, pero cada sucursal pertenece a un solo país [1:08].
Lo valioso de esta técnica es que obliga a pensar en casos concretos del negocio, no en abstracciones [1:25]. Solo existen tres resultados posibles [1:35]:
- Ambas respuestas son no: relación uno a uno.
- Una es sí y la otra no: relación uno a muchos.
- Ambas son sí: relación muchos a muchos.
¿Dónde se coloca la clave foránea en una relación uno a muchos?
El lado que responde "muchos" es siempre el que recibe la clave foránea [1:59]. Cada sucursal necesita recordar en qué país está, así que la columna PaisID va en la tabla Sucursales. Ponerla al revés significaría agregar una columna por cada sucursal en la tabla Países, lo que no tiene ningún sentido [2:13]. Dicho de otra forma, el lado "uno" guarda la clave primaria y el lado "muchos" guarda la clave foránea que apunta hacia él [2:21].
¿Qué es la relación uno a uno y cuándo aparece?
La relación uno a uno es la menos común [2:31]. En el sistema de ejemplo TiendaLatam no existe ninguna entre sus nueve tablas, y eso es normal porque son raras en la práctica [2:37]. Un caso hipotético sería guardar información sensible de empleados —contacto de emergencia o datos médicos— en una tabla separada llamada Perfil de Empleado: un empleado tiene un perfil y ese perfil pertenece a un solo empleado [2:44].
¿Por qué Pedidos y Productos necesitan una tabla intermedia?
Al aplicar las dos preguntas a Pedidos y Productos se obtiene una relación muchos a muchos [3:36]:
- ¿Puede un pedido incluir más de un producto? Sí, María compró un smartphone y café en la misma transacción [3:42].
- ¿Puede un producto aparecer en más de un pedido? También sí, el Smartphone X200 se vende en miles de pedidos [3:50].
Este tipo de relación no se puede resolver con una simple clave foránea [4:05]. Si ponemos ProductoID en Pedidos, solo registramos un producto por pedido. Si ponemos PedidoID en Productos, solo registramos un pedido por producto. En ambos casos perdemos información [4:09].
Otras salidas fallidas incluyen:
- Crear columnas producto1, producto2, producto3 en Pedidos: si alguien compra once artículos no caben, y si compra dos las demás quedan vacías [4:24].
- Duplicar la fila del pedido por cada producto repitiendo cliente, fecha y total: corregir un dato obliga a cambiarlo en varios lugares y un solo error genera contradicciones [4:41].
¿Qué papel cumple la tabla Detalle de Pedidos?
La solución es crear una tabla intermedia [4:56]. En TiendaLatam esa tabla se llama Detalle de Pedidos. Sus dos columnas principales son claves foráneas: PedidoID apunta a Pedidos y ProductoID apunta a Productos [5:09]. Cada fila representa un producto dentro de un pedido específico.
Cuando María compra un smartphone y tres paquetes de café, el pedido se registra una sola vez en Pedidos. Detalle de Pedidos crea una fila por cada producto comprado, ambas apuntando al mismo pedido [5:21]. Sin columnas vacías, sin información repetida y sin límites en la cantidad de productos.
Además, Detalle de Pedidos guarda datos propios de esa combinación específica [5:52]:
- Cantidad de unidades compradas.
- Precio unitario en el momento exacto de la venta.
- Subtotal de cada línea.
El precio unitario es el dato más relevante: si el smartphone sube de precio mañana, el registro de María sigue reflejando lo que ella pagó [6:16]. La tabla Productos dice cuánto cuesta hoy; Detalle de Pedidos dice cuánto costó en ese momento [6:22].
¿Cómo se clasifican todas las relaciones de TiendaLatam?
Con la técnica aprendida se puede identificar el tipo de relación entre cualquier par de tablas [5:29]:
- Países con Sucursales: uno a muchos.
- Categorías con Productos: uno a muchos.
- Clientes con Pedidos: uno a muchos.
- Pedidos con Productos: muchos a muchos, resuelto a través de Detalle de Pedidos.
¿Encontraste más relaciones en el sistema de TiendaLatam? Comparte cuáles identificaste y qué tipo de relación tienen.
