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

StackOverflow https://stackoverflow.com/questions/4601703

Вопрос

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

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

Это было полезно?

Решение

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

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

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

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

Другие советы

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

Большинство отношений между таблицами являются однозначными.

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

SQL.

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

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

  • В условиях SQL, Барные ссылки 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 это все, что у нас есть. Это все, что нужно.

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

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

Кардинальность

Cardinality первым объявляется в модели данных, что означает логичную и физическую (намерение), а затем в реализации (намерение реализовано).

Кардинальность

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

От одного до однозначного
Ты нуждаешься в Сделка Обеспечить принуждение того на ссылке на ссылке.

Один до нуля до одного
Вам нужно Bar:

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

Один к одному
Ты нуждаешься в Сделка Обеспечить принуждение того на ссылке на ссылке.

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

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

Многозначно решено

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

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

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

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

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

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

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

один ко многим Имеет родительский класс в количестве детей, так что это сопоставление коллекции.

много до одного имеет n количество детей содержит один родитель, так что это отображение объекта

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top