Composite attributes in ER modeling In ER diagrams and data modeling terminology, a composite attribute is best described as:
-
AAn attribute that can be decomposed into smaller component attributes
-
BAn attribute that cannot be subdivided any further
-
CA set of multiple different attributes grouped only for layout purposes
-
DAn attribute that uniquely identifies an entity (identifier)
-
EAn attribute that stores values for many entities at once
Answer
Correct Answer: An attribute that can be decomposed into smaller component attributes
Explanation
Introduction / Context:Attributes in ER modeling can be simple, composite, multivalued, or derived. Recognizing each kind helps you normalize designs and choose appropriate relational columns. Composite attributes frequently appear in early, business-facing models to express natural groupings (for example, person name or address) before implementation decisions are made.
Given Data / Assumptions:
- We are working at the conceptual design level.
- Examples of composites: address split into street, city, state, postal_code; name split into given_name, middle_name, family_name.
- The distinction from simple attributes (atomic) is important for normalization.
Concept / Approach:
A composite attribute is one that has meaningful subparts. In implementation, you can either store it as separate columns or as a single field depending on search and reporting needs. Modeling it as composite clarifies intent and avoids later data-quality problems (for example, searching by city requires city to be separately stored or derivable).
Step-by-Step Solution:
Identify the attribute whose value naturally breaks down (for example, Address).List the components (street, city, state, postal_code).Mark it as composite in the ERD (oval with sub-ovals in Chen notation).Decide at logical/physical design whether to store components as separate columns.Verification / Alternative check:
Modeling guidelines consistently define composite as decomposable into smaller attributes and contrast it with simple (atomic) attributes that cannot be subdivided for database purposes.
Why Other Options Are Wrong:
- Cannot be subdivided: that is a simple (atomic) attribute.
- Grouping for layout only: composite groups have semantic subparts, not just visual grouping.
- Identifier: any attribute can be part of a key; composite is about decomposition, not uniqueness.
- Stores values for many entities: that describes relationships or separate tables, not a single attribute.
Common Pitfalls:
- Over-aggregating values into one text field, making filtering and validation difficult.
- Confusing composite with multivalued; composite has parts, multivalued has multiple occurrences.
Final Answer:
An attribute that can be decomposed into smaller component attributes