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

117

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

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

Zhaf
источник
1
Это идеальное объяснение: en.wikipedia.org/wiki/Many-to-many_(data_model)
Роберт Питт 05
@RobertPitt, какое отношение имеет статья "многие ко многим" к вопросу? Вы, вероятно, имели в виду en.wikipedia.org/wiki/One-to-many_(data_model)
TMG

Ответы:

111

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

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

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

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

Девендра Д. Чаван
источник
2
Боюсь, что сцен не устраивает! ( НЕ УВЕРЕН, НО ) я думаю, что порядок представляет собой зависимость! Не так ли ?? Например, пользователь для роли может быть от 1 ко многим, но не многие к одному, потому что нельзя получить ссылки на пользователя, который использует роль! Имеет ли это смысл?
Амануэль Нега
Может быть, отношения с базами данных сейчас?
fragorl
29

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

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

Пример:

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

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

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

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

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

В отношении « один ко многим» в локальной таблице есть одна строка, которая может быть связана со многими строками в другой таблице. В примере из 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.

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

Серый
источник
3
Общий случай называется зависимостью включения. Ограничение внешнего ключа является наиболее распространенным типом зависимости включения, но не все зависимости включения включают внешний ключ. Общий атрибут или атрибуты («ссылка») всегда существуют в обеих таблицах. С «одной» стороны эти атрибуты называются ключом-кандидатом. Со стороны «многих» они могут быть внешним ключом. Термины «один ко многим» или «многие к одному» могут применяться к любой зависимости включения, которая включает по крайней мере один ключ-кандидат, не обязательно подразумевая, какая сторона может быть необязательной.
nvogel
Интересный @sqlvogel. В Java все javax.persistence.OneToManyиначе, чем в ManyToOne. Вы говорите, что они синонимы или это зависит от реализации? Мой ответ неверен?
Gray
2
Речь идет о реляционных базах данных и SQL, а не о Java. Может, насчет Java вы правы.
nvogel
Я использовал это как пример @sqlvogel. Вы хотите сказать, что «один ко многим» и «многие к одному» являются синонимами?
Gray
2
Я говорю, что это два способа описания одних и тех же отношений, но с разных точек зрения. Точно так же, что «A является подмножеством B» означает то же самое, что «B является надмножеством A».
nvogel
4

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

nvogel
источник
1
Разумеется, разница есть как концептуально, так и сгенерированной схемой. См. Мой ответ: stackoverflow.com/a/37954280/179850
Серый
4
@Серый. Нет, нет. Ваш ответ не только неверен, он сбивает с толку новичков (задающих этот вопрос).
PerformanceDBA
4

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

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

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

собутыльник
источник
3

пример

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

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 есть только один тип отношений).

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

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

PerformanceDBA
источник
1
@Martijn Peters. Я могу отредактировать его в соответствии с кодексом поведения. Но вы также удалили (а) объяснение и (б) свидетельство фактов в действительности. Что мне с этим делать?
PerformanceDBA
3
Найдите другой способ выразить эти вещи, не прибегая к разглагольствованиям, обзывам и клевете на чей-либо интеллект или профессиональное поведение. Сосредоточьтесь на технологиях, а не на людях, которые могут ошибаться или нет.
Мартейн Питерс
2

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

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

  1. Кратность (термин ER: мощность)
    • Индивидуальные отношения : пример мужа и жены
    • Отношения один-ко-многим : пример матери и детей
    • Отношения "многие-ко-многим" : пример ученика и предмета
  2. Направленность : не влияет на отображение, но влияет на то, как мы можем получить доступ к данным.
    • Однонаправленные отношения : поле или свойство отношения, которое относится к другому объекту.
    • Двунаправленные отношения : каждая сущность имеет поле или свойство отношения, которое относится к другой сущности.
Premraj
источник
В реляционной базе данных нет «направленности». У каждого отношения есть два «конца»: Ссылка (ссылка на таблицу) и Ссылка (таблица, на которую делается ссылка). SQL / DML позволяет ссылаться на любую таблицу, как вы хотите ... с одной стороны ... с другой стороны ... с обеих сторон ... без сторон.
PerformanceDBA
0

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

Том Белл
источник
Разумеется, разница есть как концептуально, так и сгенерированной схемой. См. Мой ответ: stackoverflow.com/a/37954280/179850
Серый
3
@Серый. Нет, нет. Ваш ответ не только неверен, он сбивает с толку новичков (задающих этот вопрос).
PerformanceDBA
0
  • --- Один ко многим --- Родители могут иметь двух или более детей.
  • --- Многие к одному --- У этих трех детей могут быть одни родители.

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

Сэмюэл Х
источник
-6

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

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

чандра
источник
этот ответ хорош, и у вас есть дополнительная информация, не понимаю, почему он был отклонен, в однонаправленном контексте один ко многим и многие к одному не обеспечат одинаковое качество кода в зависимости от UX: если вам нужно получить набор данных, связанных поэтому один ко многим будет мудрее, если вам не нужен оператор выбора, где какое-то условие в порядке, потому что набор есть на карте, однако, если пользователю не нужно получать набор данных и он интересуется каждой строкой как уникальной желаемый экземпляр, так что многие к одному - более мудрый выбор
Мохаммед Хуссейн Талеб
Это может быть хороший ответ, но это не одно и то же: многие-к-одному имеют родительский класс, содержащий n детей, а один-ко-многим - много родительских классов для одного ребенка. В SQL это может не иметь значения, поскольку отношение «многие к одному» может быть всенаправленным, но в такой структуре, как Django, это серьезная проблема, поскольку нет отношения «один ко многим» и внешнего ключа, который имеет дело с отношением "многие к одному", естественно, работает только в одном направлении, это не может быть использовано таким же образом в обратном направлении.
iFunction