Modeling many-to-many (M:N) relationships: “An intersection (associative) table is required to represent M:N relationships.” Determine whether this is accurate for relational schemas.
-
ACorrect
-
BIncorrect
-
COnly with composite natural keys
-
DOnly in third normal form (3NF)
-
EDepends on the query optimizer
Answer
Correct Answer: Correct
Explanation
Introduction / Context: Real-world data often involves many-to-many associations: students take many courses; courses have many students. Relational tables cannot directly store an M:N link between two base tables without additional structure. The standard solution is an intersection (associative) table.
Given Data / Assumptions:
- Two entities A and B with an M:N relationship.
- Each entity has its own primary key (surrogate or natural).
- We need to enforce referential integrity and prevent duplicates.
Concept / Approach: An intersection table (sometimes called a bridge or join table) contains at least two foreign keys: one to A and one to B. Its primary key is commonly the composite (a_id, b_id) or a surrogate with a unique constraint on (a_id, b_id). This structure allows any number of A–B pairings while preserving normalization and enabling ON DELETE/ON UPDATE rules. Without such a table, attempts to embed repeating groups or comma-separated lists in either parent violate first normal form and sabotage indexing and query performance.
Step-by-Step Solution:
Create A(id …), B(id …).Create AB(a_id REFERENCES A(id), b_id REFERENCES B(id), PRIMARY KEY(a_id, b_id)).Insert pairings into AB for each association.Query M:N via joins: A JOIN AB JOIN B as needed.Verification / Alternative check: Try to model without AB: you either lose normalization or cannot represent multiple Bs per A (or vice versa). Intersection table is the only normalized, enforceable approach.
Why Other Options Are Wrong:
- Tying correctness to composite keys, 3NF, or optimizers misses the conceptual requirement; intersection tables are fundamental to relational modeling of M:N.
Common Pitfalls: Storing comma-separated IDs; forgetting a uniqueness constraint on (a_id, b_id); failing to index both foreign keys for join performance.
Final Answer: Correct