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

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

Как я понимаю:

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.

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


relational-database entity-relationship
person prelic    schedule 31.01.2011    source источник

Ответы (3)


arrow_upward
13
arrow_downward

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

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

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

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

person nvogel    schedule 02.02.2011

arrow_upward
13
arrow_downward

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

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

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

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

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

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

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

    • assuming that Employee is "strong" and has a Primary Key (EmployeeId)
    • тогда "слабой" таблице EmployeeChild потребуется FK (EmployeeId) для идентификации сотрудника.
    • который был бы идеальным первым компонентом таблицы EmployeeChild, очаровательным «частичным ключом»
    • к которому вы можете добавить ChildNo, чтобы сделать обычный реляционный первичный ключ
    • но на самом деле это не «частичный», потому что это полный первичный ключ родителя.

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

person PerformanceDBA    schedule 03.02.2011
comment
голосуйте за отличный ответ, но какой источник следует использовать вместо этих 30-летних книг по СУБД? - person Govinda Sakhare; 26.11.2016

arrow_upward
1
arrow_downward

Предположим, что существует отношение между двумя сущностями «Сотрудники» и «Иждивенцы». Сотрудники — сильная сущность, а иждивенцы — слабая сущность. У зависимых есть атрибуты Name, Age, Relation, а у сотрудников есть атрибуты E_Id (первичный ключ) и E_Name. Затем, чтобы удовлетворить отношение, мы используем внешний ключ E_Id в таблице Dependents, который ссылается на таблицу E_Id сотрудников. Но, используя только внешний ключ, мы не можем однозначно идентифицировать кортежи в таблице Dependents, нам требуется атрибут Name (частичный ключ) также для уникальной идентификации кортежей. Пример: предположим, что в таблице Dependents в имени есть значения Rahul, Akshat, Rahul, тогда она не будет уникальной, и когда она объединяется с E_Id, мы можем идентифицировать ее однозначно.

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

person Rahul Singh    schedule 15.06.2019