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

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

Я не могу найти никакого «хорошего и простого для понимания» руководства по этой теме, кроме этой: SQL для начинающих: Часть 3 - Взаимосвязи с базами данных

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

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

Подробнее о типах отношений:

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

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

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

Пример:

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

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

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

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

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

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

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

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

id,name
1,Bill Smith
2,Jim Kenshaw

Затем, чтобы a Orderбыл связан с a 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(customer-id # 1) имеет 2 связанных с ним заказа: один на 12,34 доллара и один на 7,58 доллара. Jim Kenshaw(customer-id # 2) имеет только 1 заказ на 158,01 доллара.

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

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

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

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

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

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

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

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

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

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

пример

Две таблицы с одним отношением

SQL

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

• Внешний ключ в одной таблице ( Ссылки на сайтах ИНГ таблица)
  Ссылки
  на первичный ключе в других таблицах ( Ссылки на сайтах изд таблица)

• В терминах 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- многие к одному.
  • Но пусть это вас не смущает: для любой Barстроки есть только одна Fooстрока, на которую она ссылается.
• В SQL это все, что у нас есть. Это все, что нужно.

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

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

мощность

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

мощность

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

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

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

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

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

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

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

Решено "многие ко многим"

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

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

1. Кратность (термин ER: мощность)
   • Индивидуальные отношения : пример мужа и жены
   • Отношения один-ко-многим : пример матери и детей
   • Отношения "многие-ко-многим" : пример ученика и предмета
2. Направленность : не влияет на отображение, но влияет на то, как мы можем получить доступ к данным.
   • Однонаправленные отношения : поле или свойство отношения, которое относится к другому объекту.
   • Двунаправленные отношения : каждая сущность имеет поле или свойство отношения, которое относится к другой сущности.

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

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

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

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

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

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