Wordpress Material Rdbms U 5
Wordpress Material Rdbms U 5
Wordpress Material Rdbms U 5
Unit – V
Normalization
5.1 Basics of Normalization
• Database normalization is the process of removing redundant data from your tables to
improve storage efficiency, data integrity, and scalability.
• In the relational model, methods exist for quantifying how efficient a database is. These
classifications are called normal forms (or NF), and there are algorithms for converting a
given database in normal form.
• A relation R is in first normal form (1NF) if and only if all domains contain
atomic values only.
• A relation R is in first normal form (1NF) if and only if it does not contain any
composite or multi valued attributes or their combinations.
Example:
Society City
• Above relation has four attributes Cid, Name, Address, Contact_no. Here Address is
composite attribute which is further divided in to sub attributes as Society and City.
Another attribute Contact_no is multi valued attribute which can store more than one
values. So
• Above relation is not in 1NF.
Problem:
• Suppose we want to find all customers for some particular city then it is difficult to
retrieve. Reason is city name is combined with society name and stored whole as address.
Solution:
• Insert separate attribute for each sub attribute of composite attribute.
First Approach:
• Determine maximum allowable values for multi-valued attribute.
• Insert separate attribute for multi valued attribute and insert only one value on one
attribute and other in other attribute.
• So, above table can be created as follows:
Second Approach:
• Remove multi valued attribute and place it in a separate relation along with the primary
key of a given original relation.
• So, above table can be created as follows:
Customer: Customer_Contact:
C03 9898787898
• A relation R is in second normal form (2NF) if and only if it is in 1NF and every non-
prime attribute of relation is fully dependent on the primary key.
OR
• A relation R is in second normal form (2NF) if and only if it is in 1NF and no any non-
prime attribute is partially dependent on the primary key.
Example:
Depositor_Account:
cid ano acess_date balance Bname
• Above relation has five attributes cid, ano, acess_date, balance, bname and two FDS
FD1: {cid,ano} {acess_date, balance, bname} and
FD2: ano {balance, bname}
• We have cid and ano as primary key.
• As per FD2 balace and bname are only depend on ano not cid.
• In above table balance and bname are not fully dependent on primary key but these
attributes are partial dependent on primary key. So above relation is not in 2NF.
Problem:
• For example in case of joint account multiple customers have common account.
• If some account says ‘A02’ is jointly by two customers says ‘C02’ and ‘C04’ then data
values for attributes balance and bname will be duplicated in two different tuples of
customers ‘C02’ and ‘C04’.
Solution:
• Decompose relation in such a way that resultant relation does not have any partial FD.
• For this purpose remove partial dependent attributes that violets 2NF from relation. Place
them in separate new relation along with the prime attribute on which they are full
dependent.
• The primary key of new relation will be the attribute on which they are fully dependent.
• Keep other attributes same as in that table with same primary key.
• So, above table Depositor_Account can be decomposed into Account and
Account_Holder table as per following.
Account: Account_Holder:
• So, Both Account and Account_Holder relations are in second normal form.
•A relation R is in third normal form (3NF) if and only if it is in 2NF and no any non-
prime attribute of a relation is transitively dependent on the primary key.
• An attribute C is transitively dependent on attribute A if there exist an attribute B such
that:
A → B and B → C.
Example:
• Above relation has four attributes ano, balance, bname, baddress and two FDS
FD1 : ano = {balance, bname, baddress} and
FD2 : bname = baddress
• So, from FD1 and FD2 and using transitivity rule we get ano=baddress.
• So, there is transitively dependency from ano to baddress using bname in which
baddress is non-prime attribute.
• So, there is a non-prime attribute baddress which is transitively dependent on primary
key ano.
• So, above relation is not in 3NF.
Problem:
Solution:
• Decompose relation in such a way that resultant relation does not have any non-prime
attribute that are transitively dependent on primary key.
• For this purpose remove transitively dependent attribute that violets 3NF from relation.
Place them in separate new relation along with the non-prime attribute due to which
transitive dependency occurred. The primary key of new relation will be this non-prime
attribute.
• Keep other attribute same as in that table with same primary key.
• So, above table Account_Branch can be decomposed into Account and Branch table as
per following:
❖ Advantages of Normalization:
❖ Disadvantages of Normalization: