When to create an associative (bridge) entity Under which condition is it appropriate to convert a relationship into a separate associative entity in your data model?
-
AWhen at least one side is many and the relationship carries its own attributes that must be stored
-
BWhen the resulting associative entity has no attributes at all
-
CWhen all participating relationships are 1:1 only
-
DWhen naming convenience is the only reason
-
EWhen neither side participates beyond a single occurrence
Answer
Correct Answer: When at least one side is many and the relationship carries its own attributes that must be stored
Explanation
Introduction / Context:An associative entity (also called a bridge or junction entity) is used to implement many-to-many associations and to capture attributes of the association itself, such as quantity, effective dates, or roles. Choosing when to elevate a relationship into an entity affects normalization, integrity, and query performance.
Given Data / Assumptions:
- The relationship involves at least two entities.
- The association may have its own meaningful attributes (for example, enrollment_date, unit_price).
- At least one side participates with cardinality many (often both sides in M:N).
Concept / Approach:
When a relationship has attributes that do not belong to either participating entity or the association is many-to-many, it should be represented as an associative entity. In the relational model, this becomes a separate table with foreign keys to each parent and columns for the relationship attributes, enforcing integrity and enabling queries over the association's data.
Step-by-Step Solution:
Identify that the association is many-to-many or at least one side is many.List attributes that describe the association itself (for example, quantity on an order line).Create an associative entity/table with foreign keys to the parents.Add the association attributes as columns; define keys and constraints.Verification / Alternative check:
Textbook examples include Order–Product becoming OrderLine with quantity and price, and Student–Course becoming Enrollment with term and grade. These are canonical cases for associative entities.
Why Other Options Are Wrong:
- No attributes: then a pure junction table is still valid for M:N, but the option states explicitly that there are none and implies conversion regardless of need; the key driver is many-to-many and/or attributes on the relationship.
- All 1:1: rarely requires an associative entity; a foreign key is sufficient.
- Naming convenience alone is not a solid modeling reason.
- Single occurrence participation does not indicate an association entity is necessary.
Common Pitfalls:
- Forgetting to move relationship-specific attributes into the associative entity.
- Not enforcing uniqueness across the pair of foreign keys, allowing duplicate association rows.
Final Answer:
When at least one side is many and the relationship carries its own attributes that must be stored