Sub : DBMS Batch : BIT IV Sem.

Integrity Constraints
Integrity constraints guard against accidental damage to database.

Entity Integrity
Entity integrity ensures that each row in the table is uniquely identified. In other
words, entity integrity ensures a table does not have any duplicate rows. Example: Two
separate customers should not have the same customer number .SQL Server will allow
duplicate rows if entity integrity is not enforced. Entity integrity is a key concept in the
relational database model. Data in the relational database is independent of physical storage;
there is no such thing as the '5th customer row' in a table. Physical independence is achieved
by being able to reference each row by a unique value, sometimes referred to as a 'key' .Entity
integrity ensures that each row in a table has a unique identifier that allows one row to be
distinguished from another .Entity integrity is most often enforced by placing a primary key
(PK) constraint on a specific column (although it can also be enforced with a UNIQUE
constraint, a unique index, or the IDENTITY property) .The PK constraint forces each value
inserted into a column (or combination of columns) to be unique; if a user attempts to insert a
duplicate value into the column(s), the PK constraint will cause the insert to fail. A PK will not
allow any Nulls to be inserted into the column(s) (A NULL entry would be disallowed even if it
would be the only NULL in the column and therefore unique.) . A PK is referred to as a '
surrogate key' if the column contains no real data other than a uniqueness identifier .If ‘real’
Document1

data can be used as a PK (e.g., a social security number), then it is referred to as an '
intelligent key' .There can be only one PK per table .A composite PK is a PK that consists of
more than one column; it is used when none of the columns in the composite key is unique by
itself .Thus, there can be only one PK in a table but the PK can consist of more than one column
.If you need to enforce uniqueness on more than one column, use a PK constraint on one
column and a UNIQUE constraint or IDENTITY property on any other columns that must not
contain duplicates .Example: If the 'customer ID' column is the PK in the 'customers' table and
you also want to make sure there are no duplicate customer names, you can place a UNIQUE
constraint on the 'customer name' column . Non-PK columns on which uniqueness is enforced
are referred to as alternative keys or AKs; they get their name from the fact that they are
'alternatives' to the PK and as such, make good candidates for indexing or 'joining' on.

Domain Constraint
A domain of possible values must be associated with every attribute SQL allows the domain
declaration of an attribute to include the specification "not null" and thus prohibits insertion of
a null value for this attribute. Any database modification that would cause a null to be inserted
in a not null domain generates an error diagnostic. There are many situation where the
prohibition of null values is desirable. A particular case where it is essential to prohibit null
values is in the primary key of a relation schema.
The SQL-92 allows us to define domains using a create domain clause, as shown in the
following example.
create domain personName char (60)
We can then use the domain name personName to define the type of an attribute, just
like a built-in domain.
Domain constraints are the most elementary form of integrity constraint. They are tested
easily by the system whenever a new data item is entered into the database. It is possible for
several attributes to have the same domain. The principle behind attribute domains is similar
to that behind typing of variables in programming languages.
The check clause in SQL-92 permits the schema designer to specify a predicate that must
be satisfied by any value assigned to a variable whose type is the domain. For instance, a
check clause can ensure that an hourly wage domain allows only values greater that a
specified value (such as minimum wage) as shown below.
create domain hourlywage numeric (5, 2)
Constraint wage, valuetestcheck (value> = 4.00)

© 2000 College of Information Technology & Engineering. All rights reserved, Circulation copy for CITians only. 1
 The domain hourlywage is declared to be a decimal number with a total of five digits, two
of which are placed after the decimal point, and the domain has a constraint that ensures that
the hourlywage is equal to or greater that 4.00.
The check clause can also be used to restrict a domain not to contain any null values, as
shown below.
e.g.: create domain accountNumber char(10)
constraint accountNumber NullTest check (value not null)
create domain gender char (10)
constraint checkgendercheck (value in ("Male", "Female")

Referential Integrity
It is also required that a value that appears in one relation for a given set of attributes
also appears for a certain set of attributes in another relation. This condition is called
referential integrity.
The referential integrity constraint is specified between two relations and is used to
maintain the consistency among tuples of the two relations. Informally, the referential integrity
constraint states that a tuple in one relation that refers to another relation must refer to an
existing tuple in that relation. Consider the two relations EMPLOYEE and DEPARTMENT as
follows.
EMPLOYEE DEPARTMENT
NAME SSN Addres Sex Salary Dept No. Dept DeptName MGRSS
s No. N
The attribute dept No. of EMPLOYEE gives the department Number for which each
employee works. hence, its value in every EMPLOYEE tuple must match the dept no. value of
some tuple in the DEPARTMENT relation. To define referential integrity more formally, we must
first define the concept of a foreign key. The conditions for a foreign key between two relation
schemas R1 and R2 states that a set of attributes FK in relation schema R 1 is a foreign key of R1
that references relation R2 if it satisfies the following two rules.
i. The attributes in FK have the same domain as the primary key attributes PK of R 2. The
attributes FK are said to reference or refer to the relation R2.
ii. A value of FK in a tuple t 1 of the current state r1(R1) either occurs as a value of PK for
some tuple t2 in the current state r2 (R2) or is null. In the former case, we have t 1[FK] = t2
[PK], and we say that the tuple t 1 references or refers to the tuple t 2. R1 is called the
referencing relation and R2 is the referenced relation.
In a database of many relations, there are usually many referential integrity constraints.
To specify these constraints, we must first have a clear understanding of the meaning or role
that each set of attributes plays in the various relation schemas of the database.
In the EMPLOYEE relation the attribute deptNo refers to the department for which
employee work hence, we designate deptNo to be a foreign key of EMPLOYEE, referring to the
DEPARTMENT relation. This means that a value of deptNo in any tuple t 1 of the EMPLOYEE
relation must match a value of the primary key of the department.
We can diagrammatically display referential integrity constraints by drawing a directed
arc from each foreign key to the relation it references. For clarity, the arrowhead may point to
primary key of the referenced relation.
EMPLOYEE
NAME SSN address Sex Salary dept No

DEPARTMENT
dept dept Name mgrssn
no.

© 2000 College of Information Technology & Engineering. All rights reserved, Circulation copy for CITians only. 2
 DEPARTMENT_LOCATIONS
dept no. Location
s
Fig. Referential integrity constraints

Referential integrity in SQL :

Primary and foreign key can be specified as part of the SQL create table statement.
 The primary key clause of create table statement includes a list of attributes that
constitute a candidate key.
 The UNIQUE clause of create table statement includes a list of the attributes that
constitute a candidate key.
 The FOREIGN KEY clause of create table statement includes both a list of attributes
that constitute foreign key and the name of the relation referenced by the foreign
key.
Assertion
An assertion is a predicate expressing a condition that we wish the database always to
satisfy. Domain constraints and referential integrity constraints are special forms of assertions.
However, there are many constraints that we can't express using only these special forms.
For example suppose the constraints are:
i. The sum of all loan amounts for each branch must be less than the sum of all account
balances at that branch.
ii. Every loan has at least one customer who maintains an account with a minimum balance
of 50,000.
An assertion in SQL-92 takes the form
create assertion <assertionName> check <Predicate>
e.g.:
create assertion sumConstraint check
(not exists (select * from branch
where (select sum(amount) from loan
where loan.branchName = branch.branchName)
>= (select sum (amount) from account
where account.branchName = branch.branchName)))
When an assertion is created, the system tests it for validity. If the assertion is valid, then
any further modification to the database is allowed only if it does not cause that assertion to be
violated.

Triggers
A trigger is a statement that is executed automatically by the system as a side effect of a
modification to the database. Trigger must contain the following two requirements.
i. specify the conditions under which the trigger is to be executed.
ii. specify the actions to be taken when the trigger executes.
Triggers are useful mechanisms for alerting humans, or for performing certain tasks
automatically when certain conditions are met. Triggers are sometimes called rules or active
rules. Triggers are written in both front end and backend. If the triggers are written in backend,
they are called database triggers.
Types:
i. row level triggers
ii. statement level triggers
iii. before and after triggers
iv. database level triggers
Triggers can be written for events such as insert, update, delete, create, alter, drop etc.
For example suppose we want to store username and the system date into a table
logdata. For this purpose, the trigger can be written as follows.
CREATE OR REPLACE TRIGGER tg_before_update_user
BEFORE INSERT OR UPDATE
ON Policies

© 2000 College of Information Technology & Engineering. All rights reserved, Circulation copy for CITians only. 3
 FOR EACH ROW
BEGIN
INSERT INTO LOGDATA
VALUES (USER, SYSDATE); COMMIT;
END;
In this trigger, if any insert or update is made in the policies table, then the user name &
current date is stored in the logdata table.

© 2000 College of Information Technology & Engineering. All rights reserved, Circulation copy for CITians only. 4