Constraints

Constraint

A constraint is basically a restriction placed upon the data

values that can be stored in a column or columns of a table.
Of course, RDBMS products have provided several different
types of constraints for a long time now. This includes
referential constraints (to define primary and foreign keys)
and unique constraints (to prohibit duplicates).
 Integrity Constraints

Integrity constraints guard against accidental damage to

the database, by ensuring that authorized changes
to the database do not result in a loss of data consistency.

• Domain Constraints
• Referential Integrity
• Assertions
• Triggers
• Functional Dependencies
 Domain Constraints

• They define valid values for attributes

• They are the most elementary form of integrity
constraint.
• They test values inserted in the database, and test
queries to ensure that the comparisons make sense.
 Domain Constraints
• The check clause in SQL-92 permits domains to be restricted
• use check clause to ensure that an hourly-wage domain allows
only values greater than a specified value.
new domain name
create domain hourly-wage numeric(5,2)
constraint value-test check (value>=4.00)
name of constraint
condition must be TRUE
• The domain hourly-wage is declared to be a decimal number
with 5 digits, 2 of which are after the decimal point
• The domain has a constraint that ensures that the hourly-wage
is greater than 4.00.
• constraint value-test is optional; useful to indicate which
constraint an update violated.
 Specifying Constraints

• Can have complex conditions in domain check

• create domain AccountType char(10)
constraint account-type-test
check (value in („Checking‟, „Saving‟))
an SQL condition

• check can be associated with a table definition:

create table account … …

check (branch-name in (select branch-name
from branch))
 SQL Constraints

• NOT NULL • CREATE TABLE Persons

(
P_Id int NOT NULL,
LastName varchar(255)
NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255)
);
 SQL Constraints

• SQL UNIQUE • CREATE TABLE Persons

Constraint (
P_Id int NOT NULL,
LastName varchar(255)
NOT NULL,
• ALTER TABLE Persons FirstName varchar(255),
ADD UNIQUE (P_Id) Address varchar(255),
City varchar(255),
UNIQUE (P_Id)
)
 SQL Constraints

• SQL PRIMARY KEY • CREATE TABLE Persons

Constraint (
P_Id int NOT NULL,
LastName varchar(255)
NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255),
PRIMARY KEY (P_Id)
)
 Referential Integrity
• Ensures that a value that appears in one relation for a given set
of attributes also appears for a certain set of attribute in
another relation.
– If an account exists in the database with branch name “Perryridge”,
then the branch “Perryridge” must actually exist in the database.
Foreign key

account ( account-no, branch-name, balance )

A-123 Perryridge 5000

branch (branch-name, branch-city, asset )

Primary keys of Perryridge Brooklyn 500,000
respective relations

A set of attributes X in R is a foreign key if it is not a primary key of R but

it is a primary key of some relation S.
 Referential Integrity
• Formal Definition
– Let r1(R1) and r2(R2) be relations with primary keys K1 and K2
respectively.

– The subset  of R2 is a foreign key referencing K1 in relation r1, if

for every t2 in r2 there must be a tuple t1 in r1 such that
t1[K1]=t2[].

– Referential integrity constraint: (r2)  K1 (r1)

R1 ( K1, …, … ) R2 ( K2, …, , … )
t2
x
t1
x
 Referential Integrity for Insertion and Deletion
• The following tests must be made in order to preserve the
following referential integrity constraint:
(r2)  K(r1)

• Insert. If a tuple t2 is inserted into r2. The system must ensure

that there is a tuple t1 in r1 such that t1[K] = t2[]. That is
t2[] K(r1)
• Delete. If a tuple t1 is deleted from r1, the system must compute
the set of tuples in r2 that reference t1:
=t1[K](r2)
if this set is not empty, either the delete command is rejected as
an error, or the tuples that reference t1 must themselves be
deleted (cascading deletions are possible)
 Referential Integrity for Update

• if a tuple t2 is updated in relation r2 and the update modifies

