Unit VI: Relational Database

Design

Dr. Anushree Tripathi

Department of Computer Science and Engineering
National Institute of Technology Patna (NITP)
Overview
• Decomposition
• Normalization using functional dependency
• Alternative approaches to database design
Decomposition

• All attributes of an original schema (R) must appear in

the decomposition (R1, R2):
R = R 1  R2
• Lossless-join decomposition
For all possible relations r on schema R
r = R1 (r) R2 (r)
Decomposition

• Decomposition of R = (A, B)
R2 = (A) R2 = (B)
A B
 1

A B  2

 1
 2
 1

A (r) B (r) A B
 1
 2
 1
 2
Decomposition

Loss of information via a bad decomposition

Lossless-join decomposition
• How to determine whether a decomposition is lossy?
R: Relation schema, R1 and R2: Decomposition of R
Decomposition: Lossless join decomposition of R if at least
one of the following functional dependency is in F+
➢R1 ∩ R2 → R1
➢R1 ∩ R2 → R2
➢R1 ∩ R2 forma a superkey of either R1 or R2
Lossless-join decomposition
Example
• Decomposition of lending-schema
Branch-schema = (branch-name, branch-city,assets)
Loan-info-schema = (customer-name, loan-number,
branch-name, amount)
Branch-schema ∩ Loan-info-schema = {branch-name}
• Decomposition of Loan-info-schema
Loan-schema = (loan-number, branch-name, amount)
Borrower-schema = (customer-name, loan-number)
Common attribute: Loan -number
Normalization
Basics Technique to remove or reduce redundancy
from table

Minimizing redundancy
Minimizing insertion, deletion and update
anomalies
First Normal Form
Second Normal Form
Third (Boyce-Codd Normal Form, BCNF)
Fourth (Multivalued dependency)
Fifth (Join dependency)
First Normal Form

Disallow multivalued Examples of non-

Domain of attribute atomic domains:
attributes, composite
must include only
attributes and their Set of names,
atomic values
combinations composite attributes

Atomicity: Specify Examples of atomic

how the elements of domains: CS-101
domain are used
First Normal Form (contd.)

Techniques to achieve 1NF

Using primary key but

Using composite
can introduce
primary key
redundancy
Second Normal Form

Should not contain any

Relation must be in 1NF
partial dependency

LHS must be proper subset

of candidate key and RHS
All non-prime attributes
should be non prime
should be fully functional
attribute to check partial
dependent on candidate key
dependency : should not be
there in 2NF
Second Normal Form
2NF
Example
Student_ID Faculty_ID
Table is not in 2NF
1 1
Student_ID Faculty_ID Course 1 3
1 1 C 2 1
1 3 DBMS 3 2
2 1 C 4 3
3 2 C++
2NF
4 3 Java
Candidate key: Student_ID, Faculty_ID Faculty_ID Course
Prime attributes: Student_ID, Faculty_ID
Non-prime attributes: Course 1 C
3 DBMS
1 C
2 C++
3 Java
Third Normal Form

There should be no
Table must be 2NF
transitive dependency

No nonprime attribute
Non prime can not
of R is transitively
predict nonprime
dependent on primary
attribute
key

For each FD, LHS must be a superkey

or candidate key or RHS is prime
attribute
Third Normal Form
• A relation schema R is in third normal form with respect
to a set F of functional dependencies if, for all functional
dependencies in F + of the form  →  , where ⊆ R
and  ⊆ R, at least one of the following holds:
➢ →  is a trivial functional dependency
➢ is a superkey for R
➢Each attribute A in  -  is contained in a candidate key
for R
Third Normal Form
Example

dept_advisor has functional dependencies:

 = i_ID,  = dept_name
 -  = dept_name
 Third Normal Form
Example
Student_ID State City
1 Bihar Patna
2 UP Lucknow
3 Haryana Ambala
4 Manipur Imphal

Candidate key: Student_ID; Functional dependency: Student_ID State; State City

Prime attributes: Student_ID
Non-prime attributes: State, City
Boyce-Codd Normal Form (BCNF)

Every relation in BCNF

More stricter than is also in 3NF but 3NF
3NF is not necessarily in
BCNF

A relation schema R is LHS of each functional

in BCNF if whenever a dependency must be
nontrivial functional superkey or candidate
dependency X A key
Boyce-Codd Normal Form (BCNF)
Example
• Relational schema: Not in BCNF
inst dept (ID, name, salary, dept name, building, budget)
➢Functional dependency: dept_name → budget holds on
inst_dept
➢dept_name: Not a superkey
• Decomposition into instructor and department
➢Instructor in BCNF
➢All nontrivial functional dependency that holds
➢ID → name, dept_name, salary
• Department schema in BCNF
• dept_name → building, budget
Boyce-Codd Normal Form (BCNF)

• Rules to decompose relation that are not in BCNF

➢R: relation schema not in BCNF
➢At least one nontrivial functional dependency  → , 
is not a superkey for R
➢Replace R with two schemas
Comparison of BCNF and 3NF

• Disadvantages of 3NF
➢Use of null values
➢Repetition of information
• Goals of database design with functional dependencies:
➢BCNF
➢Losslessness
➢Dependency preservation