In relational databases, what referential actions are commonly supported by a FOREIGN KEY integrity constraint when related rows are deleted or updated?

Difficulty: Medium

Correct Answer: Actions such as NO ACTION, CASCADE, SET NULL, and SET DEFAULT to control behaviour on delete or update

Explanation:


Introduction / Context:
Foreign key constraints enforce referential integrity between parent and child tables in relational databases. When a row in the parent table is deleted or its key is updated, the database must decide what to do with matching child rows. To handle these situations in a controlled way, most relational databases support a set of referential actions that can be specified as part of the FOREIGN KEY definition. Understanding these actions helps designers choose behaviours that maintain data consistency while supporting business rules.


Given Data / Assumptions:

  • We have a parent table with a primary key and a child table with a foreign key referencing that primary key.
  • Delete or update operations can affect rows that participate in this relationship.
  • The database needs a defined rule for what to do with child rows in such cases.
  • Common referential actions include NO ACTION, CASCADE, SET NULL, and SET DEFAULT.


Concept / Approach:
When defining a FOREIGN KEY constraint, the designer can specify referential actions for ON DELETE and sometimes ON UPDATE events. NO ACTION or RESTRICT prevents the parent row from being deleted or updated if matching child rows exist. CASCADE automatically propagates the delete or update to child rows, removing or changing them accordingly. SET NULL sets the foreign key column to null in child rows when the parent row changes, provided the column allows nulls. SET DEFAULT sets the foreign key column to a default value. These options offer flexibility in enforcing referential integrity while matching the logic of the application.


Step-by-Step Solution:
Step 1: Identify that the question is about actions supported by FOREIGN KEY constraints in relational databases.Step 2: Recall that NO ACTION or RESTRICT prevents changes that would violate referential integrity by leaving orphan child rows.Step 3: Remember that CASCADE tells the database to automatically delete or update child rows when the parent row changes.Step 4: Note that SET NULL sets the foreign key in child rows to null when the parent is deleted or updated, if allowed.Step 5: Recognise that SET DEFAULT sets the foreign key to a predefined default value, which can be useful in some designs.


Verification / Alternative check:
To see these actions in practice, you can create a simple pair of tables, such as Departments and Employees, with a foreign key from Employees to Departments. Define different constraints using CASCADE, SET NULL, or NO ACTION and then perform delete or update operations on the Departments table. Observe how the Employees rows change or how the database prevents the operation. The behaviour will match the referential actions you specified, demonstrating how these options work in real databases.


Why Other Options Are Wrong:
Option B claims that the database server shuts down automatically when a parent row is deleted, which is not a referential action and would be unacceptable behaviour. Option C suggests that foreign keys allow any value, even non existent keys, which contradicts the purpose of referential integrity. Option D states that all child rows must be deleted manually before deleting a parent, ignoring the existence of CASCADE, SET NULL, and SET DEFAULT options that automate or adjust this behaviour. These alternatives do not correctly reflect the standard referential actions supported by FOREIGN KEY constraints.


Common Pitfalls:
A common pitfall is choosing CASCADE without considering the full impact, which can lead to large chains of deletions when a parent row is removed. Another mistake is failing to handle nullable foreign keys correctly when using SET NULL, which can create unexpected orphan like records if the business logic does not account for them. Designers should carefully analyse business requirements before choosing referential actions and should test boundary cases extensively. Clear documentation of relationships and constraints helps ensure predictable behaviour in production systems.


Final Answer:
Correct answer: Actions such as NO ACTION, CASCADE, SET NULL, and SET DEFAULT to control behaviour on delete or update

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion