Functional Dependencies

Equivalence of FDs
Decomposition
Normalization
 FUNCTIONAL DEPENDENCIES
• Functional dependencies (FDs) are a fundamental concept in relational database theory, used
to express the relationship between attributes in a database schema. functional
dependency occurs when the value of one attribute (or a combination of attributes) uniquely
determines the value of another attribute.
• If 𝐴 and 𝐵 are attributes (or sets of attributes) of a relation 𝑅, we say that 𝐴 functionally
determines 𝐵, denoted as:
.
• It is referred as: B is functionally dependent on the A or A functionally determines B.
• This means that for any two tuples in R if the tuples agree on the value of A, they must also
agree on the value of B.
 BENEFITS OF FUNCTIONAL DEPENDENCIES
Benefits of Functional Dependencies (FDs) in Databases: Functional dependencies (FDs) play a crucial role in database
normalization and design. Their benefits include:
1. Helps in Normalization
FDs help identify redundant data and guide the process of decomposition to achieve higher normal forms (e.g., BCNF, 3NF),
ensuring minimal redundancy.
2. Ensures Data Consistency
If a functional dependency exists (e.g., A→BA \to BA→B), it ensures that for every unique value of AAA, the value of BBB
remains consistent throughout the database.
3. Reduces Anomalies
FDs help eliminate insertion, deletion, and update anomalies by structuring the database properly.
4. Enhances Query Optimization
Query performance can improve because FDs allow the query optimizer to rewrite queries more efficiently and reduce the
search space.
 FUNCTIONAL DEPENDENCIES

• In any relation, a functional dependency α → β holds

if Two tuples having same value of attribute α also have same value for
attribute β.

• If α and β are the two sets of attributes in a relational table R where-

α⊆
Rβ
⊆R
• Then, for a functional dependency to exist from α to β,
If t1[α] = t2[α], then t1[β] = t2[β]
 FUNCTIONAL DEPENDENCIES

The left side of the FD is called the determinant, and the right side is the dependent.

Eg: SIN determines Name, Address and Birthdate. Given SIN, we can determine any of the other
attributes within the table.
SIN ———-> Name, Address, Birthdate

For example, SIN and Course determine the date completed (DateCompleted). This must also
work for a composite PK.
SIN, Course 🡪 DateCompleted

The example indicates that ISBN determines Title.

ISBN 🡪 Title
• roll_no → { name, dept_name, dept_building },→ Here, roll_no
can determine values of fields name, dept_name and
dept_building, hence a valid Functional dependency
• roll_no → dept_name , roll_no can determine whole set of {name,
dept_name, dept_building}, it can determine its subset dept_name
also.
• dept_name → dept_building , Dept_name can identify the
dept_building accurately, since departments with different
dept_name will also have a different dept_building
• More valid functional dependencies:
roll_no → name,
{roll_no, name} ⇢ {dept_name, dept_building},

6
Here are some valid/invalid functional
dependencies:
• name → dept_name

Students with the same name can have different dept_name, hence this is not a

valid functional dependency.

• dept_building → dept_name

There can be multiple departments in the same building, For example, in the above

table departments ME and EC are in the same building B2, hence dept_building →

dept_name is an invalid functional dependency. More invalid functional

dependencies:

• name → roll_no,

• {name, dept_name} → roll_no, √

7
• dept_building → roll_no, etc.
 Functional Dependencies
Consider the given tables

A B A B
1 1 1 1
2 4 2 4 A🡪B : YES
3 9 3 9 A🡪C : YES
4 16 4 16 D🡪C : NO
2 4 3 10 C🡪B : NO
7 9 7 9
E🡪B : NO
B🡪C : NO
Table illustrates A🡪B A does not determine B

For two different A we can have

same B value but for Same A
cant have two different values
Functional Dependencies

1
 Functional Dependencies

Note: Data depends on dependency not dependency depends on data a,b are satisfied

A: Y
B: Y
C. N
D. Y
 FUNCTIONAL DEPENDENCIES
Rule-01:
A functional dependency X → Y will always hold if all the values of X are unique (different) irrespective of the values
of Y.
Example- Consider the following table-
The following functional dependencies will always hold since all the values of attribute ‘A’ are unique-
• A→B
• A → BC
• A → CD A B C D E

• A → BCD 5 4 3 2 2
• A → DE 8 5 3 2 1

• A → BCDE 1 9 3 3 5
4 7 3 3 8
In general, we can say following functional dependency will always hold-
 FUNCTIONAL DEPENDENCIES
Rule-02:

A functional dependency X → Y will always hold if all the values of Y are same irrespective of the values of
X.

Example- Consider the following table-

The following functional dependencies will always hold since all the values of attribute ‘C’ are same-

• A→C
A B C D E

• AB → C 5 4 3 2 2
8 5 3 2 1
• ABDE → C 1 9 3 3 5

• DE → C 4 7 3 3 8

• AE → C
 FUNCTIONAL DEPENDENCIES

Rule-03:
For a functional dependency X → Y to hold, if two tuples in the table agree on the value of attribute X, then they
must
also agree on the value of attribute Y.

Rule-04:
For a functional dependency X → Y, violation will occur only when for two or more same values of X, the
corresponding Y values are different.
A B C D E

5 4 3 2 2
8 5 3 2 1
1 9 3 3 5
4 7 3 3 8
 Full/Partial Functional Dependency
Full Functional Dependency (FFD)
• An attribute fully depends on the entire key and not just a part of it.
• If any part of the key is removed, the dependency no longer holds.
Example:
Consider a relation R(Student_ID, Course_ID, Marks) with the primary key: (Student_ID,
Course_ID).

Functional Dependency:

(Student_ID, Course_ID) → Marks

Here, Marks fully depends on both Student_ID and Course_ID.

• If we remove Course_ID, we cannot uniquely determine Marks anymore.
• This is a Full Functional Dependency.
 Full/Partial Functional Dependency
Partial Functional Dependency (PFD):
• An attribute depends on only a part of the primary key, not the whole key.
• This creates redundancy and violates 2NF.
Example:
Consider a relation R(Student_ID, Course_ID, Student_Name, Marks) with the primary key: (Student_ID, Course_ID).

Functional Dependencies:
(𝑆𝑡𝑢𝑑𝑒𝑛𝑡_𝐼𝐷,𝐶𝑜𝑢𝑟𝑠𝑒_𝐼𝐷) (Full Dependency)
𝑆𝑡𝑢𝑑𝑒𝑛𝑡
𝑀𝑎𝑟𝑘𝑠_𝐼𝐷→𝑆𝑡𝑢𝑑𝑒𝑛𝑡
_𝑁𝑎𝑚𝑒
→ (Partial Dependency)

• Here, Student_Name depends only on Student_ID, not on Course_ID. This means we are storing Student_Name multiple
times if the same student is enrolled in multiple courses.
 Full/Partial Functional Dependency

A B C
1 α X
2 β Y AB C
1 γ Z (F)
3 γ Z
B
4 γ Z C (P)
5 γ Z
Types of Functional Dependency (FD)
• Transitive Functional Dependency

