normalization

1. Normalization
Normalization is a process which mainly tries to remove redundancy .
Redundancy occurs when we try to put all the information in single table .
Redundancy is the root cause of number of problems like insertion problem , deletion
problem , update problem .
Redundancy --student(s_id ,name , branch_id , br_name ,H OD name , HOD mail)
There is redundancy in this table because branch information is replicated in each tuple .
Process of replacing a relational schema by a set of relational schemas to achieve a
particular normal form is called normalization.
S_id name Branch_id Br__name HOD
name
HOD mail
1 gg1 101 IT Gaurav gg@.com
2 Gg2 101 IT Gaurav gg@.com
3 Gg3 101 IT Gaurav gg@.com
4 gg4 101 IT Gaurav gg@.com

2. Due to replication of data in student relation , there is insertion , deletion & updation
problem. For removing all these problems , it is necessary that we have to put data for
each entity in separate table .
In this example student and branch are two separate entities .
So for removing redundancy we have to put student details and branch details in
different tables .
Divide the student relation in two separate relations as student and branch . In this
way we can remove redundancy problems .
In this way we can easily remove repetition problem , data lost problem and
inconsistency problem .
,S_id name Branch_id
1 gg1 101
2 Gg2 101
3 Gg3 101
4 Gg4 101
Branch_id Br_name HOD name HOD mail
101 IT gaurav gg@.com
Student (s_id,name,branch_id)
Branch(branch_id,br_name,HODname,HODmail)

3. There may be some problems due to bad relational schema , for
removing these problems we decompose the relation . but to
decide whether designed schema is good or whether it should
be decomposed into smaller relations we need some guidance
and normal form provides such guidance.
In short, normal forms provides guidance for designing good
relational schema .
The normal forms based on functional dependencies are first
normal form , second normal form , third normal form & boyce
codd normal form (bcnf).

4. Every relation in BCNF is restricted to be in 3 NF.
Every relation in 3 NF is restricted to be in 2 NF.
Every relation in 2 NF is restricted to be in 1 NF
4NF & 5NF are also used for better schema design.
4NF is known as PROJECT JOIN NORMAL FORM .
5 NF is known as DOMAIN KEY NORMAL FORM .
Generally while designing a relational schema we always try to achieve
highest normal form , which is possible by normalization.
Dependency
based

5. a relation in BCNF, is also
in 3NF
a relation in 3NF is also in
2NF
a relation in 2NF is also in
1NF

6. Process of replacing a relational schema by a set of relational
schemas to achieve a particular normal form is called
normalization.
The process of normalization is based on schema decomposition
and functional dependencies.

7. Unnormalized relation
A relation having multiple values in a column or attribute of a
row is called an unnormalized relation .
Roll_NO name course
101 gg1 C
OS
102 gg2 DBMS
LINUX

8. 1 Normal form
1 normal form allows only atomic values in the domain of any
attribute.
Eg- student(roll_no , name , course)
Roll_ no name Course
101 Gg1 C
101 Gg1 Os
102 Gg2 Linux
102 gg2 DBMS
Relation is in 1 NF.

9. 2 NORMAL FORM
Second normal form is based on the concept of full functional
dependency . In second normal form we have to remove partial
dependency . A functional dependency x->y is full functional
dependency if no proper subset of x like z is there such that
holds . Such functional dependencies are left reduced as there is
no extraneous attribute in the left hand side of dependency .

10. Full dependency-
When non prime attribute completely depends on candidate key then it is known as
full dependency.
Partial dependency-
When non prime attribute does not depend completely on candidate key , it depends
only on a part of candidate key is known as partial dependency.
Extraneous attribute-
An attribute of an functional dependency is extraneous if we can remove it without
changing the closure of the set of fd’s .
Example-
If set of functional dependency {a->bc , a->c} ,in functional dependency a->bc , c is
extraneous attribute because after removing c from functional dependencies new set
of functional dependencies will be {a->b , a->c} and we can observe f+ = f’+ .

