ER attributes to tables: Does a composite attribute itself get mapped directly as a single column in a relation, or are its components mapped instead?

Introduction / Context:
A composite attribute is one that can be broken into smaller subattributes (e.g., Address into street, city, state, postal_code). During ER-to-relational mapping, we need to decide how such attributes appear in the resulting tables.

Given Data / Assumptions:

• Composite attributes are not atomic; each component may carry independent meaning.
• Relational design favors atomic (1NF) columns.
• Applications and queries often need to filter or sort by the individual components.

Concept / Approach:
The standard mapping rule is that composite attributes are not mapped as a single column. Instead, each component of the composite attribute is mapped to its own column(s). This preserves atomicity and supports more precise querying and indexing. The original composite “wrapper” does not become a separate column.

Step-by-Step Solution:
Identify composite attributes in the ER model.Decompose them into component attributes (e.g., street, city, state).Map each component as its own column in the relation.Apply constraints (NOT NULL, length, domain checks) as appropriate.Index individual components if required by query patterns.

Verification / Alternative check:
Consider searching by city or postal_code. If Address were a single column, such queries would require parsing. With decomposed columns, indexing and searching are straightforward, validating the mapping choice.

Why Other Options Are Wrong:
Incorrect: treating the composite as one column violates 1NF and hinders querying.True only if optional or only in 3NF: decomposition is a general rule irrespective of optionality or specific normal form levels.

Common Pitfalls:
Storing composite data in one text column; mixing components inconsistently; ignoring locale-specific formats (e.g., international addresses) when designing columns.

Final Answer:
Correct