¿Qué es una relación de uno a muchos en una base de datos? Una explicación con ejemplos

Las relaciones de uno a varios son una de las relaciones de base de datos más comunes. Si desea saber cuándo y cómo utilizar las relaciones de uno a varios, este artículo es un gran punto de partida.

Seguramente usará relaciones de uno a muchos para almacenar información en cualquier base de datos relacional, ya sea que esté diseñando software de nivel empresarial o simplemente creando una base de datos simple para realizar un seguimiento de la colección de sellos de su tío.

Una breve introducción al modelo relacional

Las bases de datos relacionales son un componente central de cualquier aplicación transaccional moderna. El modelo relacional está compuesto por tablas (datos organizados en filas y columnas) que tienen al menos una clave única que identifica cada fila. Cada tabla representa una entidad. Esto se muestra en el siguiente ejemplo, una versión muy simple de una tabla que representa los pedidos de los clientes:

El diagrama anterior, que creé en línea usando Vertabelo, tiene una sola tabla. Cada fila de la tabla representa un pedido y cada columna (también conocida como atributo ) representa cada pieza individual de información contenida en un pedido.

Para aquellos que aún no están familiarizados con la herramienta de diseño de Vertabelo, el artículo ¿Cuáles son los símbolos utilizados en los diagramas ER? explica los símbolos y convenciones utilizados. Es posible que también desee obtener más información sobre modelos relacionales y bases de datos utilizando nuestro curso de modelado de bases de datos.

¿Qué son las relaciones y por qué las necesitamos?

Si echamos un vistazo más profundo a la tabla utilizada en el ejemplo anterior, veremos que en realidad no representa un pedido completo. No tiene toda la información que esperarías que tuviera. Notarás que no incluye ningún dato relacionado con el cliente que realizó el pedido, ni tiene nada sobre los productos o servicios solicitados.

¿Qué debemos hacer para completar este diseño para almacenar datos de pedidos? ¿Deberíamos agregar información del cliente y del producto al Pedido? ¿mesa? Eso requeriría agregar nuevas columnas (atributos) para nombres de clientes, identificadores de impuestos, direcciones, etc., como se muestra a continuación:

Si hacemos eso, pronto nos encontraremos con problemas. La mayoría de los clientes realizan más de un pedido, por lo que este sistema almacenará la información del cliente muchas veces, una vez por cada pedido de cada cliente. Eso no parece un movimiento inteligente.

Además, ¿qué sucede cuando un cliente cambia su número de teléfono? Si alguien necesita llamar al cliente, puede encontrar el número anterior en pedidos anteriores, a menos que alguien actualice cientos (o incluso miles) de pedidos existentes con la nueva información. Y lo mismo ocurriría con cualquier otro cambio.

Un modelo relacional requiere que definamos cada entidad como una tabla separada y establezcamos relaciones entre ellas. Almacenar toda la información en una sola tabla simplemente no funciona.

Hay varios tipos de relaciones entre tablas, pero probablemente la más común es la relación de uno a muchos, que a menudo se escribe como 1:N. Este tipo de relación significa que una fila en una tabla (generalmente llamada tabla principal) puede tener una relación con muchas filas en otra tabla (generalmente llamada tabla secundaria). Algunos ejemplos comunes de relaciones de uno a muchos son:

• Un fabricante de automóviles fabrica muchos modelos diferentes, pero un modelo de automóvil en particular es fabricado por un solo fabricante de automóviles.
• Un cliente puede realizar varias compras, pero cada compra la realiza un solo cliente.
• Una empresa puede tener muchos números de teléfono, pero un número de teléfono pertenece a una empresa.

También existen otros tipos de relaciones entre tablas; si desea obtener más información sobre ellos, consulte este artículo sobre las relaciones de muchos a muchos.

Volviendo a nuestro ejemplo de pedido inicial, el Customer la tabla sería la tabla principal y el Order mesa al niño; un cliente puede tener muchos pedidos, mientras que un pedido puede pertenecer a un solo cliente.

Tenga en cuenta que la definición de uno a muchos permite asociar una fila en la tabla principal a muchas filas en cada tabla secundaria, pero no lo requiere. En realidad, el diseño permite que un cliente tenga cero pedidos (es decir, un cliente nuevo que aún no ha realizado su primera compra), un pedido (un cliente relativamente nuevo que ha realizado una sola compra) o muchos pedidos (un cliente frecuente).

Mostrar relaciones de uno a muchos en un diagrama ER

