Integrity Constraints in DBMS: Domain, Key, Entity & Referential Integrity

DBMS Chapter 07 · Integrity Control Center
Integrity Constraints in DBMS: Domain, Key, Entity & Referential Integrity

Integrity constraints are rules that keep database data valid, consistent and meaningful. Domain integrity controls what values are allowed in a column, key constraints protect uniqueness, entity integrity makes sure every row can be identified through a non-NULL primary key, and referential integrity keeps foreign-key references valid. In this chapter, you will learn not only the definitions, but also exactly what happens during INSERT, UPDATE and DELETE operations, how NULL behaves, how foreign keys work, and when CASCADE, SET NULL, RESTRICT and related actions are useful.

Deep A-to-Z chapter Interactive violation lab SQL examples Foreign-key actions Mobile-friendly visuals Checked: 18 September 2026
Start with the real problem

What Are Integrity Constraints in DBMS?

Integrity Constraints in DBMS: Domain, Key, Entity & Referential Integrity

Integrity constraints are conditions that valid database data must satisfy. They prevent impossible, duplicate, unidentified or wrongly linked records from entering the database.

Imagine a college database that accepts anything without rules. A student could have semester 99, two students could have the same student ID, a row could exist without any primary-key value, or a fee record could point to a student who does not exist. The database would still contain data, but the data would no longer be trustworthy.

That is why the relational model uses constraints. They act like guards around the data.

Domain IntegrityIs this value allowed here?
Key ConstraintIs this identifier unique?
Entity IntegrityCan this row be identified?
Referential IntegrityDoes this reference point to a valid row?

Shortcut #1: D-K-E-R

D = Domain · K = Key · E = Entity · R = Referential

Think of four questions: Allowed? Unique? Identifiable? Valid reference?

If relation, tuple, attribute, domain, keys or foreign keys are still new, first revise Relational Model in DBMS: Relation, Tuple, Attribute & Domain Explained. This chapter builds directly on that foundation.

See violations before memorising definitions

Interactive Integrity Constraint Violation Lab

Use the buttons below. Each one creates a different invalid situation in a small college database.

Constraint Tester

Parent table: DEPARTMENT. Child table: STUDENT.

student_id (PK)namesemesterdepartment_id (FK)
S01Asha2D01
S02Ravi2D02
Valid state: IDs are unique and non-NULL, semester values are allowed, and each department reference exists.

This visual lab is a teaching model. A real DBMS checks constraints using the actual schema definition, SQL rules and transaction behavior.

Core definitions

The Four Main Integrity Constraints

Domain Integrity Every attribute value must come from the allowed domain for that attribute. Example: semester should contain valid semester values, not 99 or random text.
Key Constraint Values of a candidate key must uniquely identify tuples. Two different rows cannot have the same candidate-key value combination.
Entity Integrity No component of the primary key can be NULL, because every tuple must be identifiable through the primary key.
Referential Integrity A foreign-key value must match a permitted referenced key value in the parent relation, unless the foreign key is allowed to be NULL.

Shortcut #2: Value → Unique → Identify → Reference

Domain checks the value. Key checks uniqueness. Entity integrity guarantees identification. Referential integrity protects references.

Constraint 01

Domain Integrity in DBMS

A domain defines the meaningful values that an attribute is allowed to take. Domain integrity makes sure stored values stay inside that permitted set.

Allowed Semester Domain

12345678
→

STUDENT.semester

Valid: 1, 2, 5, 8
Invalid for this design: 0, 9, "final", 99

How is domain integrity enforced in SQL?

Depending on the database system and design, domain rules can be enforced using datatypes, NOT NULL, CHECK constraints, generated rules, reference tables and application-level validation.

CREATE TABLE Student (
  student_id   VARCHAR(20) PRIMARY KEY,
  name         VARCHAR(100) NOT NULL,
  semester     INT NOT NULL,
  email        VARCHAR(150),
  CHECK (semester BETWEEN 1 AND 8)
);

