Integrity Constraints - Learning Module

Loading content...

0/252

Referential Integrity

The Relational Web of Dependencies

Relational databases derive much of their power from the ability to represent relationships between entities. Customers place orders. Employees work in departments. Students enroll in courses. These relationships aren't just conceptual—they are encoded as structural dependencies between tables through foreign keys.

Referential integrity is the constraint that ensures these encoded relationships remain valid. It prevents the database from entering states where references point to non-existent entities—where an order references a customer who doesn't exist, or an employee belongs to a department that was deleted.

This page provides an exhaustive treatment of referential integrity, examining its formal definition, the mechanisms for enforcing it, strategies for handling violations, and the complex scenarios that arise in real-world database design.

What You Will Master

By the end of this page, you will understand: (1) The formal definition and semantics of referential integrity, (2) Foreign key declarations and their components, (3) Referential actions (CASCADE, SET NULL, RESTRICT, NO ACTION), (4) Self-referencing and circular references, (5) Implementation considerations across database systems, and (6) Best practices for maintaining referential integrity in complex schemas.

Formal Definition of Referential Integrity

Referential integrity is formally stated as follows:

Referential Integrity Rule: If relation R₂ includes a foreign key FK matching the primary key PK of relation R₁, then every value of FK in R₂ must either:

Be equal to a value of PK in some tuple of R₁, or

Be entirely NULL (if permitted by the schema)

This definition establishes a consistency requirement between two tables: the referencing table (R₂, which contains the foreign key) and the referenced table (R₁, which contains the primary key being referenced).

Key Terminology

•Foreign Key (FK) — An attribute or set of attributes in a relation whose values must match the primary key of another relation (or be NULL).
•Referenced/Parent Table — The table containing the primary key that is referenced. It defines the set of valid values for the foreign key.
•Referencing/Child Table — The table containing the foreign key. Each non-NULL FK value must exist in the parent table.
•Dangling Reference — A foreign key value that points to a non-existent primary key. Referential integrity violations create dangling references.
•Orphan Record — A row in the child table whose foreign key no longer matches any primary key in the parent table.

The relationship semantics:

Referential integrity encodes a fundamental semantic relationship: if the child record claims to be associated with a parent entity, that parent entity must actually exist. The foreign key is essentially a promise—a claim that 'this record is associated with record X in the parent table.' Referential integrity ensures the database holds you to that promise.

Consider an e-commerce scenario:

An Order references a Customer (the customer who placed the order)
An OrderItem references both an Order and a Product

Referential integrity guarantees:

Every order is associated with an existing customer
Every order item belongs to an existing order
Every order item references an existing product

What Referential Integrity Does NOT Guarantee

Referential integrity ensures foreign keys point to existing rows, but it does NOT ensure the referenced row is the 'correct' one semantically. If you accidentally set an order's customer_id to the wrong customer (who does exist), referential integrity is satisfied—the constraint is structural, not semantic. Semantic correctness requires additional application logic.

Foreign Key Declaration and Syntax

Foreign keys are declared as constraints in the table definition. The declaration specifies the local column(s), the referenced table, and the referenced column(s). While syntax varies slightly across database systems, the core structure is consistent.

foreign_key_syntax.sql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
-- Basic foreign key declaration
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT NOT NULL,
    order_date DATE NOT NULL DEFAULT CURRENT_DATE,
    total_amount DECIMAL(12,2) NOT NULL DEFAULT 0,
    
    -- Foreign key constraint (inline syntax)
    CONSTRAINT fk_orders_customer 
        FOREIGN KEY (customer_id) 
        REFERENCES customers(customer_id)
);
 
-- Alternative: Column-level constraint syntax
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT NOT NULL REFERENCES customers(customer_id),
    order_date DATE NOT NULL DEFAULT CURRENT_DATE
);
 
