Database design principle check:\n“The DBMS allows surrogate keys to be changed.”\nDecide whether this statement is accurate, considering how surrogate keys are defined and used in relational systems.

Introduction / Context:
Surrogate keys are system-generated identifiers (for example, integer sequences or UUIDs) used as primary keys. They have no business meaning and exist solely to uniquely identify rows. This question probes whether surrogate keys are expected to be mutable in a well-designed relational database.

Given Data / Assumptions:

• “Surrogate key” means an artificial, non-business identifier such as an auto-increment integer or GUID.
• Surrogate keys typically serve as primary keys and are referenced by foreign keys in other tables.
• Standard relational integrity rules apply (primary key uniqueness; foreign key referential integrity).

Concept / Approach:
By design, surrogate keys are intended to be stable and never change once assigned. Their immutability ensures that child rows referencing the key remain valid and that replication, caching, audit logs, and foreign key relationships stay consistent. While some DBMS products technically allow updating a primary key column (for example, with cascading updates), doing so contradicts the fundamental rationale for using a surrogate key: stable identity decoupled from business meaning. If you foresee updates, you likely need a natural key (business key) or a separate alternate key for evolving attributes.

Step-by-Step Solution:

Verification / Alternative check:
Review vendor docs: although ON UPDATE CASCADE may exist, design guides and data modeling standards recommend immutable surrogate keys to maintain referential stability and simplify ETL and auditing.

Why Other Options Are Wrong:

• “Correct” ignores the principle of identity stability.
• “Only if cascading updates are enabled” is a technical possibility but a poor modeling choice; the question tests best practice, not mere capability.
• “Only in NoSQL systems” and “Depends on page size” are irrelevant to relational key semantics.

Common Pitfalls:
Using a meaningful attribute as a surrogate key; updating primary keys after deployment; confusing surrogate, natural, and alternate keys.

Final Answer:
Incorrect