Functional Dependencies

and Normalization Part-2

 Boyce and Codd Normal Form (BCNF)
This normal form is also referred as 3.5 normal forms. BCNF is an
extension of Third Normal Form on strict terms. This normal form
meets all the requirement of 3NF.
 Boyce-Codd Normal Form (BCNF states that −
 For any non-trivial functional dependency, X → A, X must be a
super-key.
 In previous example, Stu_ID is the super-key in the relation
Student_Detail.
 Zip is the super-key in the relation ZipCodes. So,
Stu_ID → Stu_Name, Zip
and
Zip → City
Which confirms that both the relations are in BCNF.
Any table is said to be in BCNF, if its candidate keys do not have
any partial dependency on the other attributes. i.e.; in any table
with (x, y, z) columns, if (x, y)->z and z->x then it's a violation
of BCNF. If (x, y) are composite keys and (x, y)->z, then there
should not be any reverse dependency, directly or partially.
In the above 3NF example, Stu_ID is the
Primary key in Student_detail table and
ZIP is the primary key in the ZipCodes
table. There is no other key column in each
of the tables which determines the
functional dependency. Hence it's in BCNF
form.

That is, with Stu_ID, we can retrieve

Stu_NAME and ZIP from Student_detail
table.
Similarly, with ZIP value, we can retrieve
CITY from ZipCodes table.
Example (For Practice)
Let us consider another example - consider each student who
has taken major subjects has different advisory lecturers.
Each student will have different advisory lecturers for same
Subjects. There exists following relationship, which is violation
of BCNF.
(STUDENT_ID, MAJOR_SUBJECT) -> ADVISORY_LECTURER
ADVISORY_LECTURER -> MAJOR_SUBJECT
i.e. Major_Subject which is a part of composite
candidate key is determined by non-key
attribute of the same table, which is against
the rule.
Below table will have all the anomalies too. If we
delete any student from below table, it deletes
lecturer's information too. If we add any new
lecturer/student to the database, it needs other
related information also. Also, if we update subject
for any student, his lecturer info also needs to be
changed, else it will lead to inconsistency.
Hence we need to decompose the table so that it
eliminates such relationship. Now in the new tables
below, there are no inter-dependent composite keys
(moreover, there is no composite key in both the
tables).
If we need to add/update/delete any lecturer, we can
directly insert record into STUDENT_ADVISOR table,
without affecting STUDENT_MAJOR table. If we need
to insert/update/delete any subject for a student,
then we can directly do it on STUDENT_MAJOR table,
without affecting STUDENT_ADVISOR table.
When we have both advisor as well as major subject
information, then we can directly add/update both
the tables.
Hence we have eliminated all the anomalies in the
database.
Fourth Normal Form (4NF)

In the fourth normal form:

It should meet all the requirement of 3NF.

Attribute of one or more rows in the table

should not result in more than one rows of
the same table leading to multi-valued
dependencies

To understand it clearly, consider a table

with Subject, Lecturer who teaches each
subject and recommended Books for each
subject.
When query…
If we observe the data in the table above, it satisfies
3NF. But LECTURER and BOOKS are two
independent entities here. There is no relationship
between Lecturer and Books. In the above example,
either Alex or Bosco can teach Mathematics. For
Mathematics subject, student can refer either
'Maths Book1' or 'Maths Book2'. i.e.;

SUBJECT --> LECTURER

SUBJECT-->BOOKS
This is a multivalued dependency on SUBJECT. If we
need to select both lecturer and books recommended
for any of the subject, it will show up (lecturer, books)
combination, which implies lecturer who recommends
which book. This is not correct.
To eliminate this dependency, we divide the table into two as
below:

Now if we want to know the lecturer names and books

recommended for any of the subject, we will fire two
independent queries. Hence it removes the multi-valued
dependency and confusion around the data. Thus the table is
in 4NF.
Fifth Normal Form (5NF)
A database is said to be in 5NF, if and only if,
It's in 4NF
If we can decompose table further to eliminate
redundancy and anomaly, and when we re-join
the decomposed tables by means of candidate
keys, we should not be losing the original data or
any new record set should not arise. In simple
words, joining two or more decomposed table
should neither lose records nor create new
records.

Consider an example of different Subjects taught

by different lecturers and the lecturers taking
classes for different semesters.
Note: Consider that Semester1 has
Mathematics, Physics and Chemistry and
Semester2 has only Physics in its academic year.
Physics class for Semester 1, but she does not
take Physics class for Semester 2. In this case,
combination of all these 3 fields is required to
identify a valid data. If we want to add a new
class - Semester3 but do not know which Subject
and who will be taking that subject. We would be
simply inserting a new entry with Class as
Semester3 and leaving Lecturer and subject as
NULL. But it's not a good to have such entries.
Moreover, all the three columns together act as a
primary key, we cannot leave other two columns
blank.

Hence we have to decompose the table in such a

way that it satisfies all the rules till 4NF and when
join them by using keys, it should give correct
record. Here, we can represent each lecturer's
Subject area and their classes in a better way.
We can divide above table into three –
Now, each of combinations is in three
different tables. If we need to identify who
is teaching which subject to which
semester, we need join the keys of each
table and get the result.
Query: who teaches Physics to Semester1,
we would be selecting Physics and
Semester1 from table 3 above, join with
table1 using Subject to filter out the
lecturer names. Then join with table2 using
Lecturer to get correct lecturer name.
That is we joined key columns of each table
to get the correct data. Hence there is no
lose or new data - satisfying 5NF condition.
select t3.Class, t3.Subject, t1.Lecturer
from TABLE3 t3, TABLE2 t2, TABLE1 t1,
where t3.Class = 'SEMESTER1' and
t3.SUBJECT= 'PHYSICS'
and t3.Subject = t1.Subject
and t3.Class = t2.Class
and t1.Lecturer = t2.Lecturer;
END of Part-2
Sources

www.studytonight.com/dbms/database-
normalization.php
www.tutorialspoint.com/dbms/pdf/
database_normalization.pdf
www.tutorialspoint.com/dbms/
dbms_storage_system.htm

www.tutorialcup.com/dbms/boyce-codd-normal-form.ht
m
Other Books.