Может ли внешний ключ быть пустым и / или дублированным?

Пожалуйста, уточните две вещи для меня:

1. Может ли внешний ключ быть пустым?
2. Может ли внешний ключ быть дублированным?

Насколько я знаю, NULLего нельзя использовать во внешних ключах, но в некоторых моих приложениях я могу вводить данные NULLкак в Oracle, так и в SQL Server, и не знаю почему.

Краткий ответ: Да, это может быть NULL или дубликат.

Я хочу объяснить, почему внешний ключ может быть нулевым или уникальным или не уникальным. Во-первых, помните, что внешний ключ просто требует, чтобы значение в этом поле сначала существовало в другой таблице (родительской таблице). Это все ФК по определению. Ноль по определению не является значением. Нуль означает, что мы еще не знаем, какова стоимость.

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

Является ли он уникальным или не уникальным, зависит от того, имеет ли таблица отношение «один-один» или «один-много» к родительской таблице. Теперь, если у вас есть отношение один к одному, возможно, что вы могли бы хранить все данные в одной таблице, но если таблица становится слишком широкой или если данные по другой теме (сотрудник - пример страхования @tbone дал например), то вы хотите отдельные таблицы с FK. Затем вы захотите сделать этот FK либо PK (который гарантирует уникальность), либо наложить на него уникальное ограничение.

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

1 - Да, хотя бы SQL Server 2000.

2 - Да, если это не UNIQUEограничение или связь с уникальным индексом.

Изо рта лошади:

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

Нет ограничений на внешний ключ

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

NOT NULL ограничение на внешний ключ

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

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

УНИКАЛЬНОЕ ограничение на внешний ключ

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

Эта модель устанавливает взаимно-однозначное отношение между родительским и внешним ключами, которое допускает неопределенные значения (нули) во внешнем ключе. Например, предположим, что в таблице сотрудников есть столбец с именем MEMBERNO, который ссылается на номер участника сотрудника в плане страхования компании. Кроме того, таблица INSURANCE имеет первичный ключ с именем MEMBERNO, а другие столбцы таблицы содержат соответствующую информацию, касающуюся страхового полиса сотрудника. MEMBERNO в таблице сотрудников должен быть как внешним ключом, так и уникальным ключом:

• Для обеспечения соблюдения правил ссылочной целостности между таблицами EMP_TAB и INSURANCE (ограничение FOREIGN KEY)

• Чтобы гарантировать, что каждый сотрудник имеет уникальный номер участника (ограничение UNIQUE)

УНИКАЛЬНЫЕ и НЕ НУЛЬНЫЕ ограничения на внешний ключ

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

Посмотри это:

Oracle 11g ссылка

Да, внешний ключ может быть нулевым, как сказано выше старшими программистами ... Я бы добавил еще один сценарий, когда внешний ключ должен быть нулевым .... предположим, у нас есть таблицы комментариев, изображений и видео в приложении, которое позволяет комментировать изображения и ролики. В таблице комментариев мы можем иметь два ForeignIs PicturesId и VideosId вместе с первичным Key CommentId. Поэтому, когда вы комментируете видео, потребуется только VideosId, а pictureId будет нулевым ... и если вы прокомментируете только изображение, потребуется PictureId, а VideosId будет нулевым ...

это зависит от того, какую роль это foreign keyиграет в ваших отношениях.

1. если это foreign keyтакже key attributeв вашем отношении, то это не может быть NULL
2. если это foreign keyнормальный атрибут в вашем отношении, то он может быть NULL.

Вот пример использования синтаксиса Oracle:
сначала давайте создадим таблицу COUNTRY

CREATE TABLE TBL_COUNTRY ( COUNTRY_ID VARCHAR2 (50) NOT NULL ) ;
ALTER TABLE TBL_COUNTRY ADD CONSTRAINT COUNTRY_PK PRIMARY KEY ( COUNTRY_ID ) ;

Создать таблицу ПРОВИНЦИЯ

CREATE TABLE TBL_PROVINCE(
PROVINCE_ID VARCHAR2 (50) NOT NULL ,
COUNTRY_ID  VARCHAR2 (50)
);
ALTER TABLE TBL_PROVINCE ADD CONSTRAINT PROVINCE_PK PRIMARY KEY ( PROVINCE_ID ) ;
ALTER TABLE TBL_PROVINCE ADD CONSTRAINT PROVINCE_COUNTRY_FK FOREIGN KEY ( COUNTRY_ID ) REFERENCES TBL_COUNTRY ( COUNTRY_ID ) ;

Это прекрасно работает в Oracle. Обратите внимание, что внешний ключ COUNTRY_ID во второй таблице не имеет "NOT NULL".

Теперь, чтобы вставить строку в таблицу PROVINCE, достаточно указать только PROVINCE_ID. Однако, если вы решили указать и COUNTRY_ID, он должен уже существовать в таблице COUNTRY.

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

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

Проще говоря, «неидентифицирующие» отношения между сущностями являются частью ER-модели и доступны в Microsoft Visio при разработке ER-диаграммы. Это необходимо для обеспечения количества элементов между сущностями типа «ноль или более нуля» или «ноль или единица». Обратите внимание на это «ноль» в количестве элементов вместо «один» в «один ко многим»

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

Так как существует возможность для одной записи объекта-A идентифицировать себя с записями другого объекта-B, поэтому в Entity-B должен быть столбец, чтобы иметь значение идентификатора записи объекта-B. Этот столбец может быть нулевым, если ни одна запись в Entity-A не идентифицирует запись (и), или объект (ы) в Entity-B.

В объектно-ориентированной (реальной) парадигме существуют ситуации, когда объект класса B не обязательно зависит (сильно связан) от объекта класса A в своем существовании, что означает, что класс B слабо связан с классом Такой, что класс А может «содержать» (сдерживать) объект класса А, в отличие от концепции объекта класса В, должен иметь (композицию) объект класса А для его (объекта класса). Б) создание.

С точки зрения SQL-запроса, вы можете запросить все записи в entity-B, которые являются "ненулевыми" для внешнего ключа, зарезервированного для Entity-B. Это приведет к тому, что все записи, имеющие определенное соответствующее значение для строк в Entity-A, в качестве альтернативы, все записи со значением Null будут теми записями, которые не имеют никаких записей в Entity-A в Entity-B.

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

Но ответ - все зависит от бизнеса.

Идея внешнего ключа основана на концепции ссылки на значение, которое уже существует в основной таблице. Вот почему он называется внешним ключом в другой таблице. Эта концепция называется ссылочной целостностью. Если внешний ключ объявлен как нулевое поле, это нарушит саму логику ссылочной целостности. На что это будет ссылаться? Это может относиться только к тому, что присутствует в основной таблице. Следовательно, я думаю, что было бы неправильно объявлять поле внешнего ключа пустым.

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