Integrity Constraints

Someone types a grade of "banana".

Someone else adds a student with no roll number.

A third person records a grade for roll GGG, who doesn't exist.

Nobody is being malicious. It's a Tuesday. Who stops them?

Why & what

Back in 1.1 you learned that a DBMS is storage plus enforced rules. This topic is those rules, by name.

They're worth taking seriously because bad data doesn't announce itself. It sits quietly until a report is wrong, and then nobody can tell which rows to trust.

An integrity constraint is a rule the database enforces on every insert, update and delete. If a change would break the rule, the change is refused.

Three constraints matter for interviews.

How it works

You know what primary and foreign keys are now. These rules are built on them.

1. Domain integrity — is this value even allowed? Every column has a type and a set of permitted values. grade accepts A, B, C. So "banana" is refused. So is a birth date of 32-13-2026.
2. Entity integrity — does this row have an identity? The primary key can't be NULL and can't repeat. A student row with no roll_no is refused, because you'd never be able to find or update it again. Insert roll 101 twice and the second one is refused too.
3. Referential integrity — does the thing I'm pointing at exist? A foreign key must match a real row in the other table, or be NULL. Enrollment with roll_no = 999 is refused, because no such student exists.
4. Then someone deletes Aisha. Her enrollments still point at roll 101. What now? You choose the behaviour up front: oCASCADE — delete her enrollments too oRESTRICT — block the delete while enrollments exist oSET NULL — keep the enrollments but blank out the link
5. Notice what all three have in common. None of them fix the data or guess your intent. They refuse the change and tell you. That's the whole design: better a rejected insert than a quietly wrong database.

Notice: all three do the same job — refuse the row, keep the data true.

Common confusion

People mix up entity and referential integrity, because both involve keys. Split them by which table the problem is in:

• Entity integrity — about this row's own primary key. Is it present and unique?
• Referential integrity — about a row in another table. Does the thing my foreign key points to exist?

Inside vs outside. That's the whole difference.

Second one: NULL is not zero, and not an empty string. NULL means "no value here." A grade of 0 means the student scored zero. A grade of NULL means nobody has entered a grade yet. Two very different facts, and treating them as the same is how averages come out wrong.

Interview angle

1. "What are the main integrity constraints?" — Domain (valid values), entity (primary key not NULL and unique), referential (foreign key must point at something real). One quick example each is better than three definitions.
2. "What happens if you delete a row another table points at?" — It depends on the rule you set: CASCADE deletes the children, RESTRICT blocks the delete, SET NULL clears the link. Say that the choice is made when you design the table, not when the delete happens.
3. "Difference between entity and referential integrity?" — Entity is about this row's own primary key; referential is about whether the row you point at exists. Inside versus outside.
4. "Why does the database refuse bad data instead of just correcting it?" — Because correcting means guessing your intent, and a wrong guess spreads silently. A rejected insert is visible; a quietly wrong row isn't.

Recap

Integrity constraints are rules enforced on every change — domain (valid values), entity (primary key present and unique), referential (foreign key points at a real row) — and a change that breaks one is refused, not fixed.