Разница между отношениями один-к-одному и один-ко-многим в базе данных - PullRequest
14 голосов
/ 20 января 2011

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

Но база данных не знает, правильно ли это соотношение один к одному или один ко многим?Взаимосвязи, которые я устанавливаю в ER-диаграмме, служат только для указания того, где должны быть внешние ключи при создании реальных таблиц?

Я не совсем понимаю идею взаимосвязей, хотя я прочитал много уроковоб этом.

Заранее спасибо.

Ответы [ 8 ]

17 голосов
/ 20 января 2011

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

Большая разницаС точки зрения структуры таблицы между один-к-одному и один-ко-многим в том, что в отношении один к одному возможно (но не обязательно) иметь двунаправленное отношение, то есть таблица A может иметь внешний ключ в таблице Bи таблица B может иметь внешний ключ в связанной записи в таблице A. Это невозможно при отношении «один ко многим».

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

5 голосов
/ 20 января 2011

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

3 голосов
/ 20 января 2011

Эквивалент уровня базы данных 1: 1 против 1: m имеет уникальный индекс для столбца внешнего ключа.Обратите внимание, что это будет работать только для 1: 1, а НЕ 1: 0..1, так как null учитывается при оценке уникальности.Для этого ограничения есть обходные пути, но это все на базовом уровне.

3 голосов
/ 20 января 2011

У меня проблемы с пониманием того, что является настоящим вопросом.

Ваш анализ по большей части правильный, в том смысле, что если у вас есть 2 таблицы, а table2 имеет внешний ключ к таблице 1, это может быть либо один к одному, либо много к одномуодин.

Ваше предложение «И в отношении« один ко многим »таблица содержит много внешних ключей».

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

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

1 голос
/ 25 ноября 2013

Точно так же, например, у продукта есть только один код продукта, так что это отношение один к одному ( product <-> ABC123 ), но клиент может приобрести более одного продукта, поэтому отношение «ко-многим» ( человек <- >>> продукт ).

1 голос
/ 20 января 2011

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

Теперь добавьте третью таблицу «города» и один из ваших информационных пунктов в город, в котором вы живете - это пример «один ко многим» (можно использовать один город, и его следует использовать для многих людей).

один-ко-многим / один-к-одному просто покажите, как взаимодействуют ваши таблицы. И все время, когда вы хотите «сохранить» строки / столбцы в таблице, не дублируя их, вы будете использовать отношение «один ко многим» с другой таблицей. Или многие ко многим :) 1005 *

0 голосов
/ 21 января 2011

Для таблиц A и B, если

  1. A и B имеют строгое отношение 1 к 1
  2. Для каждого экземпляра B всегда будет экземпляр A

Наилучший подход состоит в том, чтобы сделать первичный ключ B также внешним ключом, ссылающимся на A. Это также называется «наследованием таблиц на тип» и отношением «является».Есть и другие способы применения уникального внешнего ключа, но использование первичного ключа проясняет взаимосвязь в схеме и на диаграммах ER.

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

0 голосов
/ 20 января 2011

Предположим, у вас есть таблица с двумя атрибутами A и B. Если A - это ключ-кандидат, а B - нет, то отношение между A и B равно 1 для многих.Если и A, и B являются ключами-кандидатами, то соотношение составляет от 1 до 1.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...