Candidate keys: Must a candidate key uniquely identify each row in a relation, qualifying it to serve as a primary key?

Introduction / Context:
Candidate keys are minimal attribute sets that uniquely identify tuples in a relation. Any candidate key can be chosen as the primary key; others become alternate keys. Uniqueness and minimality are the defining properties.

Given Data / Assumptions:

• Uniqueness ensures no two rows share the same candidate-key values.
• Minimality means no proper subset of the candidate key is itself a key.
• Multiple candidate keys can exist for a single relation.

Concept / Approach:
The statement is accurate. If an attribute set does not uniquely identify rows, it cannot be a candidate key. Conversely, if it uniquely identifies rows but includes unnecessary attributes, it fails minimality and is not a candidate key (though it could be a superkey).

Step-by-Step Solution:
List functional dependencies for the relation.Determine attribute closures to find superkeys.Remove extraneous attributes to reach minimal superkeys (candidate keys).Choose one candidate key as the primary key.Enforce uniqueness and NOT NULL constraints on the chosen primary key.

Verification / Alternative check:
Compute closures in a sample schema (e.g., for EMP(emp_no, nat_id, email, ...)) and verify that each proposed candidate key functionally determines all attributes of the relation.

Why Other Options Are Wrong:
Incorrect: contradicts the definition of candidate keys.Only if surrogate: natural keys can also be candidate keys.Only in BCNF: candidate keys are a fundamental concept independent of normal form.

Common Pitfalls:
Confusing superkeys with candidate keys; overlooking composite candidate keys; failing to test minimality rigorously.

Final Answer:
Correct