• In a relation, if attribute(s) A → B and B → C, then A → C (means C is transitively depends on A via

B).
Sub_Fac
Subject Faculty Age

DS Shah 35
DBMS Patel 32
DF Shah 35

• Eg. Subject → Faculty & Faculty → Age then Subject → Age

• Therefore as per the rule of transitive dependency: Subject → Age should hold, that makes sense because if
we know the subject name we can know the faculty’s age.
 Armstrong's Axioms: Inference Rules

• Reflexivity
If B is a subset of A, then A → B always holds.
• Transitivity
If A → B and B → C, then A → C always holds.
• Augmentation
If A → B, then AC → BC always holds.
• Decomposition
If A → BC, then A → B and A → C always holds.
• Union
If X → Y, then X → Z and X → YZ always holds.
 Armstrong's Axioms: Inference Rules

Composition

If A → B and C → D, then AC → BD always holds.

Additive

If A → B and A → C, then A → BC always holds.

Pseudo-transitivity:

If X → Y and YZ → W then XZ → W.
 Armstrong's Axioms: Inference Rules

• In DBMS, soundness and completeness are properties

related to functional dependencies (FDs) and inference rules (such as
Armstrong’s Axioms).
• They ensure that the rules used to infer new dependencies are both correct and
sufficient.
 Armstrong's Axioms: Inference Rules: Soundness
• Soundness: A system (or inference rule) is sound if it never derives incorrect results.
• In terms of functional dependencies, an inference rule is sound if every FD it derives is logically valid in the
given relation.
• This ensures that we do not generate false dependencies that do not actually hold.
Example of Soundness
Given:
A→B, B→C
Using transitivity:
A→C (This is correct and valid.)
However, if we wrongly infer:

C→A (This is incorrect and unsound.)

Thus, sound rules only generate correct dependencies.

 Armstrong's Axioms: Inference Rules: Completeness

• Completeness: A system (or inference rule) is complete if it derives all possible correct results.
• In terms of functional dependencies, inference rules are complete if they can derive every
valid FD that logically follows from a given set of FDs.
• This ensures no true dependency is missed.
Example of Completeness
Given:
A→B B→C
A complete inference system should be able to
derive:
A→C (Transitivity rule)
If the system fails to derive A→C, it is not complete.
 Equivalence of Two Sets of Functional
Dependencies-
In DBMS,

• Two different sets of functional dependencies for a given relation may or may not be
equivalent.

• If F and G are the two sets of functional dependencies, then following 3 cases are possible-

• Case-01: F covers G (F ⊇ G)

• Case-02: G covers F (G ⊇ F)

• Case-03: Both F and G cover each other (F =

G)
 Case-01: Determining Whether F Covers G (F ⊇ G)
Following steps are followed to determine whether F covers G or not-

Step-01:
• Take the functional dependencies of set G into consideration.

• For each functional dependency X → Y, find the closure of X using the functional dependencies of set G.

Step-02:

• Take the functional dependencies of set G into consideration.

• For each functional dependency X → Y, find the closure of X using the functional dependencies of set F.

Step-03:

• Compare the results of Step-01 and Step-02.

• If the functional dependencies of set F has determined all those attributes that were determined by the functional dependencies of set G,
then it means F covers G.

• Thus, we conclude F covers G (F ⊇ G) otherwise not.

 Case-02: Determining Whether G Covers F (G ⊇ F)
Following steps are followed to determine whether G covers F or not-

Step-01:

• Take the functional dependencies of set F into consideration.

• For each functional dependency X → Y, find the closure of X using the functional dependencies of set F.

Step-02:

• Take the functional dependencies of set F into consideration.

• For each functional dependency X → Y, find the closure of X using the functional dependencies of set G.

Step-03: Compare the results of Step-01 and Step-02.

• If the functional dependencies of set G has determined all those attributes that were determined by the
functional dependencies of set F, then it means G covers F.

• Thus, we conclude G covers F (G ⊇ F) otherwise not.

 Case-03: Determining Whether Both F and G Cover Each Other-

• If F covers G and G covers F, then both F and G cover each other.

• Thus, if both the above cases hold true, we conclude both F and G cover each other (F =
G).
A relation R (A , C , D , E , H) is having two functional dependencies sets F and G as
shown- Set F-
A→C
AC → D
E → AD
E→H
Set G-
A → CD
E → AH

Which of the following holds true?

(A) G ⊇ F
(B) F ⊇ G (D)
(C) F = G
(D) All of the above
Step-01:
(A)+ = { A , C , D } // closure of left side of A → CD using set G

(E)+ = { A , C , D , E , H } // closure of left side of E → AH using set G

Step-02:

(A)+ = { A , C , D } // closure of left side of A → CD using set F

(E)+ = { A , C , D , E , H } // closure of left side of E → AH using set F

Step-03:

Comparing the results of Step-01 and Step-02, we find-

Functional dependencies of set F can determine all the attributes which have been determined by the functional dependencies of
set G. Thus, we conclude F covers G i.e. F ⊇ G.
Determining whether G covers F-
Step-01:
(A)+ = { A , C , D } // closure of left side of A → C using set F

(AC)+ = { A , C , D } // closure of left side of AC → D using set F

(E)+ = { A , C , D , E , H } // closure of left side of E → AD and E → H using set F

Step-02:
(A)+ = { A , C , D } // closure of left side of A → C using set G

(AC)+ = { A , C , D } // closure of left side of AC → D using set G

(E)+ = { A , C , D , E , H } // closure of left side of E → AD and E → H using set G

Step-03:
Comparing the results of Step-01 and Step-02, we find-

Functional dependencies of set G can determine all the attributes which have been determined by the functional dependencies of set F.

Thus, we conclude G covers F i.e. G ⊇ F.

Determining whether both F and G cover each other-

From Step-01, we conclude F covers G.

From Step-02, we conclude G covers F.

Thus, we conclude both F and G cover each other i.e. F =

G. Thus, Option (D) is correct.

PRACTICE UESTION-1
PRACTICE UESTION-2
Attribute closure

• If we want to check whether X→Y is in a closure of the set F, could compute F+ and
check – but expensive ☹

• Cheaper: We can instead compute the attribute closure

(X+), using the following algorithm:

closure:= X;
repeat until no change{
if ∃U→V∈F, where U⊆closure
then closure:=closure∪V
• Then F \ X→Y iff Y is a subset of X+
};
33
What is closure of a set of
FDs?
• Given a set F set of functional dependencies, there are certain other functional dependencies
that are logically implied by F.

• E.g.: F = {A → B and B → C}, then we can infer that A → C (by transitivity

rule)

• The set of functional dependencies (FDs) that is logically implied by F is called the closure
of F.

• It is denoted by F+.
Closure of a set of FDs [Example]
Suppose we are given a relation schema R(A,B,C,G,H,I) and the set of functional dependencies
are:
F=A→B (1)
A→C (2)
CG → H (3)
CG → I (4)
B→H (5)
▪ The functional dependency A → H is logical implied. (Transitive rule on 1
and 5)
▪ The functional dependency CG → HI is logical implied. (Union rule on 3 and
4)
▪ The functional dependency AG → I is logical implied. (psudeo transitivity on 2, 4)

