Data Reliability, Data Platforms

How to Maintain Referential Data Integrity

referential data integrity

Lindsay MacDonald

Lindsay is a Content Marketing Manager at Monte Carlo.

Referential integrity in a database is like making sure all the kids on a school trip have permission slips. Each kid’s name on the trip list must refer back to the same name on a valid permission slip. 

Simply put, “referential” pertains to the references or links between data in different tables, while “integrity” refers to the accuracy and consistency of the data.

Referential data integrity is the golden rule databases follow to ensure the relationships between tables remain consistently accurate, even as records are updated or deleted.

In this blog post, we’ll explain how referential data integrity works, why it matters, and practical ways you can enforce and handle it effectively.  

How Do You Keep Referential Integrity?

Referential data integrity is achieved through the use of foreign keys, which link records in different tables. For instance, think about a business that has a Customers table and an Orders table. The CustomerID in the Orders table acts as a foreign key, referencing the CustomerID in the Customers table. This ensures every order is linked to a valid customer.

Customers and orders table referential integrity example

Here’s a practical example of referential integrity:

    FirstName VARCHAR(50),
    LastName VARCHAR(50)

    OrderDate DATE,
    Amount INT,
    CustomerID INT,
    FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)

In this setup, the foreign key constraint on CustomerID in the Orders table enforces that any CustomerID value must already exist in the Customers table, maintaining the integrity of the relationship.

Domain Integrity vs. Referential Integrity

But remember, this isn’t the same as domain integrity. The difference between domain integrity and referential integrity is that domain integrity only ensures the correctness of data within a single table, while referential integrity ensures the validity of relationships between tables.

Rules of Referential Integrity

There are three rules of referential integrity:

  1. Insert Rule: A new record cannot be added to a child table if the foreign key does not match an existing value in the parent table.
  2. Update Rule: A record in the parent table cannot be updated if it would create orphaned records in the child table.
  3. Delete Rule: A record cannot be deleted from the parent table if there are matching records in the child table.

For instance, if I try to insert an order with a CustomerID that doesn’t exist in the Customers table, I’d run into this example of a referential data integrity violation:

INSERT INTO Orders (OrderID, OrderDate, Amount, CustomerID)
VALUES (1, '2024-06-01', 100, 999); -- Assuming 999 is not a valid CustomerID

And get this error in MySQL:

ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`database_name`.`Orders`, CONSTRAINT `fk_Orders_Customers` FOREIGN KEY (`CustomerID`) REFERENCES `Customers` (`CustomerID`))

Violations like this would cause issues, including:

Data Inconsistency:

  • Orphan Records: Child records that reference non-existent parent records.
  • Redundant Data: Duplicate or conflicting data entries.

Operational issues:

  • Application Errors: Missing links between data increase errors in applications.
  • System Downtime: Poor error handling can lead to system crashes.

Decision-making problems:

  • Inaccurate Reports: Faulty data leads to bad analytics and poor business decisions.

Maintaining referential data integrity is essential to ensure the accuracy, reliability, and usability of your database.

How to Enforce Referential Data Integrity

To avoid these issues, I follow these database design principles:

  1. Normalization: I organize data to reduce redundancy and improve integrity by dividing large tables into smaller, more manageable pieces.
  2. Constraints: Similar to foreign keys, these other constraints can be added to columns:
    • ON DELETE CASCADE: Deletes child records if the parent record is deleted.
    • ON UPDATE CASCADE: Updates child records if the parent record is updated.
  3. ACID Transactions: Ensure reliable processing by guaranteeing atomicity, consistency, isolation, and durability.

Best Practices

Some other best practices are:

  • Enforcement at the Application Level: Make sure your application logic enforces referential integrity rules.
  • Use Indexes: Utilize indexes to improve the performance of referential integrity checks.

Implementing these principles helps maintain a consistent and reliable database, minimizing data integrity issues and ensuring smooth operations.

Example of Referential Integrity Testing

A simple method I use for testing referential integrity is to input incorrect data and ensure it is rejected by the system. For example:

INSERT INTO Orders (OrderID, OrderDate, Amount, CustomerID)
VALUES (1, '2024-06-01', 100, 999); -- Assuming 999 is not a valid CustomerID

If the database rejects this statement, it means that our referential integrity constraints are functioning correctly.

Tools for Maintaining Data Integrity

Various tools can assist in maintaining data integrity:

  • Database Management Systems: Systems like MySQL, PostgreSQL, and Oracle have built-in mechanisms for enforcing referential integrity.
  • Monitoring and Observability Tools: Tools like Monte Carlo offer automated data observability, alerting you to data integrity issues as soon as they occur.

When Violations Occur

If violations are detected, address them promptly. Here are some options I recommend:

  • Remove orphan records in the child table.
  • Insert missing records into the parent table.
  • Correct non-existent foreign keys by updating them to existing ones.

By following these steps and using the appropriate tools, we can effectively handle referential data integrity violations and maintain a reliable database.

Automate Referential Data Integrity Testing with Monte Carlo

The concept of referential data integrity emerged in an earlier era of data management when data was far more static and structured.

Today, data is distributed across multiple databases, driven by trends like microservice-based architectures and cloud-based solutions. Additionally, the rise of NoSQL databases, which often lack built-in referential integrity, and the performance demands of real-time systems makes maintaining data integrity more challenging than ever.

That’s why data observability solutions like Monte Carlo are essential.

Interested in how data observability can monitor your data pipelines, detect issues, and understand the context around data to ensure not just integrity, but all the data quality metrics that matter? Schedule time to talk to us in the form below!

Our promise: we will show you the product.

Frequently Asked Questions

What is an example of referential data integrity violation?

An example of a referential data integrity violation is when a record in a child table references a non-existent record in the parent table. For instance, adding an order that references a customer ID that doesn’t exist in the customer table.

What is an example of referential integrity testing?

An example of referential integrity testing is to input incorrect data that references non-existent records in a related table and ensure the database rejects it. For example, trying to insert a transaction that references an invalid user ID to verify the system enforces integrity constraints.

What is the difference between entity integrity and referential integrity?

Entity integrity ensures the correctness of data within a single table, while referential integrity ensures the validity of relationships between tables.