-- Composite foreign key (multiple columns)
CREATE TABLE order_items (
    order_id INT NOT NULL,
    line_number INT NOT NULL,
    product_id INT NOT NULL,
    quantity INT NOT NULL DEFAULT 1,
    unit_price DECIMAL(10,2) NOT NULL,
    
    PRIMARY KEY (order_id, line_number),
    
    -- Single-column foreign key
    FOREIGN KEY (order_id) REFERENCES orders(order_id),
    FOREIGN KEY (product_id) REFERENCES products(product_id)
);
 
-- Composite foreign key referencing composite primary key
CREATE TABLE shipment_items (
    shipment_id INT NOT NULL,
    order_id INT NOT NULL,
    line_number INT NOT NULL,
    quantity_shipped INT NOT NULL,
    
    PRIMARY KEY (shipment_id, order_id, line_number),
    
    -- References the composite PK of order_items
    FOREIGN KEY (order_id, line_number) 
        REFERENCES order_items(order_id, line_number)
);

Anatomy of a foreign key constraint:

Foreign Key Constraint Components
Component	Required?	Description
Constraint name	Optional	Named identifier for the constraint (e.g., `fk_orders_customer`); auto-generated if omitted
FOREIGN KEY	Required	Keyword indicating this is a foreign key constraint
Local columns	Required	Column(s) in the current table that form the foreign key
REFERENCES	Required	Keyword indicating the target of the reference
Referenced table	Required	The parent table containing the primary key
Referenced columns	Optional*	Column(s) in the parent table; defaults to primary key if omitted
Referential actions	Optional	ON DELETE and ON UPDATE behaviors (discussed next section)

Best Practice: Name Your Constraints

Always provide explicit constraint names (e.g., fk_orders_customer). Auto-generated names like orders_customer_id_fkey are less readable in error messages and harder to reference when you need to drop or modify the constraint. A consistent naming convention like fk_<child_table>_<parent_table> makes schema maintenance significantly easier.

Referential Actions: Handling Violations

What happens when an operation would violate referential integrity? For example, what if someone tries to delete a customer who has existing orders? Or updates a product ID that is referenced by order items?

The referential actions (also called referential triggers or constraint actions) define the database's automatic response to such situations. These are specified with ON DELETE and ON UPDATE clauses.

Referential Actions Explained
Action	On DELETE Behavior	On UPDATE Behavior	Use Case
`RESTRICT`	Reject delete if child rows exist	Reject update if child rows reference old value	Strict protection; prevent any orphaning
`NO ACTION`	Same as RESTRICT (checked at statement end)	Same as RESTRICT (checked at statement end)	Default in most databases; allows deferred checking
`CASCADE`	Delete child rows when parent is deleted	Update child FK values when parent PK changes	Propagate changes automatically through hierarchy
`SET NULL`	Set child FK to NULL when parent deleted	Set child FK to NULL when parent PK changes	Preserve child row but break association
`SET DEFAULT`	Set child FK to default value when parent deleted	Set child FK to default when parent PK changes	Reassign to default parent entity

referential_actions.sql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
-- CASCADE: Propagate deletions through the hierarchy
CREATE TABLE departments (
    dept_id SERIAL PRIMARY KEY,
    dept_name VARCHAR(100) NOT NULL
);
 
CREATE TABLE employees (
    emp_id SERIAL PRIMARY KEY,
    emp_name VARCHAR(100) NOT NULL,
    dept_id INT,
    
    FOREIGN KEY (dept_id) 
        REFERENCES departments(dept_id)
        ON DELETE CASCADE      -- Delete employees when department deleted
        ON UPDATE CASCADE      -- Update FK when department ID changes
);
 
-- If we delete a department, all its employees are automatically deleted
DELETE FROM departments WHERE dept_id = 10;
-- All employees with dept_id = 10 are now gone!
 
-- SET NULL: Preserve child but break association
CREATE TABLE projects (
    project_id SERIAL PRIMARY KEY,
    project_name VARCHAR(100) NOT NULL,
    lead_emp_id INT,
    
    FOREIGN KEY (lead_emp_id)
        REFERENCES employees(emp_id)
        ON DELETE SET NULL     -- Project stays but has no lead
        ON UPDATE CASCADE
);
 
