Normalization in DBMS

1. Normalization in DBMS
Dr.M.Pyingkodi
Dept of MCA
Kongu Engineering College
Erode,Tamilnadu,India
pyingkodikongu@gmail.com

2. Relational Database Design
• It requires that we find a “good” collection of relation
schemas.
• Pit-falls in Relational Database design:
• A bad design may lead to
• a. Repetition of information – that leads to
• insertion, deletion, updation problems.
• b. Inability to represent certain Information.
2

3. Relational Database Design
• Design Goals:
• a. Avoid redundant data.
• b. Ensure that relationships among attributes are
represented.
• c. Facilitate the checking of updates for violation of
db integrity constraints.
3

4. Relational Database Design
• Example: Consider the relation schema:
• Lending-schema=(branch_name,branch_city,assets,customer_name,
loan_no,amount)
Here branch Adayar details are represented 2 times . This leads to a redudancy
problem.
Branch_
Name
Branch
_city
assets Customer
_name
Loan_no amount
Adayar
Bbbb
Cccc
Adayar
Chennai
XXXX
YYYY
Chennai
90,00,000
20,00,000
30,00,000
90,00,000
Anu
aaa
bbb
Barathi
L-01
L-02
L-03
L-04
1000
2000
3000
3500
4

5. Relational Database Design
• Redundancy:
• Data for branch_name,branch_city, assets are represented
for each loan that a branch makes
a. wastage space
b. Complicates updating,introducing inconsistency of
assets value.
Decomposition:
* Decompose the relation-schema, lending schema into,
5

6. Relational Database Design
• Branch-schema=(branch_name,branch_city,assets)
• Loan-schema =
(customer_name,loan_no,branch_name,amount)
• All attributes of original schema R must appear in
decomposition(R1,R2)
• R= R1 U R2
• Lossless join decomposition.
• All possible relations r on schema R.
• r = (r) (r)
• R1 R2
6
∏ ∏

7. Functional Dependencies
• It requires that the value for a certain set of attributes
determines uniquely the value for another set of attributes.
• In a given relation R, X and Y are attributes. Attributes Y is
functionally dependent on attribute X if each value of X
determines exactly one value of Y, which is represented as
X Y
i.e… “ X determines Y” or “Y is functionally dependent on X”
E.G…
Marks Grade
7

8. Functional Dependencies
• Types:
• A. Full Dependencies:
• In relation R, X and Y are attributes. X is functionally determines Y.
Subset of X should not be functionally determine Y.
• In the above eg. Marks is fully functionally dependent on student_no and
course_no together and not on subset of {student_no,course_no}
8
Marks
Student_No
Course_no

9. Functional Dependencies
• B. Partial Dependencies:
• Attribute Y is partial dependent on the
attribute X only if it is dependent on a subset
of attribute X.
• For eg.. Course_name, Instructor_name
are partially dependent on composite
attributes { student no, course_no} because
course_no alone defines course_name,
Instructor_name.
9

10. Functional Dependencies
• C. Transitive Dependencies:
X,Y and Z are 3 attributes in the relation R
X Y
Y Z
X Z
For e.g.. Grade depends on marks and in turn make depends on
{student_no course_no}, hence Grade depends fully
transitively on {student_no course_no}
10

11. NORMAL FORMS
• Normalisation:
Db designed based on E-R model may have some
amount of inconsistency (variation), uncertainty (in security)
and redundancy (duplication).
To eliminate these drawbacks some refinement has to
be done on the db.
Refinement process is called normalization.
Normalisation is defined as a step by step process of
decomposing a complex relation into a simple and stable
relations.
11

12. Purpose of Normalisation
• Minimize redundancy in data
• Remove insert, delete and update anomaly
(irregularity) during db activities.
• Reduce the need to recognize the data when it
is modified or enhanced.
• Because of duplicate data elimination, we will
be able to reduce the overall size of the db.
12

13. Normal Forms
• The different stages of normalization is called as normal
forms. They are,
• * 1NF
• * 2NF
• * 3NF
• * BCNF
13

14. First Normal Form(1NF)
• A relation schema R is in 1NF if
* all the attributes of the relation R are atomic in nature.
E.G… DEPT
Suppose we extend it by including DLOCATIONS attribute as
shown above. We assume that each dept may have a no. of
Locations.
This is not 1NF bcoz DLOCATIONS is not an atomic attribute.
DNAME DNO DHEAD DLOCATIONS
14

