Разница между отношениями "один ко многим" и "многие к одному"

Да, наоборот. Это зависит от того, на какой стороне отношений присутствует сущность.

Например, если один отдел может нанять нескольких сотрудников, то отношения между отделами и сотрудниками являются отношениями один ко многим (в одном отделе работает много сотрудников), в то время как отношения сотрудника с отделом - многие к одному (многие сотрудники работают в один отдел).

Дополнительная информация о типах отношений:

Отношения с базами данных - IBM DB2 документация

На этой странице о терминологии базы данных

Большинство отношений между таблицами - один ко многим.

Пример:

• Одна область может быть местом обитания многих читателей.
• У одного читателя может быть много подписок.
• На одну газету может быть подписано несколько человек.

Отношение «многие к одному» аналогично отношению «один ко многим», но с другой точки зрения.

• Многие читатели живут в одном районе.
• Многие подписки могут принадлежать одному и тому же читателю.
• Многие подписки идут на одну и ту же газету.

В чем реальная разница между отношениями «один ко многим» и «многие к одному»?

Между этими терминами существуют концептуальные различия, которые должны помочь вам визуализировать данные, а также возможные различия в сгенерированной схеме, которые следует полностью понять. В основном разница заключается в перспективе.

В отношении один-ко-многим в локальной таблице есть одна строка, которая может быть связана со многими строками в другой таблице. В примере из SQL для начинающих, один Customer может быть связан со многими Order.

В противоположном отношении многие-к-одному в локальной таблице может быть много строк, связанных с одной строкой в ​​другой таблице. В нашем примере многие Order могут быть связаны с одним Customer. Это концептуальное различие важно для ментального представления.

Кроме того, схема, которая поддерживает взаимосвязь, может быть по-разному представлена ​​в таблицах Customer и Order. Например, если у клиента есть столбцы id и name:

id,name
1,Bill Smith
2,Jim Kenshaw