-- If the project lead is terminated
DELETE FROM employees WHERE emp_id = 101;
-- Project still exists, but lead_emp_id is now NULL
 
-- RESTRICT: Prevent dangerous operations
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT NOT NULL,
    
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE RESTRICT     -- Cannot delete customer with orders
        ON UPDATE RESTRICT     -- Cannot change customer_id if orders exist
);
 
-- This fails if customer has orders:
DELETE FROM customers WHERE customer_id = 500;
-- ERROR: update or delete violates foreign key constraint
 
-- Mixed strategy example
CREATE TABLE invoices (
    invoice_id SERIAL PRIMARY KEY,
    order_id INT NOT NULL,
    created_by_emp_id INT,
    
    FOREIGN KEY (order_id)
        REFERENCES orders(order_id)
        ON DELETE RESTRICT,    -- Can't delete order with invoice
        
    FOREIGN KEY (created_by_emp_id)
        REFERENCES employees(emp_id)
        ON DELETE SET NULL     -- Employee leaves, invoice stays
);

CASCADE with Caution

ON DELETE CASCADE can be dangerous in complex schemas. Deleting a single parent row can trigger cascading deletions across many tables, potentially removing thousands of rows. Always map out the cascade paths in your schema before using CASCADE. In many production systems, RESTRICT is preferred because it forces explicit handling of deletions.

NO ACTION vs RESTRICT:

These two actions appear identical but have a subtle difference:

RESTRICT - Checked immediately when the DELETE/UPDATE statement executes
NO ACTION - Checked at the end of the statement (or transaction if deferred)

This difference matters when you have triggers or multiple constraints. With NO ACTION, a trigger could insert a replacement row before the constraint check occurs. With RESTRICT, the check happens first.

Self-Referencing and Circular References

A powerful but complex pattern is the self-referencing relationship, where a foreign key in a table references the primary key of the same table. This is used to model hierarchical or recursive relationships within a single entity type.

self_referencing.sql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
-- Classic self-reference: Employee hierarchy (manager relationship)
CREATE TABLE employees (
    emp_id SERIAL PRIMARY KEY,
    emp_name VARCHAR(100) NOT NULL,
    manager_id INT,  -- References another employee
    hire_date DATE NOT NULL DEFAULT CURRENT_DATE,
    
    FOREIGN KEY (manager_id) 
        REFERENCES employees(emp_id)
        ON DELETE SET NULL   -- If manager leaves, employee stays but has no manager
);
 
-- Top-level employee (CEO) has NULL manager_id
INSERT INTO employees (emp_name, manager_id, hire_date) 
VALUES ('Alice CEO', NULL, '2020-01-01');
 
-- Next level references Alice (emp_id = 1)
INSERT INTO employees (emp_name, manager_id, hire_date)
VALUES ('Bob VP', 1, '2020-02-01');
 
INSERT INTO employees (emp_name, manager_id, hire_date)
VALUES ('Carol VP', 1, '2020-02-01');
 
-- Lower levels reference VPs
INSERT INTO employees (emp_name, manager_id, hire_date)
VALUES ('Dave Manager', 2, '2021-01-01');
 
-- Query the hierarchy
SELECT 
    e.emp_name AS employee,
    m.emp_name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.emp_id
ORDER BY e.emp_id;
 
-- Recursive CTE to traverse full hierarchy
WITH RECURSIVE org_chart AS (
    -- Base case: top-level (no manager)
    SELECT emp_id, emp_name, manager_id, 1 AS level
    FROM employees
    WHERE manager_id IS NULL
    
    UNION ALL
    
    -- Recursive case: employees with managers
    SELECT e.emp_id, e.emp_name, e.manager_id, oc.level + 1
    FROM employees e
    JOIN org_chart oc ON e.manager_id = oc.emp_id
)
SELECT 
    REPEAT('  ', level - 1) || emp_name AS org_hierarchy,
    level
