Data normalization

OBJECTIVES
 To understand about the functional dependencies.
 To bring out solution of Trivial , non-trivial , full dependency and
transitive.
 To known about the Armstrong inferences rules.
 To understand about data normalization.

Functional Dependencies
1. It is important role play to design a good or bad database.
2. Basically functional dependencies is a type of constraints that is a generalization
in the notation of key.
3. Functional Dependency (FD) determines the relation of one attribute to another
attribute in a database management system (DBMS) system.
4. Functional dependency in DBMS, as the name suggests is a relationship
between attributes of a table dependent on each other. Introduced by E. F.
Codd, it helps in preventing data redundancy and gets to know about bad
designs.
5. It is represented by -> (arrow) sign. Ex- P -> Q.
6. It is a set of legal relation. Its depicts relationship of attributes.
7. For any relation r containing attributes P and Q and if for every valid instance of
P determines uniquely value of Q It is expressed as:
 P -> Q
 P determines Q
 Q dependent P or Q is determines by P

Let f: P -> Q Relation so that P -> compute the value of Q.
Fig1. Fig2.
 P & Q in set of attributes.
 This is the value which is store in P & Q. here we see that value is not duplicate in both row,
 In this fig1. we easily search any value of P. suppose if you want to search the value of a1 so you can easily
find the value of a1.
 In this fig2. we don’t say what is the actual value of a1. so that
F(P) - Q
a1  10
a1  20
b1  10
Here we see this example. It is possible to meet same value of dependent but not possible determines is same.
P Q
a1 10
b1 20
c1 30
d1 40
P Q
a1 10
a1 20
c1 30
d1 40

It is a relationship that exists when one attributes uniquely determines another attributes.
 If R is relation with all P & Q
Uniquely Determination P -> Q
Q is functional dependency on P
-> It is a set of constrains between 2 attributes in a relations.
Q is functional dependent on P
Identification key P -> Q
Eg: if every attribute Q of R dependent of P then attributes P is primary key.
In this table SSN -> FNAME
SSN -> LNAME
So it dependent of a particular table.
SSN Fname Lname
101 Ravi Kumar
102 Piyush Tiwari
103 Kartik Mishra
104 Harish Prasad

Fully Functional Dependency:
ABC - D
1. D is fully functional dependent on ABC
2. D cannot dependent on any subset of ABC
BC -> D
C -> D
A -> D
This is not possible because BC cannot determine D , C cannot determine D and A cannot
determine D.
In ABC -> D , only D is fully functional dependence of ABC.
Sid sname tid smarks
101 Ravi 201 34
102 Piyush 202 44
103 Kartik 203 55
104 Harish 204 33

Here in this table sid,tid  Identification Key
so that marks is fully dependent of sid & Pid. This is combination of two attributes full functionally
dependent.
Transitive Dependency:
Consider attributes PQ & R
When P -> Q & Q -> R
If full dependency one transitive also have the
FD : A -> C
C is transitive dependent on P through Q. Here we consider two tables Employee & Department.
Eno -> Dno P-> Q
P Q Q R
Same as Eno -> email P -> Q
Eno -> dno , dno -> dname , eno  dname so that P -> Q , Q -> R so that P -> R This is
transitive dependency.
Eno Email Dno Dname

Trivial function dependency :
Trivial dependency is a set of attributes which are called a trivial if the set of attributes are
included in that attributes.
So that P -> Q is a trivial if Q is subset of P.
Ex-: [sid , sname]  sid is a trivial dependency as sid is a subset of [sid,sname].
Non - Trivial function dependency : In this dependency which also known non-trivial occurs
when P -> Q holds true where Q is not subset of P. In attributes Q is not subset of P.
Sid -> sname or P -> Q and sname -> sdob Q -> R
Sid sname
101 Ravi
102 Piyush
103 Kartik
104 Harish
Sid sname sdob
101 Ravi 1
102 Piyush 2
103 Kartik 3
104 Harish 4

