0
0
SQLquery~10 mins

Referential integrity enforcement in SQL - Step-by-Step Execution

Choose your learning style9 modes available
Concept Flow - Referential integrity enforcement
Start: Insert/Update/Delete in Child Table
Check Foreign Key Value Exists in Parent Table?
Allow Operation
Operation Done
When you change data in a table with a foreign key, the database checks if the related value exists in the parent table. If yes, it allows the change; if no, it rejects it to keep data correct.
Execution Sample
SQL
CREATE TABLE Departments (
  DeptID INT PRIMARY KEY,
  DeptName VARCHAR(50)
);

CREATE TABLE Employees (
  EmpID INT PRIMARY KEY,
  EmpName VARCHAR(50),
  DeptID INT,
  FOREIGN KEY (DeptID) REFERENCES Departments(DeptID)
);

INSERT INTO Departments VALUES (1, 'Sales');
INSERT INTO Employees VALUES (101, 'Alice', 1);
This code creates two tables with a foreign key from Employees to Departments, then inserts a department and an employee linked to it.
Execution Table
StepOperationForeign Key CheckResultNotes
1Insert DeptID=1 into DepartmentsNo FK check neededSuccessParent table insert always allowed
2Insert EmpID=101, DeptID=1 into EmployeesCheck DeptID=1 exists in DepartmentsSuccessDeptID=1 found, insert allowed
3Insert EmpID=102, DeptID=2 into EmployeesCheck DeptID=2 exists in DepartmentsFailDeptID=2 not found, insert rejected
4Delete DeptID=1 from DepartmentsCheck Employees referencing DeptID=1FailChild rows exist, delete rejected
5Update EmpID=101 DeptID to 3Check DeptID=3 exists in DepartmentsFailDeptID=3 not found, update rejected
6Update EmpID=101 DeptID to NULLDepends on FK constraint (if allowed)Success or FailIf FK allows NULL, update allowed; else rejected
💡 Operations stop when foreign key checks fail to maintain referential integrity.
Variable Tracker
VariableStartAfter Step 1After Step 2After Step 3After Step 4After Step 5After Step 6
Departmentsempty[(1, 'Sales')][(1, 'Sales')][(1, 'Sales')][(1, 'Sales')][(1, 'Sales')][(1, 'Sales')]
Employeesemptyempty[(101, 'Alice', 1)]unchangedunchangedunchangeddepends on NULL allowance
Key Moments - 3 Insights
Why does inserting an employee with DeptID=2 fail even if Employees table is empty?
Because DeptID=2 does not exist in Departments, the foreign key check fails (see execution_table step 3). The database rejects the insert to keep data consistent.
Why can't we delete a department if employees reference it?
Deleting a department with existing employees referencing it breaks referential integrity, so the database rejects the delete (see execution_table step 4).
What happens if we update an employee's DeptID to a value not in Departments?
The update is rejected because the new DeptID does not exist in the parent table, violating referential integrity (see execution_table step 5).
Visual Quiz - 3 Questions
Test your understanding
Look at the execution_table, what happens when inserting an employee with DeptID=1 at step 2?
AInsert fails because DeptID=1 is missing
BInsert is delayed until DeptID=1 is added
CInsert succeeds because DeptID=1 exists
DInsert succeeds without checking DeptID
💡 Hint
Check the 'Foreign Key Check' and 'Result' columns at step 2 in execution_table
At which step does the database reject an operation due to missing DeptID in Departments?
AStep 3
BStep 1
CStep 4
DStep 2
💡 Hint
Look for 'Fail' results with missing DeptID in execution_table
If the foreign key allowed NULLs, what would happen at step 6 when updating DeptID to NULL?
AUpdate rejected because NULL is not allowed
BUpdate succeeds if FK allows NULL
CUpdate causes deletion of employee
DUpdate ignored by database
💡 Hint
See notes in step 6 of execution_table about NULL allowance
Concept Snapshot
Referential integrity means foreign keys must match existing parent keys.
When inserting or updating child rows, DB checks parent table for matching key.
If no match, operation is rejected to keep data consistent.
Deleting parent rows is blocked if children reference them.
NULL foreign keys may be allowed depending on constraint settings.
Full Transcript
Referential integrity enforcement ensures that foreign key values in a child table always match existing primary key values in a parent table. When you insert or update a row in the child table, the database checks if the foreign key value exists in the parent table. If it does, the operation proceeds; if not, the database rejects it to prevent broken links. Similarly, deleting a parent row is blocked if child rows reference it. This keeps data consistent and prevents orphaned records. Some foreign keys allow NULL values, which means the child row can have no parent reference if allowed by the constraint. The execution table shows examples of inserts, updates, and deletes with their foreign key checks and results, illustrating how referential integrity is enforced step-by-step.