FROM org_chart
ORDER BY level, emp_name;

Handling the root/top-level entity:

In self-referencing relationships, the 'root' entities (those at the top of the hierarchy) must have a NULL foreign key because they have no parent. This is the one case where NULL in a foreign key is semantically meaningful—it indicates 'no parent relationship exists' rather than 'parent is unknown.'

Circular reference challenges:

More complex are true circular references between different tables:

circular_references.sql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
-- Circular reference scenario: Department and Employee
-- Problem: Department has a manager (employee), Employee belongs to department
 
-- Approach 1: Deferred constraints (PostgreSQL)
CREATE TABLE departments (
    dept_id SERIAL PRIMARY KEY,
    dept_name VARCHAR(100) NOT NULL,
    manager_id INT  -- Will reference employees, but employees doesn't exist yet
);
 
CREATE TABLE employees (
    emp_id SERIAL PRIMARY KEY,
    emp_name VARCHAR(100) NOT NULL,
    dept_id INT REFERENCES departments(dept_id)
);
 
-- Now add the circular reference
ALTER TABLE departments
ADD CONSTRAINT fk_dept_manager 
FOREIGN KEY (manager_id) REFERENCES employees(emp_id)
DEFERRABLE INITIALLY DEFERRED;  -- Check at commit, not immediately
 
-- With deferred constraints, we can insert in either order
BEGIN;
    INSERT INTO departments (dept_name, manager_id) 
    VALUES ('Engineering', 1);  -- References emp_id 1 which doesn't exist yet
    
    INSERT INTO employees (emp_name, dept_id)
    VALUES ('Alice', 1);        -- References dept_id 1 which exists
COMMIT;  -- Constraint check happens here; both references now valid
 
-- Approach 2: Insert in stages with updates
BEGIN;
    -- First create department without manager
    INSERT INTO departments (dept_name, manager_id)
    VALUES ('Marketing', NULL);  -- dept_id = 2
    
    -- Create employee in department
    INSERT INTO employees (emp_name, dept_id)
    VALUES ('Bob', 2);           -- emp_id = 2
    
    -- Update department with manager
    UPDATE departments SET manager_id = 2 WHERE dept_id = 2;
COMMIT;

Avoid Complex Circular Dependencies

While databases can handle circular references with deferred constraints or careful insert ordering, complex circular dependencies make the schema harder to understand, maintain, and migrate. If you find yourself with many circular references, consider whether the data model can be restructured. Often, an intermediate relationship table can break the cycle cleanly.

Nullable Foreign Keys: Optional Relationships

The formal definition of referential integrity allows foreign key values to be NULL, provided the schema permits it. A NULL foreign key indicates that the relationship does not exist for this particular row—unlike a non-NULL value that references a specific parent.

Mandatory vs Optional relationships:

Mandatory relationship (NOT NULL FK): Every child row must be associated with a parent. Example: Every Order must have a Customer.
Optional relationship (nullable FK): A child row may or may not be associated with a parent. Example: An Employee may or may not have a Manager.

Mandatory vs Optional Relationships
Scenario	FK Nullability	Rationale
Order → Customer	NOT NULL	Every order must be placed by someone
Employee → Manager	NULL allowed	CEO has no manager; this is valid, not missing data
Invoice → Order	NOT NULL	Invoice must reference the order being billed
Product → Category	NULL allowed	Product might be uncategorized temporarily
OrderItem → Product	NOT NULL	Order item must reference a specific product
Comment → ParentComment	NULL allowed	Top-level comments have no parent

nullable_fk_examples.sql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
-- Optional relationship: Product may or may not have a category
CREATE TABLE products (
    product_id SERIAL PRIMARY KEY,
    product_name VARCHAR(100) NOT NULL,
    category_id INT,  -- NULL allowed: uncategorized products
    price DECIMAL(10,2) NOT NULL,
    
    FOREIGN KEY (category_id)
        REFERENCES categories(category_id)
        ON DELETE SET NULL  -- If category deleted, product becomes uncategorized
);
 
