If the parent entity is required and the parent uses a surrogate key, can update actions on referential integrity be ignored, or must update behavior still be considered explicitly?

Introduction / Context:Designers often choose surrogate keys because they rarely change. This question asks whether that fact allows you to ignore referential “update” actions for foreign keys when the parent is required.

Given Data / Assumptions:

• Parent table uses a surrogate primary key.
• Child table references the parent key via a NOT NULL foreign key.
• DBMS supports referential actions on update and delete.

Concept / Approach:While surrogate keys “seldom change,” they can, in principle, change (e.g., data fixes, key reseeding, migrations). Referential action settings (ON UPDATE NO ACTION/RESTRICT/CASCADE) still need to be defined intentionally. Relying on “it will never change” is risky. Therefore, you cannot simply ignore update actions; you must choose a policy (commonly NO ACTION) to protect integrity.

Step-by-Step Solution:

Verification / Alternative check:Attempt to change a parent key with NO ACTION versus CASCADE; observe the referential effect on child rows. Without an explicit choice, defaults may block updates or cause errors.

Why Other Options Are Wrong:

• “Correct” would endorse skipping a required integrity decision.
• “Only ignorable when keys never change” is brittle and not a good practice.
• “Mandatory only for natural keys” is false; referential policy applies to any key.
• “Applies only with cascading deletes” confuses update and delete actions.

Common Pitfalls:Assuming surrogate immutability; overlooking migration scenarios; leaving default referential actions undocumented.

Final Answer:Incorrect