Diferencia entre la relación uno a muchos y muchos a uno

¿Cuál es la diferencia real entre la relación uno a varios y la relación de varios a uno? ¿Solo está al revés, algo así?

No puedo encontrar ningún tutorial 'bueno y fácil de entender' sobre este tema que no sea este: SQL para principiantes: Parte 3 - Relaciones de bases de datos

Sí, es al revés. Depende de qué lado de la relación esté presente la entidad.

Por ejemplo, si un departamento puede contratar a varios empleados, la relación de departamento a empleado es de uno a muchos (1 departamento emplea a muchos empleados), mientras que la relación de empleado a departamento es de muchos a uno (muchos empleados trabajan en un departamento).

Más información sobre los tipos de relaciones:

Relaciones de bases de datos - documentación de IBM DB2

De esta página sobre terminología de bases de datos

La mayoría de las relaciones entre tablas son de uno a varios.

Ejemplo:

• Un área puede ser el hábitat de muchos lectores.
• Un lector puede tener muchas suscripciones.
• Un periódico puede tener muchas suscripciones.

Una relación de muchos a uno es lo mismo que uno a muchos, pero desde un punto de vista diferente.

• Muchos lectores viven en un área.
• Muchas suscripciones pueden ser de un mismo lector.
• Muchas suscripciones son para el mismo periódico.

¿Cuál es la diferencia real entre la relación uno a varios y la relación de varios a uno?

Existen diferencias conceptuales entre estos términos que deberían ayudarlo a visualizar los datos y también posibles diferencias en el esquema generado que deben entenderse completamente. Sin embargo, sobre todo, la diferencia es de perspectiva.

En una relación de uno a varios , la tabla local tiene una fila que puede estar asociada con muchas filas de otra tabla. En el ejemplo de SQL para principiantes , uno Customerpuede estar asociado a muchos Orders.

En la relación opuesta de muchos a uno , la tabla local puede tener muchas filas asociadas con una fila de otra tabla. En nuestro ejemplo, muchos Orders pueden estar asociados a uno Customer. Esta diferencia conceptual es importante para la representación mental.

Además, el esquema que respalda la relación se puede representar de manera diferente en las tablas Customery Order. Por ejemplo, si el cliente tiene columnas idy name:

id,name
1,Bill Smith
2,Jim Kenshaw

Luego, para que Ordera se asocie con a Customer, muchas implementaciones de SQL agregan a la Ordertabla una columna que almacena el idde los asociados Customer(en este esquema customer_id:

id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2

En las filas de datos anteriores, si miramos la customer_idcolumna de identificación, vemos que Bill Smith(id-cliente # 1) tiene 2 pedidos asociados con él: uno por $ 12.34 y otro por $ 7.58. Jim Kenshaw(customer-id # 2) tiene solo 1 pedido por $ 158.01.

Lo que es importante tener en cuenta es que, por lo general, la relación de uno a muchos no agrega ninguna columna a la tabla que es "uno". No Customertiene columnas adicionales que describan la relación con Order. De hecho, la Customerfuerza también tienen una relación de uno a varios con ShippingAddressy SalesCalltablas y sin embargo no tienen columnas adicionales a la Customermesa.

Sin embargo, para que se describa una relación de muchos a uno, a menudo idse agrega una columna a la tabla "muchos" que es una clave externa a la tabla "uno"; en este caso customer_id, se agrega una columna al Order. A la orden asociada # 10 por $ 12.34 a Bill Smith, asignamos la customer_idcolumna a Bill Smith's id 1.

Sin embargo, también es posible que haya otra tabla que describa la relación Customery Order, de modo que no sea necesario agregar campos adicionales a la Ordertabla. En lugar de agregar un customer_idcampo a la Ordertabla, podría haber una Customer_Ordertabla que contenga claves para Customery Order.

customer_id,order_id
1,10
1,11
2,12

En este caso, uno a muchos y muchos a uno son todos conceptuales, ya que no hay cambios de esquema entre ellos. Qué mecanismo depende de su esquema y la implementación de SQL.

Espero que esto ayude.

No hay diferencia. Es solo una cuestión de idioma y preferencia en cuanto a la forma en que establezca la relación.

La respuesta a su primera pregunta es: ambos son similares,

La respuesta a su segunda pregunta es: uno a muchos -> un HOMBRE (tabla MAN) puede tener más de una esposa (tabla MUJER) muchos a uno -> más de una mujer se ha casado con un HOMBRE.

Ahora bien, si desea relacionar esta relación con dos tablas MAN y WOMEN, una fila de la tabla MAN puede tener muchas relaciones con las filas de la tabla WOMEN. Espero que quede claro.

Ejemplo

Dos tablas con una relación

SQL

En SQL, solo hay un tipo de relación, se llama referencia. (Su interfaz puede hacer cosas útiles o confusas [como en algunas de las Respuestas], pero esa es una historia diferente).

• Una clave externa en una tabla (la referenc ing tabla)
  Referencias
  una clave primaria en otra tabla (la referenc ed tabla)

• En términos de SQL, Bar hace referencia a Foo
  Not al revés

  CREATE TABLE Foo (
      Foo   CHAR(10)  NOT NULL, -- primary key
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK             -- constraint name
          PRIMARY KEY (Foo)     -- pk
      )  
  CREATE TABLE Bar (
      Bar   CHAR(10)  NOT NULL, -- primary key
      Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK                -- constraint name
          PRIMARY KEY (Bar),       -- pk
      CONSTRAINT Foo_HasMany_Bars  -- constraint name
          FOREIGN KEY   (Foo)      -- fk in (this) referencing table
          REFERENCES Foo(Foo)      -- pk in referenced table
      )

• Dado que Foo.Fooes una clave principal, es única, solo hay una fila para cualquier valor dado deFoo

• Dado que Bar.Fooes una referencia, una clave externa y no hay un índice único en él, puede haber muchas filas para cualquier valor dado deFoo
• Por lo tanto, la relación Foo::Bar es de uno a muchos.
• Ahora puedes percibir (mirar) la relación al revés,Bar::Foo es de muchos a uno
  • Pero no deje que eso lo confunda: para cualquier Barfila, solo hay una Foofila a la que hace referencia
• En SQL, eso es todo lo que tenemos. Eso es todo lo que se necesita.

¿Cuál es la diferencia real entre una relación de uno a muchos y de muchos a uno?

Solo hay una relación, por lo tanto no hay diferencia. La percepción (desde un "extremo" o el otro "extremo") o leerlo al revés, no cambia la relación.

Cardinalidad

La cardinalidad se declara primero en el modelo de datos, lo que significa Lógica y Física (la intención), y luego en la implementación (la intención realizada).

Cardinalidad

Uno a cero a muchos
En SQL eso (lo anterior) es todo lo que se requiere.

Uno a uno a muchos
Necesita una transacción para hacer cumplir la de la tabla de referencia.

Uno a cero a uno
Necesita Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

Uno a uno
necesita una transacción para hacer cumplir la de la tabla de referencia.

Muchos a muchos
No existe tal cosa a nivel físico (recuerde, solo hay un tipo de relación en SQL).

En los primeros niveles lógicos durante el ejercicio de modelado, es conveniente dibujar tal relación. Antes de que el modelo se acerque a la implementación, es mejor que se eleve para usar solo las cosas que pueden existir. Esta relación se resuelve implementando una tabla asociativa.

Muchos a muchos resueltos

Uno a muchos y muchos a uno son similares en multiplicidad pero no en aspecto (es decir, direccionalidad).

El mapeo de Asociaciones entre clases de entidad y Relaciones entre tablas. Hay dos categorías de relaciones:

1. Multiplicidad (término ER: cardinalidad)
   • Relaciones uno a uno : ejemplo de esposo y esposa
   • Relaciones de uno a muchos : ejemplo de madre e hijos
   • Relaciones de varios a varios: ejemplo de estudiante y sujeto
2. Direccionalidad : no afecta el mapeo, pero marca la diferencia en cómo podemos acceder a los datos.
   • Relaciones unidireccionales : un campo de relación o propiedad que se refiere a la otra entidad.
   • Relaciones bidireccionales : cada entidad tiene un campo de relación o propiedad que se refiere a la otra entidad.

No hay ninguna diferencia práctica. Simplemente use la relación que tenga más sentido dada la forma en que ve su problema, como lo ilustra Devendra.

• --- Uno a muchos --- A Los padres pueden tener dos o más hijos.

• --- Muchos a uno --- Esos 3 niños pueden tener un solo padre.

  Ambos son similares. Esto se puede utilizar pertenece a la necesidad. Si desea encontrar hijos para padres en particular, puede optar por One-To-Many. De lo contrario, si quiere encontrar padres para un gemelo, puede elegir Many-To-One. Igualmente....,

one-to-many has parent class contiene n número de hijos, por lo que es un mapeo de colección.

muchos a uno tiene n número de hijos contiene un padre, por lo que es un mapeo de objetos