In a database with referential integrity, when can a primary key value in a parent table be updated if related rows exist in a child table?

Introduction / Context:
Primary keys in a parent table are often referenced by foreign keys in one or more child tables. When referential integrity is enforced, the database ensures that these relationships remain consistent. A common certification question is whether a primary key in the parent table can be changed when related child rows exist, and under what conditions such an update is allowed without violating referential integrity rules.

Given Data / Assumptions:

• A parent table has a primary key column that is referenced by a foreign key in a child table.
• Referential integrity constraints are enabled between the parent and child tables.
• There are existing child rows that currently reference the primary key value that you want to update.
• The database supports referential actions such as ON UPDATE CASCADE.

Concept / Approach:
Referential integrity does not completely forbid updates to primary key values, but it does enforce consistency between parent and child tables. If you update a primary key value while child rows still reference the old value, you would create orphan rows unless something keeps them in sync. This is where options like ON UPDATE CASCADE come into play. When a foreign key is defined with ON UPDATE CASCADE, updating the parent key automatically updates all dependent child keys. Alternatively, you can update or delete child rows first so that the primary key update no longer violates referential integrity.

Step-by-Step Solution:
Step 1: Recognize that a primary key can be updated technically, but only if related foreign keys are handled in a consistent way. Step 2: Check whether the foreign key constraint includes ON UPDATE CASCADE. If it does, the database automatically propagates the new primary key value to all referencing child records. Step 3: If no cascade rule exists, understand that you must first update or delete child rows so that no foreign key continues to reference the old key value. Step 4: Compare these facts to the answer choices and identify the one that states that updates are allowed only with appropriate cascade behavior or prior child row maintenance.

Verification / Alternative check:
To verify, imagine a parent table CUSTOMER with primary key customer_id and a child table ORDER with foreign key customer_id. If the foreign key uses ON UPDATE CASCADE, changing a customer_id of 10 to 20 automatically updates all matching rows in ORDER. Without cascade, attempting to update customer_id in the parent table while child rows still reference 10 results in a constraint violation. This experimental reasoning confirms the correct choice.

Why Other Options Are Wrong:
Option B is incorrect because referential integrity does restrict primary key updates when child rows exist; you cannot update freely. Option C is also wrong because primary keys are not absolutely immutable; they can be changed under controlled conditions. Option D is clearly incorrect and nonsensical because database restarts do not disable referential integrity checks in a proper relational database engine.

Common Pitfalls:
Many learners incorrectly assume that a primary key can never be updated if any foreign key references it. In reality, good design prefers stable primary keys, but technically databases allow changes when constraints and cascades are correctly defined. Another pitfall is defining foreign keys without cascade rules in systems where business requirements actually demand synchronized updates, resulting in frequent constraint errors and manual data fixes.

Final Answer:
The correct rule is that only when the foreign key constraint is defined with an appropriate ON UPDATE CASCADE or after related child rows are updated or deleted can a primary key value be safely updated while maintaining referential integrity.