Echemos un vistazo a un ejemplo más completo de un sistema simple de pedidos de clientes usando un diagrama ER (o relación de entidad). (Si desea obtener más información sobre estos diagramas, Vertabelo Features:Logical Diagrams es un excelente punto de partida). Este es el modelo:

Este es un diseño más realista. Notará que hay nuevas entidades (tablas) en el diagrama, que ahora contiene las tablas Customer , Order , Order Detail y Product . Sin embargo, lo más importante que notas es que ahora hay relaciones entre las mesas .

En un modelo de base de datos, las relaciones se representan mediante líneas que conectan dos entidades. Las características de estas relaciones están representadas por diferentes conectores:

• Cuando hay una sola línea vertical, la entidad más cercana a ese conector solo tiene una fila afectada por la relación. Es el 'uno' en uno a muchos.
• Cuando hay un conector de varias líneas que parece una pata de gallo, la entidad más cercana a ese conector tiene varias filas afectadas por la relación; son los 'muchos'.

Mirando la imagen y conociendo la notación, es simple entender que el diagrama define que cada Order puede tener muchos Order Details y que cada Order Detail pertenece a un único Order .

Implementación de una relación de uno a varios entre tablas

Para definir una relación de uno a varios entre dos tablas, la tabla secundaria debe hacer referencia a una fila en la tabla principal. Los pasos necesarios para definirlo son:

1. Agregue una columna a la tabla secundaria que almacenará el valor del identificador principal. (En realidad, la mayoría de los motores de bases de datos permiten que sea cualquier clave única de la tabla principal, no solo la clave principal). La columna se puede definir como obligatoria según las necesidades de su negocio; aun así, se suelen hacer columnas de clave foránea

Nota: Es una buena práctica mantener el nombre de las columnas de referencia igual que en la tabla referenciada (principal). Esto simplifica aún más la comprensión de la relación.

1. Añadir una clave externa restricción en la tabla secundaria. Esto indica que cada valor almacenado en esta nueva columna hace referencia a una fila en la tabla principal.

Las restricciones de clave externa son una función disponible en la base de datos relacional que exige que:

1. Cuando agrega una fila a la tabla secundaria, el valor de la columna de referencia debe coincidir con un (y solo uno) valor en la tabla principal. (Es por eso que se debe referenciar una columna o conjunto de columnas que conforman una clave primaria o clave única).
2. Si alguien intenta eliminar una fila de la tabla principal o intenta modificar los valores de la clave principal/única utilizada como referencia y hay una tabla secundaria que hace referencia a esa fila, la operación fallará.

Estas dos características aseguran que la base de datos mantenga su integridad. No hay posibilidad de crear pedidos que hagan referencia a un cliente inexistente, ni de eliminar un cliente que ya tiene pedidos.

Crear una clave externa

La sintaxis de la clave externa generalmente depende del motor de la base de datos de destino. Una vez que haya definido su modelo lógico, puede usar la función "Generar modelo físico..." en los diagramas lógicos de Vertabelo para transformar su modelo (independiente de la base de datos) en un modelo físico que coincida con su proveedor de base de datos. Vertabelo también generará el script SQL requerido que le permitirá crear las tablas y relaciones en su base de datos de destino.

Algunos ejemplos prácticos de relaciones 1:N

Ahora repasemos algunos ejemplos de relaciones de uno a muchos en el mundo real.

Relación de uno a muchos usando claves primarias

Este es probablemente el escenario más común al definir una relación de uno a muchos. La tabla secundaria utiliza el valor de clave principal de la tabla principal para establecer la relación.

Este ejemplo describe un servicio básico de transmisión en línea. Revisemos lo que está almacenado en cada una de las tablas y cómo se relacionan con las otras tablas de nuestro modelo:

1. Cada ServiceType define cómo se 'comporta' una cuenta (por ejemplo, cuántos usuarios pueden conectarse al sistema al mismo tiempo, si la cuenta tiene Full HD habilitado, etc.). Tiene una relación con otras entidades:
   • Una relación de uno a muchos con Account , lo que significa que cada tipo de servicio puede tener muchas cuentas de ese tipo.
2. Cada Account almacena información sobre un cliente. Tiene dos relaciones directas con otras entidades:
   • Cada cuenta pertenece a un solo ServiceType , como se explicó anteriormente.
   • Esta tabla tiene una relación de uno a muchos con el Profile tabla, lo que significa que más de un usuario puede conectarse a nuestro sistema usando la misma cuenta.
3. Cada Profile representa a un usuario en nuestro sistema. Tiene dos relaciones con otras entidades:
   • Cada perfil pertenece a una sola Account . Esto permite que todos los miembros de la familia (o quizás un grupo de amigos) compartan la misma cuenta mientras cada uno tiene sus propios atributos personales (por ejemplo, un nombre de perfil).
   • Cada perfil tiene un Avatar único .
