Data integrity means a database's data stays accurate, consistent, and trustworthy over time — not just correct the moment it's entered.
Why This Matters
- This chapter is deliberately the last one in this section, and works as a preview: everything you've just learned — domains, schemas, rows that shouldn't lose information when others change — exists in service of one goal.
- The next several sections (Keys, Constraints) are the actual tools for enforcing it.
Core Concept
- Data Integrity is the overall property of a database's data being accurate, consistent, and reliable — both when it's first entered and as it continues to change over time.
- It's not one single rule — it's an umbrella covering several more specific kinds of correctness you'll meet by name soon: domain integrity (values match their true domain), entity integrity (every row can be uniquely and reliably identified), and referential integrity (relationships between tables stay consistent).
Deep Dive
- A database can be perfectly readable and well-formatted while still having terrible data integrity — for example, an order that references a customer who no longer exists is a data integrity failure, not a syntax error.
- Most of the mechanisms this course covers from here on — primary keys, foreign keys, constraints — exist specifically to enforce one kind of data integrity or another, automatically, so it doesn't depend on every application getting every write correct by hand.
Common Mistakes
Assuming data integrity is something the application layer alone is responsible for.
Why: If only application code enforces correctness, any other program, script, or direct database access that skips that code can silently corrupt the data.
Fix: Push as much data integrity enforcement as possible into the database itself (via keys and constraints), so it holds regardless of what's writing to it.
Interview Questions
What is data integrity, and why isn't it just one single rule?
Data integrity is the overall accuracy, consistency, and reliability of a database's data over time. It's an umbrella term covering several distinct concerns — domain integrity, entity integrity, and referential integrity among them — each enforced by different mechanisms.
Why is it safer to enforce data integrity in the database itself rather than only in application code?
Application-level checks only protect data written through that specific application — any other process, script, or direct access bypasses them entirely. Enforcing integrity in the database, through keys and constraints, makes it hold regardless of what's writing to it.
Best Practices
Do
✓Enforce integrity rules in the database itself wherever possible, not only in application code.
✓Think of data integrity as several distinct concerns (domain, entity, referential), not one vague goal.
Don't
✗Don't rely solely on application-level validation for data that must always be correct.
✗Don't treat "the data looks fine right now" as proof of integrity — integrity is about staying correct as the data changes, not just its current snapshot.
Chapter Summary
Data integrity is the overall goal of a database's data staying accurate and consistent over time — an umbrella covering domain, entity, and referential integrity. Every tool in the next several sections of this course exists to enforce one piece of it.