CPSC 603 Database Systems
Lecturer: Laurie Webster II, M.S.S.E., M.S.E.E.,
M.S.BME, Ph.D., P.E.
Lecture 5
Introduction to a First Course in Database Systems
Referential Integrity
R1  referencing relation R2  referenced relation
A set of attributes FK  R1 and PK  R2 => foreign
key of schema R1 that reference relation R2 if :
dom (FK) = dom (PK), FK = foreign key
PK = primary key
R1 = EMPLOYEE relation
R2 = DEPARTMENT relation
Referential Integrity
t1 (DNO) = t2 (DNUMBER) ==> t1[FK] = t2[PK]
A1 . . .. . . …. .. . . . . . . . . . . . . . . .DNO
R1
t1
An
v
.
.
tm
R2
A1
. . . .. DNUMBER.. . .. .. .. .. An
t1
t2
.
tm
v
Functional Dependencies
• Informal criteria for good and bad relation
schemas
•
•
•
•
Semantics of the attributes
Reducing the redundant values in tuples
Reducing the null values in tuples
Disallowing the possibility of generating spurious
tuples
• Formal criteria for good and bad relation
schemas
– The single most important concept in relational
schema design is the FD (functional
dependency)
– We will formally define the concept
Relation Schema and Database
R (A1, A2, ….. , An) ==> relation schema
r(R) = {t1, t2, …….., tm} ==> instance of a relation
==> database
Relational Database Schema => S
S = {R1, R2, …….. , Rm} ==> with integrity
constraints (IC)
A relational Database state(instance) DB
DB = {r1(R1), r2(R2), …… , rm(Rm)} = {r1, r2, …., rm}
Functional Dependencies
•A functional dependency (FD) is a
constraint between two sets of
attributes from the database
•A FD on a relation R is a
statement of the form:
– “If two tuples of R agree on attributes A1, A2, ….,
An (I.e, the tuples have same values in their
respective components for each of these attributes)
then they must also agree on another attribute B.”
Functional Dependencies
A Functional Dependency (FD), denoted by
  
