ER-to-Relational Mapping — Multivalued Attribute When converting a multivalued attribute of an entity into the relational model, which statement correctly describes the number of relations created for that entity and attribute?

Difficulty: Easy

Correct Answer: Two relations are created.

Explanation:


Introduction:
Multivalued attributes violate first normal form because a single attribute can store multiple values for one entity instance. The standard relational fix is to split those values into a separate relation so each value is captured as a distinct row, preserving atomicity and enabling proper constraints and indexing.


Given Data / Assumptions:

  • We have a regular entity with a multivalued attribute (for example, phone numbers for a customer).
  • We are applying standard ER-to-relational mapping rules.
  • No additional complexities such as composite multivalued attributes are assumed.


Concept / Approach:
The entity maps to its own relation. The multivalued attribute maps to a second relation that includes a foreign key referencing the entity’s primary key and a column for the attribute’s single atomic value. The primary key of the second relation is usually composite (entity key plus the attribute value or a sequence number), or a surrogate key with a unique constraint paired with the foreign key and value.


Step-by-Step Solution:
Create Relation E for the entity, with its primary key.Create Relation E_A for the multivalued attribute.Include E’s primary key in E_A as a foreign key.Store one attribute value per row in E_A to satisfy first normal form.


Verification / Alternative check:
Querying the separate relation confirms that each attribute value is atomic and independently constrainable (for example, uniqueness within the parent scope).


Why Other Options Are Wrong:

  • One relation keeps repeating values in a single row and violates first normal form.
  • Three or four relations add unnecessary complexity for a single multivalued attribute.
  • Views do not replace the need for base storage structures.


Common Pitfalls:
Using multiple similarly named columns (Phone1, Phone2, Phone3) instead of a proper child table, which hampers scalability and constraints.


Final Answer:
Two relations are created.

Discussion & Comments

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