In relational database design, what do we call a unique, DBMS-supplied identifier that is used as the primary key of a relation (table)?

Introduction / Context:
A core decision in database schema design is how to identify each row uniquely. Sometimes natural keys (business keys) exist, but often designers choose system-generated identifiers. This question checks your understanding of that special type of key.

Given Data / Assumptions:

• The identifier is supplied by the DBMS or application as an arbitrary unique value.
• It is used as the table’s primary key.
• It does not encode business meaning.

Concept / Approach:
A surrogate key is a meaningless, unique identifier (for example, an auto-increment integer or a UUID) created to serve as the primary key. It simplifies joins, avoids changes when business attributes evolve, and provides uniformity across tables. It contrasts with natural keys, which come from the domain (such as email or SKU) and carry meaning.

Step-by-Step Solution:

Verification / Alternative check:
Many DBMSs support sequences, identity columns, or generated UUIDs precisely to implement surrogate keys cleanly and efficiently.

Why Other Options Are Wrong:
Primary key: Describes the role, not the nature; a surrogate key is a kind of primary key.
Foreign key: References a primary key in another table.
Composite key: Combines multiple columns; not necessarily DBMS-supplied or meaningless.

Common Pitfalls:
Believing a surrogate key must be numeric only; UUIDs are common too. Confusing “surrogate key” with “alternate key.”

Final Answer:
surrogate key