between two sets of attributes  and  that are
subsets of R specifies a constraint on the possible
tuples that can form a relation state r (R).
The constraint => any two tuples t1 and t2 in r that
have t1[X] = t2[X], we must also have t1[Y] = t2[Y].
Functional Dependencies
• The constraint => any two tuples t1 and t2 in r that
have t1[X] = t2[X], we must also have t1[Y] = t2[Y]
==> values of the Y component of a tuple in r
depend on, or are determined by, the values of the X
component; or alternatively, the values of the X of a
tuple uniquely (or functionally) determine the
values of the Y component.
•    ==> Functional depedency from X to Y or
that Y is functional dependent (FD) on X.
Functional Dependencies
• X functional determines Y in a relation schema R if
and only if, whenever two tuples of r(R) agree on
their X-value, they must necessarily agree on their
Y-value
– “If two tuples of R agree on attributes A1, A2, ….,
An (I.e, the tuples have same values in their
respective components for each of these attributes)
then they must also agree on another attribute B.”
– We write this FD formally as
• A1, A2, …., An  B and say that A1, A2, …., An
functionally determine B
Functional Dependencies
If a set of attributes A1, A2, …., An functionally determines
more than one attribute, say
A1, A2, …., An  B1
A1, A2, …., An  B2
…….
A1, A2, …., An  Bm
We can write this set of FD’s as
A1, A2, …., An  B1B2…...Bm
Functional Dependencies
A functional dependency is a property of the
SEMANTICS or MEANING OF THE ATTRIBUTES
Whenever the semantics of two sets of attributes in R
indicate that a functional dependency should hold, we
specify the dependency as a constraint
Relation extensions r(R) that satisfy the FD constraints
are called legal extensions (or legal relation states) of
R, because they obey the FD constraints
Functional Dependencies
The main use of FDs is to describe further a relation
schema R by specifying constraints on its attributes
that must hold at all times
A FD is a property of the relation schema (intension)
R, not of a particular legal relation state (extension)
r(R)
FD cannot be inferred automatically from a given
relation extension r but must be defined explicitly by
someone who knows the semantics of the attributes of
Functional Dependencies
Relation Movies with star Information
title
year
length
filmType
studioName
starName
Star Wars
1977
124
color
Fox
Star Wars
1977
124
color
Fox
Mark Hamilton
Star Wars
1977
124
color
Fox
Harrison Ford
Mighty D.
1991
104
color
Disney
Emilio Estevez
Wayne’s W. 1992
95
color
Paramount
Dana Carvey
Wayne’s W. 1992
95
color
Paramount
Mike Meyers
Carrie Fisher
Functional Dependencies
Let us consider the relation Movies from the previous
slide:
Movies(title, year, length, filmType, studioName,
starName)
There are several FD’s that we can reasonably assert
about the Movies relation:
title year  length
title year  filmType
title year  studioName
Functional Dependencies
Relation Movies with star Information
title
Star Wars
Star Wars
year
length
filmType
studioName
1977
124
color
Fox
1977
124
starName
Carrie Fisher
color
Fox
Mark Hamilto
Star Wars
1977
124
color
Fox
Harrison For
Mighty D.
1991
104
color
Disney
Emilio Estev
1992
95
color
Paramount
Dana Carvey
Wayne’s W. 1992
95
color
Paramount
Mike Meyers
Wayne’s W.
Functional Dependencies
Informal Guideline 1: Design Ri so that it is easy to
explain its meaning. Do not combine attributes from
multiple entity types and relationship types into a
single relation. Intuitively, if Ri corresponds to one
entity type are one relationship type, the meaning
(semantics) tends to be clear. Otherwise, Ri
corresponds to a mixture of multiple entities and
relationships and hence becomes semantically
unclear.
Functional Dependencies
Informal Guideline 2: Design the base relation
schemas sot that no insertion, deletion, or
modification anomalies are present in the relations. If
any anomalies are present, note them clearly and
make sure that the programs that update the database
will operate correctly.
Functional Dependencies
Informal Guideline 3: As far as possible, avoid
placing attributes in a base relation whose values may
frequently be null. If nulls are unavoidable, make sure
that they apply in exceptional cases only and do not
apply to a majority of tuples in the relation.
Functional Dependencies
Informal Guideline 4: Design Ri’s so that they can be
JOINed with equality conditions on attributes that are
either primary keys or foreign keys in a way that
guarantees that no spurious tuples are generated. Do
not have relations that contain matching attributes othe
than foreign key-primary key combinations. If such
relations are unavoidable, do not join them on such
attributes, because the join may produce spurious
tuples.
Normalization
Having studied functional dependencies and some of
their properties, we are now ready to use them as
information about the semantics of Ris.
We assume that a set of FDs is given for each Ri , and
that each Ri has a designated primary key
THIS INFORMATION COMBINED WITH THE
TESTS (CONDITIONS) FOR NORMAL FORMS
DRIVES THE NORMALIZATION PROCESS
Introduction to Normalization
Historically: The normalization process, as first
proposed by Dr. Codd (1972a), takes Ri through a
series of tests to “certify” whether it satisfies a certain
normal form (?NF).
Relational Design by Analysis!! ==> proceeds in a
top-down fashion evaluating each against the criteria
for normal forms and decomposing relations as
necessary.
Normalization
Initially, Codd proposed three normal forms, which he
called:
a) first normal form (1NF)
b) second normal form (2NF)
c) third (3NF)
Later: A stronger definition of 3NF (Boyce-Codd
normal form (BCNF) was proposed
All are based on FDs among the attributes of Ri
Normalization
Even later: 4NF and 5NF was proposed based on the
concepts of :
a) multivalued dependencies
b) join dependencies, respectively
Normalization of data => process of analyzing the
given Ri based on their FDs and PKs to achieve the
desirable properties of :
1) minimizing redundancy
2) minimizing the insertion, deletion, and
update anomalies
Normalization
Unsatisfactory Ris that do not meet certain conditions - th
normal form tests - are decomposed into smaller Ris that
meet the tests and hence possess the desirable properties
as guaranteed by the normalization test.
Normalization procedure provides the database designers
with:
*
A formal framework for analyzing based
on their keys and on the FDs among their
attributes
*
A series of NF test tha can be carried out on
individual so that the relational database can
Next Lecture
•
•
•
•
Functional Dependencies Closing Sets
Normalization
Keys of Relations
Normalization