11. Candidate key
Candidate keys are the subset of super keys. A super key with no redundant
attribute is known as Candidate Key.
Every table must have at least one candidate key but at the same time can
have more than one candidate key .
We are concerned about those super keys for which no proper subset is a
super key. Such minimal super keys are called candidate keys.
How to get candidate keys from given functional dependencies –
1. Draw rough diagram for every functional dependency .
2. Check incoming and outgoing edges on each attribute.
3. Select all the attributes which does not have any incoming edge.
4. Combine all attributes and calculate closure .
5. If these attributes are able to calculate complete set of attributes then
it is a candidate key .
6. It is possible that there may be more than one candidate key .
7. All the attributes which take part in any of candidate key are prime
attributes.

12. Example of candidate key
Given R(ABCDE)
Functional dependencies { BC->ADE
D->B}
Find candidate keys for given functional dependencies
Solution-
a b c d e
There is no incoming edge on c so c is essentially a part of candidate key .
But c is not able to calculate complete set of attributes so try to find set of candidate kays
Bc={bcade}
cd={cdbea}
So in this case bc & cd are candidate keys.
Bcd are prime attributes and ae is non prime attributes.
In this way we can find all possible candidate keys .

13. Eg- R(a,b,c,d) and there are two functional dependencies{ab->d,
b->c} check it is in second normal form or not? If relation is not in 2 NF
convert in 2NF.
Solution – 1. find candidate key for R(a,b,c,d) fd’s {Ab->c,B->c}
a b c d
There is no incoming edge
on a , b so both are parts
of candidate keys.
Closure of (ab)+ = {abdc}
By using ab we can find all other
attributes so ab is a candidate key.

14. If ab is candidate key then {a,b} are prime attributes and {c, d} are non
prime attributes.
Values of non prime attributes can be find by using prime attributes.
In this case there is only candidate key so it is primary key also.
To find value of d we have to know values of a & b both so there is no
problem because d is completely dependent on candidate key.
But in b->c , c is a non prime attribute and it is not completely
dependent on candidate key . so there is partial dependency
From definition of 2 NF , table must be independent of partial
dependency.
But b->c has partial dependency .
So R is not in 2 NF.

15. How to convert schema in 2 NF
Decompose table in two tables R1,R2
In first table put the prime attributes and non prime attributes which
are entirely dependent on candidate key.
R1(a,b,d)
In second table put the part of candidate key which can independently
find the value of non prime attribute & non prime attribute which is
dependent on that .
R2(b,c)
(in R2 (b,c) b is a part of candidate key which independently can
compute value of c . Now partial dependency removed as b become
primary key in R2) .
Now r(a,b,c,d) is converted in 2 NF.

16. 3 NF
Third normal form is based on the concept of transitive functional
dependency . If in a relation R x->y and y-> z holds then x->z also
holds and z is called to be transitively dependent on x .
A relation schema R is in 3 NF if it is In 2 NF and if no non prime
attribute of R is transitively dependent on the candidate key of the
relation .
In 3 NF for all non trivial functional dependencies on R x->a either x
is candidate key of R or a is a prime attribute . Hence third normal
form eliminates dependency of a non prime attribute to another
non prime attribute.

17. Example –
Given R(a , b , c , d)
Functional dependencies {ab->c
c->d}
Check whether it is in 3 Normal form or not .
Solution –
Calculate candidate key
ab is considered as a candidate key from given dependencies .
Because we can get all other attributes of relation from ab
(ab)+ = {abcd}
So a,b are prime attributes.
c,d are non prime attributes .
As we know that if we wants to be in 3 NF then relation have to be In 2 NF .
Check from given dependencies that either table is in 2 NF or not .
From ab->c we can conclude that a non prime attribute c is fully dependent on
candidate key , there is no partial dependency .
C->d a non prime attribute depends on another non prime attribute which is also
allowed in 2 NF so given relation is in 2 NF.

