Composite identifiers: confirm whether a composite primary key must consist of two or more attributes.
-
AValid statement
-
BInvalid statement
-
CValid only when both attributes are foreign keys
-
DAmbiguous — depends on normalization
-
EValid only with surrogate keys
Answer
Correct Answer: Valid statement
Explanation
Introduction / Context:Composite identifiers (composite primary keys) are common in associative entities and certain natural-key domains. The question asks whether the definition “two or more attributes form the identifier” is correct.
Given Data / Assumptions:
- Primary key uniquely identifies each row/instance.
- Composite means the key is formed by multiple attributes (columns).
- No assumption is made that the attributes must be foreign keys, though that is common in bridge tables.
Concept / Approach:A composite identifier is precisely a key consisting of two or more attributes. Typical examples include many-to-many bridge tables (e.g., student_course(student_id, course_id)) or natural keys like country_code + local_number for phone numbers in certain systems.
Step-by-Step Solution:Define composite: more than one attribute participates in uniqueness.Check examples: dual FK bridges, date + sequence combinations, code + version pairs.Therefore, the statement matches the formal definition.
Verification / Alternative check:Examine DDL: PRIMARY KEY (student_id, course_id)—this is a composite identifier of two attributes.
Why Other Options Are Wrong:Requiring both attributes to be FKs is unnecessary; normalization choices do not change the definition; surrogate keys are single columns and are unrelated to whether alternates are composite.
Common Pitfalls:Assuming composite keys are always inferior; in associative tables they express natural uniqueness succinctly. Conversely, using composites where a surrogate would be simpler can complicate FKs.
Final Answer:Valid statement