OOAD: Normalization (Recall)

Presenter: Dr. Ha Viet Uyen Synh.

Normalization
Normalization is a process that “improves” a database
design by generating relations that are of higher normal
forms.

We discuss four normal forms: first, second, third, and

Boyce-Codd normal forms _ 1NF, 2NF, 3NF, and BCNF
 Normalization

1NF a relation in BCNF, is also in 3NF

a relation in 3NF is also in 2NF

2NF a relation in 2NF is also in 1NF

3NF

BCNF
 Normalization
We consider a relation in BCNF to be fully normalized.

The benefit of higher normal forms is that update

semantics for the affected data are simplified.

This means that applications required to maintain the

database are simpler.

A design that has a lower normal form than another

design has more redundancy. Uncontrolled redundancy
can lead to data integrity problems.
 Functional Dependencies
We say an attribute, B, has a functional dependency on
another attribute, A, if for any two records, which have
the same value for A, then the values for B in these two
records must be the same. We illustrate this as:
A→B

Example: Suppose we keep track of employee email

addresses, and we only track one email address for
each employee. Suppose each employee is identified
by their unique employee number. We say there is a
functional dependency of email address on employee
number:
employee number → email address
Keys
Primary Key: a minimal set of attributes that form a
candidate key

Any attribute or collection of attributes that functionally

determine all attributes in a record is a Candidate Key.

A key consisting of more than one attribute is called a

“composite key.”

Foreign Key: A value in the “child” table that matches

with the related value in the “parent” table.
Ex:
SalesRep(SalesRepNumber, Name)
Customer(CustomerNumber, SalesRepNumber)
 Functional Dependencies
EmpNum EmpEmail EmpFname EmpLname
123 [email protected] John Doe
456 [email protected] Peter Smith
555 [email protected] Alan Lee
633 [email protected] Peter Doe
787 [email protected] Alan Lee

If EmpNum is the PK then the FDs:

EmpNum → EmpEmail
EmpNum → EmpFname
EmpNum → EmpLname
must exist.
Functional Dependencies
EmpNum → EmpEmail
EmpNum → EmpFname
EmpNum → EmpLname

EmpEmail
EmpNum EmpFname

EmpLname

EmpNum EmpEmail EmpFname EmpLname

Properties of Functional Dependencies

1. Reflexivity: If Y ⊆ X, then X → Y

2. Augmentation: If X → Y , then XZ → Y Z

3. Transitivity: If X → Y and Y → Z, then X → Z

4. Union: If X → Y and X → Z, then X → Y Z

5. Decomposition: If X → Y Z, then X → Y and X → Z

6. Pseudo-transitivity: If X → Y and WY → Z, then W X → Z

7. Composition: If X → Y and Z → W , then XZ → Y W

Determinant
Functional Dependency

EmpNum → EmpEmail

Attribute on the LHS is known as the determinant

• EmpNum is a determinant of EmpEmail
 Transitive dependency
Consider attributes A, B, and C, and where
A → B and B → C.

Functional dependencies are transitive, which means that

we also have the functional dependency A → C

We say that C is transitively dependent on A through B.

 Transitive dependency
EmpNum → DeptNum

EmpNum EmpEmail DeptNum DeptNname

DeptNum → DeptName

EmpNum EmpEmail DeptNum DeptNname

DeptName is transitively dependent on EmpNum via DeptNum

EmpNum → DeptName
 Partial dependency
A partial dependency exists when an attribute B is
functionally dependent on an attribute A, and A is a
component of a multipart candidate key.

InvNum LineNum Qty InvDate

Candidate keys: {InvNum, LineNum} .

InvDate is partially dependent on {InvNum, LineNum}
as InvNum is a determinant of InvDate and InvNum is
part of a candidate key
Closure
Given a set of functional dependencies F , and a set of attributes X, the
closure of X with respect to F , written XF+, is the set of all the attributes
whose values are determined by the values of X because of F .

Ex: Given the following set, M, of functional dependencies:

1. A → B
2. B → C
3. BC → D
Compute the closure of A with respect to M.

i A → A ( by reflexivity rule )
ii A → AB ( by (i) and 1 )
iii A → ABC ( by (ii), 2, and transitivity rule )
iv A → ABCD ( by (iii), and 3 )
Therefore, A+M = {ABCD}.
Cover
A set of functional dependencies F covers another set of functional
dependencies G, if every functional dependency in G can be inferred
from F . More formally, F covers G if G+ ⊆ F+.

F is a minimal cover of G if F is the smallest set of functional

dependencies that cover G.

Ex: we have the following functional dependencies (F ):

• AB → C
•A→B
And we want to know if we can simplify to the following (H):
•A→C
•A→B
Then A+H = {ABC}.
Finding the Minimal Cover
Minimal cover: opposite extreme from closure
• Given a set of FDs F, want to minimize F’ s.t.
– F’  F
– F’ entails X, X  F
• Properties of a minimal basis F’
– RHS is always singleton
– If any FD is removed from F’, F’ is no longer a minimal basis
– If for any FD in F’ we remove one or more attributes from the LHS of
F, the result is no longer a minimal basis

1. Split all RHS into singletons

2. X  F’, test whether J = (F’‐X)+ is still equivalent to F+
=> Might make F’ too small
3. i  LHS(X) X  F’, let LHS(X’)=LHS(X)‐i
Test whether (F’‐X+X’)+ is still equivalent to F+
=> Might make F’ too big
4. Repeat (2) and (3) until neither makes progress
Example
Relation R: R(A, B, C, D)
Defined FDs:
–F={ A‐>AC,
B‐>ABC,
D‐>ABC}
Find the minimal cover M of F
Example: Solution
1st Step
– H = {A‐>A, A‐>C, B‐>A, B‐>B, B‐>C, D‐>A, D‐>B, D‐>C}

2nd Step
– A‐>A, B‐>B: can be removed as trivial
– A‐>C: can’t be removed, as there is no other LHS with A
– B‐>A: can’t be removed, because for J=H‐{B‐>A} is B+=BC
– B‐>C: can be removed, because for J=H‐{B‐>C} is B+=ABC
– D‐>A: can be removed, because for J=H‐{D‐>A} is D+=DBAC
– D‐>B: can’t be removed, because for J=H‐{D‐>B} is D+=DC
– D‐>C: can be removed, because for J=H‐{D‐>C} is D+=DBAC
Step outcome => H = {A‐>C, B‐>A, D‐>B}

3rd Step
– H doesn’t change as all LHS in H are single attributes
4th Step
– H doesn’t change
Minimal Cover: M = H = {A‐>C, B‐>A, D‐>B}
Normal Forms
All attributes depend on the key, the whole key and
nothing but the key.

1NF Keys and no repeating groups

2NF No partial dependencies
3NF All determinants are candidate keys
BCNF No multivalued dependencies
 First Normal Form

We say a relation is in 1NF if all values stored in the

relation are single-valued and atomic.

1NF places restrictions on the structure of relations.

Values must be simple.

- Table has a primary key

- Table has no repeating groups
A multivalued attribute is an attribute that may have
several values for one record
A repeating group is a set of one or more multivalued
attributes that are related
Example
Multivalued attribute:
Orders(OrderNumber, OrderDate, {PartNumber})
[ 12491 | 9/02/2001 | BT04, BZ66 ]

Repeating group:
Orders(OrderNumber, OrderDate, {PartNumber,
NumberOrdered})
[12491 | 9/02/2001 | (BT04, 1), (BZ66, 1)]
 First Normal Form
The following in not in 1NF

EmpNum EmpPhone EmpDegrees

123 233-9876
333 233-1231 BA, BSc, PhD
679 233-1231 BSc, MSc

EmpDegrees is a multi-valued field:

employee 679 has two degrees: BSc and MSc
employee 333 has three degrees: BA, BSc, PhD
 First Normal Form
EmpNum EmpPhone EmpDegrees
123 233-9876
333 233-1231 BA, BSc, PhD
679 233-1231 BSc, MSc

To obtain 1NF relations we must, without loss of

information, replace the above with two relations
Employee
EmpNum EmpDegree
EmpNum EmpPhone
333 BA
123 233-9876
333 BSc
333 233-1231
333 PhD
679 233-1231
679 BSc
EmployeeDegree 679 MSc
 Second Normal Form
A relation is in 2NF if it is in 1NF, and every non-key
attribute is fully dependent on each candidate key.

• 2NF (and 3NF) both involve the concepts of key and

non-key attributes.

• A key attribute is any attribute that is part of a key;

any attribute that is not a key attribute, is a non-key
attribute.

• Relations that are not in BCNF have data redundancies

• A relation in 2NF will not have any partial dependencies

 Second Normal Form
Consider this InvLine table (in 1NF):
InvNum LineNum ProdNum Qty InvDate

InvNum, LineNum ProdNum, Qty There are two

InvNum InvDate candidate keys.
Invdate is the only non-
key attribute, and it is
dependent on InvNum

Since there is a determinant that is not a candidate

key, InvLine is not BCNF
InvLine is not 2NF since there is a partial dependency
of InvDate on InvNum

=> InvLine is only in 1NF

 Second Normal Form
InvLine
InvNum LineNum ProdNum Qty InvDate
The above relation has redundancies: the invoice date is
repeated on each invoice line.
We can improve the database by decomposing the
relation into two relations:

InvNum LineNum ProdNum Qty

InvNum InvDate

Question: What is the highest normal form for these

relations? 2NF? 3NF? BCNF?
Exercise #1
Is the following relation in 2NF?

inv_no line_no prod_no prod_desc qty

 Exercise #2
What is the highest normal form for these relations?

EmployeeDept
ename ssn bdate address dnumber dname
 Third Normal Form
• A relation is in 3NF if the relation is in 1NF and all
determinants of non-key attributes are candidate
keys. That is, for any functional dependency:
X → Y,
where Y is a non-key attribute (or a set of non-key
attributes), X is a candidate key.

• This definition of 3NF differs from BCNF only in the

specification of non-key attributes - 3NF is weaker
than BCNF. (BCNF requires all determinants to be
candidate keys.)

• A relation in 3NF will not have any transitive

dependencies of non-key attribute on a candidate
key through another non-key attribute.
 Third Normal Form
Consider this Employee relation

EmpNum EmpName DeptNum DeptName

EmpName, DeptNum, and DeptName are non-key

attributes.
DeptNum determines DeptName, a non-key attribute,
and DeptNum is not a candidate key.

Is the relation in BCNF? …

Is the relation in 3NF? …
Is the relation in 2NF? …
 Third Normal Form

EmpNum EmpName DeptNum DeptName

We correct the situation by decomposing the original

relation into two 3NF relations. Note the decomposition is
lossless.

EmpNum EmpName DeptNum DeptNum DeptName

Verify these two relations are in 3NF.

 Instructor teaches one
course only.
student_no course_no instr_no
Student takes a course
and has one instructor.

{student_no, course_no} → instr_no

instr_no → course_no

since we have instr_no → course-no, but instr_no is not a

Candidate key.
 student_no course_no instr_no

student_no instr_no

course_no instr_no

{student_no, instr_no} → student_no

{student_no, instr_no} → instr_no
instr_no → course_no
 Boyce-Codd Normal Form
Boyce-Codd Normal Form

BCNF is defined very simply:

a relation is in BCNF if only if every determinant is a
candidate key.

If our database will be used for OLTP (on line

transaction processing), then BCNF is our target.
Usually, we meet this objective. However, we might
denormalize (3NF, 2NF, or 1NF) for performance
reasons.
Exercise #3

Order(OrderNumber, OrderDate, {PartNumber,

{Supplier}})
Exercise #4
(supplier_no, status, city, part_no, quantity)

Functional Dependencies:
(supplier_no, part_no) → quantity
(supplier_no) → status
(supplier_no) → city
city → status (Supplier's status is determined by location)
Exercise #5
SUPPLIER_PART (supplier_no, supplier_name, part_no,
quantity)

Functional Dependencies:
We assume that supplier_name's are always unique to
each supplier. Thus we have two candidate keys:
(supplier_no, part_no) and (supplier_name, part_no)

Thus we have the following dependencies:

(supplier_no, part_no) → quantity
(supplier_no, part_no) → supplier_name
(supplier_name, part_no) → quantity
(supplier_name, part_no) → supplier_no
supplier_name → supplier_no
supplier_no → supplier_name
Any Questions?

 [email protected]