Here, INT prevents text like “hello” from being treated as a normal integer semester value, while the CHECK constraint restricts the accepted range to 1 through 8.

Datatype alone is not a complete domain rule

If semester is an integer, the datatype might still allow values like 500 unless an additional rule blocks them. So the real business domain is often narrower than the technical datatype.

Shortcut #3: Datatype says “what kind”; domain says “which values”

INTEGER ≠ valid semester range

More domain-integrity examples

Marks0 to 100.
CreditsPositive values from an approved set.
StatusACTIVE, INACTIVE, SUSPENDED.
Date of birthA valid date according to the database type and business rules.
EmailMay require length, format and uniqueness rules depending on the system.
Department IDUsually also participates in referential integrity when it references another relation.
Constraint 02

Key Constraint in DBMS

A key constraint protects uniqueness. If an attribute set is a candidate key, no two distinct tuples are allowed to have the same key value combination.

Super KeysAll unique identifying sets
Candidate KeysMinimal unique sets
Primary KeyChosen candidate key
Alternate KeysOther candidate keys

Suppose both student_id and email are unique for every student. Then both can be candidate keys. If student_id is selected as the primary key, email can still be protected as an alternate key using a UNIQUE constraint.

CREATE TABLE Student (
  student_id VARCHAR(20) PRIMARY KEY,
  email      VARCHAR(150) UNIQUE,
  name       VARCHAR(100) NOT NULL
);

Duplicate primary key example

Allowed

INSERT INTO Student
VALUES ('S01', 'asha@example.com', 'Asha');

S01 does not exist yet, so the primary key remains unique.

Rejected

INSERT INTO Student
VALUES ('S01', 'ravi@example.com', 'Ravi');

If S01 already exists, the insert violates the primary-key uniqueness rule.

Composite candidate keys

A key does not have to contain only one attribute. In ENROLLMENT, (student_id, course_id) may be a composite candidate key if one student can have at most one active enrollment record for one course.

The advanced key chapter explains this hierarchy in more depth: Keys, Mapping Constraints, Generalization & Aggregation in ER Model.

Constraint 03

Entity Integrity in DBMS

Entity integrity says that the primary key of a relation cannot contain NULL. Every tuple must have a definite identity.

Valid Student

student_id: S01
name: Asha

The tuple can be identified clearly.

Invalid Student

student_id: NULL
name: Ravi

There is no valid primary-key identity for this tuple.

Why is NULL not allowed in the primary key?

A primary key exists to identify one exact tuple. NULL represents absence of a normal value, so a NULL primary key would fail at the basic job of identification.

What if the primary key is composite?

If the primary key is made from multiple attributes, each component is part of the tuple's identity. In SQL primary-key constraints, the primary-key columns are non-NULL.

CREATE TABLE Enrollment (
  student_id VARCHAR(20),
  course_id  VARCHAR(20),
  grade      VARCHAR(5),
  PRIMARY KEY (student_id, course_id)
);

Here, both student_id and course_id are required as parts of the composite primary key.

Shortcut #4: Entity Integrity = “No nameless primary identity”

Primary Key → UNIQUE + NOT NULL identity
Constraint 04

Referential Integrity in DBMS

Referential integrity protects relationships between relations.

Suppose we have a parent relation DEPARTMENT and a child relation STUDENT.

DEPARTMENT

department_id (PK)name
D01Computer Science
D02Electronics

STUDENT

student_idnamedepartment_id (FK)
S01AshaD01
S02RaviD02

The foreign key STUDENT.department_id refers to a key in DEPARTMENT. A student cannot normally point to department D99 if D99 does not exist in the referenced parent key.

Basic referential-integrity rule

Shortcut #5: Foreign key has two safe states

FK = matching parent key OR permitted NULL

Whether NULL is permitted depends on the schema. If the relationship is mandatory, the foreign-key column can also be declared NOT NULL.

Invalid child insert

INSERT INTO Student
(student_id, name, department_id)
VALUES ('S03', 'Neha', 'D99');