Armstrong Inferences Rules:
The term Armstrong axioms to the sound and complete set of inference rules or
axioms, introduced by William W. Armstrong, that is used to test the logical
implication of functional dependencies. If F is a set of functional dependencies
then the closure of F, denoted as F plus, is the set of all functional dependencies
logically implied by F. Armstrong’s Axioms are a set of rules, that when applied
repeatedly, generates a closure of functional dependencies.
 It is a basic rule.
 It are used to conclude functional dependencies on a relational database.
 The inference rule is a type of assertion. It can apply to a set of FD(functional
dependency) to derive other FD.
 By using of this , we can derive additional functional dependency from the
initial set.

1. Reflexive Rule
according to reflexive rule, if B is a subset of A, then A determines B.
If A ⊇ B then A → B eid - > eid
A = {eid,ename,eage}
B = {eid,ename}
2. Augmentation Rule
The augmentation is also called as a partial dependency. In augmentation, if A
determines B, then AC determines BC for any C.
If A → B then AC → BC
Example:
For R(ABC), if A → B then AC → BC

3. Transitive Rule
In the transitive rule, if A determines B and B determine C, then A must also determine
C.
If A → B and B → C then A → C
4. Union Rule
Union rule says, if A determines B and A determines C, then A must also determine B
and C.
If A → B and A → C then A → BC
1. A → B (given)
2. A → C (given)
3. A → AB (using 2 rules on 1 by augmentation with A. Where AA = A)
4. AB → BC (using 2 rules on 2 by augmentation with B)
5. A → BC (using 3 rules on 3 and 4)

5. Decomposition Rule
Decomposition rule is also known as project rule. It is the reverse of union rule.
This Rule says, if A determines B and C, then A determines B and A determines C
separately.
If A → BC then A → B and A → C
1. A → BC (given)
2. BC → B (using rule 1)
3. A → B (using rule 3 on 1 and 2)
6. Pseudo transitive Rule
If A holds B and BC holds D, then AC holds D.
If {A → B} and {BC → D}, then {AC → D}
1. A → B (given)
2. DB → C (given)
3. DA → DB (By using 2 rule on 1 by augmenting with D)
4. DA → C (by using 3 rule on 3 and 2)

Example:
Consider relation E = (P, Q, R, S, T, U) having set of Functional Dependencies (FD).
P -> Q P -> R
QR -> S Q -> T
QR -> U PR -> U
Calculate some members of Axioms are as follows,
1. P -> T
2. PR -> S
3. QR -> SU
4. PR -> SU
Solution:
1. P -> T
In the above FD set, P -> Q and Q -> T
So, Using Transitive Rule: If {P -> Q} and {Q -> T}, then {P -> T}
? If P -> Q and Q -> T, then P -> T.
P -> T

2. PR -> S
In the above FD set, P -> Q
As, QR -> S
So, Using Pseudo Transitivity Rule: If{A -> B} and {BC -> D}, then {AC -> D}
If P -> Q and QR -> S, then PR -> S.
PR -> S
3. QR -> SU
In above FD set, QR -> S and QR -> U
So, Using Union Rule:
If{A -> B} and {A -> C}, then {A -> BC}
If QR -> S and QR -> U, then QR -> SU.
QR -> SU
4. PR -> SU
So, Using Pseudo Transitivity Rule:
If{A -> B} and {BC -> D}, then {AC -> D}
If PR -> S and PR -> U, then PR -> SU.
PR -> SU

Data Normalization
Database Normalization is a technique of organizing the data in the database.
Normalization is a systematic approach of decomposing tables to eliminate data
redundancy(repetition) and undesirable characteristics like Insertion, Update and Deletion
Anomalies. It is a multi-step process that puts data into tabular form, removing duplicated
data from the relation tables.
 Normalization is used for mainly two purposes,
 Eliminating redundant(useless) data.
 Ensuring data dependencies make sense i.e. data is logically stored.
Problems Without Normalization
If a table is not properly normalized and have data redundancy then it will not only eat up
extra memory space but will also make it difficult to handle and update the database,
without facing data loss. Insertion, Updating and Deletion Anomalies are very frequent if
database is not normalized. To understand these anomalies let us take an example of
a Student table.

