Fundamental ideas in database
management and design are functional
dependency and attribute closure.
They are essential to maintaining data
integrity and building effective, organized,
and normalized databases.
Functional dependency helps ensure the same
data doesn't exist repetitively across a database
or network of databases.
Maintain the quality and integrity of data.
A functional dependency occurs when the value of
one attribute determines the value of another
attribute
The attributes of a table is said to be dependent on each
other when an attribute of a table uniquely identifies another
attribute of the same table.
For example: Suppose we have a student table with
attributes:
Stu_Id, Stu_Name, Stu_Age.
Here Stu_Id attribute uniquely identifies the Stu_Name
attribute of student table because if we know the student id
we can tell the student name associated with it.
This is known as functional dependency and can be written
as Stu_Id->Stu_Name or in words we can say Stu_Name is
functionally dependent on Stu_Id.
If column X of a table uniquely identifies the column Y of same
table then it can represented as X->Y
(Attribute Y is functionally dependent on attribute X)
Functional dependency is represented by an arrow sign (→)
that is, X→Y, where X functionally determines Y.
The left-hand side attributes determine the values of attributes
on the right-hand side.
X- Determinant
Y-Dependent
Since for each value of A there is associated one and only one value of B.
Since for A = 3 there is associated more than one value of B.
• STUD_NO is unique for each student.
So
STUD_NO->STUD_NAME,
STUD_NO->STUD_PHONE,
STUD_NO->STUD_STATE,
STUD_NO->STUD_COUNTRY and
STUD_NO -> STUD_AGE all will be true.
Similarly,
• STUD_STATE->STUD_COUNTRY will be true as if two
records have same STUD_STATE, they will have
same STUD_COUNTRY as well.
For relation STUDENT_COURSE,
COURSE_NO->COURSE_NAME will be true as two
records with same COURSE_NO will have same
COURSE_NAME.
Functional Dependency set or FD set of a relation
is the set of all FDs present in the relation
{ STUD_NO->STUD_NAME, STUD_NO->STUD_PHONE,
STUD_NO->STUD_STATE, STUD_NO->STUD_COUNTRY,
STUD_NO -> STUD_AGE, STUD_STATE->STUD_COUNTRY }
• The Closure Of Functional Dependency
means the complete set of all possible
attributes that can be functionally derived
from a given functional dependency using
the inference rules known as Armstrong’s
Rules.
• If “F” is a functional dependency then
closure of functional dependency can be
denoted using “{F}+”.
• There are three steps to calculate closure of
functional dependency. These are:
Step-1 : Add the attributes which are present
on Left Hand Side in the original functional
dependency.
Step-2 : Now, add the attributes present on the
Right Hand Side of the functional dependency.
Step-3 : With the help of attributes present on
Right Hand Side, check the other attributes
that can be derived from the other given
functional dependencies.
Repeat this process until all the possible
attributes which can be derived are added in
the closure.
Consider the table student_details
having
(Roll_No, Name, Marks, Location) as
the attributes and having two
functional dependencies.
FD1 : Roll_No -> Name, Marks
FD2 : Name -> Marks, Location
Now, We will calculate the closure of all
the attributes present in the relation
using the three steps mentioned below.
Step-1 : Add attributes present on the LHS of the first
functional dependency to the closure.
{Roll_no}+ = {Roll_No}
Step-2 : Add attributes present on the RHS of the original
functional dependency to the closure.
{Roll_no}+ = {Roll_No, Marks}
Step-3 : Add the other possible attributes which can be
derived using attributes present on the RHS of the closure.
So Roll_No attribute cannot functionally determine any
attribute but Name attribute can determine other attributes
such as Marks and Location using 2nd Functional
Dependency(Name [icon name="long-arrow-right" class=""
unprefixed_class=""] Marks, Location).
Therefore, complete closure of Roll_No will
be :
{Roll_no}+ = {Roll_No, Marks, Name,
Location}
Similarly, we can calculate closure for other attributes too i.e
“Name”.
Step-1 : Add attributes present on the LHS of the functional
dependency to the closure.
{Name}+ = {Name}
Step-2 : Add the attributes present on the RHS of the
functional dependency to the closure.
{Name}+ = {Name, Marks,
Location}
Step-3 : Since, we don’t have any functional dependency
where “Marks or Location” attribute is functionally
determining any other attribute , we cannot add more
attributes to the closure. Hence complete closure of Name
would be :
{Name}+ = {Name, Marks,
Location}
NOTE : We don’t have any Functional dependency where
marks and location can functionally determine any
attribute. Hence, for those attributes we can only add the
attributes themselves in their closures. Therefore,
{Marks}+ = {Marks}
and
{Location}+ = { Location}
Consider a relation R(A,B,C,D,E) having
below mentioned functional dependencies.
FD1 : A -> BC , FD2 : C -> B, FD3 : D ->
E , FD4 : E -> D
Now, we need to calculate the
closure of attributes of the
relation R. The closures will be:
{A}+ = {A, B, C}
{B}+ = {B}
{C}+ = {B, C}
{D}+ = {D, E}
{E}+ = {E,D}
A Candidate Key of a relation is an
attribute or set of attributes that can
determine the whole relation or
contains all the attributes in its
closure."
Consider the relation R(A,B,C) with
given functional dependencies :
FD1 : A -> B
FD2 : B ->C
Now, calculating the closure of the
attributes as
{A}+ = {A, B, C}
{B}+ = {B, C}
{C}+ = {C}
Clearly, “A” is the candidate key
as, its closure contains all the
attributes present in the relation
“R”.
Consider another relation R(A, B, C, D,
E) having the Functional
dependencies :
FD1 : A -> BC
FD2 : C -> B
FD3 : D ->E
FD4 : E -> D
Now, calculating the closure of the attributes as :
{A}+ = {A, B, C}
{B}+ = {B}
{C}+ = {C, B}
{D}+ = {E, D}
{E}+ = {E, D}
In this case, a single attribute is
unable to determine all the {A, D}+ = {A, B, C, D, E
attribute on its own like in {A, E}+ = {A, B, C, D, E
previous example. Here, we need
to combine two or more
attributes to determine the
candidate keys.
Hence, "AD" and "AE" are the two possible keys of the given
relation “R”. Any other combination other than these two
would have acted as extraneous attributes.
• Through the identification and removal of
redundant or unneeded data, they aid in the
reduction of data redundancy in databases.
• By guaranteeing that data is correct and
consistent throughout the database, they
enhance data integrity.
• They make it simpler to add, edit, and remove
data, which helps with database management.
• time-consuming and complex, -large
databases
• slow query performance
• may not always reflect the true relationships
between data elements.
IR1. (Reflexive) If Y subset-of X, then X -> Y
In the reflexive rule, if Y is a subset of X, then X
determines Y.
Example:
X = {a, b, c, d, e}
Y = {a, b, c}
IR2. (Augmentation) If X -> Y, then XZ -> YZ
(Notation: XZ stands for X U Z)
The augmentation is also called as a partial
dependency.
In augmentation, if X determines Y, then XZ
determines YZ for any Z.
For R(ABCD), if A → B then AC → BC
IR3. (Transitive) If X -> Y and Y -> Z, then X -> Z.
In the transitive rule, if X determines Y and Y determines Z,
Various Types of Functional Dependencies
are –
Single Valued Functional Dependency
Fully Functional Dependency
Partial Functional Dependency
Transitive Functional Dependency
Trivial Functional Dependency
The relation is said to be a single-valued functional
dependency if and only if there exists only one value of B
(dependent) for a particular value of A (determinant).
A simple example of single value functional dependency is
when A is the primary key of an entity (eg. SID) and B is
some single valued attribute of the entity (eg. Sname).
Then, A → B must always hold.
Student_ID → Student_Name.
Sname is dependent on SID
CID SID Sname
SIDSname C1 S1 A
S1 A C1 S2 A
S1 A C2 S1 A
C3 S1 A
S1 A
A functional dependency P → Q is full functional
dependency if removal of any attribute A from P
means that the dependency does not hold any
more.
If AD → C, is fully functional dependency, then we
cannot remove A or D. i.e. C is fully functional
dependent on AD. If we are able to remove A or
D, then it is not full functional dependency.
FD: ABC → D
D is said to be fully functional dependent if and only if any proper
subset of ABC (determinant) doesn’t determine D (dependent).
Marks is fully functionally dependent (Student_ID, Course) → Marks.
on Student_ID and Course.
Only Student_ID or Course (a subset
of determinant) cannot determine
marks of the student.
{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
Contrary to fully functional dependency, if any subset or ABC
(determinant) can determine D (dependent) then D is said to be partially
functionally dependent on ABC.
FD: ABC → D
For example, Consider a Relation R(A,B,C,D,E) having FD : AB → CDE
where PK is AB.
Then, { A → C; A → D; A → E; B → C; B → D; B → E } all are Partial
Dependencies.
(Student_ID, Course) → Student_Name. Student_Name can
also be determined with only Student_ID and Course is not
necessary. Hence, Student_Name is said to be partially
functionally dependent on (Student_ID, Course).
Given a relation R(A,B,C) then dependency like A–>B, B–>C is a
transitive dependency, since A–>C is implied .
Ex: SSN --> DMGRSSN is a transitive FD {since SSN -->
DNUMBER and DNUMBER --> DMGRSSN hold}
Student_ID → Semester; Semester → Hostel.
The semester can only be told if we have the Student_ID and
the hostel can be determined only if we knew the semester.
The final result comes out as we can determine the hostel only
if we know the Student_ID.
Hence, the Hostel is transitively functionally dependent on
Student_ID.
Converse to transitive functional
dependency, the relation is said to be a
non-transitive dependency if there exists no
transitive relation between the attributes.
From Table 6, Student_Name is not
transitively dependent on Student_ID.
FD: A → B
A and B are said to have trivial functional dependency if and only
if
B is a subset or equal to that of A.
Trivial functional dependency is always valid independent of
the values in the table.
(Student_ID,Student_Name) →Student_Name.
Here the tuple
(Student_ID,Student_Name) is a (in
(a,b)) as multiple attributes can also
be in functional dependency and b is
Student_Name.
If you observe b is a subset of a i.e.
Student_Name is already present in
the tuple of a.
FD: A → B
A and B are said to have non-trivial functional dependency if and only if A intersection B is
an empty set.
Non-trivial functional dependency may be valid or not with respect to the values in the
table.
Hence, we cannot assure that the non-trivial functional dependency is always valid.
A ∩ B = Φ.
Ex: Student_ID → Student_Name.
It has a non-trivial functional dependency as there is no common attribute between the two.
And the functional dependency is valid.
• 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 undesirable
characteristics like Insertion, Update, and Deletion
Anomalies.
• Normalization divides the larger table into smaller
ones and links them using relationships.
• The normal form is used to reduce redundancy from
the database table.
The main reason for normalizing the
relations is removing these anomalies.
Failure to eliminate anomalies leads to data
redundancy and can cause data integrity
and other problems as the database grows.
• Anomaly means the inconsistency occurred
in the relational table during the operations
performed on the relational table
• Insertion Anomaly: Insertion Anomaly
refers to when one cannot insert a new tuple
into a relationship due to lack of data.
• Deletion Anomaly: The delete anomaly
refers to the situation where the deletion of
data results in the unintended loss of some
other important data.
• Updatation Anomaly: The update anomaly
is when an update of a single data value
requires multiple rows of data to be updated.
emp_id emp_name emp_address emp_dept
101 Rick Delhi D001
101 Rick Delhi D002
123 Maggie Agra D890
166 Glenn Chennai D900
166 Glenn Chennai D004
Update anomaly: In the above table we
have two rows for employee Rick as he
belongs to two departments of the company.
If we want to update the address of Rick then
we have to update the same in two rows or
the data will become inconsistent.
If somehow, the correct address gets updated
in one department but not in other then as
per the database, Rick would be having two
different addresses, which is not correct and
would lead to inconsistent data.
Insert anomaly: Suppose a new employee
joins the company, who is under training
and currently not assigned to any
department then we would not be able to
insert the data into the table if emp_dept
field doesn’t allow nulls.
Delete anomaly: Suppose, if at a point of
time the company closes the department
D890 then deleting the rows that are having
emp_dept as D890 would also delete the
information of employee Maggie since she
is assigned only to this department.
Stu_id Stu_name Stu_branch Stu_club Insertion Anomaly
If we add a new row for
2018nk01 Shivani Computer literature student Ankit who is not a
science part of any club, we
2018nk01 Shivani Computer dancing cannot insert the row into
science the table as we cannot
2018nk02 Ayush Electronics Videograph insert null in the column
y of stu_club. This is called
insertion anomaly.
2018nk03 Mansi Electrical dancing
2018nk03 Mansi Electrical singing
2018nk04 Gopal Mechanical Photograph Deletion Anomaly
y If we remove the
Update Anomaly photography club from
In the above table, if Shivani changes the college, then we will
her branch from Computer Science to have to delete its row
Electronics, then we will have to from the table. But it will
update all the rows. If we miss any also delete the table of
row, then Shivani will have more than Gopal and his details. So,
one branch, which will create the this is called deletion
update anomaly in the table. anomaly and it will make
. the database inconsistent
Un-Normalized Form (UNF)
If a table contains non-atomic values at each row, it is
said to be in UNF. An atomic value is something that
can not be further decomposed. A non-atomic value,
as the name suggests, can be further decomposed and
simplified. Consider the following table:
Emp-Id Emp-Name Month Sales Bank-Id Bank-Name
E01 AA Jan 1000 B01 SBI
Feb 1200
Mar 850
E02 BB Jan 2200 B02 UTI
Feb 2500
E03 CC Jan 1700 B01 SBI
Feb 1800
Mar 1850
Apr 1725
In the sample table above, there are multiple occurrences of rows under each key Emp-Id.
Although considered to be the primary key, Emp-Id cannot give us the unique identification
facility for any single row. Further, each primary key points to a variable length record (3
for E01, 2 for E02 and 4 for E03).
First normal form(1NF)
Second normal form(2NF)
Third normal form(3NF)
Boyce & Codd normal form (BCNF)
Fourth normal form(4NF)
Five normal form(5NF)
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.
BCNF A stronger definition of 3NF is known as
Boyce Codd's normal form.
4NF A relation will be in 4NF if it is in Boyce
Codd's normal form and has no multi-valued
dependency.
5NF A relation is in 5NF. If it is in 4NF and does
not contain any join dependency, joining
should be lossless.
A relation is said to be in 1NF if it contains atomic
values and each row can provide a unique
combination of values.
As per the rule of first normal form, an
attribute (column) of a table cannot hold
multiple values. It should hold only
atomic values.
Emp-Id Emp-Name Month Sales Bank-Id Bank-Name
E01 AA Jan 1000 B01 SBI
E01 AA Feb 1200 B01 SBI
E01 AA Mar 850 B01 SBI
E02 BB Jan 2200 B02 UTI
E02 BB Feb 2500 B02 UTI
E03 CC Jan 1700 B01 SBI
E03 CC Feb 1800 B01 SBI
E03 CC Mar 1850 B01 SBI
E03 CC Apr 1725 B01 SBI
As you can see now, each row contains unique combination of values. Unlike
in UNF, this relation contains only atomic values, i.e. the rows can not be
further decomposed, so the relation is now in 1NF.
First Normal Form (1NF)
Not Normalized
emp_id emp_name emp_address emp_mobile
emp_id emp_name emp_address emp_mobile
101 Herschel New Delhi 8912312390
101 Herschel New Delhi 8912312390
8812121212
102 Jon Kanpur 102 Jon Kanpur 8812121212
9900012222
103 Ron Chennai 7778881212 102 Jon Kanpur 9900012222
9990000123
103 Ron Chennai 7778881212
104 Lester Bangalore
8123450987
104 Lester Bangalore 9990000123
104 Lester Bangalore 8123450987
A relation is said to be in 2NF if already it is in 1NF and each and
every attribute fully depends on the primary key of the relation.
Speaking inversely, if a table has some attributes which is not
dependant on the primary key of that table, then it is not in 2NF.
Emp-Id is the primary key of the above relation. Emp-Name, Month,
Sales and Bank- Name all depend upon Emp-Id.
But the attribute Bank-Name depends on Bank-Id, which is not the
primary key of the table. So the table is in 1NF, but not in 2NF.
If this position can be removed into another related relation, it would
come to 2NF.
A table is said to be in 2NF if both the following
conditions hold:
A relation is said to be in 2NF if it is already in 1NF
and each and every attribute fully depends on the
primary key of the relation.
non-prime attribute
The attribute which is not in the primary key is called
non-prime attribute.
Emp-Id Emp-Name Month Sales Bank-Id
E01 AA JAN 1000 B01
E01 AA FEB 1200 B01
E01 AA MAR 850 B01
E02 BB JAN 2200 B02 Bank-Id Bank-Name
E02 BB FEB 2500 B02 B01 SBI
E03 CC JAN 1700 B01 B02 UTI
E03 CC FEB 1800 B01
E03 CC MAR 1850 B01
E03 CC APR 1726 B01
After removing the portion into another relation we store the lesser
amount of data in two relations without any loss of information.
There is also a significant reduction in redundancy.
Example: Suppose a school wants to store
the data of teachers and the subjects they
teach. They create a table that looks like
this: Since a teacher can teach more than
one subjects, the table can have multiple
rows for a same teacher.
teacher_id subject teacher_age
111 Maths 38
111 Physics 38
222 Biology 38
333 Physics 40
333 Chemistry 40
Candidate Keys: {teacher_id, subject}
Non prime attribute: teacher_age
The table is in 1 NF because each attribute has atomic values. However, it is not in
2NF because non prime attribute teacher_age is dependent on teacher_id alone
which is a proper subset of candidate key. This violates the rule for 2NF as the
rule says “no non-prime attribute is dependent on the proper subset of any
candidate key of the table”.
teacher_details table
teacher_id teacher_age teacher_subje
ct table:
111 38
222 38 teacher_id subject
333 40 111 Maths
111 Physics
222 Biology
333 Physics
333 Chemistry
A relation is said to be in 3NF, if it is already in 2NF and there exists no
transitive dependency in that relation. Speaking inversely, if a table
contains transitive dependency, then it is not in 3NF, and the table must be
split to bring it into 3NF.
What is a transitive dependency?
Within a relation if we see
A B [B depends on A]
And
B C [C depends on B]
Then we may derive
A C[C depends on A]
Such derived dependencies hold well in most of the situations.
For example if we have Roll Marks
And
Marks Grade
Then we may safely derive Roll Grade.
This third dependency was not originally specified but we have
derived it.
The derived dependency is called a transitive dependency when
such dependency becomes improbable.
emp_id emp_name emp_zip emp_state emp_city emp_district
1001 John 282005 UP Agra Dayal Bagh
1002 Ajeet 222008 TN Chennai M-City
1006 Lora 282007 TN Chennai Urrapakkam
1101 Lilly 292008 UK Pauri Bhagwan
1201 Steve 222999 MP Gwalior Ratan
Super keys: {emp_id}, {emp_id, emp_name}, {emp_id, emp_name, emp_zip}…
so on
Candidate Keys: {emp_id}
Non-prime attributes: all attributes except emp_id are non-prime as they are
not part of any candidate keys.
Here, emp_state, emp_city & emp_district dependent on emp_zip. And,
emp_zip is dependent on emp_id that makes non-prime attributes (emp_state,
emp_city & emp_district) transitively dependent on super key (emp_id). This
violates the rule of 3NF.
Employee table
Employee_zip table
emp_distri
emp_id emp_name emp_zip emp_zip emp_state emp_city
ct
1001 John 282005
282005 UP Agra Dayal Bagh
1002 Ajeet 222008 222008 TN Chennai M-City
Urrapakka
1006 Lora 282007 282007 TN Chennai
m
1101 Lilly 292008 292008 UK Pauri Bhagwan
1201 Steve 222999 222999 MP Gwalior Ratan
Student_Detail Table :
Student Studen DOB Street city State Zip
_id t_nam
e
New Student_Detail Table :
Student_id Student_na DOB Zip
me
Address Table :
Zip Street city state
A relationship is said to be in BCNF if it is already in 3NF
and the left hand side of every dependency is a candidate
key. A relation which is in 3NF is almost always in BCNF.
There could be some situation when a 3NF relation may not
be in BCNF the following conditions are found true.
1. The candidate keys are composite.
2. There are more than one candidate keys in the relation.
3. There are some common attributes in the relation.
Professor Code Department Head of Dept. Percent Time
P1 Physics Ghosh 50
P1 Mathematics Krishnan 50
P2 Chemistry Rao 25
P2 Physics Ghosh 75
P3 Mathematics Krishnan 100
Consider, as an example, the above relation. It is assumed that:
1. A professor can work in more than one department
2. The percentage of the time he spends in each department is given.
3. Each department has only one Head of Department.
The relation diagram for the above relation is given as the following:
The given relation is in 3NF. Observe, however, that the
names of Dept. and Head of Dept. are duplicated. Further, if
Professor P2 resigns, rows 3 and 4 are deleted. We lose the
information that Rao is the Head of Department of Chemistry.
The normalization of the relation is done by creating a new
relation for Dept. and Head of Dept. and deleting Head of
Dept. form the given relation. The normalized relations are
shown in the following.
Example: Suppose there is a company wherein employees work
in more than one department. They store the data like this:
emp_nationalit dept_typ dept_no_of_e
emp_id emp_dept
y e mp
Production and
1001 Austrian D001 200
planning
1001 Austrian stores D001 250
design and
1002 American technical D134 100
support
Purchasing
1002 American D134 600
department
Functional dependencies in the table above:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate key: {emp_id, emp_dept}
The table is not in BCNF as neither emp_id nor emp_dept alone
are keys.
To make the table comply with BCNF we can break the table in
three tables like this:
emp_nationality table:
emp_id emp_nationality
1001 Austrian
1002 American
emp_dept table:
dept_typ dept_no_
emp_dept emp_dept_mapping table
e of_emp
emp_id emp_dept
Production and
D001 200
planning Production
1001
and planning
stores D001 250
1001 stores
design and
design and technical
D134 100 1002 technical
support
support
Purchasing
1002
department
Purchasing
D134 600
department
Functional dependencies:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate keys:
For first table: emp_id
For second table: emp_dept
For third table: {emp_id, emp_dept}
This is now in BCNF as in both the functional
dependencies left side part is a key.
When attributes in a relation have multi-valued dependency, further
Normalization to 4NF and 5NF are required. Let us first find out what
multi-valued dependency is.
A multi-valued dependency is a typical kind of dependency in which each
and every attribute within a relation depends upon the other, yet none of
them is a unique primary key.
Consider a vendor supplying many items to many projects in an organization. The
following are the assumptions:
1. A vendor is capable of supplying many items.
2. A project uses many items.
3. A vendor supplies to many projects.
4. An item may be supplied by many vendors.
A multi valued dependency exists here because all the
attributes depend upon the other and yet none of them
is a primary key having unique value.
Vendor Code Item Code Project No.
V1 I1 P1
V1 I2 P1
V1 I1 P3
V1 I2 P3
V2 I2 P1
V2 I3 P1
V3 I1 P2
V3 I1 P3
The given relation has a number of problems. For example:
1.Ifvendor V1 has to supply to project P2, but the item is not yet decided, then
a row with a blank for item code has to be introduced.
2.The information about item I1 is stored twice for vendor V3.
Observe that the relation given is in 3NF and also in BCNF. It still has the
problem mentioned above. The problem is reduced by expressing this relation
as two relations in the Fourth Normal Form (4NF). A relation is in 4NF if it
has no more than one independent multi valued dependency or one
independent multi valued dependency with a functional dependency.
The table can be expressed as the two 4NF relations given as following. The
fact that vendors are capable of supplying certain items and that they are
assigned to supply for some projects in independently specified in the 4NF
relation.
These relations still have a problem. While defining the 4NF we mentioned
that all the attributes depend upon each other. While creating the two tables
in the 4NF, although we have preserved the dependencies between Vendor
Code and Item code in the first table and Vendor Code and Item code in the
second table, we have lost the relationship between Item Code and Project
No. If there were a primary key then this loss of dependency would not
have occurred. In order to revive this relationship we must add a new table
like the following. Please note that during the entire process of
normalization, this is the only step where a new table is created by joining
two attributes, rather than splitting them into separate tables.
First Normal Form (1NF)
• Each table cell should contain a single value.
• Each record needs to be unique.
Second Normal Form (2NF)
• Rule 1- Be in 1NF
• Rule 2- Single Column Primary Key that does not
functionally dependent on any subset of candidate
key relation
Third Normal Form (3NF)
• Rule 1- Be in 2NF
• Rule 2- Has no transitive functional dependencies
