Evaluating ER-to-Relational Mapping Statements

In ER modeling, the question asks which statement is false among four standard claims about weak entities, partial keys, many-to-many relationships, and candidate keys. The correct answer is that statement (iv) is false: not every relation generated from an ER model has a single candidate key.2

Statements (i), (ii), and (iii) are standard ER-to-relational mapping rules. A weak entity is existence-dependent on an identifying strong entity, and its relation typically uses the owner’s primary key together with the weak entity’s partial key.2 Likewise, a binary many-to-many relationship is normally mapped into a separate relation whose attributes include the primary keys of the participating entity types, often forming a composite key.2 However, a generated relation can have multiple candidate keys, even though one of them is chosen as the primary key.

Footnotes

1. Relational Database Design by ER- and EERR-to-Relational Mapping - Standard ER-to-relational mapping rules for weak entities and binary $M:N$ relationships. ↩ ↩² ↩³

2. Chapter 6. Entity-Relationship Modelling - Explains candidate keys, weak entities, and relational implementation concepts. ↩ ↩²

3. Weak Entity Set in ER diagrams - GeeksforGeeks - Summarizes weak entity dependence and partial-key behavior. ↩

4. Mapping an ERD to a Relational Database – Relational Databases - Describes why binary many-to-many relationships are implemented as separate relations. ↩

To evaluate the options rigorously, it helps to distinguish between a relation’s primary key and its full set of candidate keys. During ER-to-relational mapping, designers often choose one key as the primary key, but this does not eliminate other possible unique identifiers.2 For example, an EMPLOYEE relation might use EmployeeID as primary key while NationalID also remains a candidate key if it is unique.

This distinction is exactly why statement (iv) fails. The phrase “always has a single candidate key” is too strong. A relation can have one, two, or several candidate keys depending on the semantics and constraints of the data model.2

A useful formal reminder is:

$$\text{Primary Key} \in \{\text{Candidate Keys}\}$$

but in general,

$$|\{\text{Candidate Keys}\}| \ge 1$$

and not necessarily

$$|\{\text{Candidate Keys}\}| = 1$$

So the falsehood comes from confusing “has a chosen primary key” with “has only one candidate key.”

Footnotes

1. Chapter 6. Entity-Relationship Modelling - Explains candidate keys, weak entities, and relational implementation concepts. ↩ ↩² ↩³ ↩⁴

2. Mapping ER Diagram to a Relational Database - Notes that when more than one candidate key exists, one is chosen as the primary key. ↩ ↩²

Statement-by-statement analysis

This means the correct exam-style response is:

$$\boxed{(iv)\text{ is false}}$$

The key mapping algorithm idea is that relational design preserves identification constraints, but it does not force uniqueness of candidate-key count across all resulting relations.2

Footnotes

1. Weak Entity Set in ER diagrams - GeeksforGeeks - Summarizes weak entity dependence and partial-key behavior. ↩ ↩²

2. ER-to-Relational Mapping Algorithm - Concise mapping algorithm for strong entities, weak entities, and many-to-many relationships. ↩

3. Relational Database Design by ER- and EERR-to-Relational Mapping - Standard ER-to-relational mapping rules for weak entities and binary $M:N$ relationships. ↩ ↩² ↩³

4. Mapping an ERD to a Relational Database – Relational Databases - Describes why binary many-to-many relationships are implemented as separate relations. ↩

5. Chapter 6. Entity-Relationship Modelling - Explains candidate keys, weak entities, and relational implementation concepts. ↩ ↩²

6. Mapping ER Diagram to a Relational Database - Notes that when more than one candidate key exists, one is chosen as the primary key. ↩

Compact conceptual example

Consider a weak entity Dependent owned by Employee.

• Employee(EmployeeID, Name, NationalID)
• Dependent(EmployeeID, DependentName, BirthDate)

Here, DependentName may act as a discriminator under a given employee, so the weak relation key becomes:

$$(\text{EmployeeID}, \text{DependentName})$$

This supports statements (i) and (ii).2

Now consider a many-to-many relationship WorksOn between Employee and Project:

• WorksOn(EmployeeID, ProjectID, Hours)

This is the standard separate relation created from a binary $M:N$ relationship, confirming statement (iii).2

Finally, in Employee, if both EmployeeID and NationalID are unique and minimal, then the relation has at least two candidate keys:

$$\{\text{EmployeeID}\}, \{\text{NationalID}\}$$

Hence statement (iv) is false.2

Footnotes

1. Relational Database Design by ER- and EERR-to-Relational Mapping - Standard ER-to-relational mapping rules for weak entities and binary $M:N$ relationships. ↩ ↩²

2. Weak Entity Set in ER diagrams - GeeksforGeeks - Summarizes weak entity dependence and partial-key behavior. ↩

3. Mapping an ERD to a Relational Database – Relational Databases - Describes why binary many-to-many relationships are implemented as separate relations. ↩

4. Chapter 6. Entity-Relationship Modelling - Explains candidate keys, weak entities, and relational implementation concepts. ↩

5. Mapping ER Diagram to a Relational Database - Notes that when more than one candidate key exists, one is chosen as the primary key. ↩