Several members of F+ are

Closure of a set of FDs [Example]
🞂​Compute the closure of the following set F of functional dependencies FDs for relational
schema R = (A,B,C,D,E,F):
⮩ F = (A → B, A → C, CD → E, CD → F, B → E)
▪ Find out the closure of F.

A→B&A→C Union Rule A → BC

CD → E & CD → F Union Rule CD → EF

A→B&B→E Transitivity Rule A→E

A → C & CD → F Pseudo-transitivity Rule AD → F

A → C & CD → E Pseudo-transitivity Rule AD → E

F+ = (A → BC, CD → EF, A → E, AD → E, AD → F)
 Properties of Decomposition
The process of breaking up or dividing a single relation into two or more sub relations is called as decomposition of a
relation.
Properties of Decomposition-
1. Lossless decomposition- Lossless decomposition ensures-
• No information is lost from the original relation during decomposition.

• When the sub relations are joined back, the same relation is obtained that was decomposed.

• Every decomposition must always be lossless.

• Lossless join decomposition is also known as non-additive join decomposition.

• This is because the resultant relation after joining the sub relations is same as the decomposed relation.

• No extraneous tuples appear after joining of the sub-relations.

2/26/2025 37
 Properties of Decomposition of a Relation

2. Dependency Preservation- Dependency preservation ensures-

• None of the functional dependencies that holds on the original relation are lost.

• The sub relations still hold or satisfy the functional dependencies of the original
relation.

2/26/2025 38
Lossless Join Decomposition
• Lossless join decomposition is a decomposition of a relation R into relations R1, and R2 such
that if we perform a natural join of relation R1 and R2, it will return the original
relation R.

• This is effective in removing redundancy from databases while preserving the original data.

• In other words by lossless decomposition, it becomes feasible to reconstruct the relation R from
decomposed tables R1 and R2 by using Joins.

2/26/2025 39
 EXAMPLE:

• This relation is same as the original relation R.

• Thus, we conclude that the above decomposition is

lossless join decomposition.

40
2/26/2025
Lossy Join Decomposition
• Consider there is a relation R which is decomposed into sub relations R1 , R2 , …. , Rn.

• This decomposition is called lossy join decomposition when the join of the sub relations does
not result in the same relation R that was decomposed.

• The natural join of the sub relations is always found to have some extraneous tuples.

• For lossy join decomposition, we always have-

2/26/2025 41
Example

This relation is not same as the original relation R and contains some
extraneous tuples.

Clearly, R1 ⋈ R2 ⊃ R.

Thus, we conclude that the above decomposition is lossy join decomposition.

NOTE-

Lossy join decomposition is also known as careless decomposition.

• This is because extraneous tuples get introduced in the natural join of the
sub-relations.

• Extraneous tuples make the identification of the original tuples difficult.

2/26/2025 42
 • Find the value of C if the value of A= “1”. (Using decomposed
A B C
table ) Select R2.C from R2 Natural Join R1 where R1.A=“1”.
1 2 1
We get 1 tuple from the original table and we get only one tuple for this query
2 2 2
using decomposed tables as well.
3 3 2
• Hence, there is consistency. Therefore, this decomposition is Lossless.
R(ABC)

A B C
A B A C 1 2 1✓
1 2 1 1 2 2 2
2 2 2 2
3 3 2
3 3 3 2
R1(AB) R2(AC)
• If we see A here it has all values as unique.

43
2/26/2025
 R(ABC) • Find the value of C if the value of A= “1”. (Using decomposed
A B C table ) Select R2.C from R2 Natural Join R1 where R1.A=“1”.
1 2 1 • We get 2 tuples but from the original table we get only one tuple for this query. Hence,
2 2 2 there is inconsistency. Therefore, this decomposition is Lossy.
3 3 2

A B C
1 2 1✓
1 2 2✓
A B B C 2 2 1
Natural Join

1 2 2 1
2 2 2
2 2 2 2
3 3 2
3 3 3 2
R1(AB) R2(BC) R1 ⋈ R2 = R

• Here we have taken B as a common attribute which is a mistake bcz B has

duplicate values by itself then how it can be used for consistent database
 Rules to Determine Lossless and Lossy Decomposition
Consider a relation R is decomposed into two sub relations R 1 and R2.

• If all the following conditions satisfy, then the decomposition is lossless.

• If any of these conditions fail, then the decomposition is lossy.

• Condition-01: Union of both the sub relations must contain all the attributes that are present in the original relation R.

• Condition-02: Intersection of both the sub relations must not be null. In other words, there must be some common
attribute which is present in both the sub relations.

• Condition-03: Intersection of both the sub relations must be a super key of either R 1 or R2 or both.

2/26/2025 45
 EXAMPLE-1
1. Consider a relation schema R ( A , B , C , D ) with the functional dependencies A → B and C → D.
Determine whether the decomposition of R into R1 ( A , B ) and R2 ( C , D ) is lossless or lossy.

Condition-01:
R1 ( A , B ) ∪ R2 ( C , D )

= R (A, B , C , D )
Condition-02:
R1 ( A , B ) ∩ R 2 ( C , D )

=Φ
Clearly, intersection of the sub relations is
null. So, condition-02 fails.
Thus, we conclude that the decomposition is lossy.

2/26/2025 46
 Rules for Multiple Decomposition of one Table

When a given relation is decomposed into more than two sub relations, then-

• Consider any one possible ways in which the relation might have been decomposed
into those sub relations.
• First, divide the given relation into two sub relations.

• Then, divide the sub relations according to the sub relations given in the question.

Thumb rule:- Any relation can be

decomposed only into two sub relations at

2/26/2025
a time. 47
 EXAMPLE-2
Consider a relation schema R ( A , B , C , D ) with the following functional dependencies-
A→B
B→C
C→D
D→B
Determine whether the decomposition of R into R 1 ( A , B ) , R2 ( B , C ) and R3 ( B , D ) is lossless or lossy.

First Decomposition: Condition 1:

R‘ ( A , B , C ) ∪ R3 ( B , D ) = R ( A , B , C , D )
First Decomposition: Condition 2:

R‘ ( A , B , C ) ∩ R3 ( B , D ) = B

First Decomposition: Condition 3:

R‘ ( A , B , C ) ∩ R3 ( B , D ) = B,

B+ = { B , C , D }
2/26/2025 48
Thus, it is a super key of the sub relation R 3.
 EXAMPLE-2
Consider a relation schema R ( A , B , C , D ) with the following functional dependencies-
A→B
B→C
C→D
D→B
Determine whether the decomposition of R into R 1 ( A , B ) , R2 ( B , C ) and R3 ( B , D ) is lossless or lossy.

Second Decomposition: Condition 1:

R1 ( A , B ) ∪ R2 ( B , C ) = R’ ( A , B , C )
Second Decomposition: Condition 2:
R1 ( A , B ) ∩ R 2 ( B , C ) = B

Second Decomposition: Condition 3:

R1 ( A , B ) ∩ R 2 ( B , C ) = B

