ENFORCING INTEGRITY

CONSTRAINTS
Presented by : Y Sharmisha
ENFORCING INTEGRITY CONSTRAINTS:
• Integrity constraints are a set of rules.

• It is used to maintain the quality of information.

•  Integrity constraints ensure that the data insertion, updating, and other processes have to be performed in
such a way that data integrity is not affected.

• It is specified that when a relation created and enforced when a relation is modified.

• The impact of domain, primary key and unique constraints is straight forward : if an insert, delete or
update command causes a violation then it is rejected.

• Every potential Integrity constraint violation is genuinely checked at the end of each SQL statement
execution, although it can be defined until the end of the transaction.

• Example of executing the statements we use the terms : Fields (Attributes, Columns)
: Tuples (Records, Rows)
The below is the table which explains about attributes and tuples

SID NAME LOGIN AGE CGPA

50000 Dave dave@cse 19 3.3

53666 Jones jones@cse 18 3.4

53688 Smith smith@ee 18 3.2

53650 Smith smith@math 19 3.8

53831 Mahesh mahesh@music 11 1.8

53832 Guru guru@music 12 2.0

Transact-SQL provides several mechanisms for integrity enforcement in a database such as rules, defaults, indexes, and
triggers. These mechanisms allow you to maintain these types of data integrity:

• Requirement – requires that a table column must contain a valid value in every row; it cannot allow null values.
The create table statement allows you to restrict null values for a column.

• Check or validity – limits or restricts the data values inserted into a table column. You can use triggers or rules to
enforce this type of integrity.

• Uniqueness – no two table rows can have the same non-null values for one or more table columns. You can use indexes
to enforce this integrity.

• Referential – data inserted into a table column must already have matching data in another table column or another
column in the same table. A single table can have up to 192 references.

• As an alternative to using rules, defaults, indexes, and triggers, Transact-SQL provides a series of integrity
constraints as part of the create table statement to enforce data integrity as defined by the SQL standards.
The following insertion relates the primary key constraint because there is already a tuple with the SID 53688 and it will be
rejected by the DBMS :

INSERT
INTO Students (SID, NAME, LOGIN, AGE, CGPA) VALUES (53688, ‘Mike’, ’mike@ec’, 17, 3.4);

The following insertion violates the constraints that the primary key cannot contain null in the DBMS :

INSERT
INTO Students (SID, NAME, LOGIN, AGE, CGPA) VALUES (null, ‘Mike’, ’mike@ec’, 17, 3.4);

Deletion does not cause a violation of domain, primary key or unique constraints. However, an update can cause violations,
similar to an insertion:

UPDATE Students S
SET S.SID = 50000
WHERE S.SID = 53688

This update violates the primary key constraint because there is already a tuple with SID 50000
The Referential Integrity Enforcement steps taken by the DBMS in terms of our Enrolled and Students table, with the
foreign key constraint that Enrolled SID is a reference to Students.

With the references of Referential Integrity Figure:

Deletion of Enrolled Tuples do not violate Referential Integrity, but insertion of Enrolled Tuples could. The
following insertion is illegal because there is no Students Tuple with SID 51111

INSERT
INTO Enrolled (SUBJID, GRADE, SID) VALUES (‘HINDI101’, ‘B’, 51111);

Consider Students and Enrolled Tables:

SID in enrolled is a foreign key that references the student table.

NOTE:

• If an enrolled tuple with a non existent Students ID is inserted then DBMS Reject it.

• If a Student S Tuple is deleted then DBMS delete all enrolled Tuples that refer to it.

• Disallow deletion of a Students tuple that is referred to.

• Set SID in Enrolled tuples that refer to it to a default SID.

DATA INTEGRITY :

• Data integrity refers to the accuracy, consistency, and reliability of data that is stored in the database.

• Both database designers and database developers are responsible for implementing data integrity within one or a set of
related databases.

• A simple example is that in any one of the table, Student ID must be unique no matter how many records the table holds. If
this rule is not enforced, Student Department category could be accidentally stored twice in the table which clearly violates
DBMS rules.

Data integrity is enforced by database constraints :

Database Constraints are declarative integrity rules of defining table structures. They include the following 7 constraint types:

Data type constraint :

This defines the type of data, data length, and a few other attributes which are specifically associated
with the type of data in a column.

Default constraint :
This defines what value the column should use when no value has been supplied explicitly when
inserting a record in the table.
Nullability constraint :
This defines that if a column is NOT NULL or allow NULL values to be stored in it.

Primary key constraint :

This is the unique identifier of the table. Each row must have a distinct value. The primary key can
be either a sequentially incremented integer number or a natural selection of data that represents what is happening in the real
world (e.g. Social Security Number). NULL values are not allowed in primary key values.

Unique constraint :
This defines that the values in a column must be unique and no duplicates should be stored.
Sometimes the data in a column must be unique even though the column does not act as Primary Key of the table. For example
Category Name column is unique in categories table but Category Name is not primary key of the table.

Foreign key constraint :

This defines how referential integrity is enforced between two tables.

Check constraint :
This defines a validation rule for the data values in a column so it is a user-defined data integrity
constraint. This rule is defined by the user when designing the column in a table. Not every database engine supports check
constraints. As of version 5.0, MySQL does not support check constraint. But you can use Enum data type or set data type to
achieve some of its functionalities that are available in other Relational Database Management Systems (Oracle, SQL Server,
etc.)
 Data integrity type Enforced by database constraint

Row integrity Primary key constraint

Unique constraint

Column integrity Foreign key constraint

Check constraint
Default constraint
Data type constraint
Nullability constraint

Referential integrity Foreign key constraint

User-defined integrity Check constraint

Use database constraints whenever possible.

There are two main reasons why using database constraints is a preferred way of enforcing data integrity.

• First, constraints are inherent to the database engine and so use less system resources to perform their dedicated tasks.
We resort to external user-defined integrity enforcement only if constraints are not sufficient to do the job properly.

• Second, database constraints are always checked by the database engine before insert, update, or delete operation.
Invalid operation is cancelled before the operation is undertaken. So they are more reliable and robust for enforcing data
integrity.