15. First Normal Form(1NF)
DNAME DNO DHEAD DLOCATIONS
Research 3 John (Mianus,Rye,Stratford)
Administrator 2 prince Mianus
Headquarter 1 Peter Rye
15
Dept:

16. First Normal Form(1NF)
• There are 2 main techniques to achieve 1NF,
1. Remove the attribute DLOCATIONS and place it in separate relation
DEPT_LOCATIONS along with a primary key DNO. The primary key of the
original DEPT is the combination {DNO,DLOCATIONS}
DEPT-LOCATIONS
DNO DLOCATIONS
1
2
3
3
3
Rye
Mianus
Rye
Mianus
stratford
16

17. First Normal Form(1NF)
• 2. Expand the key so that there will be a separate tuple in the orginal DEPT
relation for each location of a DEPT as shown below,
• So the first technique is superior.
DNAME DNO DHEAD DLOCATIONS
Research
Research
Research
Administration
HQ
3
3
3
2
1
John
John
John
Princy
Peter
Mianus
Rye
Statford
Mianus
Rye
17

18. Second Normal Form(2NF)
• A relation R is in 2NF if and only if,
• It is in the 1NF and
• No partial dependency exists between non-key
attributes and key attributes.
• The test for 2NF involves testing for functional
dependencies whose left hand side attributes are
part of primary key. If the primary key contains a
single attribute, the test need not be applied at all.
• A relation schema R is in 2NF if every non-prime attribute
A in R is fully functionally dependent on the primary key of
R.
18

19. Second Normal Form(2NF)
• E.G.. Consider the EMP_PROJ relation, it is in 1NF but not in 2NF,
The non-prime attribute ENAME violates 2NF because of FD2, as do the non-prime
attribute PNAME and PLOCATION because of FD2 and FD3 make ENAME, PNAME
and PLOCATION partially dependent on the primary key {SSN,PNO}, thus violating
2NF test.
19
PNAME
SSN PNO ENAME PLOCATION
HOURS
FD1
FD2
FD3
EMP-PROJ EMP-PROJ Relation in 1NF

20. Second Normal Form(2NF)
• The Functional dependencies FD1,FD2 and FD3 leads
to the decomposition of EMP_PROJ into the 3 relation
schemas EP1,EP2 and EP3, each of which is in 2NF.
SSN PNO HOURS SSN ENAME
20
EP2
EP1
PNO PNAME PLOCATION
EP3
FD1 FD2 FD3

21. Third Normal Form (3NF)
• A relation R is said to be in the 3NF if and only if
* It is in 2 NF and
* No transitive dependency exists between non-key attributes and key attributes.
E.G… Consider the relation schema EMP_DEPT
The dependency SSN DNGRSSN is transitive through DNO in EMP-DEPT,
because both the dependencies SSN DNO and DNO DNGRSSN hold
and DNO a key itself nor a subset of the key of EMP-DEPT is neither.
A relation schema R is n 3NF, if it satisfies 2NF and no non-prime attribute
of R is transitively dependent on the primary key.
ENAME SSN BDATE ADDRESS DNO DNAME DNGRSSN
21
EMP_DEPT Relation Schema in 2NF

22. Third Normal Form (3NF)
• We can normalize schemas ED1 and ED2,
• 3NF relation schemas ED1 and ED2
• Here ED1 and ED2 represet independent entity facts about employees and
departments.
ENAME SSN BDATE ADDRESS DNO
DNO DNAME DNGRSSN
22
ED1
ED2

23. Boyce-Codd Normal Form (BCNF)
• A relation R is said to be in BCNF, if and only if all the
determinant are candidate keys.
• BCNF relation is a strong 3NF, but not every 3NF relation is
BCNF.
• A relation schema R is in BCNF with respect to a set F of
functional dependencies if for all functional dependencies in
F of the form
• Where R and R,
23

24. Boyce-Codd Normal Form (BCNF)
• at least one of the following holds
• 1. is trivial (i.e )
• 2. is a super key of R
24

25. First Normal Form
• Domain is atomic if its elements are considered to be
indivisible units
– Examples of non-atomic domains:
• Set of names, composite attributes
• Identification numbers like CS101 that can be broken up into parts
• A relational schema R is in first normal form if the domains of
all attributes of R are atomic
• Non-atomic values complicate storage and encourage
redundant (repeated) storage of data
– Example: Set of accounts stored with each customer, and set of
owners stored with each account
– We assume all relations are in first normal form (and revisit this in
Chapter 9)
25