In a one-to-many (1:M) relationship, does the primary key from the “one” side migrate to the “many” side as a foreign key on the “many” side?
-
ACorrect
-
BIncorrect
-
CTrue only when both sides are weak entities
-
DApplies only in star schemas
Answer
Correct Answer: Correct
Explanation
Introduction / Context:This question targets a fundamental transformation rule in ER-to-relational mapping: how to place foreign keys when converting a one-to-many relationship into tables. Understanding this rule underpins correct referential integrity and efficient joins.
Given Data / Assumptions:
- The relationship cardinality is 1:M (exactly one instance on one side relates to zero or many on the other).
- Both participating entity types map to relations with defined primary keys.
- We want to preserve relationship semantics in the relational schema.
Concept / Approach:In a 1:M relationship, the standard mapping rule is to include the primary key of the “one” side as a foreign key attribute in the relation representing the “many” side. This allows each “many” record to reference its unique parent and enables referential integrity constraints to prevent orphaned rows.
Step-by-Step Solution:Identify the “one” side relation and its primary key (e.g., customer.customer_id).Identify the “many” side relation (e.g., order).Add customer_id to the order table as a foreign key referencing customer(customer_id).Declare the foreign key constraint and, as needed, on delete/update rules.Use indexes on the foreign key to improve join performance.
Verification / Alternative check:Think of common examples: Department (1) to Employee (M). department_id appears in Employee as a foreign key, which aligns with the rule and ensures each employee references one department.
Why Other Options Are Wrong:Incorrect: contradicts the core rule for 1:M mapping.True only when both are weak: unnecessary; standard rule applies to regular strong entities.Star schemas only: a star schema is just a specialized pattern; the rule is general.
Common Pitfalls:Putting the foreign key on the wrong side (on the “one” side) or attempting to create a separate relationship table, which is unnecessary for pure 1:M and adds complexity.
Final Answer:Correct