Normal Forms

Normalization
DBMS Normalization is a systematic approach to decompose (break down)
relations to eliminate data redundancy (repetition of data) and undesirable
anomalies like Insertion, Update and Delete.
To understand these anomalies let us take an example of a Student table.
Anomalies
Data Redundancy : the fields branch, hod(Head of Department), and office_tel are
repeated for the students who are in the same branch in the college,

Insertion Anomaly: Suppose for a new admission, until and unless a student opts
for a branch, data of the student cannot be inserted, or else we will have to set the
branch information as NULL. Also, if we have to insert data for 100 students of the
same branch, then the branch information will be repeated for all those 100 students.

Updation Anomaly Mr. X is no longer the HOD of the computer science

department? In that case, all the student records will have to be updated, and if by
mistake we miss any record, it will lead to data inconsistency.

Deletion Anomaly If only a single student is enrolled in a branch, and that student
leaves the college, or for some reason, the entry for the student is deleted, we will
lose the branch information too.
Normalization
Solution:
The solution for all the three anomalies described above is to keep the student
information and the branch information in two different tables. And use the
branch_id in the student table to reference the branch.
Decomposition:
Decomposition is the process of splitting a relation into into two or
more sub relations.
Decomposition helps in eliminating some of the problems of bad
design such as redundancy, inconsistencies and anomalies.
Desirable properties of decomposition:
● Attribute preservation
● Lossless-join decomposition
● Dependency preservation
● Lack of redundancy
Decomposition:
Types of decomposition:

● Lossy (or Lossy join) decomposition

● Lossless(or non additive or non loss) join decomposition
Application of Closure to Testing Dependency
Preservation

We decomposed the PROJECTS relation PROJECTS ( Project,

Project-Budget, Department, Dept_address)
With {Project →Project-Budget, Project →Department, Department
→Dept-Address, Project →Dept-Address.}
into two relations.
PROJECTS(Project, Project-Budget, Department) and DEPT(
Department, Dept_address)
Application of Closure to Testing Dependency
Preservation

If we look at all FDs in the new schema taken together it appears

that we have lost one of the original FDs: {Project →Project-Budget,
Project →Department,}, {Department →Dept-Address}
However, using the axioms, we can infer that Project
→Dept-Address is logically implied by Project →Department and
Department →Dept-Address so that the FD has not actually been
lost.
Dependency preserving
A decomposition of a relation R, on which the dependencies F hold,
into relations R1 and R2 is dependency preserving if:
(FR1 ∪ FR2)+ = F+
Where FR1 is the set of dependencies that apply between attributes
only in R1 and similarly FR2 is the set of dependencies that apply
between attributes only in R2.

E.g the closure of the PROJECTS relation in the previous example

is:
{Project →Project-Budget, Project →Department,
Department →Dept-Address, Project →Dept-Address}
The closure of the combined FDs in the decomposed tables is the
same, so the decomposition is dependency preserving.
Lossy and Lossless Decomposition

Consider the following example of

decomposition:
R1 = ({A, B, C}, {A→B, C→B})
If we decompose this into the
relations:
R2 = ({A, B}, {A→B})
R3 = ({B, C}, {C→B})
we would have:
Lossy Decomposition

Now, if we join relations R2 and R3 over the common attribute B,

the resultant relation would appear as follows:

The resultant relation

contains more rows
(spurious tuples) than
existed in the original R1.
This is called a “lossy
decomposition” as it
causes constraint
information to be lost
Determining Whether Decomposition Is Lossless Or Lossy-
Consider a relation R is decomposed into two sub relations R1 and R2.
Then,
● If all the following conditions satisfy, then the decomposition is
lossless.
● If any of these conditions fail, then the decomposition is lossy.
Cond 1. Union of both the sub relations must contain all the attributes
that are present in the original relation R.
Thus R1 U R2 = R
Determining Whether Decomposition Is Lossless Or Lossy-
Cond 2. 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.
Thus, R1 ∩ R2 ≠ ∅
Cond 3. Intersection of both the sub relations must be a super key of
either R1 or R2 or both.
Thus, R1 ∩ R2 = Super key of R1 or R2
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.
To determine whether the decomposition is lossless or lossy,
● We will check all the conditions one by one.
● If any of the conditions fail, then the decomposition is lossy
otherwise lossless.
According to condition-01, union of both the sub relations must
contain all the attributes of relation R.
So, we have-
R1 ( A , B ) ∪ R2 ( C , D )= R ( A , B , C , D )
Clearly, union of the sub relations contain all the attributes of relation
R.
Thus, condition-01 satisfies.
According to condition-02, intersection of both the sub relations must not
be null.
So, we have-
R1 ( A , B ) ∩ R2 ( C , D )= Φ
Clearly, intersection of the sub relations is null.
So, condition-02 fails.
Thus, we conclude that the decomposition is lossy.
Test for lossless/lossy decomposition?

