Mapping between weak and strong entity

Question

Consider the er diagram.

Q1:

The dependants table will have a serial number column as a surrogate key for the sake of uniqueness of rows in this table. But we are not including this surrogate key column as an attribute in er diagram since its not an attribute of dependants. Right? YES or NO?

Q2:

Okay now my second question is that in order to uniquely identify that which dependant is owned by which employee, we will use a combination of Employee SSN and Dependants Name. Pretty good. But my confusion here is that how are we gonna find that out? I mean we are not storing any kind of dependants info in employee table and i know that doing so is illogical. but how to find that which dependant belongs to which employee? If possible, please write down a sql query regarding this so my confusion regarding this clears out.

Q3:

In dependants table, primary key would be serial Number but for searching that which dependant belongs to which employee, we will use a unique combination of employee id and dependant name.

I pretty confuse at all of this. I do know what weak and strong entities are and that they have identifying relationship between them but i am pretty clueless at above questions. And please answer questions by numbering them to their respective question number. Thanks:)

Answer 1

Q1:

The diagram shows Dependent as a weak entity identified by a combination of Ssn from Employee and Dependent's own Name. However, if you introduce a surrogate key, Dependent will become a strong entity in a regular (non-identifying) relationship with Employee.

A surrogate key is an attribute of the entity it identifies (it's a mapping from an entity set to a value set) and I would show it in the diagram in the same way other key attributes (like Ssn) are shown.

Q2:

A weak entity relation is implemented by incorporating the identifying relation. This means Dependent as shown in the diagram would be implemented as:

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

Including the Employee_Ssn allows us to join Dependent to Employee in queries, e.g.

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

Q3:

Once you add a surrogate key, Dependent becomes a strong entity:

and can be implemented as:

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

to which you can add a unique constraint on (Employee_Ssn, Name) as an integrity constraint and for efficient queries, but this doesn't affect the diagram.