In simple databases with one or two tables and only one user entering data it is easy to ensure that the data remains consistent.
For example, if a Stories on CD supplier changed its company name, it would be relatively straightforward for a single user to update the name in a Vendors table and in an Items table that identified that company as the vendor for that product.
When you create a larger database or grant multiple users access to a database, it becomes harder to keep track of which data has been entered and changed.
As an example, consider the CUSTOMER and ORDER tables.

The two tables share the CustID field, which is the primary key in the CUSTOMER table and a foreign key in the ORDER table. For a record in the ORDER table to make sense, there must be an associated record in the CUSTOMER table.
Your RDBMS can make sure no one enters unmatched foreign keys into your tables by enforcing referential integrity. In terms of the preceding example, enforcing referential integrity means that if you attempted to enter an order and typed in a nonexistent CustID, the database system would inform you that there was no matching record in the CUSTOMER table and prevent you from writing the record to the database.
A database satisfies the referential integrity rule if and only if for every tuple containing a reference there exists a referent.
The next lesson concludes this module.