If D99 does not exist in DEPARTMENT and a foreign-key constraint is active, the DBMS rejects the insert.

Valid NULL foreign key?

If department_id is allowed to be NULL, a student may temporarily exist without a department assignment:

INSERT INTO Student
(student_id, name, department_id)
VALUES ('S04', 'Meera', NULL);

This does not violate referential integrity because NULL is not pretending to reference a missing parent. If the relationship must be compulsory, add NOT NULL as well.

Where referential integrity becomes practical

What Happens When a Referenced Parent Row Is Updated or Deleted?

Suppose D01 is referenced by 300 students. What should happen if someone tries to delete D01 from DEPARTMENT?

The database design must define the intended referential action.

CASCADE

Related child references are automatically updated or deleted along with the parent action.

RESTRICT / NO ACTION

The parent change is rejected when dependent child references would become invalid. Exact timing semantics can vary by DBMS.

SET NULL

The child foreign key becomes NULL after the parent is deleted or changed, if that foreign key permits NULL.

SET DEFAULT

The child foreign key is set to its defined default value, where the DBMS supports the action and the result remains valid.

Example foreign-key definition

CREATE TABLE Student (
  student_id     VARCHAR(20) PRIMARY KEY,
  name           VARCHAR(100) NOT NULL,
  department_id  VARCHAR(10),

  CONSTRAINT fk_student_department
    FOREIGN KEY (department_id)
    REFERENCES Department(department_id)
    ON UPDATE CASCADE
    ON DELETE SET NULL
);

In this design, changing a referenced department ID can propagate to child rows, while deleting a department clears the student reference instead of deleting the student.

Should you always use CASCADE?

No. CASCADE is useful only when automatic propagation matches the real business meaning. For important master data, silently deleting hundreds of child rows can be dangerous. Choose the referential action based on the relationship, not convenience.

Shortcut #6: Parent change asks “Block, Follow, Clear or Default?”

RESTRICT · CASCADE · SET NULL · SET DEFAULT
NULL rules

NULL, NOT NULL and Integrity Constraints

NULL is one of the most misunderstood parts of database constraints.

Primary key cannot be NULL This is required by entity integrity.
A foreign key may be NULL Only when the schema permits an optional relationship. Add NOT NULL when the relationship must always exist.
NULL is not zero Zero is a normal numeric value. NULL represents absence of a normal value.
NULL is not an empty string An empty string is still a value in systems that distinguish it from NULL.
Use IS NULL in SQL NULL follows special SQL comparison logic and should not be treated like an ordinary value using equality.
SELECT *
FROM Student
WHERE department_id IS NULL;
Put all four constraints into one table

Complete SQL Example With Domain, Key, Entity and Referential Integrity

CREATE TABLE Department (
  department_id   VARCHAR(10) PRIMARY KEY,
  department_name VARCHAR(100) NOT NULL UNIQUE
);

CREATE TABLE Student (
  student_id      VARCHAR(20) PRIMARY KEY,
  name            VARCHAR(100) NOT NULL,
  semester        INT NOT NULL,
  email           VARCHAR(150) UNIQUE,
  department_id   VARCHAR(10),

  CHECK (semester BETWEEN 1 AND 8),

  CONSTRAINT fk_student_department
    FOREIGN KEY (department_id)
    REFERENCES Department(department_id)
    ON UPDATE CASCADE
    ON DELETE SET NULL
);

What each line protects

VARCHAR / INTBasic type-level domain restriction.
CHECK semesterNarrows the domain to the valid semester range.
PRIMARY KEYUniqueness + non-NULL identity for the primary key.
UNIQUE emailProtects an alternate candidate key where the design requires uniqueness.
NOT NULL nameBusiness/domain requirement that a normal student row must have a name.
FOREIGN KEYProtects valid Department references.
ON UPDATE CASCADEPropagates a valid referenced-key update.
ON DELETE SET NULLRemoves the reference while preserving the child row.
Think like the DBMS

