Diseñar una base de datos sin comprender cómo se conectan las tablas es la receta perfecta para la duplicación masiva de información y errores difíciles de corregir en producción. Las relaciones son el corazón del modelo relacional, y dominarlas marca la diferencia entre un esquema limpio y uno problemático.

Cuando no existen relaciones bien definidas, ocurre lo que muchos experimentan al migrar desde hojas de cálculo: datos del cliente copiados en cada pedido. Quinientos pedidos significan quinientas copias del nombre, correo electrónico y teléfono. Además, las llaves foráneas mal definidas provocan integridad referencial rota, es decir, pedidos que referencian clientes que ya fueron eliminados. La base de datos acepta datos inválidos sin protestar [0:36].

¿Qué es una relación uno a uno y cuándo conviene usarla?

Es la relación menos común, pero resulta muy útil para separar datos por seguridad o rendimiento. Un registro de la tabla A se relaciona con exactamente un registro de la tabla B, y viceversa [1:06].

En el ejemplo de Tienda Latam, la entidad empleado se relaciona con legajo empleado. El legajo contiene datos sensibles que no todos deben ver:

• Sueldo del empleado.
• Número de identificación.
• Datos bancarios.

Estos campos se almacenan en una tabla separada por razones de seguridad. También se aplica esta estrategia para separar datos que se consultan raramente de aquellos que se necesitan constantemente, mejorando así el rendimiento de las consultas.

¿Por qué la relación uno a varios es el patrón dominante?

Es la relación más común en cualquier modelo de datos de negocio. Un registro de la tabla A se relaciona con uno o muchos registros de la tabla B. La regla fundamental es que la llave foránea siempre va en el lado "muchos" [1:36].

En Tienda Latam, un cliente puede hacer muchos pedidos, pero cada pedido pertenece a un solo cliente. La columna cliente_id en la tabla pedidos es la llave foránea que establece esta conexión [1:55].

Casi todo el modelo de Tienda Latam sigue este patrón:

• País a clientes.
• Categoría a productos.
• Empleado a pedidos.

¿Cómo funciona la relación muchos a muchos con tablas intermedias?

Es la relación más compleja y la que más errores genera. Muchos registros de A se relacionan con muchos registros de B, y siempre requieren una tabla intermedia, también llamada tabla de unión o tabla puente [2:19].

En Tienda Latam, un pedido puede contener muchos productos y un producto puede estar en muchos pedidos. Intentar guardar múltiples productos en una sola columna es uno de los errores más costosos de corregir: resulta imposible de consultar con SQL [1:00].

La tabla intermedia en este caso se llama detalle_pedido, y no solo conecta las dos entidades, sino que agrega valor. Guarda información contextual como:

• La cantidad comprada.
• El precio al momento de la compra.

Esto es fundamental: si el precio del producto cambia mañana, el pedido histórico conserva el valor correcto [2:50].

¿Cuál es la regla práctica para elegir el tipo de relación?

Al momento de diseñar, conviene tener presente este resumen [3:06]:

• Uno a uno: un A tiene exactamente un B, sin tabla extra. La llave foránea puede ir en cualquiera de las dos tablas.
• Uno a varios: un A tiene muchos B, sin tabla extra. La llave foránea está en el lado de muchos.
• Muchos a muchos: muchos A tienen muchos B, con tabla intermedia obligatoria. Las llaves foráneas están en esa tabla intermedia.

La regla ante la duda es pensar en el negocio real: ¿puede un pedido tener un solo producto? Casi nunca. Entonces es muchos a muchos [3:40].

En el panorama completo de Tienda Latam, pedidos es la entidad central que se conecta con clientes, empleados y productos. La única relación muchos a muchos es pedidos a productos, resuelta con detalle_pedido. Todo lo demás sigue el patrón uno a varios [3:50].

El siguiente paso natural es trasladar estas relaciones a un diagrama entidad-relación formal, utilizando la notación estándar de la industria. ¿Qué tipo de relación te ha resultado más difícil de identificar en tus propios proyectos?