Anomalies in DBMS
There are three types of anomalies that occur when the database is not normalized.
These are – Insertion, update and deletion anomaly.
Example: Suppose a Software company stores the employee details in a table
named emp that has five attributes: eid for storing employee id ,ename for storing
employee name, eadd for storing employee address , edept for storing the
department information and emno for storing employee mobile no in which the
employee works. Lets see this table this is not normalized.
eid ename eadd edept emno
101 Ravi Kanpur ed101 777799
102 Karim Kannauj ed105 555555
103 Raju Hamirpur ed110 434434

Update anomaly: In the above table we have two rows for employee
Ravi as he belongs to two departments of the software company. If we
want to update the address of Ravi then we have to update the same
in two rows or the data will become inconsistent.
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 edept field
doesn’t allow nulls.
Delete anomaly: Suppose, if at a point of time the company closes the
department ed105 then deleting the rows that are having edept as
ed105 would also delete the information of employee Karim since he is
assigned only to this department.
There are different types of Normalization. In this slide we explain only
1NF , 2NF and 3NF.

1 Normalization Form (1NF): The first normal form expects you to follow a
few simple rules while designing your database, and they are:
Rule 1: Single Valued Attributes
Rule 2: Attribute Domain should not change
Rule 3: Unique name for Attributes/Columns
Rule 4: Order doesn't matters
777799
434434
104 Piyush Lucknow ed111 343434

104 Piyush Lucknow ed111 343434
Now This table employee atomic.

2 Normalization Form (2NF):
A table is said to be in 2NF if both the following conditions hold:
 Table is in 1NF (First normal form)
 No non-prime attribute is dependent on the proper subset of any candidate key of table. There
should be no Partial Dependency.
An attribute that is not part of any candidate key is known as non-prime attribute.
Example: Suppose a college 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.
tid tsub tage
101 C 30
101 C++ 30
102 Python 32
103 C++ 35
103 DBMS 35

Candidate Keys: {tid, tsub}
Non prime attribute: tage
The table is in 1 NF because each attribute has atomic values. However, it is not in 2NF
because non prime attribute tage is dependent on tid 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”. To make the table
complies with 2NF we can break it in two tables like this, Now the tables comply with Second
normal form (2NF).
tid tage
101 30
102 32
103 35
tid tsub
101 C
101 C++
102 Python
103 C++
103 DBMS

3 Normalization Form (3NF):
A table design is said to be in 3NF if both the following conditions hold:
 Table must be in 2NF
 Transitive functional dependency of non-prime attribute on any super key should be removed.
An attribute that is not part of any candidate key is known as non-prime attribute. In other words 3NF
can be explained like this: A table is in 3NF if it is in 2NF and for each functional dependency X-> Y at
least one of the following conditions hold:
 X is a super key of table
 Y is a prime attribute of table.
An attribute that is a part of one of the candidate keys is known as prime attribute.
Example: Suppose a company wants to store the complete address of each customer, they create a
table named cust that looks like this:

cid cname cpincode cstate ccity cdistrict
101 Ravi 110010 MP Satna abc
102 Rahul 110019 CG Raipur ccd
103 Rakesh 110017 CG Bilaspur ppd
104 Lalit 110013 UP Kanpur lll
105 Piyush 110014 AP Tirupati ooo
Super keys: {cid}, {cid, cname}, {cid,cname,cpincode}…so on
Candidate Keys: {cid}
Non-prime attributes: all attributes except cid are non-prime as they are not part of any candidate keys.
Here, cstate, ccity & cdistrict dependent on cpincode And, cpincode is dependent on cid that makes
non-prime attributes (cstate, ccity & cdistrict) transitively dependent on super key (cid). This violates the
rule of 3NF.
To make this table complies with 3NF we have to break the table into two tables to remove the transitive
dependency:

cid cname cpincode
101 Ravi 110010
102 Rahul 110019
103 Rakesh 110017
104 Lalit 110013
105 Piyush 110014
cpincode cstate ccity cdistrict
110010 MP Satna abc
110019 CG Raipur ccd
110017 CG Bilaspur ppd
110013 UP Kanpur lll
110014 AP Tirupati ooo

Data normalization

Recommended

More Related Content

What's hot (20)

Similar to Data normalization (20)

More from Bosco Technical Training Society, Don Bosco Technical School (Aff. GGSIP University, New Delhi) (20)

Recently uploaded (20)

Data normalization