values for the foreign key , then a test similar to the insert
case is made. Let t2‟ denote the new value of tuple t2. The
system must ensure that
new foreign key
t2‟[] K(r1)
value must exist

• if a tuple t1 is updated in r1, and the update modifies values for

primary key(K), then a test similar to the delete case is made.
The system must compute
no foreign keys contain
=t1[K](r2)
the old primary key

using the old value of t1 (the value before the update is applied).
If this set is not empty, the update may be rejected as an error,
or the update may be applied to the tuples in the set (cascade
update), or the tuples in the set may be deleted.
 Referential Integrity in SQL

• Primary and candidate keys and foreign keys can be specified as

part of the SQL create table statement:
– The primary key clause of the create table statement
includes a list of the attributes that comprise the primary
key.
– The unique key clause of the create table statement includes
a list of the attributes that comprise a candidate key.
– The foreign key clause of the create table statement
includes both a list of the attributes that comprise the
foreign key and the name of the relation referenced by the
foreign key.
Referential Integrity in SQL -example

create table customer

(customer-name char(20) not null,
customer-street char(30),
customer-city char(30),
primary key (customer-name))

create table branch

(branch-name char(15) not null,
branch-city char(30),
assets integer,
primary key (branch-name))
 Referential integrity in SQL- example

create table account

(branch-name char(15),
account-number char(10) not null,
balance integer,
primary key(account-number),
foreign key (branch-name) references branch)

create table depositor

(customer-name char(20) not null,
account-number char(10) not null,
primary key (customer-name, account-number),
foreign key (account-number) references account,
foreign key (customer-name) references customer)
 Cascading Actions in SQL

create table account

…..
foreign key (branch-name) references branch
on delete cascade
on update cascade,
…)

• Due to the on delete cascade clauses, if a delete of a tuple in branch

results in referential-integrity constraint violation, the delete “cascades”
to the account relation, deleting the tuple that refers to the branch that
was deleted.
• Cascading updates are similar.
 Cascading Actions in SQL
• If there is a chain of foreign-key dependencies across multiple
relations, with on delete cascade specified for each dependency,
a deletion or update at one end of the chain can propagate
across the entire chain.

• If a cascading update or delete causes a constraint violation

that cannot be handled by further cascading operation, the
system aborts the transaction. As a result, all the changes
caused by the transaction and its cascading actions are undone.
SQL CHECK Constraint on CREATE TABLE
 Assertions
• An assertion is predicate expressing a condition that we wish
the database always to satisfy.
• Where a constraint cannot be expressed in these
forms, we use an assertion, e.g.
– Ensuring the sum of loan amounts for each branch is less
than the sum of all account balances at the branch.
– Ensuring every loan customer keeps a minimum of $1000 in
an account.
• An assertion in SQL-92 takes the form
create assertion <assertion-name> check <predicate>
• When an assertion is made, the system tests it for validity. This
testing may introduce a significant amount of overhead; hence
assertions should be used with great care.
• Any predicate allowed in SQL can be used.
 Assertion Example 1

• The sum of all loan amounts for each branch must be less than the
sum of all account balances at the branch.

create assertion sum-constraint check

(not exists (select * from branch
where (select sum(amount) from loan
where loan.branch-name=branch.branch-name)
>=
(select sum(amount) from account
where loan.number-name=branch.branch-name) ))
 Assertion Example 2
• Every loan has at least one borrower who maintains an
account with a minimum balance of $1000.00.

create assertion balance-constraint check loans without

(not exists (select * from loan such an account
where not exists
(select * from borrower, depositor, account
where loan.loan-number=borrower.loan-number
and borrower.customer-name=depositor.customer-name
and depositor.account-number=account.account-number
and account.balance >=1000) ))

must return T or F
 Triggers

• A trigger is a statement that is executed automatically by the

system as a side effect of a modification to the database.

• To design a trigger mechanism, we must:

