DBMS Normalization
DBMS Normalization
DBMS Normalization
UNIT-3
KEY CONCEPTS
Formal Name Common Name Also Known As
2
KEYS in DBMS
• KEYS in DBMS is an attribute or set of attributes which helps you to
identify a row(tuple) in a relation(table).
• They allow you to find the relation between two tables. Keys help you
uniquely identify a row in a table by a combination of one or more columns
in that table.
• Key is also helpful for finding unique record or row from the table.
Database key is also helpful for finding unique record or row from the
table.
• There are mainly seven different types of Keys in DBMS and each key has
it’s different functionality:
• Table – Sales
Relational Decomposition
• When a relation in the relational model is not in appropriate normal form
then the decomposition of a relation is required.
• In a database, it breaks the table into multiple tables.
• If the relation has no proper decomposition, then it may lead to problems
like loss of information.
• Decomposition is used to eliminate some of the problems of bad design like
anomalies, inconsistencies, and redundancy.
• Lossless Decomposition
• If the information is not lost from the relation that is decomposed, then the
decomposition will be lossless.
• The lossless decomposition guarantees that the join of relations will result in the
same relation as it was decomposed.
• The relation is said to be lossless decomposition if natural joins of all the
decomposition give the original relation.
EMPLOYEE table:
• Now, when these two relations are joined on the common column
"EMP_ID", then the resultant relation will look like:
In above example Marks is fully functionally dependent on STUDENT#
COURSE#and not on sub set of STUDENT# COURSE#. This means Marks
can not be determined either by STUDENT# OR COURSE# alone. It can be
determined only using STUDENT# AND COURSE# together. Hence Marks
is fully functionally dependent on STUDENT# COURSE#.
Another Example
• CourseName is not fully functionally dependent on STUDENT#
COURSE# because subset of STUDENT# COURSE#
• i.e only COURSE# determines the CourseName and STUDENT# does not
have any role in deciding CourseName.
• X is a super key.
• If all these conditions are true for any relation(table), it is said to have
multi-valued dependency.
As you can see in the table above, student with s_id 1 has opted for two
courses, Science and Maths, and has two hobbies, Cricket and Hockey.
You must be thinking what problem this can lead to, right?
Well the two records for student with s_id 1, will give rise to two more records, as
shown below, because for one student, two hobbies exists, hence along with both the
courses, these hobbies should be specified.
Now this relation satisfies the fourth normal form.
A table can also have functional dependency along with multi-valued dependency.
In that case, the functionally dependent columns are moved in a separate table and
the multi-valued dependent columns are moved to separate tables.
Fifth normal form (5NF)
• A relation is in 5NF if it is in 4NF and not contains any join dependency
and joining should be lossless.
• 5NF is satisfied when all the tables are broken into as many tables as
possible in order to avoid redundancy.
• 5NF is also known as Project-join normal form (PJ/NF).
• In the above table, John takes both Computer and Math class for
Semester 1 but he doesn't take Math class for Semester 2. In this
case, combination of all these fields required to identify a valid
data.
54