Show that decomposition of R1 = ({A, B, C},

{A→B, C→B}) into R2 = ({A, B}, {A→B}) and R3 = ({B, C}, {C→B}) is
not lossless.
Test for lossless/lossy decomposition?

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 R1 ( A , B ) , R2 ( B , C ) and R3 ( B , D )
is lossless or lossy.
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.

As a thumb rule, remember-Any relation can be decomposed only into two sub relations at a time.
Test for lossless/lossy decomposition?

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 R1 ( A , B ) , R2 ( B , C ) and R3 ( B , D )
is lossless or lossy.

Step 1: Decomposition of R(A, B, C, D) into R'(A, B, C) and R3(B, D)

Step 2: Decomposition of R'(A, B, C) into R1(A, B) and R2(B, C)

Normal Forms
Let R be a relation schema with a set F of functional dependencies.

■ Decide whether a relation schema R is in “normal” form.

■ In the case that a relation schema R is not in “normal” form,

decompose it into a set of relation schema {R1, R2, ..., Rn} such
that

● each relation schema is in normal form

● the decomposition is a lossless-join decomposition

●Preferably, the decomposition should be dependency

preserving
Normal Forms
Normalization rules are divided into the following normal
forms:
1. First Normal Form
2. Second Normal Form
3. Third Normal Form
4. BCNF
5. Fourth Normal Form
6. Fifth Normal Form
First Normal Forms
For a table to be in the First Normal Form, it should follow the following 4
rules:

Rule 1: Single Valued Attributes

Rule 2: Attribute Domain should not change

Rule 3: Unique name for Attributes/Columns
Rule 4: Order doesn't matters
First Normal Forms
Solution :
Second Normal Forms
For a table to be in the Second Normal Form, it should follow the
following 2 rules:
Rule 1: Follow First Normal Form
Rule 2: No Partial Dependency: No non-prime attribute depends on
parts of a candidate key
(An attribute is non-prime if it does not belong to any candidate
key for R)
Second Normal Forms
student_id + subject_id forms a Primary Key for Score
Table

column teacher is only dependent on the subject

Second Normal Forms
To remove Partial dependency, identify the determinants for each partial
dependency and their dependents and create new table with the
determinants as PKs
Second Normal Forms
Given a relation R( A, B, C, D) and Functional Dependency set FD = { AB
→ CD, B → C }, determine whether the given R is in 2NF? If not convert it
into 2 NF.

Given a relation R( P, Q, R, S, T) and Functional Dependency set FD = {

PQ → R, S → T }, determine whether the given R is in 2NF? If not convert
it into 2 NF.

Given a relation R (A,B,C,D) and FD set FD = {AB → CD, A → C, B → D }

Determine whether the given R is in 2NF? If not convert it into 2 NF.
Second Normal Forms: Redundancy
Instructor (Name, Salary, DepName, DepBudget) = I (A,B,C,D)
FD = {A -> BCD , C -> D}

{Name} is the only candidate key and no non-prime attribute is

partially functional dependent on the candidate key

Hence, I is in 2NF.

Redundancy:

We repeat the budget of a department if there is more than one

instructor working for that department
Third Normal Form
A relation schema R is in third normal form (3NF) if for all: X→Y in F+
there is no transitive dependency for non-prime attributes and at least
one of the following holds:

● X→ Y is a trivial FD
● X is a superkey for R
● Y is a prime attribute, i.e., each element of Y is part of some
candidate key. Or Each attribute A in Y–X is contained in a
candidate key for R.
Transitive dependency: When a non-prime attribute depends on other
non-prime attributes rather than depending upon the prime attributes or
primary key.
Third Normal Form
A relation schema Score (score_id ,student_id, subject_id ,marks,
exam_name, total_marks)