– Specify the conditions under which the trigger is to be
executed.
– Specify the actions to be taken when the trigger executes.

• The SQL-92 standard does not include triggers, but many

implementations support triggers.
 Trigger Example
• Suppose that instead of allowing negative account balances, the
bank deals with overdrafts by
– setting the account balance to zero
– creating a loan in the amount of the overdraft
– giving this loan a loan number which is identical to the
account number of the overdrawn account.

• The condition for executing the trigger is an update to the

account relation that results in a negative balance value.
 Trigger Example

define trigger overdraft on update of account T

(if new T.balance < 0
then (insert into loan values
(T.branch-name, T.account-number, - new T.balance)
insert into borrower
(select customer-name, account-number
from depositor
where T.account-number = depositor.account-number)
update account S
set S.balance =0
where S.account-number =T.account-number))
The keyword new used before T.balance indicates that the value of
T.balance after the update should be used; if it is omitted, the value
before the update is used.
PL/SQL Trigger Example
 Triggers (Active database)

• Trigger: A procedure that starts automatically if

specified changes occur to the DBMS

• Analog to a "daemon" that monitors a database for

certain events to occur

• Three parts:
– Event (activates the trigger)
– Condition (tests whether the triggers should run) [Optional]
– Action (what happens if the trigger runs)

• Semantics:
– When event occurs, and condition is satisfied, the action is
performed.
 Triggers – Event,Condition,Action

• Events could be :

BEFORE|AFTER INSERT|UPDATE|DELETE ON <tableName>

e.g.: BEFORE INSERT ON Professor

• Condition is SQL expression or even an SQL query

(query with non-empty result means TRUE)

• Action can be many different choices :

– SQL statements , body of PSM, and even DDL and
transaction-oriented statements like “commit”.
 Example Trigger

Assume our DB has a relation schema :

Professor (pNum, pName, salary)

We want to write a trigger that :

Ensures that any new professor inserted

has salary >= 60000
 Example Trigger

CREATE TRIGGER minSalary BEFORE INSERT ON Professor

for what context ?

BEGIN

check for violation here ?

END;
 Example Trigger

CREATE TRIGGER minSalary BEFORE INSERT ON Professor

FOR EACH ROW

BEGIN

Violation of Minimum Professor Salary?

END;
 Example Trigger

CREATE TRIGGER minSalary BEFORE INSERT ON Professor

FOR EACH ROW

BEGIN

IF (:new.salary < 60000)

THEN RAISE_APPLICATION_ERROR (-20004,
‘Violation of Minimum Professor Salary’);
END IF;

END;
 Example trigger
CREATE TRIGGER minSalary BEFORE INSERT ON Professor
FOR EACH ROW

DECLARE temp int; -- dummy variable not needed

BEGIN
IF (:new.salary < 60000)
THEN RAISE_APPLICATION_ERROR (-20004,
‘Violation of Minimum Professor Salary’);
END IF;

temp := 10; -- to illustrate declared variables

END;
.
run;
 Details of Trigger Example

• BEFORE INSERT ON Professor

– This trigger is checked before the tuple is inserted
• FOR EACH ROW
– specifies that trigger is performed for each row inserted
• :new
– refers to the new tuple inserted
• If (:new.salary < 60000)
– then an application error is raised and hence the row is not
inserted; otherwise the row is inserted.
• Use error code: -20004;
– this is in the valid range
 Example Trigger Using Condition
CREATE TRIGGER minSalary BEFORE INSERT ON Professor
FOR EACH ROW
WHEN (new.salary < 60000)
BEGIN
RAISE_APPLICATION_ERROR (-20004,
‘Violation of Minimum Professor Salary’);
END;
.
run;

• Conditions can refer to old/new values of tuples modified by

the statement activating the trigger.
 Triggers: REFERENCING

CREATE TRIGGER minSalary BEFORE INSERT ON Professor

REFERENCING NEW as newTuple

FOR EACH ROW

