Mapping many-to-many relationships: Is the primary key of the new junction (associative) relation typically a composite key formed from the primary keys of the two participating entities?

Difficulty: Easy

Correct Answer: Correct

Explanation:


Introduction / Context:
When mapping an M:N (many-to-many) relationship from an ER model to a relational schema, we create a new relation—often called a junction or associative table—that connects the two entity tables. The widely taught canonical design uses a composite primary key based on both entities’ primary keys.



Given Data / Assumptions:

  • Two entities A and B participate in an M:N relationship.
  • Each entity is mapped to its own relation with a primary key.
  • We seek a normalized design preserving all relationship instances without redundancy.



Concept / Approach:
The junction relation includes the primary key of A (as a foreign key) and the primary key of B (as a foreign key). Declaring both together as the junction’s composite primary key ensures each pair appears at most once, preventing duplicates and preserving the relationship’s multiplicity.



Step-by-Step Solution:
Map A and B to separate relations with their PKs (say a_id and b_id).Create relation A_B(a_id, b_id, ...relationship attributes...).Declare a_id references A(a_id) and b_id references B(b_id).Declare PRIMARY KEY (a_id, b_id) in A_B.Add additional attributes to A_B if the relationship carries its own data (e.g., created_at, role).



Verification / Alternative check:
Try inserting duplicate pairs into the junction table; the composite primary key prevents duplicates, which confirms correct design.



Why Other Options Are Wrong:
Incorrect: contradicts standard normalization practice.True only without surrogates: even when adding a surrogate key, the natural composite key is typically enforced via a unique constraint.Only in denormalized designs: the composite key approach is actually the normalized standard.



Common Pitfalls:
Adding only one foreign key to the junction, which loses M:N semantics; omitting a unique constraint when introducing a surrogate key, enabling duplicates.



Final Answer:
Correct

More Questions from Logical Database Design

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion