1. PMIT-6102 Advanced Database Systems
By-
Jesmin Akhter
Assistant Professor, IIT, Jahangirnagar University

2. Lecture 02 Relational Database Design Normalization

3. Outline
Overview of Relational DBMS
Normalization

4. Normalization
The aim of normalization is to eliminate various anomalies (or undesirable aspects) of a relation in order to obtain “better” relations.
The following four problems might exist in a relation scheme:
Repetition anomaly
Update anomaly
Insertion anomaly
Deletion anomaly

5. Repetition Anomaly
The NAME,TITLE, SAL attribute values are repeated for each project that the employee is involved in.
Waste of space
Complicates updates
Contrary to the spirit of databases
ENO
EMP
ENAME
TITLE
SAL
J. Doe
Elect. Eng.
40000
M. Smith
34000
Analyst
A. Lee
Mech. Eng.
27000
J. Miller
Programmer
24000
B. Casey
Syst. Anal.
L. Chu
R. Davis E1 E2 E3 E4 E5 E6 E7 E8
J. Jones 24
PNO
RESP
DUR P1
Manager 12 P2 6 P3
Consultant 10 P4
Engineer 48 18 36 40

6. Update Anomaly
If any attribute of project (say SAL of an employee) is updated, multiple tuples have to be updated to reflect the change.
ENO
EMP
ENAME
TITLE
SAL
J. Doe
Elect. Eng.
40000
M. Smith
34000
Analyst
A. Lee
Mech. Eng.
27000
J. Miller
Programmer
24000
B. Casey
Syst. Anal.
L. Chu
R. Davis E1 E2 E3 E4 E5 E6 E7 E8
J. Jones 24
PNO
RESP
DUR P1
Manager 12 P2 6 P3
Consultant 10 P4
Engineer 48 18 36 40

7. Insertion Anomaly
It may not be possible to store information about a new project until an employee is assigned to it.
ENO
EMP
ENAME
TITLE
SAL
J. Doe
Elect. Eng.
40000
M. Smith
34000
Analyst
A. Lee
Mech. Eng.
27000
J. Miller
Programmer
24000
B. Casey
Syst. Anal.
L. Chu
R. Davis E1 E2 E3 E4 E5 E6 E7 E8
J. Jones 24
PNO
RESP
DUR P1
Manager 12 P2 6 P3
Consultant 10 P4
Engineer 48 18 36 40

8. Deletion Anomaly
If an engineer, who is the only employee on a project, leaves the company, his personal information cannot be deleted, or the information about that project is lost.
May have to delete many tuples.
ENO
EMP
ENAME
TITLE
SAL
J. Doe
Elect. Eng.
40000
M. Smith
34000
Analyst
A. Lee
Mech. Eng.
27000
J. Miller
Programmer
24000
B. Casey
Syst. Anal.
L. Chu
R. Davis E1 E2 E3 E4 E5 E6 E7 E8
J. Jones 24
PNO
RESP
DUR P1
Manager 12 P2 6 P3
Consultant 10 P4
Engineer 48 18 36 40

9. What to do?
Take each relation individually and “improve” it in terms of the desired characteristics
Normal forms
Atomic values (1NF)
Can be defined according to keys and dependencies.
Functional Dependencies ( 2NF, 3NF, BCNF)
Multivalued dependencies (4NF)
Projection-join dependencies (5NF)
Normalization
Normalization is a process of concept separation which applies a top-down methodology for producing a schema by subsequent refinements and decompositions.
Do not combine unrelated sets of facts in one table; each relation should contain an independent set of facts.
Universal relation assumption

10. Normalization Issues
How do we decompose a schema into a desirable normal form?
What criteria should the decomposed schemas follow in order to preserve the semantics of the original schema?
Reconstructability: recover the original relation  no spurious joins
Lossless decomposition: no information loss
Dependency preservation: the constraints (i.e., dependencies) that hold on the original relation should be enforceable by means of the constraints (i.e., dependencies) defined on the decomposed relations.

11. A Lossy Decomposition

12. Example of Lossless-Join Decomposition
Decomposition of R = (A, B, C) R1 = (A, B) R2 = (B, C) A B C A B B C   1 2 A B   1 2 1 2 A B r
A,B(r)
B,C(r) A B C
A (r) B (r)   1 2 A B

13. Stages of Normalization
Unnormalized
(UDF)
First normal form
(1NF)
Remove repeating groups
Second normal form
(2NF)
Remove partial dependencies
Third normal form
(3NF)
Remove transitive dependencies
Boyce-Codd normal
form (BCNF)
Remove remaining functional
dependency anomalies
Fourth normal form
(4NF)
Remove multivalued dependencies
Fifth normal form
(5NF)
Remove remaining anomalies

14. Repeating Groups
A repeating group is an attribute (or set of attributes) that can have more than one value for a primary key value.
Example We have the following relation that contains staff and department details and a list of telephone contact numbers for each member of staff.
staffNo
job
dept
dname
city
contact Number
SL10
Salesman 10
Sales
Stratford
, ,
SA51
Manager 20
Accounts
Barking
DS40
Clerk
Null
OS45 30
Operations
Repeating Groups are not allowed in a relational design, since all attributes have to be ‘atomic’ - i.e., there can only be one value per cell in a table!

15. Repeating Groups
Multivalued Attributes (or repeating groups): non-key attributes or groups of non-key attributes the values of which are not uniquely identified by (directly or indirectly) (not functionally dependent on) the value of the Primary Key (or its part).
STUDENT
Stud_ID
Name
Course_ID
Units
101
Lennon
MSI 250, MSI 415
3.00
125
Johnson
MSI 331

16. Functional Dependency
Formal Definition: Attribute B is functionally dependant upon attribute A (or a collection of attributes) if a value of A determines a single value of attribute B at any one time.
Formal Notation: A  B This should be read as ‘A determines B’ or ‘B is functionally dependant on A’. A is called the determinant and B is called the object of the determinant.
staffNo job dept dname
SL Salesman Sales
SA Manager Accounts
DS Clerk Accounts
OS Clerk Operations
Example:
staffNo  job
staffNo  dept
staffNo  dname
dept  dname
Functional Dependencies

17. Functional Dependency
Compound Determinants: If more than one attribute is necessary to determine another attribute in an entity, then such a determinant is termed a composite determinant.
Full Functional Dependency: Only of relevance with composite determinants. This is the situation when it is necessary to use all the attributes of the composite determinant to identify its object uniquely.
order# line# qty price A A A A
Example:
(Order#, line#)  qty
(Order#, line#)  price
Full Functional Dependencies

18. Functional Dependency
Partial Functional Dependency: This is the situation that exists if it is necessary to only use a subset of the attributes of the composite determinant to identify its object uniquely.
student#
unit#
room
grade
A01
TH224 2 14
A02
JS075 3 16
(student#, unit#)  grade
Full Functional Dependencies
unit#  room
Partial Functional Dependencies
Repetition of data!

19. Functional Dependency
Partial Dependency – when an non-key attribute is determined by a part, but not the whole, of a COMPOSITE primary key.
Partial Dependency

20. Transitive Dependency
Definition: A transitive dependency exists when there is an intermediate functional dependency.
Formal Notation: If A  B and B  C, then it can be stated that the following transitive dependency exists: A  B  C
Example:
staffNo  dept
dept  dname
staffNo  dept  dname
Transitive Dependencies
Repetition of data!
staffNo
job
dept
dname
SL10
Salesman 10
Sales
SA51
Manager 20
Accounts
DS40
Clerk
OS45 30
Operations

21. Transitive Dependency
Transitive Dependency – when a non-key attribute determines another non-key attribute.
Transitive Dependency

22. Normal Forms: Review
Unnormalized – There are multivalued attributes or repeating groups
1 NF – No multivalued attributes or repeating groups.
2 NF – 1 NF plus no partial dependencies
3 NF – 2 NF plus no transitive dependencies

23. Example 1: Determine NF ISBN  Title ISBN  Publisher
All attributes are directly or indirectly determined by the primary key; therefore, the relation is at least in 1 NF
ISBN  Title
ISBN  Publisher
Publisher  Address

24. Example 1: Determine NF ISBN  Title ISBN  Publisher
The relation is at least in 1NF. There is no COMPOSITE primary key, therefore there can’t be partial dependencies. Therefore, the relation is at least in 2NF
ISBN  Title
ISBN  Publisher
Publisher  Address

25. Example 1: Determine NF ISBN  Title ISBN  Publisher
Publisher is a non-key attribute, and it determines Address, another non-key attribute. Therefore, there is a transitive dependency, which means that the relation is NOT in 3 NF.
ISBN  Title
ISBN  Publisher
Publisher  Address

26. Example 1: Determine NF ISBN  Title ISBN  Publisher
We know that the relation is at least in 2NF, and it is not in 3 NF. Therefore, we conclude that the relation is in 2NF.
ISBN  Title
ISBN  Publisher
Publisher  Address

27. Example 1: Determine NF ISBN  Title ISBN  Publisher
In your solution you will write the following justification:
No M/V attributes, therefore at least 1NF
No partial dependencies, therefore at least 2NF
There is a transitive dependency (Publisher  Address), therefore, not 3NF
Conclusion: The relation is in 2NF
ISBN  Title
ISBN  Publisher
Publisher  Address

28. Example 2: Determine NF Product_ID  Description
All attributes are directly or indirectly determined by the primary key; therefore, the relation is at least in 1 NF

29. The relation is at least in 1NF.
Example 2: Determine NF
Product_ID  Description
The relation is at least in 1NF.
There is a COMPOSITE Primary Key (PK) (Order_No, Product_ID), therefore there can be partial dependencies. Product_ID, which is a part of PK, determines Description; hence, there is a partial dependency. Therefore, the relation is not 2NF. No sense to check for transitive dependencies!

30. Example 2: Determine NF Product_ID  Description
We know that the relation is at least in 1NF, and it is not in 2 NF. Therefore, we conclude that the relation is in 1 NF.

31. Example 2: Determine NF Product_ID  Description
In your solution you will write the following justification:
1) No M/V attributes, therefore at least 1NF
2) There is a partial dependency (Product_ID  Description), therefore not in 2NF
Conclusion: The relation is in 1NF

32. Example 3: Determine NF Part_ID  Description Part_ID  Price
Comp_ID and No are not determined by the primary key; therefore, the relation is NOT in 1 NF. No sense in looking at partial or transitive dependencies.
Part_ID  Description
Part_ID  Price
Part_ID, Comp_ID  No
Part_ID
Descr
Price
Comp_ID No

33. Example 3: Determine NF Part_ID  Description Part_ID  Price
In your solution you will write the following justification:
There are M/V attributes; therefore, not 1NF
Conclusion: The relation is not normalized.
Part_ID  Description
Part_ID  Price
Part_ID, Comp_ID  No

34. Bringing a Relation to 1NF

35. Bringing a Relation to 1NF
Option 1: Make a determinant of the repeating group (or the multivalued attribute) a part of the primary key.
Composite Primary Key

36. Bringing a Relation to 1NF
Option 2: Remove the entire repeating group from the relation. Create another relation which would contain all the attributes of the repeating group, plus the primary key from the first relation. In this new relation, the primary key from the original relation and the determinant of the repeating group will comprise a primary key.

37. Bringing a Relation to 1NF

38. Bringing a Relation to 2NF
Composite Primary Key

39. Bringing a Relation to 2NF
Goal: Remove Partial Dependencies
Partial Dependencies
Composite Primary Key

40. Bringing a Relation to 2NF
Remove attributes that are dependent from the part but not the whole of the primary key from the original relation. For each partial dependency, create a new relation, with the corresponding part of the primary key from the original as the primary key.

41. Bringing a Relation to 2NF

42. Bringing a Relation to 3NF
Goal: Get rid of transitive dependencies.
Transitive Dependency

43. Bringing a Relation to 3NF
Remove the attributes, which are dependent on a non-key attribute, from the original relation. For each transitive dependency, create a new relation with the non-key attribute which is a determinant in the transitive dependency as a primary key, and the dependent non-key attribute as a dependent.

44. Bringing a Relation to 3NF

45. Unnormalised Normal Form (UNF)
ORDER (order-no, order-date, cust-no, cust-name, cust-add,
(prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total

46. First Normal Form (1NF)
Definition: A relation is in 1NF if, and only if, all its underlying attributes contain atomic values only.
Remove repeating groups into a new relation
A repeating group is shown by a pair of brackets within the relational schema.
ORDER (order-no, order-date, cust-no, cust-name, cust-add,
(prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total
Steps from UNF to 1NF:
Remove the outermost repeating group (and any nested repeated groups it may contain) and create a new relation to contain it.
Add to this relation a copy of the PK of the relation immediately enclosing it.
Name the new entity (appending the number 1 to indicate 1NF)
Determine the PK of the new entity
Repeat steps until no more repeating groups.

47. Example - UNF to 1NF
ORDER (order-no, order-date, cust-no, cust-name, cust-add,
(prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total
1. Remove the outermost repeating group (and any nested repeated groups it may contain) and create a new relation to contain it. (rename original to indicate 1NF)
ORDER-1 (order-no, order-date, cust-no, cust-name, cust-add, order-total
(prod-no, prod-desc, unit-price, ord-qty, line-total)
2. Add to this relation a copy of the PK of the relation immediately enclosing it.
ORDER-1 (order-no, order-date, cust-no, cust-name, cust-add, order-total
(order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)
3. Name the new entity (appending the number 1 to indicate 1NF)
ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)
4. Determine the PK of the new entity
ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)

48. Second Normal Form (2NF)
Definition: A relation is in 2NF if, and only if, it is in 1NF and every non-key attribute is fully dependent on the primary key.
Remove partial functional dependencies into a new relation
Steps from 1NF to 2NF:
Remove the offending attributes that are only partially functionally dependent on the composite key, and place them in a new relation.
Add to this relation a copy of the attribute(s) which are the determinants of these offending attributes. These will automatically become the primary key of this new relation.
Name the new entity (appending the number 2 to indicate 2NF)
Rename the original entity (ending with a 2 to indicate 2NF)

49. Example - 1NF to 2NF
ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)
1. Remove the offending attributes that are only partially functionally dependent on the composite key, and place them in a new relation.
ORDER-LINE-1 (order-no, prod-no, ord-qty, line-total)
(prod-desc, unit-price)
2. Add to this relation a copy of the attribute(s) which determines these offending attributes. These will automatically become the primary key of this new relation..
(prod-no, prod-desc, unit-price)
ORDER-LINE-1 (order-no, prod-no, ord-qty, line-total)
3. Name the new entity (appending the number 2 to indicate 2NF)
PRODUCT-2 (prod-no, prod-desc, unit-price)
4. Rename the original entity (ending with a 2 to indicate 2NF)
ORDER-LINE-2 (order-no, prod-no, ord-qty, line-total)

50. Third Normal Form (3NF)
Definition: A relation is in 3NF if, and only if, it is in 2NF and every non-key attribute is non-transitively dependent on the primary key.
Remove transitive dependencies into a new relation
Steps from 2NF to 3NF:
Remove the offending attributes that are transitively dependent on non-key attribute(s), and place them in a new relation.
Add to this relation a copy of the attribute(s) which are the determinants of these offending attributes. These will automatically become the primary key of this new relation.
Name the new entity (appending the number 3 to indicate 3NF)
Rename the original entity (ending with a 3 to indicate 3NF)

51. Example - 2NF to 3NF
ORDER-2 (order-no, order-date, cust-no, cust-name, cust-add, order-total
1. Remove the offending attributes that are transitively dependent on non-key attributes, and place them in a new relation.
(cust-name, cust-add )
ORDER-2 (order-no, order-date, cust-no, order-total
2. Add to this relation a copy of the attribute(s) which determines these offending attributes. These will automatically become the primary key of this new relation..
(cust-no, cust-name, cust-add )
ORDER-2 (order-no, order-date, cust-no, order-total
3. Name the new entity (appending the number 3 to indicate 3NF)
CUSTOMER-3 (cust-no, cust-name, cust-add )
4. Rename the original entity (ending with a 3 to indicate 3NF)
ORDER-3 (order-no, order-date, cust-no, order-total

52. Example - Relations in 3NF
CUSTOMER-3 (cust-no, cust-name, cust-add )
ORDER-3 (order-no, order-date, cust-no, order-total
ORDER-LINE-2 (order-no, prod-no, ord-qty, line-total)
PRODUCT-2 (prod-no, prod-desc, unit-price)
CUSTOMER
ORDER
ORDER-LINE
PRODUCT
places
placed by
contains
part of
shows
belongs to
cust-no
order-no
prod-no
order-no, prod-no

53. Case Study on Normalization
Consider the table
EMP_DEPT_PROJ
And the following dependencies which exist in the above table:

54. Steps to Normalize the database
Thus we will have 3 tables

55. Steps to Normalize the database
Let us now identify the transitive dependency and remove it.

56. Steps to Normalize the database
Let us now identify the non key determinants and remove them.
Thus we will have 5 tables

57. Thank You