How Constraints Are Checked During INSERT, UPDATE and DELETE

Operation Typical checks Possible violation
INSERT child row Domain, NOT NULL, key uniqueness, foreign-key reference Invalid semester, duplicate key, NULL primary key, missing parent
UPDATE normal column Domain and business rules Changing marks from 80 to 150
UPDATE key Uniqueness + possible referenced children Duplicate new key or orphaned foreign keys
UPDATE foreign key New reference must remain valid Changing D01 to missing D99
DELETE parent row Referential action Would leave child rows pointing to nothing
DELETE child row Usually simpler for parent reference Other business rules may still apply

This is why constraints are not just static definitions. They actively control which database states are allowed after data-changing operations.

Database rule vs app rule

Database Constraints vs Application Validation

Good applications usually validate data before sending it to the database, but important integrity rules should not depend only on the user interface.

Application Validation

Gives fast, friendly feedback such as “Semester must be between 1 and 8.” It improves user experience.

Database Constraint

Protects the data even if another application, script, import tool or developer sends invalid data directly.

For important invariants, using both is usually stronger: the application explains the problem early, and the database remains the final guard.

Where these constraints fit

Integrity Constraints and the Relational Model

The relational model is not only about storing rows and columns. A valid relation state should also respect the schema's constraints.

Think of it like this:

Relation SchemaDefines structure
DomainsDefine permitted values
KeysDefine identity and uniqueness
ConstraintsDefine valid database states

This is the natural next step after the Relational Model chapter. Relation, tuple, attribute and domain tell you what the structure is; integrity constraints tell you which data states are allowed inside that structure.

One complete real example

College Database Example: All Four Constraints Together

Suppose a college has DEPARTMENT and STUDENT relations.

Domain rule

Semester must be between 1 and 8.

Key rule

Every student_id must be unique. Email is also unique if the college uses one account per student.

Entity-integrity rule

student_id cannot be NULL.

Referential-integrity rule

If department_id is present, it must refer to an existing department.

Now test four inserts

InsertResultReason
S10, Asha, semester 3, D01AcceptAll constraints are satisfied.
S11, Ravi, semester 15, D01RejectDomain/check violation.
S10, Neha, semester 2, D02RejectDuplicate primary key.
S12, Meera, semester 1, D99RejectMissing referenced department.

This is the chapter in one picture: every invalid row fails for a different reason.

Common mistakes

Do Not Confuse These Integrity Rules

Domain integrity ≠ only datatypeDatatype may be only one part of the allowed-value rule.
Key constraint ≠ only primary keyCandidate keys also carry uniqueness requirements.
Entity integrity ≠ “all columns NOT NULL”It specifically requires the primary key to be non-NULL so tuples have identity.
Referential integrity ≠ foreign key must always be non-NULLA nullable foreign key can represent an optional relationship.
NULL ≠ missing parent referenceNULL means no normal reference value; D99 means a specific reference that may be invalid.
CASCADE ≠ always safeAutomatic propagation must match the real business rule.
UNIQUE ≠ PRIMARY KEYBoth can protect uniqueness, but a primary key has the special identity role and cannot contain NULL.
Foreign key ≠ primary key onlyIn relational systems, a foreign key references a candidate key or other permitted unique referenced key depending on DBMS rules.
App validation ≠ database integrityFrontend checks can be bypassed. Database constraints remain important final protection.
Constraint failure ≠ bad DBMSA rejected operation often means the DBMS successfully protected the database.
Write according to marks

How to Write Integrity Constraints in Semester Exams

2 marks

Definition + one example

Define the asked constraint directly. Example: “Entity integrity requires the primary key to be non-NULL so every tuple can be uniquely identified.”

5 marks

Explain four constraints

Write Domain, Key, Entity and Referential integrity with one short college example for each.

8-10 marks

Add SQL + violation cases

Explain all four constraints, show parent/child relations, add primary and foreign keys, discuss NULL and referential actions, then include SQL examples.