Затем, чтобы Order был связан с Customer, многие реализации SQL добавляют в Order таблицу столбец, в котором хранится id связанного Customer (в этой схеме customer_id:

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

В приведенных выше строках данных, если мы посмотрим на столбец customer_id id, мы увидим, что Bill Smith (идентификатор клиента # 1) имеет 2 связанных с ним заказа: один на 12,34 доллара и один на 7,58 доллара. Jim Kenshaw (идентификатор клиента №2) имеет только 1 заказ на сумму 158,01 доллара США.

Важно понимать, что обычно отношение «один ко многим» фактически не добавляет столбцов в таблицу, которая является «единицей». Customer не имеет дополнительных столбцов, описывающих связь с Order. Фактически Customer может также иметь отношение "один ко многим" с таблицами ShippingAddress и SalesCall, но при этом не иметь дополнительных столбцов, добавленных в таблицу Customer.

Однако для описания отношения «многие к одному» часто в таблицу «многие» добавляется столбец id, который является внешним ключом для таблицы «один» - в этом случае столбец customer_id добавляется к таблице «многие». Order. Связанному заказу № 10 на сумму $ 12,34 до Bill Smith, мы назначаем столбец customer_id идентификатору 1 Bill Smith.

Однако также возможно наличие другой таблицы, описывающей отношения Customer и Order, так что в таблицу Order не нужно добавлять никаких дополнительных полей. Вместо добавления поля customer_id в таблицу Order может быть таблица Customer_Order, содержащая ключи как для Customer, так и для Order.

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

В этом случае один-ко-многим и многие-к-одному все концептуально, поскольку между ними нет изменений схемы. Какой механизм зависит от вашей схемы и реализации SQL.

Надеюсь это поможет.

SQL

В SQL существует только один вид отношений, он называется Ссылка. (Ваш интерфейс может делать полезные или запутанные вещи [например, в некоторых ответах], но это другая история.)

• Внешний ключ в одной таблице (справочная таблица)
  Ссылки
  a Первичный ключ в другой таблице (ссылочная ed таблица)

• С точки зрения SQL, Bar указывает на Foo
  Не наоборот.

  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
      )
  

• Поскольку Foo.Foo является первичным ключом, он уникален, существует только одна строка для любого заданного значения Foo.

• Поскольку Bar.Foo является ссылкой, внешним ключом и для него нет уникального индекса, может быть много строк для любого заданного значения Foo.

• Следовательно, отношение Foo::Bar - "один ко многим".

• Теперь вы можете воспринимать (смотреть на) отношения с другой стороны, Bar::Foo - это многие к одному

  • But do not let that confuse you: for any one Bar row, there is just one Foo row that it References

• В SQL это все, что у нас есть. Это все, что нужно.

В чем разница между отношениями «один ко многим» и «многие к одному»?

Есть только одно отношение, поэтому нет никакой разницы. Восприятие (с одного или другого конца) или чтение в обратном направлении не меняют отношения.

Мощность

Мощность сначала объявляется в модели данных, что означает логическое и физическое (намерение), а затем в реализации (реализованное намерение).

От одного к нулю ко многим
В SQL это все, что требуется.

Один к одному ко многим
Вам понадобится Транзакция, чтобы применить транзакцию в таблице ссылок.

Один к нулю к одному
Вам нужно Bar:

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

Один к одному
Вам потребуется транзакция, чтобы применить транзакцию в таблице ссылок.

Многие ко многим

На физическом уровне такого нет (напомним, в SQL есть только один тип отношения).

На ранних логических уровнях во время упражнения по моделированию удобно нарисовать такое отношение. Прежде чем модель приблизится к реализации, лучше использовать только те вещи, которые могут существовать. Такое отношение разрешается путем реализации ассоциативной таблицы на физическом уровне [DDL].

Нет никакой разницы. Это просто вопрос языка и предпочтений относительно того, как вы описываете отношения.

Один-ко-многим и многие-к-одному похожи по множественности, но не по аспекту (т.е.направленности).

Сопоставление связей между классами сущностей и связей между таблицами. Есть две категории отношений:

1. Кратность (термин ER: количество элементов)

• Индивидуальные отношения (сокращенно 1: 1): пример мужа и жены
• Отношения "один ко многим" (сокращенно 1: N): пример "Мать и дети"
• Отношения "многие ко многим" (сокращенно M: N): пример ученика и предмет

2. Направленность: не влияет на отображение, но влияет на то, как мы можем получить доступ к данным.

• Однонаправленные отношения: поле или свойство отношения, которое относится к другой сущности.
• Двунаправленные отношения. Каждая сущность имеет поле или свойство отношения, которое ссылается на другую сущность.

Ответ на ваш первый вопрос: оба похожи,

Ответ на ваш второй вопрос: один-ко-многим -> МУЖЧИНА (таблица МУЖЧИНА) может иметь более одной жены (ЖЕНСКАЯ таблица) многие-к-одному -> более одной женщины вышли замуж за одного МУЖЧИНА.

Теперь, если вы хотите связать это отношение с двумя таблицами MAN и WOMEN, одна строка таблицы MAN может иметь много связей со строками в таблице WOMEN. надеюсь, это ясно.

Это отличный вопрос, по моему опыту, в диаграммах ERD и реляционных базах данных подразумевается направление. В РСУБД вы всегда определяете отношения «многие-к-одному» (тривиальный случай «Один-к-одному»). Многосторонняя сторона отношений, также известная как дочерние элементы, ссылается на одну сторону, также известную как родитель, и вы реализуете это с помощью ограничения внешнего ключа. С технической точки зрения вам нужно получить доступ к индексу, получить запись первичного ключа на стороне One, а затем посетить эту запись, чтобы получить дополнительную информацию.

Вы не можете сделать это наоборот, если мы не говорим об объектно-реляционных СУБД, таких как Postgres, Intersystems Cache и т. Д. Эти СУБД позволяют вам определять двунаправленную связь между двумя объектами (таблицами). В этом случае доступ к записям осуществляется наоборот, то есть One - To - ›Many достигается за счет использования массива ссылок (дочерних элементов). В ORM у вас есть классы, которые ссылаются друг на друга так же, как мы описали здесь.

ВНИМАНИЕ: Большинство СУБД на ИТ-рынке НЕ являются системами управления реляционными базами данных в строгом смысле слова, подумайте о нулевых значениях, дублированных записях и т. Д., Многие из этих разрешенных функций нарушают определение того, что такое отношение.

Практической разницы нет. Просто используйте отношения, которые имеют наибольший смысл с учетом того, как вы видите свою проблему, как проиллюстрировал Девендра.

Отношения «один ко многим» и «многие к одному» говорят об одних и тех же логических отношениях, например, у владельца может быть много домов, но у дома может быть только один владелец.

Итак, в этом примере владелец - один, а дома - множество. У каждого дома всегда есть owner_id (например, внешний ключ) в качестве дополнительного столбца.

Разница в реализации между этими двумя вариантами заключается в том, какая таблица определяет взаимосвязь. В «Один ко многим» отношения определяются именно владельцем. Например, owner1.homes перечисляет все дома с идентификатором owner_id owner1. В Many-to-One отношение определяется домом. Например, home1.owner перечисляет owner1's owner_id.

На самом деле я не знаю, в каком случае вы бы реализовали схему «многие к одному», потому что это кажется немного избыточным, поскольку вы уже знаете owner_id. Возможно, это связано с чистотой удалений и изменений.

• --- Один ко многим --- Родитель может иметь двух или более детей.

• --- Многие к одному --- У этих трех детей может быть один родитель

  Оба похожи. Это можно использовать по мере необходимости. Если вы хотите найти детей для определенного родителя, вы можете выбрать «Один ко многим». Или, если хотите найти родителей для близнецов, вы можете пойти с Many-To-One.

Самым простым объяснением этих отношений я могу дать evendra D. Chavan'sanswer.

Использование отношений отдела и сотрудников

В отделе может быть несколько сотрудников, поэтому со стороны сотрудников это one-to-many отношения, а со стороны отдела это many-to-one relationship

Но если сотрудник может принадлежать более чем к одному отделу, мы также можем сказать со стороны сотрудника, что теперь он many, а не one, поэтому отношение становится many-to-many

Проще говоря, можно сказать, что мы можем заявить, что отношения many-to-many, если one-to-many можно рассматривать с обеих сторон, то есть если;

• один сотрудник может принадлежать к нескольким отделам (one-to-many)
• в одном отделе может быть много сотрудников (one-to-many)

один-ко-многим имеет родительский класс, содержащий n дочерних элементов, поэтому это отображение коллекции.

many-to-one имеет n дочерних элементов, содержит одного родительского элемента, поэтому это сопоставление объектов