Разница между отношениями "один-к-одному" и "один ко многим" в базе данных

Ответ 1

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

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

Индивидуальные отношения связывают одну запись в одной таблице с одной записью в другой таблице. Связывание "один ко многим" связывает одну запись в одной таблице со многими записями в другой таблице.

Ответ 2

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

Ответ 3

Мне трудно понять, каков фактический вопрос.

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

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

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

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

Ответ 4

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

Ответ 5

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

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

one-to-many/one-to-one просто показывают, как взаимодействуют ваши таблицы. И все время вы хотите "сохранить" строки/столбцы в таблице, не дублируя их, вы будете использовать отношение "один ко многим" с другой таблицей. Или много-ко-многим:)

Ответ 6

Аналогично, например, продукт имеет только один код продукта, поэтому он имеет отношение один к одному (продукт ↔ ABC123), но клиент может приобрести более одного продукта, поэтому это отношения "один ко многим" ( person ↔ → product).

Ответ 7

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

Ответ 8

Приведенные таблицы A и B, если

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

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

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