Las relaciones son vínculos lógicos que conectan dos o más tablas entre sí basándose en columnas que comparten.
Su objetivo fundamental es estructurar la información para evitar la duplicación de datos y garantizar la consistencia en todo el sistema.
Por ejemplo, si vienes del mundo de Excel, estarás acostumbrado a tener una “súper tabla” donde repites datos:
| Pedido | Cliente | Dirección | Producto | |
|---|---|---|---|---|
| 100 | Juan Pérez | [email protected] | Calle Falsa 123 | Bici |
| 101 | Juan Pérez | [email protected] | Calle Falsa 123 | Casco |
Pero ¿qué pasa si Juan cambia de email? Tienes que actualizarlo en 500 filas. O puedes meter la pata y cambiar uno solo de los emails por error.
Las bases de datos relacionales solucionan esto dividiendo la información en tablas separadas (Clientes, Pedidos, Productos) y conectándolas mediante Relaciones.
Los protagonistas: PK y FK
Para crear una relación, necesitamos dos elementos fundamentales:
Es el identificador único e irrepetible de una fila. Es como el DNI o el número de Pasaporte de ese registro.
- En la tabla
Clientes, elClienteIDes la PK. - Juan Pérez tiene el ID
1. No puede haber otro cliente con el ID1.
Es un campo en otra tabla que apunta a la Clave Primaria de la primera. Es el “gancho” o enlace.
- En la tabla
Pedidos, añadimos una columnaClienteID. - Esa columna no es única (Juan puede hacer muchos pedidos), pero debe existir en la tabla de Clientes.
Tipos de relaciones
Dependiendo de cómo interactúan los datos, existen tres tipos de relaciones. Vamos a verlas con ejemplos.
Relación Uno a Muchos (1
Esta es, con diferencia, la más común (el 90% de las veces).
El concepto:
- Un Cliente puede hacer Muchos Pedidos.
- Pero Un Pedido pertenece a un solo Cliente.
Cómo se hace: Ponemos la Foreign Key en el lado del “Muchos” (la tabla hija).
Gracias a que el ClienteID (FK) se repite en la tabla de Pedidos, sabemos que Ana ha comprado dos veces.
Relación Muchos a Muchos (N
Aquí la cosa se complica.
El concepto:
- Un Alumno se matricula en Muchas Asignaturas.
- Una Asignatura tiene matriculados a Muchos Alumnos.
El problema: No podemos poner una columna AsignaturaID en Alumnos (porque estudia varias), ni una columna AlumnoID en Asignaturas (porque tiene varios alumnos). Tampoco podemos guardar una lista separada por comas (1, 5, 8) porque eso viola las reglas de las bases de datos.
La solución: La Tabla Intermedia Creamos una tercera tabla (Tabla Puente) cuya única misión es conectar a las otras dos.
Cuando hagamos JOINS, para conectar Alumnos con Asignaturas, tendremos que pasar obligatoriamente por esta tabla puente.
Relación Uno a Uno (1:1)
Es la menos frecuente.
El concepto:
- Un empleado tiene Un movil de empresa asignado.
- Ese movil de empresa pertenece solo a ese empleado.
Generalmente, si la relación es 1 a 1, solemos guardar los datos en la misma tabla. Pero a veces se separan por seguridad o limpieza (ej: TablaUsuarios y TablaDatosMedicosConfidenciales).
La FK puede ir en cualquiera de las dos tablas, marcada como única (UNIQUE).
Integridad referencial
Las relaciones no sirven solo para consultar datos, sirven para protegerlos. Las bases de datos tienen una mecanismo llamado Integridad Referencial.
Esto significa que la base de datos no te dejará romper la relación:
- No puedes crear un Pedido con
ClienteID = 99si el cliente 99 no existe en la tabla Clientes. (Error: Foreign Key Constraint Violation). - No puedes borrar al Cliente “Juan” si tiene pedidos asociados en la tabla Pedidos (dejarías registros huérfanos). Primero tendrías que borrar sus pedidos.