B+ = { B , C , D }
Thus, it is a super key of the sub relation R 2.
49
2/26/2025
Functional Dependency Preservation: Rule
 Dependency Preserving Decomposition

• The process of breaking down a relation (table) into two or more smaller relations
(tables). The idea is to simplify the design while preserving the ability to reconstruct the
original relation.

• During decomposition, it’s crucial to ensure that all functional dependencies (FDs) that
were present in the original relation are still enforced in the decomposed relations.

• This means that every functional dependency that existed in the original relation should
be expressible in terms of the decomposed relations.

2/26/2025 Dr. Ananya Pandey 51

 Functional Dependency Preservation: Rule

Let R be a relation schema and F be a set of functional dependencies on R. Suppose R is decomposed into
R1,R2,…,Rn. The decomposition is dependency preserving if:
F1 is subset of F
F2 is subset of F
and (F1∪ F2∪⋯∪ Fn)+ = F+
where:
• F+ is the closure of the original functional dependencies.
• Fi is the set of functional dependencies that hold within R i.
• The union of the FDs in the decomposed relations should be able to derive all dependencies in F (i.e., no
FD is lost).
 Functional Dependency Preservation: Rule
Let R be a relation schema and F be a set of functional dependencies on R. Suppose R is decomposed into
R1,R2,…,Rn. The decomposition is dependency preserving if:
F1is subset of F
F2 is subset of F
and (F1∪F2∪⋯∪Fn)+=F+
where:
• F+ is the closure of the original functional dependencies.
• Fi is the set of functional dependencies that hold within R i.
• The union of the FDs in the decomposed relations should be able to derive all dependencies in F (i.e., no
FD is lost).
If we decompose a relation R into relations R1 and R2, all dependencies of
R must be part of either R1 or R2 or must be derivable from combination
of functional dependencies(FD) of R1 and R2
 Functional Dependency Preservation: Rule

Importance of Dependency Preservation

• Ensures Data Integrity → No dependency from the original relation is lost.

• Avoids Expensive Joins → If dependencies are not preserved, we

may need to recombine relations frequently to check constraints.

• Simplifies Updates and Queries → Dependency preservation helps

in efficiently enforcing constraints without complex joins.

 Dependency Preserving Decomposition
R(A, B, C, D, E) Decomposed into R₁ (A, B, C) and R₂(C, D,
E)

F := { A → B, (FD1), B → C (FD2), C → D (FD3), D → A

R1 (A, (FD3)
B, C) } R2 (C, D, E)

A⁺ = ABCD : A → BC (A → A is trivial) and (D not in R1) B ⁺ = C⁺ = CDAB : C→D

D⁺ = DABC : D→C
BCDA : B → CA (B → B is trivial) and (D not in R1) C ⁺ =
E⁺ = {} :
CDAB : C → AB (C → C is trivial) and (D not in R1)
CD⁺ = CDAB (AB not in R2)
AB⁺ = ABCD : AB → C (AB → AB is trivial) and (D not in R1) DE⁺ = DEABC : DE → C
BC⁺ = BCDA : BC → A (BC → BC is trivial) and (D not in R1) CE⁺ = CEDAB : CE → D
AC⁺ = ACBD : AC → B (AC → AC is trivial) and (D not in R1)

F₁ := { A → BC, B → CA, C → AB, AB → C, BC → A, AC →

B } F₂ := { C → D, D → C, DE → C, CE → D }
You can write (C → AB as C → A, C → B Then use D → C, C → A to drive D → A )
(F1 union F2)+ =
F+
2/26/2025 55
 Dependency Preserving Decomposition
Let R(A,B,C,D) with Functional Dependencies

R 𝑨 → 𝑩, 𝑩 → 𝑪, 𝑪 → 𝑫, 𝑫 → 𝑩

R is decomposed into R1(AB), R2(BC), R3(BD). Check whether the decomposition is dependency preserving or
not?

R1(AB) R2(BC) R3(BD) 𝑨

𝑨 → 𝑨 ✘𝑪 → 𝑪 ✘ 𝐃 → 𝐃 →𝑩
Now, take Original Functional Dependencies

𝑩
and take closure from the

𝑩 → 𝑩 ✘𝑩 → 𝑩 ✘ 𝑩 → 𝑩
✘
→𝑪
Dependencies
Functional which are obtained from the
decomposed table. By checking it is clear that
𝐂
𝑨 → 𝑩 ✓𝑩 → 𝑪 ✓ 𝑩 → 𝑫
✘ it is dependency preserving decomposition.
→𝑩
𝑩
𝑫 → 𝑩
✓
𝐁→𝑨✘𝐂→𝑩✓ →𝑫
𝑫 preserving decomposition
✓

→𝑩
Yes, it is dependency
2/26/2025 56
 Dependency Preserving Decomposition
Let R(A,B,C,D) with Functional Dependencies

R 𝑨𝑩 → 𝑪𝑫, 𝑫 → 𝑨

R is decomposed into R1(AD), R2(BCD). Check whether the decomposition is dependency preserving or not?

R1(AD) R2(BCD)
𝑨→𝑨✘ 𝐁𝑪 → 𝐃 ✘
Now, take Original Functional Dependencies and take

𝑫
D→ 𝐃 ✘ 𝑩𝐃 → 𝐂 ✓
closure

→𝐀
from the Functional Dependencies which are obtained from the

𝑨 → 𝐃✘ 𝐂𝐃 → 𝐁 ✘
𝑩𝐃 →
decomposed table. By checking it is clear that it is NOT

𝐃→𝑨✓ B→ 𝐂𝐃 ✘ 𝐂
dependency preserving decomposition.

C→ 𝐁𝐃✘
D→ 𝐂𝐁✘ No, it is not dependency preserving
decomposition

2/26/2025
57
[Example]
R=(A,B,C), F={A→B,B→C}
Decomposition of R: R1=(A,C), R2=(B,C)
Does this decomposition preserve the given dependencies?

In R1, the following dependencies

hold:
F1′={A→A,C→C,A→C,AC→AC}
In R2, the following dependencies hold:
F2′={B→B,C→C,B→C,BC→BC}
The set of nontrivial dependencies that hold on R1 and
R2: F′:={B→C,A→C}
A→B cannot be derived from F′, so this decomposition is NOT dependency
preserving.
[Example]

R = (A, B, C), F = {A → B, B → C}, Decomposition of R: R1 = (A, B), R2 = (B, C) Does this decomposition preserve the
given dependencies?

Solution:
In R1 the following dependencies hold:
F1 = {A → B, A → A, B → B, AB → AB}
In R2 the following dependencies hold:
F2 = {B → B, C → C, B → C, BC → BC}
F' = F1' ∪ F2' = {A → B, B → C, trivial dependencies}
In F', all the original dependencies occur, so this decomposition preserves dependencies.
Anomalies in Relational Model

In Database Management Systems (DBMS), anomalies refer to inconsistencies or issues that arise when performing

insert, update, or delete operations on poorly designed databases. These anomalies occur due to redundant data and

can lead to inefficiencies and data integrity problems.

Causes: Poor management of storing everything in the flat

database, lack of normalization, data redundancy, and

improper use of primary or foreign keys. leading to data

