Functional Dependencies

and Normalization for

Relational Databases

Dr. Shivani Joshi

Informal Design Guidelines for
Relational Databases

• 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
• Criteria for "good" base relations:
• Discuss informal guidelines for good relational design
• Discuss formal concepts of functional dependencies and
normal forms 1NF 2NF 3NF BCNF
Semantics of the Relation
Attributes
• Each tuple in a relation should represent one entity
or relationship instance
• Only foreign keys should be used to refer to other entities
• Entity and relationship attributes should be kept apart as
much as possible
• Design a schema that can be explained easily relation by
relation. The semantics of attributes should be easy to
interpret.
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
EXAMPLE OF AN UPDATE
ANOMALY
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
• 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.
EXAMPLE OF AN UPDATE
ANOMALY (2)

• 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.
• 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
Null Values in Tuples

• 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:
• a. attribute not applicable or invalid
• b. attribute value unkown (may exist)
• c. value known to exist, but unavailable
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
• 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
Functional Dependencies

• 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
Functional Dependencies (2)

• A set of attributes X functionally determines a set of

attributes Y if the value of X determines a unique value for Y
• X Y holds if whenever two tuples have the same value for
X, they must have the same value for Y
If t1[X]=t2[X], then t1[Y]=t2[Y] in any relation instance r(R)
• X  Y in R specifies a constraint on all relation instances r(R)
• FDs are derived from the real-world constraints on the
attributes
Examples of FD constraints

• 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
Functional Dependencies (3)
• 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])

• Types of functional dependencies

Types of Functional dependency

1. Trivial functional dependency

• A → B has trivial functional dependency if B is a subset of A.
• The following dependencies are also trivial like: A → A, B → B
• Example:
• Consider a table with two columns Employee_Id and Employee_Name.
• {Employee_id, Employee_Name} → Employee_Id is a trivial functional depe
ndency as
• Employee_Id is a subset of {Employee_Id, Employee_Name}.
• Also, Employee_Id → Employee_Id and Employee_Name → Employee_Na
me are trivial dependencies too.
2. Non-trivial functional dependency
A → B has a non-trivial functional dependency if B is not a subset of A.
When A intersection B is NULL, then A → B is called as complete non-trivial.
Example:
ID → Name,
Name → DOB
1.Inference Rule (IR):
The Armstrong's axioms are the basic inference rule.
Armstrong's axioms are used to conclude functional dependencies on a relational
database.
The inference rule is a type of assertion. It can apply to a set of FD(functional
dependency) to derive other FD.
Using the inference rule, we can derive additional functional dependency from the initial
set.
The Functional dependency has 6 types of inference rule:
2. Reflexive Rule (IR1)
In the reflexive rule, if Y is a subset of X, then X determines Y.
If X ⊇ Y then X → Y
Example:
X = {a, b, c, d, e}
Y = {a, b, c}
 3. Augmentation Rule (IR2)
The augmentation is also called as a partial dependency. In
augmentation, if X determines Y, then XZ determines YZ for any
IfZ
X → Y then XZ → YZ
Example:
For R(ABCD), if A → B then AC → BC
4. Transitive Rule (IR3)
In the transitive rule, if X determines Y and Y determine Z, then X must also determine Z.
If X → Y and Y → Z then X → Z

5. Union Rule (IR4)

Union rule says, if X determines Y and X determines Z, then X must also determine Y and Z.
If X → Y and X → Z then X → YZ

Proof:
1. X → Y (given)
2. X → Z (given)
3. X → XY (using IR2 on 1 by augmentation with X. Where XX = X)
4. XY → YZ (using IR2 on 2 by augmentation with Y)
5. X → YZ (using IR3 on 3 and 4)
6. Decomposition Rule (IR5)
Decomposition rule is also known as project rule. It is the reverse of union rule.
This Rule says, if X determines Y and Z, then X determines Y and X determines
Z separately.
If X → YZ then X → Y and X → Z
Proof:
1.X → YZ (given)
2. YZ → Y (using IR1 Rule)
3. X → Y (using IR3 on 1 and 2)

7 Pseudo transitive Rule (IR6)

In Pseudo transitive Rule, if X determines Y and YZ determines W, then XZ
determines W.

If X → Y and YZ → W then XZ → W
Proof:
1. X → Y (given)
2. WY → Z (given)
3. WX → WY (using IR2 on 1 by augmenting with W)
4. WX → Z (using IR3 on 3 and 2)
Determinant
Functional Dependency

EmpNum  EmpEmail

Attribute on the LHS is known as the determinant

• EmpNum is a determinant of EmpEmail

91.2914 22
Transitive dependency
Transitive dependency

Consider attributes A, B, and C, and where