For exam presentation, use How to Write High-Scoring Answers in University Semester Exams. For unit prioritisation, use the previous-year-paper method.

Practice with explanations

Practice Questions With Answers

1. What is an integrity constraint in DBMS?

An integrity constraint is a rule that valid database data must satisfy. It helps prevent invalid, duplicate, unidentified or incorrectly referenced records.

2. What is domain integrity?

Domain integrity requires an attribute value to come from the allowed domain defined for that attribute.

3. What is a key constraint?

A key constraint requires candidate-key values to uniquely identify tuples, so two distinct tuples cannot share the same candidate-key value combination.

4. What is entity integrity?

Entity integrity requires the primary key to be non-NULL so every tuple has a valid identity.

5. What is referential integrity?

Referential integrity requires a foreign-key value to match a permitted referenced key value in the parent relation, unless the foreign key is allowed to be NULL.

6. Can a foreign key be NULL?

Yes, if the schema permits an optional relationship. If the relationship is mandatory, the foreign-key column can also be declared NOT NULL.

7. Can a primary key be NULL?

No. A NULL primary key would violate entity integrity because the tuple would not have a valid primary-key identity.

8. What is ON DELETE CASCADE?

It is a referential action that automatically deletes dependent child rows when the referenced parent row is deleted. It should be used only when that behavior matches the data model.

9. What is the difference between SET NULL and RESTRICT?

SET NULL removes the child reference by making the foreign key NULL, while RESTRICT blocks the parent change when dependent references exist.

10. Why are database constraints needed if an application already validates input?

Other applications, scripts, imports or direct database access can bypass one user interface. Database constraints protect the data at the database layer itself.

60-second revision

Integrity Constraints One-Minute Revision Sheet

Domain IntegrityValue must come from the allowed domain.
Key ConstraintCandidate-key values must be unique.
Entity IntegrityPrimary key cannot be NULL.
Referential IntegrityForeign key must match a valid referenced key or be permitted NULL.
CHECKEnforces a condition such as semester between 1 and 8.
UNIQUEProtects uniqueness for a candidate/alternate key.
NOT NULLRequires a normal value to be present.
FOREIGN KEYRepresents a reference between relations.
CASCADEPropagates the parent action to children.
SET NULLClears the child reference when allowed.
RESTRICTBlocks a parent action that would break references.
Best shortcutAllowed? Unique? Identifiable? Valid reference?
Frequently asked questions

Frequently Asked Questions

What are the four main integrity constraints in DBMS?

The four commonly taught integrity constraints are domain integrity, key constraints, entity integrity and referential integrity.

What is the difference between entity integrity and referential integrity?

Entity integrity protects the primary-key identity of a tuple by disallowing NULL primary keys. Referential integrity protects relationships by requiring foreign-key references to remain valid.

What is the difference between domain constraint and key constraint?

A domain constraint checks whether a value is allowed for an attribute. A key constraint checks whether identifying values remain unique.

Can a foreign key contain NULL?

Yes, when the schema permits the relationship to be optional. A NOT NULL constraint can be added when every child row must have a parent reference.

What happens when a parent row referenced by a foreign key is deleted?

The result depends on the referential action defined by the schema, such as blocking the delete, cascading it to child rows, setting child foreign keys to NULL, or another supported action.

What should I study after integrity constraints?

Study relational algebra, SQL constraints in depth, functional dependencies and normalization. These topics build directly on valid relational design.

Next chapter

What Should You Learn After Integrity Constraints?

Next: Relational Algebra

You now know what a valid relational database state looks like. The next step is to learn how relations are transformed and queried using Relational Algebra: selection, projection, union, set difference, Cartesian product, rename and joins.

After relational algebra, continue with SQL, functional dependencies and normalization. For video revision after understanding the written chapter, you can use the DBMS YouTube study guide as a secondary resource.

Tags

Post a Comment

0 Comments
* Please Don't Spam Here. All the Comments are Reviewed by Admin.
Join Telegram Exam updates and free resources