Может ли CK иметь FK, ссылающийся на CK в другой таблице?

Question

В качестве примера:

Department (**Dept**, Dept_name)  
Employee(**RegNo**, FirstName, LastName, BirthDate, Dept_fk, Salary, City)  

Dept_name - это CK таблицы отдела.

Может ли Dept_fk быть частью CK(Dept_fk, FirstName, LastName, Birthdate) в Employee, поскольку Dept_name не задано в качестве первичного ключа в таблице Department?

РЕДАКТИРОВАТЬ: я изменяю некоторые имена атрибутов, чтобы было легче понять. Dept_fk - это внешний ключ, ссылающийся на таблицу Dept in Department.

Answer 1

Два определения "CK (ключ-кандидат) данной таблицы":

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

Мы не можем определить CK таблицы без информации, необходимой для определения, которое мы используем. Например, все FD (функциональные зависимости), или каноническое покрытие FD, или все наборы столбцов, значения подстрок которых являются уникальными, и т. Д. Эта информация всегда может быть выражена без использования другой таблицы.

Мы можем выбрать один CK таблицы, чтобы вызвать ее " PK" (первичный ключ). ПК не имеют отношения к теории отношений. (Если вы используете метод ER, и у него есть правила относительно PKs против CK, то вы должны ссылаться и помечать его.)

Dept не может быть частью ключа-кандидата (например, Dept, FirstName, LastName, Birthdate) в таблице Employee, поскольку Dept не задан в качестве первичного ключа в таблице Department

Отдел не находится в Employee, поэтому он не может быть частью CK этого. Но если вы добавили его, был ли он CK, это не зависит от других таблиц.

Если вы спрашиваете, можете ли вы что-то сделать, исходя из различий между Dept и CK против PK в Department: PK всегда не имеют значения.

Если "Dept" являются опечатками для "Dept#": сам факт того, что Dept # является или не является PK таблицы Department, не имеет никакого отношения к CKs другой таблицы. Является ли это PK против CK, всегда не имеет значения.

Но могу ли я позвонить в Dept ключ-кандидат, зная, что Dept является ключом-кандидатом в таблице Department?

Это ЦК Департамента. Так что по-английски мы можем сказать, что это CK. Но быть CK - это быть CK конкретной таблицы.

Может быть, вы имеете в виду "могу ли я все еще позвонить в Dept a CK" сотрудника, просто зная… ". Только если вы покажете, что он один. И не зависит ли он от какой-либо другой таблицы.

(Может быть, вы должны называть некоторые вещи ФК в этом вопросе?)

PS Столбец может появляться в нескольких таблицах без FK между ними. ("Справочник" полезен только тогда, когда вы говорите о ФК.) В разных столбцах могут быть ФК между ними. FK существует тогда и только тогда, когда все значения вложенных строк в одном наборе столбцов появляются в другом ("ссылочном"). SQL FK должен идти только к суперключу (надмножеству CK), а не к CK. FK может быть из любого набора столбцов: FK является только (супер) ключом в ссылочной таблице. Изучите определения FD, superkey, CK, PK, FK (для CK или superkey).