integrity problems.
Insertion Anomaly
When adding new data requires unnecessary additional information.

Consider the following STUDENT table:

• If we want to insert a new course (AI, taught by Sarah) but no students have enrolled yet, we cannot insert it
because there is no Student_ID associated with it.
• We are forced to enter a NULL value or wait for a student to register.

• OR In a student database, if we need to add a new student but must also add a course (even if they haven’t

enrolled yet Student_ID Student_Name Course Instructor Instructor_Phone

101 Alice DBMS John 9876543210
102 Bob ML Mike 8765432109
Deletion Anomaly
Removing one piece of data unintentionally removes important related data.
Consider the following STUDENT table:

• If we remove Bob from the table, we also lose information about the ML course and instructor Mike, which

should ideally remain. Now, the ML course is lost even though it still exists.
Student_ID Student_Name Course Instructor Instructor_Phone
101 Alice DBMS John 9876543210
102 Bob ML Mike 8765432109

Student_ID Student_Name Course Instructor Instructor_Phone

After Deletion
101 Alice DBMS John 9876543210
Updation Anomaly
If data is stored redundantly, updating it in one place but not another can lead to inconsistencies.

Example: If Instructor "John" changes his phone number, we must update it in all rows where he appears. If we
forget to update some rows, inconsistent data remains in the table. Now, the instructor has two different phone
numbers, which leads to confusion.

Student_ID Student_Name Course Instructor Instructor_Phone

101 Alice DBMS John 9876543210
103 Bob DBMS John 8765432109
Redundant Data Anomaly
Normalization in DBMS
• Normalization is the process of organizing a database to reduce redundancy and eliminate anomalies
by dividing tables into smaller related ones. It ensures data integrity and improves efficiency.

• Normalization ensures a well-structured database.

• Reduces data redundancy, improves integrity, and avoids anomalies.

• Helps maintain consistent and efficient data updates.
Normalization in DBMS
Key Purposes of Normalization
1. Eliminate Data Redundancy
• Redundant data increases storage costs and can cause inconsistencies.
• Normalization ensures that data is stored in one place only, reducing duplication.
2. Prevent Data Anomalies
3. Improve Data Integrity & Consistency
• By ensuring that each piece of data is stored logically, normalization enforces referential integrity (foreign keys) and
domain integrity (constraints).
4. Enhance Query Performance
• Although excessive joins can slow queries, proper normalization reduces the size of tables, leading to faster searches
and updates.
5. Maintain Scalability & Flexibility
• A normalized database is easier to modify and expand without affecting existing data relationships.
1st Normal Form (1NF) – Remove Repeating Groups
• 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.

• This relation can be brought into 1NF.

Student_id Name Subjects • This can be done by rewriting the relation such that each cell of the table
100 Akshay Computer Networks, Designing contains only one value.
101 Aman Database Management System
Student_id Name Subjects
102 Anjali Automata, Compiler Design
100 Akshay Computer Networks
The following relation is not in 1NF-
Relation is not in 1NF (Subject is 100 Akshay Designing
multivalued)
101 Aman Database Management System
102 Anjali Automata
102 Anjali Compiler Design
1st Normal Form (1NF) – Remove Repeating Groups
1st Normal Form (1NF) – Remove Repeating Groups
1st Normal Form (1NF) – Remove Repeating Groups
2nd Normal Form (2NF) – Remove Partial Dependency

A relation is in Second Normal Form (2NF) if:

1️⃣It is already in First Normal Form (1NF) (i.e., no repeating groups, atomic values).

2️⃣It has no partial dependencies (i.e., every non-prime attribute must be fully functionally
dependent on the entire Candidate key, not just a part of it).
2nd Normal Form (2NF) – Remove Partial Dependency

Partial Dependency
A partial dependency is a dependency where a portion of the candidate key or incomplete or few attributes of a candidate key
determines non-prime attribute(s). In other words, A → B is called a partial dependency if and only if-

1. A is a subset of some candidate key

2. B is a non-prime attribute.

If any one condition fails, then it will not be a partial dependency.

NOTE-
To avoid partial dependency, incomplete candidate key must not determine any non-prime attribute.

However, incomplete candidate key can determine prime attributes.

2nd Normal Form (2NF) – Remove Partial Dependency
Steps to Convert a Relation into 2NF

Step 1: Identify the Candidate Key(s)

• If the candidate key is a single attribute, the relation is already in 2NF.

• If the candidate key is composite (multiple attributes), check for partial dependencies.

Step 2: Identify Partial Dependencies

• A partial dependency exists if a non-prime attribute depends on only a part of the composite key rather than the full
key.

Step 3: Remove Partial Dependencies

• Create new relations (tables) for attributes that have a partial dependency.

• Create new table has primary key that fully determines all its attributes.

Step 4: Retain the Main Relation

2nd Normal Form (2NF) – Remove Partial Dependency
Example: R(A, B, C, D, E, F)
𝑭𝑫 {𝑪 → 𝑭, 𝑬 → 𝑨, 𝑬𝑪
→ 𝑫, 𝑨 → 𝑩}

Candidate Key: (EC)+ = (ECDABF) Decomposition into 2NF:

Check for Partial Dependency : R1 (C,F) (For PD1)

C→F Partial Dependency (C is part of EC, but not whole key) R2 (E, A, B) (For PD2)
R3 (E, C, D) (For Candidate key)
E→A Partial Dependency (E is part of EC, but not whole key)
EC→D No Partial Dependency (EC is the full key)
A→B No Partial Dependency
Partial Dependencies Exist! So the relation is not in 2NF.

2NF: Non-Prime Attribute should not be determined by the part of the Candidate
Key.
2nd Normal Form (2NF) – Remove Partial Dependency
Example: Decomposition Lossy or LossLess R(A, B, C, D, E, F)
𝑭𝑫 {𝑪 → 𝑭, 𝑬 → 𝑨, 𝑬𝑪
→ 𝑫, 𝑨 → 𝑩}
Decomposition into 2NF:
R1 (C, F), R2 (E, A, B), R3 (E, C, D)
R2 (E, A, B)
Step1: Decompose into two: R’ (C, F, E, D)

and COND1 : R′ ∪ R2 = R
COND2 : R′ ∩ R2= E
COND3: E is the super key of R2
So, first decomposition is lossless.
Step2: Decompose R’ (C, F, E, C, D) into two: R1 ( C, F), R3 ( E, C, D)
COND1 : R1 ∪ R3=
R’ COND2 : R′∩ R3=
C
COND3: C is the super key of R1
So, Second decomposition is also lossless.
2nd Normal Form (2NF) – Remove Partial Dependency
Example: Is Decomposition is dependency Preserving R(A, B, C, D, E, F)
𝑭𝑫 {𝑪 → 𝑭, 𝑬 → 𝑨, 𝑬𝑪
→ 𝑫, 𝑨 → 𝑩}
R1 (C, F), R2 (E, A, B), R3 (E, C, D)
E+= (E, A, B): E → AB
A+= (A, B): A →B
C+= (C,F) : E+= (E, A, B):
C → F F+= (F) C+= (C):
B+= (B) :
D+= (D) :

EA+= (E, A, B): EA → B EC+= (E, C, D, A, B): EC→ D

AB+= (A, B) : CD+= (C, D, F) : CD→ F
EB+= (E, B, A) : EB → A ED+= (E, D, A, B) :

Dependency holed on R2:

E → AB, A →B, EA → B, EB → A
Dependency holed on R1: Dependency holed on R3:
C→F EC→ D, CD→ F
The decomposition is dependency preserving.
2nd Normal Form (2NF) – Remove Partial Dependency
Consider a relation- R ( A, B, C, D, E ) with functional dependencies-
AB → C
D→E

Candidate Key: (ABD)+ = R

Check for Partial Dependency :
AB→C Partial Dependency (AB is part The proposed decomposition In 2NF:
of ABD) D→E Partial Dependency (D is part R1 (A, B, C) → Handling AB→C
of ABD)
Partial Dependencies Exist! So the relation is not in R2 (D, E) → Handling D→E
2NF.
R3 (A, B, D) → Ensuring the candidate key ABD is preserved

2NF: Non-Prime Attribute should not be determined by the part of the Candidate Key.
2nd Normal Form (2NF) – Remove Partial Dependency
Consider a relation- R ( A, B, C, D, E ) with functional dependencies-
AB → C
D→E
R1 (A, B, C), R2 (D, E) and R3 (A, B, D) is lossy or lossless
decomposition.
Step1: Decompose into two: R’ (A, B, C, D) and R2 (D, E)
COND1 : R′ ∪ R2 = R
COND2 : R′ ∩ R2 = A, B, D
COND3: ABD is the super key of R2
So, first decomposition is lossless.
Step2: Decompose R’ (A, B, C, D) into two: R1( A, B, C), R2( A, B, D)
COND1 : R1 ∪ R2= R’
COND2 : R′ ∩ R3= A B
COND3: AB is the super key of R1
So, Second decomposition is also lossless.
2nd Normal Form (2NF) – Remove Partial Dependency
Consider a relation- R ( A, B, C, D, E ) with functional dependencies-
AB → C
D→E
R1 (A, B, C), R2 (D, E) and R3 (A, B, D) is dependency preserving.

R1 (A, B, C) R2 (D, E) R3 (A, B, D)

A+= (A) : A → A D+= (D, E) : D → DE A+= (A): (A→ A (Tr)) • AB→C is

(D → D (Tr), New Only: D →
(Tr)
B→B
B+= (B): (B→ B (Tr)) preserved in R1(A,B,C).
E) E+= (E) : E → E D+= (D, E) : D → D (Tr) , D → E (New)
B = (B)
+
:
(Tr) • D→ED is
(Tr)
C+= (C) : C→C preserved in R2(D,E).
(Tr)

AB = (A, B, C) : AB → ABC
• R3(A,B,D)
+
AB = (A, B, C) : AB→ ABC
AB → AB
+

helps ensure that all

: (AB→ AB (Tr), AB→ C

AB → (New)) BD+= (BDE) : BD→ BDE attributes remain

New Only:
C BC+= (B, C) : BC → BC (Tr)
: (BD→ BD (Tr), BD→ E connected and

AC+= (A, C) : AC → AC (Tr)

(New) ) AD+= (A, D, E) : (AD→ AD (Tr), AD→ recoverable.
E (New) )

Dependency holed on Dependency holed on Dependency holed on R3:

R1: AB → C (FD1) R2: D → E (FD2)
2nd Normal Form (2NF) – Remove Partial Dependency
Consider a relation- R ( A, B, C, D, E ) with functional dependencies-
A→B
B→E
C→E

Candidate Key: (ACD)+ = R

Check for Partial Decomposition into 2NF:
Dependency :
A→B Partial Dependency (AB is part of ABD) R1 (A, B, E) (For
B→E NPD PD1)

C→E PD R2 (C, E) (For PD2)

R3 (A, C, D) (For Candidate Key)
Partial Dependencies Exist! So the relation is not in 2NF.

2NF: Non-Prime Attribute should not be determined by the part of the Candidate Key.
2nd Normal Form (2NF) – Remove Partial Dependency
Consider a relation- R ( A, B, C, D, E ) with functional dependencies-
A→B
B→E
C→D

Candidate Key: (AC)+ = R

Check for Partial Decomposition into 2NF:
Dependency : R1 (A, B, E) (For
A→B Partial Dependency
B→E Not a Partial Dependency PD1)
R2 (C, D) (For PD2)
C→D Partial
R3 (A, C) (For Candidate Key)
Dependency
Partial Dependencies Exist! So the relation is not in
2NF.

2NF: Non-Prime Attribute should not be determined by the part of the Candidate Key.
2nd Normal Form (2NF) – Remove Partial Dependency
Consider a relation- R ( A, B, C, D, E, F, G, H, I, J ) with Candidate Key: (ABD)+ = R, Check for Partial
functional dependencies- Dependency :
AB→C Partial Dependency
AB → C,
AD→GH
AD → GH,
Partial Dependency
A→I Partial Dependency
BD → EF,
BD→EF Partial
H→J Not Partial
A→I Dependency
Partial Dependencies Exist! So the relation is not in
H→J 2NF.
Decomposition into 2NF:
R1 (A, B, C) (For PD1)
R2 (A, D, G, H, J) (For PD2)
R3 (B, D, E, F) (For PD3)
R4 (A, I) (For PD4)
R5 (ABD) (For Candidate Key)

2NF: Non-Prime Attribute should not be determined by the part of the Candidate Key.
3rd Normal Form (3NF) – Remove Transitive Dependency

A given relation is called in Third Normal Form (3NF) if and only if-
1. Relation already exists in 2NF.
2. No transitive dependency exists for non-prime attributes. meaning no non-key attribute depends on
another non-key attribute.
3. In 3NF, every non-key attribute must only depend on the primary key, not on another non-key attribute.

OR

A relation is called in Third Normal Form (3NF) if and only if-

• Any one condition holds for each non-trivial functional dependency A → B
4. A is a super key
5. B is a prime attribute
3rd Normal Form (3NF) – Remove Transitive Dependency

Transitive Dependency
A → B is called a transitive dependency if and only if-

1. A is not a super key.

2. B is a non-prime attribute.

If any one condition fails, then it is not a transitive

dependency.

NOTE-

3. Transitive dependency must not exist for non-prime attributes.

4. However, transitive dependency can exist for prime attributes.

3rd Normal Form (3NF) – Remove Transitive Dependency
A B C
1 x γ
Consider a relation- R ( A , B , C ) with functional dependencies- 2 x γ
A→B 3 x γ
4 y α
B→C
5 y α
The possible candidate keys for this relation are- 6 y α
7 y α
A A B B C
1 x x γ
From here,
2 X y α

• Prime attributes = { A } 3 x Redundancy Get reduced

after
4 y
• Non-prime attributes = {B, C} decomposition.
lossless because B is super key of
5 y Decomposition is
second relation, and all dependencies
NOTE: Non-prime B generates to non prime 6 y are preserved
C 7 y
So, Given relation is not in 3NF. Decomposed into 3NF having R1(A, B), R2(B,
C)
3rd Normal Form (3NF) – Remove Transitive Dependency
Consider a relation- R ( A , B , C , D , E ) with functional dependencies-
A → BC
CD → E
B→D
E→A

The possible candidate keys for this relation are-

A , E , CD , BC

From here,

• Prime attributes = { A , B , C , D , E }

• There are no non-prime attributes

Now: Thus, we conclude that the given relation is in 3NF.

3rd Normal Form (3NF) – Remove Transitive Dependency
R(A, B, C, D)
𝐹𝐷 {𝐴𝐵 → 𝐶, 𝑪 → 𝑫}

𝑨𝑩+= ABCD
Prime attribute= {A, B}, Non-Prime attribute= {C, D}
Not in 3NF But in 2NF because there is no Partial Dependency.

Conversion into 3NF: R(A, B, C, D) = R1(A B C) and R2(C D)

Lossy or Lossless? : COND1 : R1 ∪ R2= R
COND2 : R1 ∩ R2= C
COND3: C is the super key of R2, So decomposition is lossless.

Is Dependency Preserving? Yes

R1(A B C) R1(C, D)
Preserves 𝑨𝑩 → 𝑪 Preserves C→ 𝑫
A+ = {A}: Preserves 𝐴 → 𝐴
(𝑇𝑟𝑖) B+ = {B}: Preserves
B→ 𝐵 (𝑇𝑟𝑖) C+= {CD}:
Preserves C→ 𝐶 𝑇𝑟𝑖 C→ 𝐶 (D
not present in R1)
Try other dependencies generated by combination of 2 attribute and 3 attributes by yourself
3rd Normal Form (3NF) – Remove Transitive Dependency

𝐹𝐷 {𝐴𝐵
R(A, B, C, D,)

→ 𝐶𝐷,
𝐷 → 𝐴}

𝐴𝐵+= ABCD
𝐷𝐵+= ABCD
Prime attribute= {A, B, D}

Non-Prime attribute= {C}

It is in 2NF as well as in 3NF.

3rd Normal Form (3NF) – Remove Transitive Dependency
R(A, B, C, D, E)
𝐹𝐷: 𝐴𝐵 → 𝐶 (3𝑁𝐹)

B → 𝐷 (PD )

D →E (TD)

Candidate Key: 𝐴𝐵+= ABCDE

Prime attribute= {A, B}

Non-Prime attribute= {CDE}

It is not in 2NF as well as in 3NF.

Decomposition into 3NF: R11 (B, D, E), R12 (D, E) and R2(A, B, C)
Also, Lossless and dependency preserving.
First decomposition has common attribute B superkey of R1
Second decomposition of R1 has common attribute D superkey of
R12.
So decomposition is lossless.
3rd Normal Form (3NF) – Remove Transitive Dependency
R(A, B, C, D, E, F, G, H, I, J)
𝐹𝐷: 𝐴𝐵 → 𝐶 (3𝑁𝐹) Candidate Key: 𝐴𝐵+= ABCDEFGHIJ

𝐴 → 𝐷𝐸 (PD )
Prime attribute= {A, B}

𝐵→𝐹 (PD)
Non-Prime attribute= {CDEFGHIJ}

F→ 𝐺𝐻 (𝑇𝐷)
It is not in 2NF as well as in 3NF.

𝐷 → 𝐼𝐽 (TD )

2NF Decomposition into 3NF: Total 5 tables, R11, R12, R21, R22, R3
Also, Lossless and dependency preserving. (Prove by yourself)

3NF
3rd Normal Form (3NF) – Remove Transitive Dependency
R(A, B, C, D, E, F, G, H, I, J) Candidate Key: 𝐴𝐵𝐷+= ABCDEFGHIJ
𝐹𝐷: 𝐴𝐵 → 𝐶 (𝑃𝐷) Prime attribute= {A, B, D}

𝐴𝐷 → 𝐺𝐻 (PD ) Non-Prime attribute= {CEFGHIJ}

𝐵𝐷 → 𝐸𝐹 It is not in 2NF as well as in 3NF.

(PD)

A → 𝐼 (𝑃𝐷)
𝐻 →J (TD )
2NF

3NF

Decomposition into 3NF: Total 6 tables, R11, R12, R21, R22, R3

Also, Lossless and dependency preserving. (Prove by yourself)
3rd Normal Form (3NF) – Remove Transitive Dependency
R(A, B, C, D, E, F, G, H, I, J)
𝐹𝐷: 𝐴𝐵 → 𝐶 (𝑃𝑟𝑒𝑠𝑒𝑟𝑣𝑒𝑑 𝑏𝑦 𝑅11)

𝐴𝐷 → 𝐺𝐻 (Preserved by R21 )

𝐵𝐷 → 𝐸𝐹 (Preserved by

R3) A → 𝐼
Dependency Preserving: Yes, Lossless Decomposition : Yes
(𝑃𝑟𝑒𝑠𝑒𝑟𝑣𝑒𝑑 𝑏𝑦 𝑅12)

𝐻 →J (Preserved by R22)

Note: INT means Intersection

Boyce-Codd Normal Form

A given relation is called in BCNF if and only if-

1. Relation already exists in 3NF.
2. For each non-trivial functional dependency A → B, A is a super key of the
relation.

Decomposition is lossless but not dependency preserving AB -> C Lost.

Question R(A, B, C, D, E, F, G , H) Decompose in BCNF
𝐴 → 𝐵𝐶𝐷𝐸𝐹
𝐵𝐶 → 𝐴𝐷𝐸𝐹
𝐵 →F (PD)
𝐷→𝐸
𝐷→𝐵

𝐷 → 𝐵 𝐵 𝑖𝑠 𝑝𝑟𝑖𝑚𝑒 𝑠𝑜
𝑛𝑜𝑡 𝑇𝐷, B→ 𝐹 (𝐵 𝑖𝑠 𝑠𝑢𝑝𝑒𝑟 𝑘𝑒𝑦 𝑠𝑜 𝑖𝑛
𝐵𝐶𝑁𝐹)

D→ 𝐸 (𝐷 𝑖𝑠 𝑠𝑢𝑝𝑒𝑟 𝑘𝑒𝑦 𝑠𝑜 𝑖𝑛
𝐵𝐶𝑁𝐹)
BC→ 𝐴𝐷 (𝐵𝐶 𝑖𝑠 𝑠𝑢𝑝𝑒𝑟 𝑘𝑒𝑦 𝑠𝑜 𝑖𝑛
2NF
𝐵𝐶𝑁𝐹)
A→ 𝐵𝐶𝐷 (𝐴 𝑖𝑠 𝑠𝑢𝑝𝑒𝑟 𝑘𝑒𝑦 𝑠𝑜 𝑖𝑛
𝐵𝐶𝑁𝐹)
D→ 𝐵 (𝐷 𝑖𝑠 𝑛𝑜𝑡 𝑠𝑢𝑝𝑒𝑟 𝑘𝑒𝑦 𝑠𝑜
𝑛𝑜𝑡 𝑖𝑛 𝐵𝐶𝑁𝐹) Decompose

2/26/2025 94
Boyce-Codd Normal Form
Consider a relation- R ( A , B , C ) with the functional
dependencies-
A→B
B→C
C→A

The possible candidate keys for this relation are-

A,B,C

Now, we can observe that RHS of each given functional dependency is a candidate
key.

Thus, we conclude that the given relation is in BCNF.

Normal Form
• Third Normal Form (3NF) is considered adequate for normal relational database design
• BCNF decomposition is always lossless but not always dependency preserving.
• Lossy decomposition is not allowed in 2NF, 3NF and BCNF. Unlike BCNF, Lossless and dependency preserving decomposition
into 3NF and 2NF is always possible.
Questio
n
The relation scheme Student Performance (name, courseNo, rollNo,
grade) has the following functional dependencies:

The highest normal form of this relation scheme is:

97
 Questio
n

{name, Courseno} and {rollno, Courseno} will be the candidate keys because these can determine all the
attributes of a relation.
Prime Attributes: {name, Courseno, rollno}
Non-Prime Attributes: {grade}
Since, there is no partial dependency in any of the functional dependency therefore, it is in 2NF. Also, the relation
is in 3NF but not in BCNF because LHS of the 3 rd and 4th functional dependencies is not a candidate key or super
key.

2/26/2025 98
Questio
n
The relation schema Registration (Rollno, Course) has the following
functional dependencies:

𝐹𝐷 {𝑅𝑜𝑙𝑙𝑛𝑜 → 𝐶𝑜𝑢𝑟𝑠𝑒}

The highest normal form of this relation scheme is given that Rollno is
the Primary Key?

2/26/2025 99
Questio
n
The relation schema Registration (Rollno, Course) has the following
functional dependencies:

𝐹𝐷 {𝑅𝑜𝑙𝑙𝑛𝑜 → 𝐶𝑜𝑢𝑟𝑠𝑒}

The highest normal form of this relation scheme is given that Rollno is
the Primary Key?
BCNF (because we have only one functional dependency and the LHS
of that Functional dependency is the Candidate Key). Since it is in
BCNF, therefore it would be in 3NF, 2NF and 1NF as well.
2/26/2025 100
Questio
n
The relation schema Registration (Rollno, Courseid, Email) has the
following functional dependencies:

𝐹𝐷 𝑅𝑜𝑙𝑙𝑛𝑜, 𝐶𝑜𝑢𝑟𝑠𝑒𝑖𝑑 → 𝐸𝑚𝑎𝑖𝑙, 𝐸𝑚𝑎𝑖𝑙 → 𝑅𝑜𝑙𝑙𝑛𝑜

The highest normal form of this relation scheme is given that Rollno,
Courseid is the Primary Key?

2/26/2025 101
Questio
n
The relation schema Registration (Rollno, Courseid, Email) has the
following functional dependencies:

𝐹𝐷 𝑅𝑜𝑙𝑙𝑛𝑜, 𝐶𝑜𝑢𝑟𝑠𝑒𝑖𝑑 → 𝐸𝑚𝑎𝑖𝑙, 𝑬𝒎𝒂𝒊𝒍 → 𝑹𝒐𝒍𝒍𝒏𝒐

The highest normal form of this relation scheme is given that Rollno,
Courseid is the Primary Key?
Not in BCNF (because in 𝑬𝒎𝒂𝒊𝒍 → 𝑹𝒐𝒍𝒍𝒏𝒐 LHS is not a
candidate key or a super key). But it is in 3NF (because in 𝑬𝒎𝒂𝒊𝒍
→ 𝑹𝒐𝒍𝒍𝒏𝒐 RHS is a prime attribute), therefore it would be in 2NF
2/26/2025 102
Questio
n
The relation schema Registration (Rollno, Courseid, marks, grade) has
the following functional dependencies:

𝑅𝑜𝑙𝑙𝑛𝑜, 𝐶𝑜𝑢𝑟𝑠𝑒𝑖𝑑 →
𝐹
𝑚𝑎𝑟𝑘𝑠, 𝑔𝑟𝑎𝑑𝑒
𝐷
𝑚𝑎𝑟𝑘𝑠 → 𝑔𝑟𝑎𝑑𝑒

The highest normal form of this relation scheme is given that Rollno,
Courseid is the Primary Key?

2/26/2025 103
Questio
n
The relation schema Registration (Rollno, Courseid, marks, grade) has the following
functional dependencies:

𝑅𝑜𝑙𝑙𝑛𝑜, 𝐶𝑜𝑢𝑟𝑠𝑒𝑖𝑑 →
𝐹
𝑚𝑎𝑟𝑘𝑠, 𝑔𝑟𝑎𝑑𝑒
𝐷
𝒎𝒂𝒓𝒌𝒔 → 𝒈𝒓𝒂𝒅𝒆
The highest normal form of this relation scheme is given that Rollno, Courseid is the

Not in BCNF (because in 𝐦𝐚𝐫𝒌𝒔 → 𝒈𝒓𝒂𝒅𝒆 LHS is not a candidate key or a

Primary Key?

super key). Also it is not in 3NF (because in𝐦𝐚𝐫𝒌𝒔 → 𝒈𝒓𝒂𝒅𝒆 RHS is not
a prime attribute), But it is in 2NF (because no partial dependency exists),
therefore it is in 1NF as well.

2/26/2025 104
Questio
n
The relation schema Registration (Rollno, Courseid, Credit) has the
following functional dependencies:

𝐹 𝑅𝑜𝑙𝑙𝑛𝑜, 𝐶𝑜𝑢𝑟𝑠𝑒𝑖𝑑
𝐷 → 𝐶𝑟𝑒𝑑𝑖𝑡
𝐶𝑜𝑢𝑟𝑠𝑒𝑖𝑑 → 𝐶𝑟𝑒𝑑𝑖𝑡
The highest normal form of this relation scheme is given that Rollno,
Courseid is the Primary Key?

2/26/2025 105
Question
The relation schema Registration (Rollno, Courseid, Credit) has the following functional
dependencies:

𝐹 𝑅𝑜𝑙𝑙𝑛𝑜, 𝐶𝑜𝑢𝑟𝑠𝑒𝑖𝑑
𝐷 → 𝐶𝑟𝑒𝑑𝑖𝑡
𝑪𝒐𝒖𝒓𝒔𝒆𝒊𝒅 → 𝑪𝒓𝒆𝒅𝒊𝒕

The highest normal form of this relation scheme is given that Rollno, Courseid is the Primary Key?

Not in BCNF (because in𝑪𝒐𝒖𝒓𝒔𝒆𝒊𝒅 → 𝑪𝒓𝒆𝒅𝒊𝒕 LHS is not a candidate key or a super key). Also it is
not in 3NF (because in 𝑪𝒐𝒖𝒓𝒔𝒆𝒊𝒅 → 𝑪𝒓𝒆𝒅𝒊𝒕 RHS is not a prime attribute). Also, it is not in 2NF
(because partial dependency exists), therefore it is in 1NF only.

2/26/2025 Dr. Ananya Pandey 106

Question

2/26/2025 Dr. Ananya Pandey 107