-- Mandatory relationship: Order must have customer
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT NOT NULL,  -- NOT NULL: every order needs a customer
    order_date DATE NOT NULL DEFAULT CURRENT_DATE,
    
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE RESTRICT  -- Can't delete customer with orders
);
 
-- Query handling: Include/exclude based on relationship presence
-- Find all products with their categories (excluding uncategorized)
SELECT p.product_name, c.category_name
FROM products p
JOIN categories c ON p.category_id = c.category_id;
 
-- Find all products including uncategorized
SELECT p.product_name, COALESCE(c.category_name, 'Uncategorized') AS category
FROM products p
LEFT JOIN categories c ON p.category_id = c.category_id;
 
-- Find uncategorized products specifically
SELECT product_name, price
FROM products
WHERE category_id IS NULL;

Design Decision: NULL FK vs Sentinel Value

Some systems use a 'sentinel' or 'unknown' row in the parent table instead of NULL FKs. For example, a category_id of 0 points to a special 'Uncategorized' category row. This avoids NULL handling in queries (no need for LEFT JOIN or COALESCE) but adds artificial data. Choose based on your querying patterns and team preferences.

Implementation Details Across Database Systems

While the SQL standard defines referential integrity semantics, implementations vary in important ways. Understanding these differences is crucial for cross-platform development and migration.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
-- PostgreSQL: Full referential integrity support
 
-- All referential actions supported
CREATE TABLE child_table (
    id SERIAL PRIMARY KEY,
    parent_id INT,
    
    FOREIGN KEY (parent_id) REFERENCES parent_table(id)
        ON DELETE CASCADE       -- Supported
        ON UPDATE SET NULL      -- Supported
);
 
-- Deferrable constraints (unique to PostgreSQL)
-- Check at commit instead of immediately
CREATE TABLE cyclical_a (
    id SERIAL PRIMARY KEY,
    b_id INT,
    
    FOREIGN KEY (b_id) REFERENCES cyclical_b(id)
        DEFERRABLE INITIALLY DEFERRED
);
 
-- Set constraint timing per-transaction
SET CONSTRAINTS fk_name DEFERRED;
SET CONSTRAINTS fk_name IMMEDIATE;
 
-- Partial foreign keys with expressions (PostgreSQL 15+)
-- Only enforced when condition is true
CREATE TABLE conditional_ref (
    id SERIAL PRIMARY KEY,
    type VARCHAR(10),
    ref_id INT,
    
    FOREIGN KEY (ref_id) REFERENCES other_table(id)
        WHERE type = 'linked'   -- Only enforced for type='linked' rows
);
 
-- Check existing constraints
SELECT 
    tc.constraint_name,
    tc.table_name,
    kcu.column_name,
    ccu.table_name AS foreign_table,
    ccu.column_name AS foreign_column
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu
    ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage ccu
    ON tc.constraint_name = ccu.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY';

SQLite Warning

SQLite has foreign key support OFF by default. If you're using SQLite and haven't explicitly run PRAGMA foreign_keys = ON, your foreign key constraints are being completely ignored. This is a common source of data corruption in applications using SQLite without proper configuration.

Performance Considerations

Referential integrity enforcement has performance implications that should be understood and optimized:

Cost of constraint checking:

Every INSERT into a child table requires looking up the parent row to verify the FK value exists. Every DELETE from a parent table may require scanning child tables to check for referencing rows (unless CASCADE is used). Every UPDATE to a primary key value may need similar checks and cascading updates.

Performance Optimization Strategies