4. Cada Avatar es una imagen que nos permite identificar rápidamente a cada usuario de la cuenta. Tiene una relación con otra entidad:
   • Una relación de uno a muchos con Profile , lo que significa que se puede asignar un solo avatar a perfiles en diferentes cuentas.

Relaciones de uno a muchos con claves únicas naturales o sustitutas

El uso de claves primarias sustitutas es una forma ampliamente aceptada de modelar tablas. (Las claves primarias sustitutas son generadas por la base de datos y no tienen ningún valor comercial real). Este método produce claves que son más simples de usar y agrega cierta flexibilidad para cuando se requieren cambios.

Sin embargo, hay situaciones, p. cuando necesitamos interactuar con sistemas externos, donde usar una clave generada en nuestra base de datos es un mal enfoque. Para esos escenarios, generalmente es mejor usar claves naturales, que son valores únicos que forman parte de la entidad que se almacena y que nuestra base de datos no genera automáticamente.

El siguiente ejemplo representa un modelo de datos básico de una organización que realiza un seguimiento de los vehículos (es decir, la marca, el modelo, el color y el año del automóvil), sus propietarios y cualquier infracción de tránsito asociada. Cuando lo definimos, utilizamos claves primarias sustitutas para establecer las relaciones entre los vehículos y las marcas, modelos y propietarios, ya que toda esta información es manejada internamente por nuestro sistema.

En este sistema, ¿cómo puede un oficial de policía en otra ciudad denunciar un automóvil estacionado ilegalmente usando la clave principal de nuestro vehículo (VehicleID )? Naturalmente, dicha información no está disponible en el vehículo estacionado, pero la matrícula está ahí. Eso significa que la forma más sencilla de recibir y asociar información de una fuente externa (en este ejemplo, cualquier departamento de policía del país) es mediante el uso de una clave única natural en lugar de una clave principal sustituta.

La implementación física de este diagrama lógico para SQL Server está disponible aquí:

Relaciones de uno a muchos en la misma tabla

Los ejemplos anteriores se centraron en las relaciones entre dos o más tablas, pero también hay escenarios en los que la relación se da entre filas de una misma tabla. Este tipo de relación de uno a muchos también se denomina relación jerárquica; se utiliza en muchos sistemas para representar estructuras en forma de árbol, es decir, un organigrama, una cuenta del libro mayor o un producto y sus componentes.

La primera vez que necesite crear este tipo de estructura, tendrá la tentación de definir una tabla para cada uno de los niveles de su jerarquía, como se muestra en el siguiente diagrama:

Hay muchos problemas con este enfoque:

• Todas las tablas son casi idénticas y almacenan información idéntica.
• Si su organización agrega un nuevo nivel, deberá modificar el modelo de datos y agregar una nueva tabla, nuevas claves externas, etc.
• Si un empleado recibe una promoción, debe eliminarlo de una tabla e insertarlo en otra.

Por lo tanto, la mejor manera de modelar este tipo de estructura es usar una sola tabla que se referencia a sí misma, como se muestra en este diagrama:

Aquí vemos un solo Employee tabla y una columna llamada EmployeeID_Manager . Esa columna hace referencia a otro empleado de la misma organización que es el supervisor/gerente del empleado actual.

Agregué el _Manager sufijo para distinguir entre el ID de la fila actual y el ID del administrador. (Podríamos usar ManagerID en su lugar, pero prefiero mantener el nombre original de la columna referenciada y, en aquellos casos en que ambos están en la misma tabla, agregar un sufijo que explique el rol que realmente tiene).

Comprender las relaciones jerárquicas es más complejo que otras relaciones de uno a muchos. Pero si te olvidas de la tabla donde se almacena toda la información e imaginas que en realidad hay diferentes tablas, cada una de las cuales representa un nivel en la jerarquía, es un poco más fácil de visualizar. Imagina que estableces la relación entre dos entidades y luego las combinas en una sola entidad.

¿Qué sigue?

Los ejemplos proporcionados lo ayudarán a identificar diferentes escenarios que requieren una relación de uno a muchos. Puede comenzar a diseñar su propia estructura de base de datos utilizando Vertabelo Database Modeler, una herramienta basada en web que le permite no solo generar un modelo lógico sino también crear una versión física del mismo para el proveedor de base de datos que necesita.

Ahora es su turno:use la sección de comentarios para contarnos su opinión sobre este artículo, hacer preguntas adicionales o compartir sus experiencias con el modelado de bases de datos.