18. But there is a problem that a non prime attribute is finding
another non prime attribute which is a case of transitive
dependency .
Transitive dependency is not allowed in 3 NF .
In short , a table is in 3 NF if there is no partial and transitive
dependency .
So this table is not in 3 Normal form.

19. How to convert relation In 3 NF
Decompose the given relation R in R1 and R2.
In first relation put candidate key and fully dependent attributes .
As R1(a , b , c). ab is candidate key and c is fully dependent on
candidate key .
In second relation put R2(c , d) now c become a key and prime
attribute so it can not be null and our issue is solved . In every
situation c is able to find d .

20. BCNF
BCMF is more strong than 3 NF and for most of the database
applications , ultimate goal of schema refinement is BCNF .
A relation R is in BCNF if for every non trivial functional
dependency in the closure of the set of functional dependencies
F on R , i.e. of form x->a , x is super key of R .
A relation schema is in BCNF if it in 3 NF and determinant of
dependency is super key .
Effectively , 3 NF allows non trivial fd’s whose determinant is not
a super key if the right hand side of dependency is is part of
candidate key , but in BCNF , an fd is allowed only if the
determinant is a super key of relation .

21. Example – consider given relation R(a , b , c)
functional dependency{ab->c
c->b}
check is it in BCNF or not ?
Solution-
Candidate key of Relation R – ab , ac
(ab)+ = {abc}
(ac)+ ={abc}
First check for 2 NF-
The relation is in 2NF because
In 1 dependency there is no partial dependency .
In 2 dependency c is a part of candidate key but b is prime
attribute. So there is not partial dependency .so relation is in 2
NF.

22. For 3 NF check for transitive dependency
As we know , transitive dependency is for non prime to non
prime .
In both dependencies there is only prime attributes so there is
no transitive dependency
Table is also in 3 NF.
Now for BCNF given dependency determinant should be super
key
From 1 dependency ab is super key but in second dependency c
is not a super key so this is not eligible for BCNF.

23. Note –
1. x->y
X is super key then relation is in BCNF .
2. x->y
If y is prime or x is candidate key then always relation will be in 3 NF
3. x->y
If y is fully dependent on x then always relation will be in 2NF .

24. Objective -R(ABCDEFGH)
Functional dependency F
{AB->C
A->DE
B->F
F->GH }
Check normal form for given schema .
Solution –
Candidate key for relation - AB
1 check for BCNF
In 1 dependency AB is a super key or candidate key so it satisfies the condition but in 2 dependency A is
not a key so we can conclude that given relation is not in BCNF.
2 check for 3 NF
In 1 dependency AB is a key so it satisfies the condition but in second dependency neither A is a super or
candidate key nor DE is prime attribute so we can conclude that given relation is not in 3 NF .
3 check for 2 NF
In 1 dependency C is a non prime attribute which is fully dependent on candidate key so it satisfies the
condition but in 2 dependency DE are partially dependent on A . So we can conclude that given relation is
not in 2 NF .
Now we can conclude that relation is in 1 NORMAL FORM .

25. Given R(ABCDEFGHIJ)
F={AB->C
A->DE
B->F
D->IJ
F->GH}
Convert this form in 2 NF , 3 NF & BCNF.
Solution- for 2 NORMAL FORM
Find candidate key for given relation R
AB is candidate key because (AB)+ ={ABCDEFGHIJ}
Decompose R in R1 , R2 , R3 for converting in 2 NF
R1(ABC)
R2(ADEIJ)
R3(BFGH)
Now there is no partial dependency and schema is in 2 NORMAL FORM

26. For 3 NORMAL FORM
In converted schema there is no partial dependency but transitive
dependency occurs .
for removing transitive dependency decompose R2 and R3 further.
R2 is decomposed in R4 &R5.
R3 is decomposed in R6 & R7.
now R4 (ADE)
R5(DIJ)
R6(BF)
R7(FGH)
Complete relation
R1(ABC)
R4(ADE)
R5(DIJ)
R6(BF)
R7(FGH)
RELATION IS CONVERTED IN 3NF.