Сопоставление между слабым и сильным объектом

Question

Рассмотрите схему er.

1:

В таблице иждивенцев будет иметь серийный номер столбца в качестве суррогатного ключа ради уникальности строк в этой таблице. Но мы не включаем этот суррогатный ключевой столбец как атрибут в диаграмму er, поскольку это не атрибут иждивенцев. Правильно? ДА или НЕТ?

Q2:

Хорошо, теперь мой второй вопрос заключается в том, что для того, чтобы однозначно идентифицировать то, что зависимый принадлежит какой сотрудник, мы будем использовать комбинацию Сотрудника ССН и Зависимые Имя. Довольно хорошо. Но мое замешательство здесь в том, что как мы это узнаем? Я имею в виду, что мы не храним информацию о зависимых лицах в таблице сотрудников, и я знаю, что это нелогично. но как найти то, что зависит от какого сотрудника? Если возможно, напишите sql-запрос относительно этого, так что моя путаница в отношении этого проясняется.

Q3:

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

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

Answer 1

Q1:

Диаграмма показывает Dependent как слабые идентифицированную комбинацией Ssn из Employee и Dependent «s собственного Name. Однако, если вы вводите суррогатный ключ, Dependent станет сильным сущностью в регулярной (неидентифицирующей) связи с Employee.

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

Q2:

слабое отношение сущностей реализуется путем включения идентифицирующей связи. Это означает, что Dependent, как показано на схеме будет осуществляться следующим образом:

Dependent (Employee_Ssn PK/FK, Name PK, Sex, Birth_date, Relationship)

В том числе Employee_Ssn позволяет присоединиться к DependentEmployee в запросах, например

SELECT Employee.*, Dependent.* 
FROM Employee 
INNER JOIN Dependent ON Employee.Ssn = Dependent.Employee_Ssn 

Q3:

После добавления суррогатный ключ, Dependent становится сильным лицом:

и могут быть реализованы в виде:

Dependent (Id PK, Employee_Ssn FK, Name, Sex, Birth_date, Relationship)

которому вы можете добавить уникальное ограничение на (Employee_Ssn, Name) в качестве ограничения целостности и для эффективных запросов, но это не влияет на диаграмму.