Denormalization choice for 1-to-1 relationships If a denormalization situation exists with a one-to-one (1:1) binary relationship between two entities, the recommended physical design is to:

Introduction / Context:
Normalization reduces redundancy; denormalization re-introduces some redundancy or merges entities for performance or simplicity. With a strict 1:1 relationship, a common pragmatic choice is to collapse the entities into a single table to eliminate constant joins and simplify access paths.

Given Data / Assumptions:

• Every row in entity A corresponds to exactly one row in entity B.
• They are frequently queried together.
• Security/optional columns do not require strict separation.

Concept / Approach:

When 1:1 holds and access is co-located, merging eliminates joins and foreign keys. You still enforce constraints with unique keys and CHECKs. If some columns are optional or rarely used, vertical partitioning may be a viable alternative, but the core denormalized design is a single relation.

Step-by-Step Solution:

Verification / Alternative check:

Physical design texts recommend merging 1:1 entities when joins add overhead without adding information content, provided governance needs allow it.

Why Other Options Are Wrong:

• Two or more relations add joins without benefit for strict 1:1.
• Bridge tables are for many-to-many, not 1:1.
• Four relations/heap storage are unjustified and harmful to integrity.

Common Pitfalls:

• Merging prematurely when 1:1 later evolves into 1:N.
• Ignoring column-level security that may require separation.

Final Answer:

Store all fields in one relation (merge the two logical entities into a single table).