¿Qué es una relación uno a uno en el modelado de datos? ¿Cómo se implementa esta relación en una base de datos? Los ejemplos de este artículo responderán estas preguntas.
Hay tres tipos de relaciones entre entidades (tablas) en el modelado de datos:
- Relaciones de uno a muchos (también denominadas 1:M).
- Relaciones de muchos a muchos (M:N).
- Relaciones uno a uno (1:1).
El tipo de relación más común es una relación de uno a varios, en la que varios registros de otra entidad pueden hacer referencia a un registro de una entidad. Otro tipo común es una relación de muchos a muchos. Este tipo de relación solo se usa en modelos de datos lógicos. En una base de datos física, debe implementarse utilizando relaciones de uno a muchos y una tabla de unión.
En este artículo, discutiremos el tercer tipo de relaciones:la relación uno a uno . Este es el tipo de relación menos común en un modelo de datos. Daremos ejemplos de relaciones uno a uno, mostraremos la notación de las relaciones uno a uno en un diagrama ER y analizaremos las relaciones uno a uno en la práctica.
Ejemplos de relaciones uno a uno
Primero, ¿qué es una relación uno a uno? Es una relación en la que un registro en una entidad (tabla) está asociado con exactamente un registro en otra entidad (tabla).
Veamos algunos ejemplos de la vida real de relaciones uno a uno:
- País - ciudad capital :Cada país tiene exactamente una ciudad capital. Cada ciudad capital es la capital de exactamente un país.
- Persona:sus huellas dactilares . Cada persona tiene un conjunto único de huellas dactilares. Cada conjunto de huellas dactilares identifica exactamente a una persona.
- Correo electrónico - cuenta de usuario . Para muchos sitios web, una dirección de correo electrónico está asociada con exactamente una cuenta de usuario y cada cuenta de usuario se identifica por su dirección de correo electrónico.
- Cónyuge - cónyuge :En un matrimonio monógamo, cada persona tiene exactamente un cónyuge.
- Perfil de usuario:configuración de usuario . Un usuario tiene un conjunto de configuraciones de usuario. Un conjunto de configuraciones de usuario está asociado con exactamente un usuario.
Para mayor claridad, comparemos estos ejemplos con relaciones que no son uno a uno:
- País - ciudad: Cada ciudad se encuentra exactamente en un país, pero la mayoría de los países tienen muchas ciudades.
- Padre - hijo :Cada hijo tiene dos padres, pero cada padre puede tener muchos hijos.
- Empleado - gerente :Cada empleado tiene exactamente un supervisor o gerente inmediato, pero cada gerente generalmente supervisa a muchos empleados.
Denotar una relación uno a uno en un diagrama ER
Una relación uno a uno en un diagrama ER se denota, como todas las relaciones, con una línea que conecta las dos entidades. La cardinalidad "uno" se denota con una sola línea recta. (La cardinalidad "varios" se indica con el símbolo de una pata de gallo).
La relación de uno a uno entre el país y la capital se puede denotar así:
Las líneas rectas perpendiculares significan “obligatorio ”. Este diagrama muestra que es obligatorio que una capital tenga un país y que es obligatorio que un país tenga una capital.
Otra posibilidad es que uno o ambos lados de la relación sean opcionales. . Un lado opcional se indica con un círculo abierto. Este diagrama dice que existe una relación de uno a uno entre una persona y sus huellas dactilares. Una persona es obligatoria (las huellas dactilares deben asignarse a una persona), pero las huellas dactilares son opcionales (una persona puede no tener huellas dactilares asignadas en la base de datos).
Relaciones uno a uno en una base de datos física
Hay algunas formas de implementar una relación uno a uno en una base de datos física.
Clave principal como clave externa
Una forma de implementar una relación uno a uno en una base de datos es usar la misma clave principal en ambas tablas. Las filas con el mismo valor en la clave principal están relacionadas. En este ejemplo, Francia es un country con el id 1 y su ciudad capital está en la tabla capital bajo id 1.
country
| id | nombre |
|---|---|
| 1 | Francia |
| 2 | Alemania |
| 3 | España |
capital
Técnicamente, una de las claves principales debe marcarse como clave externa, como en este modelo de datos:
La clave principal en la tabla capital también es una clave externa que hace referencia a la columna id en la tabla país . Desde capital.id es una clave principal, cada valor en la columna es único, por lo que la capital puede hacer referencia a un país como máximo. También debe hacer referencia a un país:es una clave principal, por lo que no se puede dejar vacía.
Clave foránea adicional con restricción única
Otra forma de implementar una relación uno a uno en una base de datos es agregar una nueva columna y convertirla en una clave externa.
En este ejemplo, agregamos la columna country_id en la tabla capital . La capital con id 1, Madrid, está asociado con el país 3, España.
country
| id | nombre |
|---|---|
| 1 | Francia |
| 2 | Alemania |
| 3 | España |
capital
| id | nombre | id_país |
|---|---|---|
| 1 | Madrid | 3 |
| 2 | Berlín | 2 |
| 3 | París | 1 |
Técnicamente, la columna country_id debe ser una clave externa que haga referencia al id columna en la tabla country . Dado que desea que cada capital se asocie con exactamente un país, debe hacer que la columna de clave externa sea country_id único.
Relaciones uno a uno en la práctica
Pocas relaciones uno a uno duran
Las relaciones uno a uno son el tipo de relación menos frecuente. Una de las razones de esto es que existen muy pocas relaciones uno a uno en la vida real. Además, la mayoría de las relaciones uno a uno son uno a uno solo por un período de tiempo. Si su modelo incluye un componente de tiempo y captura el historial de cambios, como suele ser el caso, tendrá muy pocas relaciones uno a uno.
Una relación monógama puede dividirse o uno de los socios puede morir. Si modela la realidad de las relaciones monógamas (como matrimonios o uniones civiles) a lo largo del tiempo, es probable que necesite modelar el hecho de que duran solo un período determinado.
Uno pensaría que una persona y sus huellas dactilares nunca cambian. Pero, ¿qué pasa si la persona pierde un dedo o el dedo está muy quemado? Sus huellas dactilares podrían cambiar. No es un escenario muy frecuente; aún así, en algunos modelos, es posible que deba tener esto en cuenta.
Incluso algo aparentemente tan estable como los países y sus capitales cambian con el tiempo. Por ejemplo, Bonn solía ser la capital de Alemania Occidental (Bundesrepublik Deutschland) después de la Segunda Guerra Mundial, cuando Berlín formaba parte de Alemania Oriental. Esto cambió después de la reunificación alemana; la capital de Alemania (Bundesrepublik Deutschland) es ahora Berlín. Si debe o no tener esto en cuenta depende de la realidad de su negocio y de la aplicación en la que esté trabajando.
Un escenario 1:1 factible:partes opcionales de la tabla
Puedo pensar en un escenario factible para una relación uno a uno real:partes opcionales de una tabla. Imagina que tienes la tabla usuario con datos de usuario. La tabla contiene información general del usuario, como nombres de usuarios, direcciones de correo electrónico y fechas de registro. También contiene configuraciones de usuario, como el tema de color o el inicio de sesión automático para esa aplicación. Sin embargo, la mayoría de los usuarios no tienen ninguna configuración de usuario; utilizan la configuración predeterminada.
user
| id | nombre | correo electrónico | fecha_de_registro | tema | inicio de sesión automático |
|---|---|---|---|---|---|
| 1 | Natanael Talbot | [email protected] | 2020-12-12 | oscuro | verdadero |
| 2 | Talitha Yates | [email protected] | 2020-12-14 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | luz | falso |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Iglesia de Mauricio | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 2020-12-21 |
Hay muchos campos vacíos en esta tabla. Podrías dividir el user tabla en dos tablas:user y user_settings , que contiene información sobre la configuración de los usuarios para aquellos que optaron por seleccionarlos.
user
| id | nombre | correo electrónico | fecha_de_registro | tema | inicio de sesión automático |
|---|---|---|---|---|---|
| 1 | Natanael Talbot | [email protected] | 2020-12-12 | oscuro | verdadero |
| 2 | Talitha Yates | [email protected] | 2020-12-14 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | luz | falso |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Iglesia de Mauricio | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 2020-12-21 |
user_settings
| id_usuario | tema | inicio de sesión automático |
|---|---|---|
| 1 | oscuro | verdadero |
| 3 | luz | falso |
La división de datos en dos tablas hace que la consulta de tablas sea más compleja:debe unir los datos de ambas tablas. Por otro lado, el usuario principal la tabla es más fácil de administrar.
Más información sobre las relaciones de bases de datos
Una relación uno a uno es una relación en la que un registro de una tabla está asociado con exactamente un registro de otra tabla. Este tipo de relación es raro en la vida real. Si incluye el tiempo en su modelo de datos, muchas relaciones de uno a uno se convierten en relaciones de uno a muchos o de muchos a muchos. El escenario más común para usar una relación uno a uno en una base de datos es dividir una tabla en dos:una con columnas obligatorias y la otra con columnas opcionales.
Si le gustó este artículo, consulte otros artículos sobre relaciones de uno a muchos y de muchos a muchos en nuestro blog.
Si es un estudiante que toma clases de bases de datos, asegúrese de crear una cuenta académica gratuita en Vertabelo, nuestra herramienta de dibujo de diagramas ER en línea. Vertabelo le permite dibujar diagramas ER lógicos y físicos directamente en su navegador. Es compatible con PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift y otras bases de datos relacionales. ¡Pruébelo y vea lo fácil que es comenzar!