A  B and B  C.
Functional dependencies are transitive, which
means that we also have the functional dependency
AC
We say that C is transitively dependent on A
through B.

91.2914 23
Transitive dependency
EmpNum  DeptNum

EmpNum EmpEmail DeptNum DeptNname

DeptNum  DeptName

EmpNum EmpEmail DeptNum DeptNname

DeptName is transitively dependent on EmpNum via DeptNum

EmpNum  DeptName

91.2914 24
Partial dependency
A partial dependency exists when an attribute B is
functionally dependent on an attribute A, and A is a
component of a multipart candidate key.

InvNum LineNum Qty InvDate

Candidate keys: {InvNum, LineNum} InvDate is

partially dependent on {InvNum, LineNum} as
InvNum is a determinant of InvDate and InvNum is
part of a candidate key
91.2914 25
Additional Useful Inference Rules

• 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
• Closure of a set F of FDs is the set F+ of all FDs that
can be inferred from F
Normalization
•Normalization is the process of organizing the data in the database.
•Normalization is used to minimize the redundancy from a relation or set of relations. It
is also used to eliminate the undesirable characteristics like Insertion, Update and
Deletion Anomalies.
•Normalization divides the larger table into the smaller table and links them using
relationship.
•The normal form is used to reduce redundancy from the database table.

Types of Normal Forms

There are the four types of normal forms
Normal Form Description
1NF A relation is in 1NF if it contains an atomic value.
2NF A relation will be in 2NF if it is in 1NF and all non-key attributes
are fully functional dependent on the primary key.
3NF A relation will be in 3NF if it is in 2NF and no transition
dependency exists.
4NF A relation will be in 4NF if it is in Boyce Codd normal form and
has no multi-valued dependency.
5NF A relation is in 5NF if it is in 4NF and not contains any join
dependency and joining should be lossless.
Introduction to Normalization

• Normalization: Process of decomposing

unsatisfactory "bad" relations by breaking up their
attributes into smaller relations
• Normal form: Condition using keys and FDs of a
relation to certify whether a relation schema is in a
particular normal form
• 2NF, 3NF, BCNF based on keys and FDs of a relation
schema
• 4NF based on keys, multi-valued dependencies
First Normal Form
• Disallows composite attributes, multivalued attributes, and nested
relations; attributes whose values for an individual tuple are non-
atomic
• Considered to be part of the definition of relation
• A relation will be 1NF if it contains an atomic value.
• It states that an attribute of a table cannot hold multiple values. It
must hold only single-valued attribute.
• First normal form disallows the multi-valued attribute, composite
attribute, and their combinations.
Second Normal Form

• Uses the concepts of FDs, primary key

• Definitions:
• Prime attribute - attribute that is member of the primary key K
• Full functional dependency - a FD Y  Z where removal of any attribute
from Y means the FD does not hold any more
Examples
Second Normal Form
• {SSN, PNUMBER}  HOURS is a full FD since neither SSN
 HOURS nor PNUMBER  HOURS hold
• {SSN, PNUMBER}  ENAME is not a full FD (it is called a
partial dependency ) since SSN  ENAME also holds
• A relation schema R is in second normal form (2NF) if
every non-prime attribute A in R is fully functionally
dependent on the primary key
• R can be decomposed into 2NF relations via the process of
2NF normalization
Third Normal Form

• Definition
• Transitive functional dependency – if there a set of
atribute Z that are neither a primary or candidate key and
both X  Z and Y  Z holds.
• Examples:
• SSN  DMGRSSN is a transitive FD since
SSN  DNUMBER and DNUMBER  DMGRSSN hold
• SSN  ENAME is non-transitive since there is no set of
attributes X where SSN  X and X  ENAME
3rd Normal Form

A relation schema R is in third normal form (3NF) if it is in 2NF and no

non-prime attribute A in R is transitively dependent on the primary
key
BCNF (Boyce-Codd Normal
Form)
• A relation schema R is in Boyce-Codd Normal Form
(BCNF) if whenever an FD X  A holds in R, then X
is a superkey of R
• Each normal form is strictly stronger than the previous
one:
• Every 2NF relation is in 1NF
• Every 3NF relation is in 2NF
• Every BCNF relation is in 3NF
• There exist relations that are in 3NF but not in BCNF
• The goal is to have each relation in BCNF (or 3NF)
BCNF

• {Student,course}  Instructor
• Instructor  Course
• Decomposing into 2 schemas
• {Student,Instructor} {Student,Course}
• {Course,Instructor} {Student,Course}
• {Course,Instructor} {Instructor,Student}
Example

• Given the relation

Book(Book_title, Authorname, Book_type, Listprice, Author_affil,
Publisher)
The FDs are
Book_title Publisher, Book_type
Book_type Listprice
Authorname Author_affil
Example

• What normal form the relation in?