Domain Constraints Referential Integrity Assertions Triggers Functional Dependencies

Silberschatz, Korth and Sudarshan 6.
1 Database System Concepts

Chapter 6: Integrity Constraints
Domain Constraints
Referential Integrity
Assertions
Triggers
Functional Dependencies
Silberschatz, Korth and Sudarshan 6.2 Database System Concepts
Domain 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 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 (Cont.)
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.
create domain hourly-wage numeric(5,2)
constraint value-test check(value > = 4.00)
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
The clause constraint value-test is optional; useful to indicate which
constraint an update voilated.
Referential Integrity
Ensures 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.
Example: If Perryridge is a branch name appearing in one of the
tuples in the account relation, then there exists a tuple in the branch
relation for branch Perryridge.
Formal Definition
Let r
1
(R
1
) and r
2
(R
2
) be relations with primary keys K
1
and K
2

respectively.
The subset o of R
2
is a foreign key referencing K
1
in relation r
1
, if for
every t
2
in r
2
there must be a tuple t
1
in r
1
such that t
1
[K
1
] = t
2
[o].
Referential integrity constraint: [
o
(r
2
) _ [
K1
(r
1
)

referential Integrity in the E-R Model
Consider relationship set R between entity sets E
1
and E
2
. The
relational schema for R includes the primary keys K
1
of E
1
and K
2

of E
2
.
Then K
1
and K
2
form foreign keys on the relational schemas for
E
1
and E
2
respectively.
Weak entity sets are also a source of referential integrity
constraints. For the relation schema for a weak entity set must
include the primary key of the entity set on which it depends.
Database Modification
The following tests must be made in order to preserve
the following referential integrity constraint:
[
o
(r
2
) _ [
K
(r
1
)
Insert. If a tuple t
2
is inserted into r
2
, the system must
ensure that there is a tuple t
1
in r
1
such that t
1
[K] =
t
2
[o]. That is

t
2
[o] e [
K
(r
1
)
Delete. If a tuple, t
1
is deleted from r
1
, the system
must compute the set of tuples in r
2
that reference t
1
:

o
o
= t
1[K]
(r
2
)
If this set is not empty, either the delete command is
rejected as an error, or the tuples that reference t
1

must themselves be deleted (cascading deletions are
possible).

Database Modification (Cont.)
Update. Updates to the referencing relation(r2),
updates to the referenced relation(r1).
There are two cases:
If a tuple t
2
is updated in relation r
2
and the update
modifies values for foreign key o, then a test similar to the
insert case is made. Let t
2
denote the new value of tuple
t
2
. The system must ensure that
t
2
[o] e [
K
(r
1
)
If a tuple t
1
is updated in r
1
, and the update modifies
values for the primary key (K), then a test similar to the
delete case is made. The system must compute
o
o
= t
1[K]
(r
2
)
using the old value of t
1
(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 cascaded to
the tuples in the set, 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 (Cont.)
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 (Cont.)
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 to delete causes a constraint violation that
cannot be handled by a further cascading operation, the system
aborts the transaction. As a result, all the changes caused by
the transaction and its cascading actions are undone.
Assertions
An assertion is a predicate expressing a condition that we wish
the database always to satisfy.
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.
Assertion Example
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 branch-name = branch branch-name)))
Assertion Example
Every loan has at least one borrower who maintains an
account with a minimum balance or $1000.00
create assertion balance-constraint check
(not exists (select * from loan
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)))
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 trigger, 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 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 (Cont.)
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.
Functional Dependencies
Constraints on the set of legal relations.
Require that the value for a certain set of attributes determines
uniquely the value for another set of attributes.
A functional dependency is a generalization of the notion of a
key.
Functional Dependencies (Cont.)
Let R be a relation schema
o _ R | _ R
The functional dependency
o |
holds on R if and only if for any legal relations r(R),
whenever any two tuples t
1
and t
2
of r agree on the
attributes o, they also agree on the attributes |. That
is,
t
1
[o] = t
2
[o] t
1
[|] = t
2
[|]
K is a superkey for relation schema R if and only if K
R
K is a candidate key for R if and only if
K R, and
for no o c K, o R
Functional Dependencies (Cont.)
Functional dependencies allow us to express constraints that
cannot be expressed using superkeys. Consider the schema:
Loan-info-schema = (branch-name, loan-number,
customer-name, amount).
We expect this 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
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.
Note: 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 F set of functional dependencies, 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 Armstrongs Axioms:
if | _ o, then o | (reflexivity)
if o |, then Z o Z | (augmentation)
if o |, then | Z, then o Z (transitivity)
These rules are sound and complete.
Closure (Cont.)
We can further simplify computation of F
+
by using the
following additional rules.
If o | holds and o Z holds, then o | Z holds
(union)
If o | Z holds, then o | holds and o Z holds
(decomposition)
If o | holds and Z| A holds, then oZ A holds
(pseudotransitivity)
The above rules can be inferred from Armstrongs axioms.
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
AG I
CG HI

Closure of Attribute Sets
Define the closure of I under F (denoted by I
+
) as the set of
attributes that are functionally determined by I under F:
I0 is in F
+
0 _ I
+

Algorithm to compute I
+
, the closure of I under F
result := I;
while (changes to result) do
for each 0 Z in F do
begin
if 0 _ result then result := result Z;
end
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 and A _ AGB)
3. result = ABCGH (CG H and CG _ AGBC)
4. result = ABCGHI (CG I and CG _ AGBCH)
Is AG a candidate key?
1. AG R
2. does A
+
R?
3. does G
+
R?
Canonical Cover
Consider a set F of functional dependencies and the
functional dependency I 0 in F.
Attribute A is extraneous in I if A e I and F logically
implies (F {I 0}) {(I A) 0}.
Attribute A is extraneous in 0 if A e 0 and the set of
functional dependencies (F {I 0}) {I (0 A)}
logically implies F.
A canonical cover F
c
for F is a set of dependencies
such that F logically implies all dependencies in F
c
and
F
c
logically implies all dependencies in F
1
and further
No functional dependency in F
c
contains an extraneous
attribute.
Each left side of functional dependency in F
c
is unique.

Canonical Cover (Cont.)
Compute a canonical cover for F:
repeat
Use the union rule to replace any dependencies in F
I
1
0
1
and I
1
0
1
with I
1
0
1
0
2

Find a functional dependency I 0 with an
extraneous attribute either in I or in 0
If an extraneous attribute is found, delete it from I 0
until F does not change
Example of Computing a Canonical Cover
R = (A, B, C)
F = {A BC
B C
A B
AB C}
Combine A BC and A B into A BC
A is extraneous in AB C because B C logically
implies AB C.
C is extraneous in A BC since A BC is logically
implied by A B and B C.
The canonical cover is:
A B
B C
Figure 6.01

Domain Constraints Referential Integrity Assertions Triggers Functional Dependencies

Uploaded by

Copyright:

Available Formats

Domain Constraints Referential Integrity Assertions Triggers Functional Dependencies

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Domain Constraints Referential Integrity Assertions Triggers Functional Dependencies

Uploaded by

Copyright:

Available Formats

Silberschatz, Korth and Sudarshan 6.

1 Database System Concepts

You might also like