Иностранные ключи против частичных ключей и их E-R представления

Question

У меня проблемы с пониманием разницы между частичными ключами / слабыми объектами и внешними ключами.Я чувствую себя идиотом из-за неспособности понять это.

Насколько я понимаю:

Weak Entity: An entity that is dependent on another entity.
Partial Key: Specifies a key that that is only partially unique.  Used for weak entities.

vs

Foreign Key: A key that is used to establish and enforce a relation between data in different tables.

Не похоже, что это одно и то же, но яЯ с трудом различаю их использование.

Возьмите [очень] простой пример:

We have employees specified by an empid.  We also have children specified by name.  A
child is uniquely specified by name when the parent (employee) is known.

Будет ли дочерняя сущность слабой личностью, где частичный ключ - это имя (частично уникальное)?Или я должен использовать внешний ключ, потому что я пытаюсь установить и применить отношения между работником и ребенком?Я чувствую, что могу оправдать оба, но я также чувствую, что что-то здесь упускаю.Любое понимание приветствуется, и я прошу прощения за глупые вопросы.

Answer 1

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

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

2. Использование терминологии IDEF1X. Идентификационная связь - это та, в которой FK (родительский Pk в дочернем) также используется для формирования дочернего PK. Он уникален в родительском, но не уникален в дочернем, вам нужно добавить столбец, чтобы сделать его уникальным. Отсюда и глупый термин «Частичный ключ». Либо это ключ (уникальный), либо это не ключ; понятие «частичный ключ» слишком глупо, чтобы обдумывать.

3. В должным образом нормализованной и соответствующей стандартам базе данных будет очень мало независимых субъектов. Все остальное будет зависеть от какой-либо независимой организации. Такие сущности не являются «слабыми», за исключением того, что они не могут существовать без сущности, от которой они зависят.

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

   Использовать стандартные термины.

4. Но чтобы ответить на ваш явный вопрос:

   • при условии, что сотрудник является "сильным" и имеет первичный ключ (EmployeeId)
   • тогда «слабой» таблице EmployeeChild потребуется FK (EmployeeId) для идентификации сотрудника
   • , который был бы идеальным первым компонентом таблицы EmployeeChild, восхитительный «частичный ключ»
   • , к которому вы можете добавить ChildNo, чтобы сделать обычный Реляционный Первичный Ключ
   • но на самом деле это не "частично", потому что это полный Первичный Ключ Родителя.

Читатели, не знакомые со Стандартом моделирования реляционных баз данных, могут найти ▶ IDEF1X Notation ◀ полезными.

Answer 2

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

Частичный ключ означает только часть ключа - некоторое правильное подмножество ключевых атрибутов.

В вашем примере, если первичным ключом Child был (Empid, ChildName) с Empid в качестве внешнего ключа, ссылающегося на Employee, то Child является слабым объектом. Если бы Empid не был частью первичного ключа, тогда Child был бы сильной сущностью.

Стоит помнить, что слабое / сильное различие является чисто концепцией ER-моделирования. В терминах реляционных баз данных это не имеет большого значения. В частности, реляционная модель не проводит различий между первичными ключами и другими потенциальными ключами, поэтому для всех практических целей не имеет значения выделять атрибуты первичного ключа как «особый» случай, когда они ссылаются на другие таблицы. 1007 *

Answer 3

Предположим, существует связь между двумя сотрудниками организации и иждивенцами. Сотрудники - сильная организация, а Зависимые - слабая. У иждивенцев есть атрибуты Имя, Возраст, Отношение и Сотрудники имеют атрибуты E_Id (первичный ключ) и E_Name. Затем для удовлетворения отношения мы используем внешний ключ E_Id в таблице Dependents, которая ссылается на таблицу E_Id of Employees. Но используя только ключ foregin, мы не можем однозначно идентифицировать кортежи в таблице «Зависимости», нам необходим атрибут Name (частичный ключ), чтобы также уникально идентифицировать кортежи. Пример: предположим, что таблица «Зависимые» имеет значения в поле «Имя»: «Рахул», «Акшат», «Рахул», тогда она не будет уникальной, и когда она объединится с «E_Id», мы сможем идентифицировать ее уникально.

E_Id с именем действует как первичный ключ в таблице зависимостей.