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?

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.