Candidate key (student_id, subject_id)

Student_id, subject_id → exam_name

exam_name –> total marks

Student_id, subject_id → exam_name → total_marks

This is Transitive Dependency. Hence not in 3NF

Third Normal Form

To remove transitive dependencies, identify the determinant of each

transitive dependency which then becomes the Pk of new table and then
assign the corresponding dependents. Remove the dependent attributes
from original table. The determinants remain and become FKs.

A relation schema Score (score_id ,student_id, subject_id ,marks,

exam_name, total_marks) will be decomposed into:

Score(score_id, student_id, subject_id, Marks, exam_id )

Exam(exam_id, exam_name total_marks)

Third Normal Form

Consider a schema: dept_advisor(s_ID, i_ID, dept_name)

With function dependencies: i_ID → dept_name,
s_ID, dept_name → i_ID
Two candidate keys = {s_ID, dept_name}, {s_ID, i_ID }
dept_advisor is in 3NF
s_ID, dept_name is a superkey
i_ID → dept_name and i_ID is NOT a superkey, but dept_name is
contained in a candidate key.
Third Normal Form: Redundancy

There is some redundancy in this schema dept_advisor (s_ID, i_ID,

dept_name) with FD = {i_ID → dept_name, s_ID, dept_name → i_ID}

Repetition of information (i_ID, dept_name)

Exercises

Given a relation R( X, Y, Z) and Functional Dependency set FD = { X → Y

and Y → Z }, determine whether the given R is in 3NF? If not convert it
into 3 NF.

Given a relation R( X, Y, Z, W, P) and Functional Dependency set FD = { X

→ Y, Y → P, and Z → W}, determine whether the given R is in 3NF? If not
convert it into 3 NF.
Exercises
Consider the relation PLAYER with relational schema PLAYER (Player-no, Player-name,
Team, Team-color, Coach-no, Coach-name, Player-position, Team-captain) and set of
functional dependencies as follows;
F = {Player-no → Player-name, Player-no → Player-position, Player-no → Team,
Coach-no → Coach-name, Team → Team-color, Team → Coach-no, Team →
Team-captain} with Player-no is the only candidate key.
Answer the questions given below;
a) Is PLAYER in 2NF? If not, convert into 2NF.
As the key (Player-no) is single and simple attribute, there is no possibilities for
partial-key dependencies. Hence, PLAYER is in 2NF

b) Is PLAYER in 3NF? If not, convert into 3NF.

To answer this question, we need to check for non-key dependencies or transitive

dependencies. That is, we have to look for dependencies like the one follows;
Non-key attribute(s) → Non-key attribute(s)
Exercises
Team → Team, Team-color, Team-captain, Coach-no, Coach-name
Coach-no → Coach-no, Coach-name
Hence, PLAYER is not in 3NF.
Decompose PLAYER into more tables based on the non-key dependencies. Then
we shall get the tables as follows;
PLAYER (Player-no, Player-name, Player-position, Team)
TEAM (Team, Team-color, Team-captain, Coach-no, Coach-name)
The key for PLAYER is Player-no, and all the others are non-key attributes. Hence,
PLAYER is in 2NF (no partial dependencies) and 3NF (no transitive
dependencies).
Exercises
The key for TEAM is Team. All the other attributes are non-key attributes and depends on
Team-no. Hence, TEAM is in 2NF. TEAM has following transitive dependency;
Team → Coach-no → Coach-name.
Hence, TEAM is not in 3NF. To convert, decompose TEAM as follows;
TEAM (Team, Team-color, Team-captain, Coach-no)
COACH (Coach-no, Coach-name)
Now, TEAM and COACH are both in 2NF and 3NF.

Final set of decomposed tables that are in 3NF are;

PLAYER (Player-no, Player-name, Player-position, Team)
TEAM (Team, Team-color, Team-captain, Coach-no)
COACH (Coach-no, Coach-name)
Boyce-Codd Normal Form (3.5 Normal Form)

A relation schema R is in BCNF with respect to a set F of functional

dependencies if for all functional dependencies in F+ of the form X→ Y
where X in R and Y in R, at least one of the following holds:

● X→ Y is trivial
● X is a superkey for R

Example schema not in BCNF:

Instr_dept (ID, name, salary, dept_name, building, budget )

because dept_name → building, budget holds on instr_dept, but

