Primary key placement in one-to-one (1:1) relationships:\n“In a 1:1 relationship, the primary key placement is arbitrary.”\nEvaluate this statement with respect to optionality and design practice.

Difficulty: Easy

Correct Answer: Incorrect

Explanation:


Introduction / Context:
In a 1:1 relationship, each row in table A matches at most one row in table B and vice versa. While it may seem that key placement is arbitrary, good modeling ties the foreign key choice to business semantics and optionality (whether either side can exist without the other).



Given Data / Assumptions:

  • Two entities A and B with a one-to-one relationship.
  • Optionality may be mandatory or optional on either side (for example, every Person has exactly one Passport versus some Persons have a Passport).
  • Goal: enforce integrity and support efficient access.


Concept / Approach:
If one side is optional, place the foreign key in the optional table and often make it both FOREIGN KEY and PRIMARY KEY (or UNIQUE) to enforce 1:1. If both sides are mandatory, you still choose the table that logically “depends on” the other or consolidate them into one table if separation brings no benefit. Arbitrary placement risks awkward insertion order, unnecessary NULLs, and harder enforcement of optionality. Therefore, primary key/foreign key decisions are guided by semantics, not caprice.



Step-by-Step Solution:

If B is optional, add B.pk = A.pk, declare B.pk as both PRIMARY KEY and FOREIGN KEY referencing A.pk.This ensures at most one B per A and prevents B rows without A.If both mandatory, consider merging tables or choose based on lifecycle (which is created first) and update patterns.Conclusion: placement follows optionality/lifecycle, not arbitrary choice.


Verification / Alternative check:
Attempt to model “optional” with the foreign key on the mandatory side; you will end up with NULLs or a schema that allows invalid states.



Why Other Options Are Wrong:

  • Calling it “correct” ignores optionality and lifecycle considerations.
  • Surrogate keys and physical storage do not override modeling principles.
  • Even when both sides are mandatory, “arbitrary” is poor guidance; design should be justified.


Common Pitfalls:
Duplicating keys on both sides; not enforcing uniqueness; splitting a single conceptual entity into two tables without a real need.



Final Answer:
Incorrect

More Questions from Data Models into Database Designs

Discussion & Comments

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