WHEN (newTuple.salary < 60000)

BEGIN
RAISE_APPLICATION_ERROR (-20004,
‘Violation of Minimum Professor Salary’);
END;
.
run;
 Example Trigger

CREATE TRIGGER minSalary

BEFORE UPDATE ON Professor
REFERENCING OLD AS oldTuple NEW as newTuple
FOR EACH ROW
WHEN (newTuple.salary < oldTuple.salary)
BEGIN
RAISE_APPLICATION_ERROR (-20004, ‘Salary
Decreasing !!’);
END;
.
run;

• Ensure that salary does not decrease

 Leaving SQL
Going into Relation Database Theory
 Functional Dependence
• Existence dependence: The existence of B depends on A
• Functional dependence: B‟s value depends on A‟s value
– EmpName is functionally dependent on EmpNo
– Given the EmpNo, I can one and only one value of EmpName
• Constraints on the set of legal relation instances
• Require that the value for a certain set of attributes determines
uniquely the value for another set of attributes.
• Functional dependence is a generalization of the notion of a key.
 Functional Dependencies
• Let R be a relation schema R = ( A, B, C, D, E )
  R,   R  = A, B, C
• The functional dependency  = C, D

holds on R if and only if for
any legal relation r(R),
whenever any two tuples t1
and t2 of r agree on the
attributes , they also agree
on the attributes . That is,
t1[] = t2[]  t1[] =
t2[]
– True for all tuple pairs
– True for all instances
 Functional Dependencies
• Functional dependencies allow us to express constraints that
cannot be expressed using superkeys. Consider the schema:

Loan-info = (branch-name, loan-number, customer-name,

amount)

We expect the following set of functional dependencies to hold:

loan-number  amount
loan-number  branch-name

but would not expect the following to hold:

loan-number  customer-name
 Examples

loan-number  amount loan-info

loan-number  branch-name branch-nm loan-no cust-nm amount
Perryridge L-001 Peter Yeung 100000
 customer-name
loan-number  Perryridge L-001 David Chan 100000
Perryridge L-001 May Chan 100000
Wanchai L-002 Leon Lai 100000

loan-info
Another example:
branch-nm loan-no cust-nm amount
reverse of the fd‟s above Perryridge L-001 Peter Yeung 100000
Perryridge L-001 Peter Yeung 100000
Central L-001 Peter Yeung 250000
Wanchai L-002 Leon Lai 100000
 Use of Functional Dependencies

• We use functional dependencies to:

– test relations to see if they are legal under a given set of
functional dependencies. If a relation r is legal under a set F
of functional dependencies, we say that r satisfies F.
– Specify constraints on the set of legal relations; we say that
F holds on R if all legal relations on R satisfy the set of
functional dependencies F.

A specific instance of a relation schema may satisfy a functional

dependency even if the functional dependency does not hold on all
legal instances. For example, a specific instance of Loan-schema may,
by chance, satisfy loan-number  customer-name.
 Closure of a Set of Functional Dependencies
• Given a set of functional dependencies F, there are certain other
functional dependencies that are logically implied by F.
• The set of all functional dependencies logically implied by F is
the closure of F.
• We denote the closure of F by F+.
• We can find all of F+ by applying Armstrong‟s Axioms:

– if   , then    (reflexivity)
– if   , then    (augmentation)
– if    and  , then    (transitivity)

these rules are sound and complete.

 Examples of Armstrong‟s Axioms
• We can find all of F+ by applying Armstrong‟s Axioms:
– if   , then    (reflexivity)
loan-no  loan-no
loan-no, amount  loan-no
loan-no, amount  amount

– if   , then    (augmentation)
loan-no  amount (given)
loan-no, branch-name  amount, branch-name

– if    and  , then    (transitivity)

loan-no  branch-name (given)
branch-name  branch-city (given)
loan-no  branch-city
 Closure
• We can further simplify computation of F+ by using the following
additional rules.

– If    holds and    holds, then    holds (union)

