The Database Design Resource Center



Referential integrity explained: Bonding tables together

In an ordinary database design, referential integrity is a key component. Have you ever wondered what this term really means? I have. Let us explore Referential Integrity together. But first, get yourself a cup of coffee, as we need to work a little on this topic.

Let us break up the phrase (Which is always a smart thing to do: If it's not overseeable; break it down until you can study a small part of the problem which is seeable).

Let us look up the word referential: A dictionary will give an explanation like this:<> Ref`er*en"tial: Containing a reference; pointing to something out of itself;

Hmm, something outside itself...not contained inside, but outside.

Now, let us check out integrity: A new lookup gives us the following:

The state of being unimpaired; soundness. The quality or condition of being whole or undivided; completeness.

I really like that one; That spells that something is not broken, but sound and complete.

Together the two words actually spell:

Referential integrity means just that pointers from something to something outside itself are sound and unbroken.

In database design, the term referential integrity simply means that if a row in a table has a pointer to a row in another table, the row in the table that is pointed at, must be sound (exist). Said another way, you should not remove a row which contains information that other row(s) depend on.

The following example will further clarify this. Take this simple server model:

Referential integrity

This is a model that should be easy to understand: We have two tables, TRANSACTIONS and ACCOUNTS. F or a given account, there may be one or many (or none) transactions. Sounds fair enough: If you are like me, your bank account have far to many transactions each month. OK, I'll be serious again.

But let us look at it once more: Let us say that the above model is for a bank with lots of accounts and transactions: What if we just deleted all (or just one) accounts?

We would end up with a lot of transactions, but if we wanted to check out which name each transaction belonged to, we couldn't tell! Referential integrity is broken: It is no longer, as defined above, sound and unbroken.

It goes without saying that this is a very unhealthy situation for an information system that is relying upon a good database design.

Referential integrity is a concept to be taken dead serious: From the little example above, I'm certain that you can see the dangers of breaking referential integrity. But do you also notice the danger of changing the value of the primary key in ACCOUNTS? Giving an account a new number, will just as effectively break the rule of referential integrity as deleting the very same row. That is why it is so important to be absolutely sure when you choose your primary key for ANY table. Oh, come to think of it, we are now talking about the subject of another article on my site: Candidate Keys . I consider that as a very important article, and it has been published on many prominent sites on the Net. (That does NOT imply that my site is not prominent...). However, the original is on this site. Referential integrity

Now let's return to the real subject: How can we enforce (be sure) that referential integrity is maintained?

A long, long time ago, before the database world had really powerful products, referential integrity was programmed in each application SW piece. Image all the possible sources for bugs popping up all over the place!

A relational database system supports the enforcement of referential integrity as constraints (Read more about Oracle database constraints): Special definitions done via the DDL (Data Definition Language) part of the database. Let us look at how these constraints can be defined by using Oracle's DDL (I have the full script also for SQL Server in the Database Normalization eBook). The constraint definitions look like this:

Referential integrity

The first two ALTER-statements are establishing the primary key for each table. The third statement is the important one in our context: It tells Oracle that the ACCOUNT_NO in TRANSACTIONS is referencing the primary key ACCOUNT_NO in ACCOUNTS, and that Oracle should see to it that any references from TRANSACTIONS to a given account in ACCOUNTS should never be broken. And, if you delete a row in ACCOUNTS that has TRANSACTIONS, then that's exactly what you are trying to do!

Actually, the last constraint definition also establishes ACCOUNT_NO in TRANSACTIONS as a foreign key for ACCOUNTS. That is really most of the difference between primary and foreign keys: A primary key in one table becomes a foreign key in tables it has a mother-child relation to. But; that's a different article for some day to come...

Back to the topic: Let us take this a bit further; The following example shows you the two tables and which rows they contain (For the TRANSACTIONS table I have selected only the interesting columns). Now, look at the end of it: I try to delete the row in ACCOUNTS, and I promptly (and correctly) get the error message.

Referential integrity

Isn't that nice?: The database is actually stopping me, and preventing me from breaking the referential integrity between ACCOUNTS and TRANSACTIONS. And rightfully so.

The next question then arises: How does your application detect this? The answer is: By comprehensive error detection procedures. Yes, procedures: Stored procedures that throw exceptions when an error occurs. That way, no matter what application is running, it bumps into constraint control, error processing logic and error handling that is defined outside the application itself.

However, that is also the subject of a completely different article. For now, I hope you have gotten a few ideas for your own database design and application development, as well as I hope that the "mystery" of referential integrity is unveiled.

Return to Primary and Foreign Keys

Exclusive interviews with:
Steven Feuerstein, PLSQL expert
Donald Burleson, Top IT consultant


Free eBook

Subscribe to my newsletter and get my ebook on Entity Relationship Modeling Principles as a free gift:


What visitors say...

"I just stumbled accross your site looking for some normalization theory and I have to say it is fantastic.

I have been in the database field for 10+ years and I have never before come across such a useful site. Thank you for taking the time to put this site together."

Mike, USA

Read more Testimonials



Database Normalization eBook:


Database Normalization eBook




Copyright © www.databasedesign-resource.com / Alf A. Pedersen
All rights reserved.
All information contained on this website is for informational purposes only.
Disclaimer: www.databasedesign-resource.com does not warrant any company, product, service or any content contained herein.

Return to top

Copyright acknowledgement note:

The name Oracle is a trademark of Oracle Corporation.
The names MS Access/MS SQL Server are trademarks of Microsoft Corporation.
Any other names used on this website may be trademarks of their respective owners, which I fully respect.