1

Database Systems
Lecture 21

Functional Dependencies
Database Management
Systems
 2

Database Management S
ystems

Today’s Agenda

• Informal Design Guidelines for Relational

Databases
▫ Semantics of the Relation Attributes
▫ Redundant Information in Tuples and Update
Anomalies
▫ Null Values in Tuples
▫ Spurious Tuples
• Functional Dependencies
 3

Database Management S
ystems

Informal Design Guidelines for Relational Databases (1)

• What is relational database design?

The grouping of attributes to form "good" relation
schemas
• Two levels of relation schemas
▫ The logical "user view" level
▫ The storage "base relation" level
• Design is concerned mainly with base relations
• What are the criteria for "good" base relations?
 4

Database Management S
ystems

Semantics of the Relation Attributes

GUIDELINE 1: Informally, each tuple in a relation
should represent one entity or relationship
instance. (Applies to individual relations and their
attributes).
• Attributes of different entities (EMPLOYEEs, DEPARTMENTs,
PROJECTs) should not be mixed in the same relation
• Only foreign keys should be used to refer to other entities
• Entity and relationship attributes should be kept apart as much as
possible.
Bottom Line: Design a schema that can be
explained easily relation by relation. The
semantics of attributes should be easy to interpret.
Figure 10.1 A simplified COMPANY
relational database schema

Note: The above figure is now called Figure 10.1 in Edition 4

Chapter 10-5
Example database state for the relational
database schema of Figure 10.1.

Chapter 10-6
 7

Database Management S
ystems

Redundant Information in Tuples and Update

Anomalies
• Mixing attributes of multiple entities may cause
problems
• Information is stored redundantly wasting
storage
• Problems with update anomalies
▫ Insertion anomalies
▫ Deletion anomalies
▫ Modification anomalies
 8

Database Management S
ystems

EXAMPLE OF AN UPDATE ANOMALY (1)

Consider the relation:
EMP_PROJ ( Emp#, Proj#, Ename, Pname, No_hours)

• Update Anomaly: Changing the name of

project number P1 from “Billing” to “Customer-
Accounting” may cause this update to be made
for all 100 employees working on project P1.
 9

Database Management S
ystems

EXAMPLE OF AN UPDATE ANOMALY (2)

• Insert Anomaly: Cannot insert a project
unless an employee is assigned to .
Inversely - Cannot insert an employee unless
he/she is assigned to a project.
• Delete Anomaly: When a project is deleted, it
will result in deleting all the employees who
work on that project. Alternately, if an employee
is the sole employee on a project, deleting that
employee would result in deleting the
corresponding project.
 10

Database Management S
ystems

Figure 10.3 Two relation schemas suffering

from update anomalies
 11

Figure 10.4 Example States for EMP_DEPT

Database Management S
ystems

and EMP_PROJ

Note: The above figure is now called Figure 10.4 in Edition 4

 12

Database Management S
ystems

Guideline to Redundant Information in

Tuples and Update Anomalies
• GUIDELINE 2: Design a schema that does not
suffer from the insertion, deletion and update
anomalies. If there are any present, then note
them so that applications can be made to take
them into account
 13

Database Management S
ystems

Null Values in Tuples

GUIDELINE 3: Relations should be designed
such that their tuples will have as few NULL
values as possible
• Attributes that are NULL frequently could be
placed in separate relations (with the primary
key)
• Reasons for nulls:
▫ attribute not applicable or invalid
▫ attribute value unknown (may exist)
▫ value known to exist, but unavailable
 14

Database Management S
ystems

Spurious Tuples
• Bad designs for a relational database may result
in erroneous results for certain JOIN operations
• The "lossless join" property is used to guarantee
meaningful results for join operations

GUIDELINE 4: The relations should be

designed to satisfy the lossless join condition. No
spurious tuples should be generated by doing a
natural-join of any relations.
 15

Database Management S
ystems

Spurious Tuples (2)

There are two important properties of
decompositions:
(a) non-additive or losslessness of the
corresponding join
(b) preservation of the functional dependencies.

Note that property (a) is extremely important and

cannot be sacrificed. Property (b) is less
stringent and may be sacrificed.
 16

Database Management S
ystems

Particularly poor design for the EMP_PROJ relation of Figure 10.3b.

 17

Database Management S
ystems

Result of applying NATURAL JOIN to the tuples above the dotted lines
in EMP_PROJ1 and EMP_LOCS of Figure 10.5. Generated spurious
tuples are marked by asterisks.
 18

Database Management S
ystems

Functional Dependencies (1)

• Functional dependencies (FDs) are used to
specify formal measures of the "goodness" of
relational designs
• FDs and keys are used to define normal
forms for relations
• FDs are constraints that are derived from the
meaning and interrelationships of the data
attributes
• A set of attributes X functionally determines a
set of attributes Y if the value of X determines a
unique value for Y
 19

Database Management S
ystems

Functional Dependencies (2)

• X -> Y holds if whenever two tuples have the same value
for X, they must have the same value for Y
• For any two tuples t1 and t2 in any relation instance
r(R): If t1[X]=t2[X], then t1[Y]=t2[Y]
• X -> Y in R specifies a constraint on all relation
instances r(R)
• Written as X -> Y; can be displayed graphically on a
relation schema as in Figures. ( denoted by the arrow: ).
• FDs are derived from the real-world constraints on the
attributes
 20

Database Management S
ystems

Figure 10.3 Two relation schemas suffering

from update anomalies
 21

Database Management S
ystems

Examples of FD constraints (1)

• social security number determines employee
name
SSN -> ENAME
• project number determines project name and
location
PNUMBER -> {PNAME, PLOCATION}
• employee ssn and project number determines
the hours per week that the employee works on
the project
{SSN, PNUMBER} -> HOURS
 22

Database Management S
ystems

Examples of FD constraints (2)

• An FD is a property of the attributes in the
schema R
• The constraint must hold on every relation
instance r(R)
• If K is a key of R, then K functionally determines
all attributes in R (since we never have two
distinct tuples with t1[K]=t2[K])
 23

Database Management S
ystems

Inference Rules for FDs (1)

• Given a set of FDs F, we can infer additional
FDs that hold whenever the FDs in F hold
Armstrong's inference rules:
IR1. (Reflexive) If Y subset-of X, then X -> Y
IR2. (Augmentation) If X -> Y, then XZ -> YZ
(Notation: XZ stands for X U Z)
IR3. (Transitive) If X -> Y and Y -> Z, then X -> Z

• IR1, IR2, IR3 form a sound and complete set of

inference rules
 24

Database Management S
ystems

Inference Rules for FDs (2)

Some additional inference rules that are
useful:
(Decomposition) If X -> YZ, then X -> Y and X -> Z
(Union) If X -> Y and X -> Z, then X -> YZ
(Psuedotransitivity) If X -> Y and WY -> Z, then WX ->
Z

• The last three inference rules, as well as any

other inference rules, can be deduced from IR1,
IR2, and IR3 (completeness property)