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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

Пример:

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

Отношение "многие к одному" такое же, как отношение "один ко многим", но с другой точки зрения.

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

Ответ 3

Какова реальная разница между отношениями один-ко-многим и многие-к-одному?

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

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

В противоположном отношении " многие к одному" в локальной таблице может быть много строк, связанных с одной строкой в другой таблице. В нашем примере много 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, мы увидим, что с Bill Smith (идентификатор клиента № 1) связано 2 заказа: один на 12,34 доллара и один на 7,58 доллара. Jim Kenshaw (идентификатор клиента № 2) только 1 заказ на 158,01 $.

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

Однако для описания отношения "многие к одному" часто в таблицу "многие" добавляется столбец id который является внешним ключом к таблице "один" - в этом случае столбец customer_id добавляется в таблицу "многие". Order Для связанного с Bill Smith заказа № 10 за 12,34 доллара США мы присваиваем столбец 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.

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

Ответ 4

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

Ответ на ваш второй вопрос: один-ко-многим → MAN (таблица MAN) может иметь более одной жены (таблица WOMEN) много-к-одному → более одной женщины вышли замуж за одного мужчины.

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

пример

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

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

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

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

Ответ 8

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

Ответ 9

  • ---One - Many--- Родители могут иметь двух или более детей.

  • ---Many - one--- Эти 3 ребенка могут иметь одного родителя.

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

Ответ 10

Давайте возьмем первый пример: отношение клиента к еде:

Отношение клиент к еде - один ко многим. Позвольте мне объяснить, почему: во-первых, когда мы говорим об отношении, мы ссылаемся на строки (то есть: на экземпляр сущности, то есть на строку в таблице сущностей, такой как таблица Customer или таблица Meal, и т.д..)

Таким образом, экземпляр Meal, например экземпляр с (Meal_ID = 100), не может быть заказан двумя разными экземплярами Customer (логически говоря, еда не может быть продана и доставлена до Customer_ID = 10, а затем иметь тот же экземпляр с Meal_ID = 100 быть доставлено другому клиенту, т.е. другому экземпляру customer_ID = 11.

Тем не менее, хорошим примером взаимоотношений "многие ко многим" могут быть отношения между студентами и курсами Я объясню ниже:

'Adam', 'Sara' и 'Bob' могут взять один и тот же экземпляр курса у сущности Course (course_ID = 101, course_name = 'Intro to CS'), а также курс 'Intro to CS' и курс 'Algorithms' могут быть взятым тем же клиентским экземпляром 'Адам'.

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

Ответ 11

Родительский класс one-to-many содержит n дочерних элементов, поэтому он является отображением коллекции.

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