dept_name is not a superkey
Boyce-Codd Normal Form

To convert to BCNF, let R be a schema R that is not in BCNF.

Let X→ Y be the FD that causes a violation of BCNF.
We decompose R into: R1 (X U Y ) and R2 ( R - ( Y - X ) )

In our example of instr_dep (ID, name, salary, dept_name, building, budget )

dept_name → building, budget

X= dept_name Y = {building, budget}

and instr_dep is replaced by two new tables ( X U Y ) = ( dept_name, building,
budget )
( R - ( Y - X ) ) = ( ID, name, dept_name, salary )

Dept( dept_name, building, budget )

Inst ( ID, name, dept_name, salary )
Boyce-Codd Normal Form

Given class (course_id, title, dept_name, credits, sec_id, semester, year,

building, room_number, capacity, time_slot_id) with FDs:

course_id→ title, dept_name, credits

building, room_number→capacity
course_id, sec_id, semester, year→building, room_number, time_slot_id

A candidate key {course_id, sec_id, semester, year}.

Is the relation in BCNF if not convert it to BCNF.

Boyce-Codd Normal Form
course_id→ title, dept_name, credits holds but course_id is not a superkey.
We replace class by:

Course (course_id, title, dept_name, credits)

class-1 (course_id, sec_id, semester, year, building, room_number, capacity,
time_slot_id)
course is in BCNF

building, room_number→capacity holds on class-1

but {building, room_number} is not a superkey for class-1.
We replace class-1 by:
classroom (building, room_number, capacity)
section (course_id, sec_id, semester, year, building, room_number,
time_slot_id)
classroom and section are in BCNF.
Boyce-Codd Normal Form
Consider a relation schema R with attributes ABCDEFGH with functional
dependencies S:
S = {B → CD; BF → H; C → AG; CEH → F; CH → B}
Which of these functional dependencies violate BCNF (Boyce-Codd Normal
Form)?
Dependency Preservation

Let Fi be the set of dependencies F+ that include only

attributes in Ri.
A decomposition is dependency preserving, if
(F1 U F2 U…U Fn )+ = F +
When dependency preservation is maintained, FDs can be
checked by accessing only one table, instead of joining tables.
This avoids joins, which are typically slow.
Testing for Dependency Preservation
Consider a relation R (A, B, C, D) with the following set of functional dependencies;

F = {A → B, B → C, and C → D}.
Is the decomposition of R (A, B, C, D) into R1 (A, C, D) and R2 (B, C) a dependency
preserving decomposition?
Step 1: for R1, the derivable non-trivial functional dependency is, C → D. Hence,
F1 = {C → D}
Step 2: for R2, the derivable non-trivial functional dependency is, B → C. Hence,
F2 = {B → C}
(F1 U F2) = ({C → D} U {B → C}) = {C → D, B → C} ≠ F.
(F1 U F2)+ = {C → D, B → C, B → D}
F+ = {A → B, B → C, C → D, A → C, A → D, B → D}
Hence, (F1 U F2)+ ≠ F+
Testing for Dependency Preservation
To check if a dependency X→ Y is preserved in a decomposition of R into
R1, R2, …, Rn we apply the following test (with attribute closure done with
respect to F)
result = X
while (changes to result) do
for each Ri in the decomposition
t = (result ∩ Ri)+ ∩ Ri
result = result U t
● If result contains all attributes in Y, then the functional dependency
X→Y is preserved.
Testing for Dependency Preservation
Consider a relation R (A, B, C, D) with the following set of functional dependencies;

F = {A → B, B → C, and C → D}.
Is the decomposition of R (A, B, C, D) into R1 (A, C, D) and R2 (B, C) a dependency
preserving decomposition?
Step 1: for R1, the derivable non-trivial functional dependency is, C → D. Hence,
F1 = {C → D}
Step 2: for R2, the derivable non-trivial functional dependency is, B → C. Hence,
F2 = {B → C}
Testing for Dependency Preservation
F = {A → B, B → C, and C → D}. R1 (A, C, D) and R2 (B, C)
Step 3: check if a dependency A→ B is preserved
result = A
t = (result ∩ (R1))+ ∩ (R1)) = A+ ∩ (ACD) = (ABCD) ∩ (ACD) = ACD
result = result U t = ACD
t = (result ∩ (R2))+ ∩ (R2)) = C+ ∩ (BC) = (CD) ∩ (BC) = C
result = result U t = ACD
result does not contain B, so A→ B is not preserved
BCNF and Dependency Preservation
It is not always possible to achieve both BCNF and dependency reservation

Consider a schema: dept_advisor(s_ID, i_ID, dept_name)

With function dependencies: i_ID → dept_name, {s_ID, dept_name} —> i_ID

Two candidate keys = {s_ID, dept_name}, {s_ID, i_ID }

dept_advisor is not in BCNF as i_ID is not a superkey.

Decomposition : IDept( i_ID, dept_name ) , Inst ( s_ID, i_ID). Now it's in BCNF

Any decomposition of dept_advisor will not preserve the dependency

{s_ID, dept_name} → i_ID

Thus, the decomposition is NOT dependency preserving

Comparison of BCNF and 3NF
It is always possible to decompose a relation into a set of relations that are
in 3NF such that:

The decomposition is lossless

The dependencies are preserved

It is always possible to decompose a relation into a set of relations that are

in BCNF such that:

The decomposition is lossless

It may not be possible to preserve dependencies

Summary Normal Forms
■ BCNF -> 3NF -> 2NF -> 1NF
■ 1NF
● atomic attributes
■ 2NF
● no non-trivial dependencies of non-prime
attributes on parts of the key
■ 3NF
● no transitive non-trivial dependencies on the key
■ BCNF
● only non-trivial dependencies on a superkey
Design Goals

● Goal for a relational database design is:

○ BCNF.
○ Lossless join.
○ Dependency preservation.

● If we cannot achieve this, we accept one of

○ Lack of dependency preservation
○ Redundancy due to use of 3NF
How good is BCNF?
Consider a relation inst_info (ID, child_name, phone) where an instructor
may have more than one phone and can have multiple children

There are no non-trivial functional dependencies and therefore the relation

is in BCNF

■ Insertion anomalies – i.e., if we add a phone 981-992-3443 to 99999, we

need to add two tuples
Higher Normal Forms
It is better to decompose inst_info into:

This suggests the need for higher normal forms.

Multivalued Dependencies
For a dependency P → Q, if for an individual value of P, multiple value of Q exist, then the
relationship would be a multivalued dependency.

It is defined as P →→ Q in relation R(P,Q,S) if each P value is associated with a set of Q

values in a way that does not depend on the S values. Here P and Q are both subsets of R.

SUBJECT dependent on SID but not

functionally dependent SID SUBJECT ACTIVITY

ACTIVITY dependent on SID but not 200 OS Swimming

functionally dependent 200 C++ Tennis
The relation STUDENT (SID, SUBJECT, 200 OS Tennis
ACTIVITY) has a multivalued dependency
200 C++ Swimming
SID →→SUBJECT and SID→→ ACTIVITY 250 Math Jogging
Multivalued Dependencies
Let R be a relation schema and let α⊆R and β⊆R be sets of attributes. The
multivalued dependency α→→β (" α multidetermines β ") holds on R if, for
any legal relation r(R) and all pairs of tuples t1 and t2 in r such that:

t1[α]=t2[α] , there exist tuples t3 and t4 in r such that:

t1[α]=t2[α]=t3[α]=t4[α] t1[β]=t3[β] t2[β]=t4[β]

t1[R∖(α∪β)]=t4[R∖(α∪β)] t2[R∖(α∪β)]=t3[R∖(α∪β)]

Informally, if one denotes by (x,y,z) the tuple having values for α, β, R−α−β
collectively equal to x, y, z, then whenever the tuples (a,b,c) and (a,d,e) exist
in r, the tuples (a,b,e) and (a,d,c) should also exist in r.
Multivalued Dependencies
Tabular representation of α→→β
Multivalued Dependencies
Consider STUDENT (SID, SUBJECT, ACTIVITY)

SID SUBJECT ACTIVITY

200 OS Swimming
200 C++ Tennis
200 OS Tennis
200 C++ Swimming
250 Math Jogging

SID →→SUBJECT and SID→→ ACTIVITY

Multivalued Dependencies
Multivalued dependencies generate to anomalies.

SID SUBJECT ACTIVITY

Suppose that student 200 decides
200 OS Swimming
to sign up for skiing, 200 C++ Tennis
To keep consistent, we must add 200 OS Tennis
one row for each of these subjects
200 C++ Swimming
paired with skiing.
250 Math Jogging
row [200, OS, Skiing].
We can remove the anomaly by
row [200, c++, Skiing]. decomposing STUDENT relation into two
relations. STU-SUBJECT (SID, SUBJECT)
This is an Insert anomaly and STU-ACT (SID, ACTIVITY),
Elimination of Multivalued Dependency
We can remove the anomaly by decomposing STUDENT relation into two
relations. STU-SUBJECT (SID, SUBJECT) and STU-ACT (SID, ACTIVITY),

SID ACTIVITY
SID SUBJECT
200 OS 200 Swimming

200 C++ 200 Tennis

250 Math 250 Jogging

Remarks

The following all follow immediately from the definition of MVD.

1. Functional dependencies are a special case of MVDs.

Multivalued dependencies (MVDs) are a generalisation of functional

dependencies (FDs), i.e. every FD is an MVD, but the converse is not true.

Suppose an FD A→ B holds on a relation R. Then the MVD A →→ Β also

holds on R such that the set of values of B that are dependent on each value
of A always consists of a single value.
Remarks

2. For every relation R and (set of) attributes A, A →→ Α holds. (it is a trivial
MVD).

3. For every relation R and (set of) attributes A, A →→ R holds (where R

stands for all attributes of R). This is also a a trivial MVD.

4. MVDs always come in pairs.

If MVD A →→ Β holds on R then the MVD A →→ R–A–B also holds on R.

Trivial MVD : An MVD A →→ B on R is trivial if B⊆A or A ∪ B = R

(i.e. A ∪ B is all attributes of R)
Fourth Normal Form (4NF)

A relation R is in fourth normal form (4NF) iff whenever there is a

non-trivial multivalued dependency A →→ B in R, then all attributes of R
are functionally dependent on A.

Equivalently, R is in 4NF if and only if every non-trivial multivalued

dependency A →→ B in R is in fact a functional dependency A → B and
A contains a candidate key.

Equivalently, R is in 4NF if and only if it is in BCNF and all non-trivial

multivalued dependencies in R are in fact functional dependencies.
Fourth Normal Form (4NF)

The relation STUDENT (SID, SUBJECT, ACTIVITY) has a multivalued dependency

SID →→SUBJECT and SID→→ ACTIVITY

but not SID →SUBJECT and SID→ ACTIVITY. Hence not in 4NF

SID SUBJECT ACTIVITY

200 OS Swimming
200 C++ Tennis
200 OS Tennis
200 C++ Swimming
250 Math Jogging
Fourth Normal Form (4NF)

Decomposing STUDENT relation into two relations. STU-SUBJECT (SID,

SUBJECT) and STU-ACT (SID, ACTIVITY),

SID ACTIVITY
SID SUBJECT
200 OS 200 Swimming

200 C++ 200 Tennis

250 Math 250 Jogging

Join Dependency

A relation is said to have join dependency if it can be recreated by joining

multiple sub relations and each of these sub relations has a subset of the
attributes of the original relation.

Condition for join dependency:

If the join of R1 and R2 over Q is equal to relation R then we can say that a
join dependency exists, where R1 and R2 are the decomposition R1 (P, Q)
and R2 (Q, S) of a given relation R (P, Q, S). R1 and R2 are a lossless
decomposition of R.

Note: an MVD is a special case of a JD where n = 2.

A join dependency JD(R1, R2, ..., Rn), specified on relation schema R, is a
trivial JD if one of the relation schemas Ri in JD(R1, R2, ..., Rn) is equal to R.
Fifth Normal Form

A relation R is in 5NF if and only if it satisfies the following conditions:

1. R should be already in 4NF.

2. No further lossless decomposition ( no join dependency exists).

In 5NF, consideration must be given to tables where non-loss decomposition

can be achieved by decomposition into 3 or more separate tables.
 Fifth Normal Form

Relation SUPPLY with Join Dependency and conversion to Fifth Normal Form

The relation Supply (CK: Sname, Part_name, Proj_name) with no MVDs is in

4NF but not in 5NF
 Fifth Normal Form

Decomposition SUPPLY into 5NF

relations R1, R2, R3
Other Dependencies and Normal Forms (Self Read)

Inclusion Dependencies
Template Dependencies
Domain-Key Normal Form (DKNF)