– If    holds, then    holds and    holds (decomposition)
– If    holds and    holds, then    holds (pseudotransitivity)

• The above rules can be inferred from Armstrong‟s axioms.

E.g.,   ,    (given)
   (by augmentation)
   (by transitivity)
 Exercise
Given loan-no amount
Does loan-no, branch-name  amount
Why???

It is not covered by any of the above axioms, so we must derive it:

loan-no, branch-name  loan-no (reflexivity)

loan-no amount (given)
loan-no, branch-name  amount (transitivity)
Example

• R = (A, B, C, G, H, I)

• F = {A B
A C
CG H
CG I
B H}
• some members of F+
A H A  B; B  H
AG I A  C; AG  CG; CG  I
CG HI
 Closure of Attribute Sets
• Define the closure of  under F (denoted by +) as the set of
attributes that are functionally determined by  under F:
   is in F+    +
 is a set of attributes
Given loan-no
If loan-no  amount
then amount is part of loan-no+
I.e., loan-no+= loan-no,amount, …

If loan-no  branch-name
then branch-name is part of loan-no+
I.e., loan-no+= loan-no,amount, branch-name …

If loan-no  customer-name then continue ….

Else stop
 Algorithm to Compute Closure
• Algorithm to compute +, the closure of  under F

result:= ; result  a subset of itself

while (changes to result) do
for each    in F do
begin
if   result then result :=result  ;
end
result  

result is a (growing) set of attributes

Example

• R = (A, B, C, G, H, I)
F = ( A B
A C
CG H
CG I
B H}
• (AG+)
1. Result= AG
2. Result= ABCG (A  C; A  B and A
 AG)
3. Result= ABCGH (CG  H and CG 
AGBC)
result contains all of
4. Result=ABCGHI (CG  I and CG 
the attributes of R,
AGBCH)
so stop
• Is AG a candidate key?
1. AG  R Question: What is A+ and G+ ?
2. Does A+  R?
3. Does G+  R?
 Canonical Cover
• Consider a set F of functional dependencies and the functional
dependency    in F.
– Attribute A is extraneous in  if A  and if A is removed from , the set
of functional dependencies implied by F doesn‟t change. From A  C

Given AB  C and A  C then B is extraneous in AB I get AB  C
– Attribute A is extraneous in  if A   and if A is removed from , the set
of functional dependencies implied by F doesn‟t change.

Given A  BC and A  B then B is extraneous in BC
• A canonical cover Fc for F is a set of dependencies such that F logically
implies all dependencies in Fc and Fc logically implies all dependencies
in F, and further
– No functional dependency in Fc contains an extraneous attribute.
– Each left side of a functional dependency in Fc is unique.
 Canonical Cover

• Compute a canonical over for F:

repeat
use the union rule to replace any dependencies
in F
1  1 and 1  2 replaced with 1  12
Find a functional dependency    with an
extraneous attribute either in  or in 
If an extraneous attribute is found, delete it from

until F does not change
Example of Computing a Canonical Cover

• R = (A, B, C)
F = { A  BC
A  BC
B  C
B  C
A  B
AB  C
AB  C}
• Combine A  BC and A  B into A 
A  BC
BC A  BC
B C
• A is extraneous in AB  C because B  B C B C
C logically implies AB  C.
• C is extraneous in A  BC since A  BC A B
is logically implied by A  B and B  C. B C
• The canonical cover is:
AB
BC
 Example
• R = (A, B, C, G, H, I)
F={ AB
AC
CG  H
CG  I
B  H}
• some members of F +
– AH
• by transitivity from A  B and B  H
– AG  I
• by augmenting A  C with G, to get AG  CG
and then transitivity with CG  I
– CG  HI
• from CG  H and CG  I : “union rule” can be inferred from
– definition of functional dependencies, or
– Augmentation of CG  I to infer CG  CGI, augmentation of
CG  H to infer CGI  HI, and then transitivity