•Index foreign key columns — The parent table lookup uses an index. The child table check on DELETE uses an index if one exists on the FK column. Without an index, the child table is fully scanned.
•Batch operations carefully — Deleting 10,000 parent rows with CASCADE triggers 10,000 checks and possibly 10,000+ child deletions. Consider deleting children first in batches.
•Defer constraints for bulk loads — When loading large datasets, deferring constraint checks to transaction commit can improve performance significantly.
•Avoid unnecessary FKs — Not every relationship needs a foreign key constraint. Log tables, analytics data, and append-only tables often skip FKs for performance.
•Use surrogate integer keys — Integer comparisons are faster than string comparisons. Foreign keys on INT columns outperform those on VARCHAR.

fk_performance.sql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
-- ALWAYS index foreign key columns
CREATE TABLE order_items (
    item_id SERIAL PRIMARY KEY,
    order_id INT NOT NULL,
    product_id INT NOT NULL,
    quantity INT NOT NULL
);
 
-- Create indexes on FK columns (essential for performance)
CREATE INDEX idx_order_items_order_id ON order_items(order_id);
CREATE INDEX idx_order_items_product_id ON order_items(product_id);
 
-- Now add the foreign keys
ALTER TABLE order_items
ADD CONSTRAINT fk_order_items_order
    FOREIGN KEY (order_id) REFERENCES orders(order_id);
 
ALTER TABLE order_items
ADD CONSTRAINT fk_order_items_product
    FOREIGN KEY (product_id) REFERENCES products(product_id);
 
-- PostgreSQL: Check if FK columns are indexed
SELECT 
    tc.table_name,
    kcu.column_name AS fk_column,
    CASE 
        WHEN idx.indexname IS NOT NULL THEN 'Indexed'
        ELSE 'NOT Indexed!'
    END AS index_status
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu ON tc.constraint_name = kcu.constraint_name
LEFT JOIN pg_indexes idx ON idx.tablename = tc.table_name 
    AND idx.indexdef LIKE '%' || kcu.column_name || '%'
WHERE tc.constraint_type = 'FOREIGN KEY'
    AND idx.indexname IS NULL;  -- Show only unindexed FKs
 
-- Bulk load with deferred constraints
BEGIN;
SET CONSTRAINTS ALL DEFERRED;
 
-- Bulk insert operations here (constraint checks delayed)
INSERT INTO orders SELECT * FROM staging_orders;
INSERT INTO order_items SELECT * FROM staging_order_items;
 
COMMIT;  -- All constraint checks happen here

Missing FK Indexes = Poor Performance

One of the most common database performance problems is missing indexes on foreign key columns. When you delete or update a parent row, the database must check if any child rows reference it. Without an index on the FK column, this requires a full table scan of the child table—potentially devastating for large tables.

Summary: Referential Integrity Mastery

Referential integrity is the guardian of relational consistency. Let's consolidate the essential knowledge:

Key Takeaways

•Definition — Referential integrity requires that every non-NULL foreign key value must match an existing primary key in the referenced table.
•Foreign keys encode relationships — They are promises that the referenced entity exists; referential integrity enforces the promise.
•Referential actions — CASCADE, SET NULL, SET DEFAULT, RESTRICT, and NO ACTION define automatic responses to violations.
•Self-referencing — Tables can reference themselves for hierarchical relationships; root entities have NULL foreign keys.
•Nullable FKs — Represent optional relationships; NULL means 'no relationship' rather than 'unknown relationship.'
•Implementation varies — SQLite requires explicit enabling; MySQL requires InnoDB; each system has unique behaviors.
•Performance matters — Always index FK columns; use deferred constraints for bulk loads; understand the cost of CASCADE.

What's next:

Entity integrity ensures each row is identifiable. Referential integrity ensures relationships are valid. The next page explores Domain Constraints—the rules that govern what values are valid for individual columns, ensuring that data not only exists and connects properly, but contains meaningful, valid values.

Page Complete

You now have a comprehensive understanding of referential integrity—from its formal definition through foreign key syntax, referential actions, self-referencing patterns, and performance optimization. Combined with entity integrity, you can design schemas that prevent the most common data corruption scenarios.