cs 405g: introduction to database systems 18. normal forms and normalization

CS 405G: Introduction to Database Systems

18. Normal Forms and Normalization

How to connect MySQL server

Know your user id and password (provided by Paul Linton)

Server installed on mysql.cs.uky.edu

04/21/23 Chen Qian @ Univ of Kentucky

04/21/23 Chen Qian @ Univ of Kentucky

04/21/23 Chen Qian @ University of Kentucky

Last class

Functional Dependency. Normalization Decomposition

6

Review

Functional dependencies X -> Y: X “determines” Y

If two rows agree on X, they must agree on Y

04/21/23 7

Attribute on the LHS is known as the determinant

• X is a determinant of Y

04/21/23 Chen Qian @ University of Kentucky 8

Normalization

A normalization is the process of organizing the fields and tables of a relational database to minimize redundancy and dependency.

A normal form is a certification that tells whether a relation schema is in a particular state

First Normal Form ( 1NF )

A relation is in first normal form if the domain of each attribute contains only atomic values, and the value of each attribute contains only a single value from that domain.



2nd Normal Form

An attribute A of a relation R is a nonprimary attribute if it is not part of any key in R, otherwise, A is a primary attribute.

R is in (general) 2nd normal form if every nonprimary attribute A in R is not partially functionally dependent on any key of R

Redundancy Example

If a key will result a partial dependency of a nonprimary attribute.

e.g. EID, PID-> Ename In this case, the attribute (Ename) should be separated

with its full dependency key (EID) to be a new table.

So, to check whether a table includes redundancy. Try every nonprimary attribute and check whether it fully depends on any key.



Decomposition

Decomposition eliminates redundancy To get back to the original relation, use natural join.

EID PID Ename email Pname Hours

1234 10 John Smith [email protected] B2B platform 10

1123 9 Ben Liu [email protected] CRM 40

1234 9 John Smith [email protected] CRM 30

1023 10 Susan Sidhuk [email protected] B2B platform 40

Decomposition

EID Ename email

1234 John Smith [email protected]

1123 Ben Liu [email protected]

1023 Susan Sidhuk [email protected]

EID PID Pname Hours

1234 10 B2B platform 10

1123 9 CRM 40

1234 9 CRM 30


Foreign key


Decomposition

Decomposition may be applied recursively

EID PID Pname Hours


1123 9 CRM 40

1234 9 CRM 30


PID Pname

10 B2B platform

9 CRM

EID PID Hours

1234 10 10

1123 9 40

1234 9 30

1023 10 40


Questions about decomposition

When to decompose

How to come up with a correct decomposition (i.e., lossless join decomposition)

Third normal form

• 3NF requires that there are no non-trivial functional dependencies of non-key attributes on something other than a superset of a candidate key.

• Recall: non-trivial FD means LHS has no intersection with RHS.

• In summary, all non-key attributes are mutually independent.


Ename and email has no FD


EID Ename email

1234 John Smith [email protected]

1123 Ben Liu [email protected]

1023 Susan Sidhuk [email protected]

Boyce-Codd normal form (BCNF)

• BCNF requires that there are no non-trivial functional dependencies of attributes on something other than a superset of a candidate key (called a superkey).

• All attributes are dependent on a key, a whole key and nothing but a key (excluding trivial dependencies, like A->A).


• A table is said to be in the BCNF if and only if it is in the 3NF and every non-trivial, left-irreducible functional dependency has a candidate key as its determinant.

• In more informal terms, a table is in BCNF if it is in 3NF and the only determinants are the candidate keys.



Non-key FD’s

Consider a non-trivial FD X -> Y where X is not a super key Since X is not a super key, there are some attributes (say

Z) that are not functionally determined by X

That b is always associated with a is recorded by multiple rows: redundancy, update anomaly, deletion anomaly

X Y Z

a b c

a b d


Dealing with Nonkey Dependency: BCNF

A relation R is in Boyce-Codd Normal Form if For every non-trivial FD X -> Y in R, X is a super key That is, all FDs follow from “key -> other attributes”

When to decompose As long as some relation is not in BCNF

How to come up with a correct decomposition Always decompose on a BCNF violation (details next) Then it is guaranteed to be a lossless join decomposition


BCNF decomposition algorithm

Find a BCNF violation That is, a non-trivial FD X -> Y in R where X is not a

super key of R Decompose R into R1 and R2, where

R1 has attributes X Y

R2 has attributes X Z, where Z contains all attributes of R that are in neither X nor Y (i.e. Z = attr(R) – X – Y)

Repeat until all relations are in BCNF


BCNF decomposition example

WorkOn (EID, Ename, email, PID, hours)BCNF violation: EID -> Ename, email

Student (EID, Ename, email)Grade (EID, PID, hours)

BCNF BCNF


Another example

WorkOn (EID, Ename, email, PID, hours)BCNF violation: email -> EID

StudentID (email, EID)

StudentGrade’ (email, Ename, PID, hours)BCNF

BCNF violation: email -> Ename

StudentName (email, Ename)Grade (email, PID, hours)BCNF

BCNF


Exercise

Property(Property_id#, County_name, Lot#, Area, Price, Tax_rate) Property_id#-> County_name, Lot#, Area, Price,

Tax_rate County_name, Lot# -> Property_id#, Area, Price,

Tax_rate County_name -> Tax_rate area -> Price


Exercise

Property(Property_id#, County_name, Lot#, Area, Price, Tax_rate)

BCNF violation: County_name -> Tax_rate

LOTS1 (County_name, Tax_rate )

LOTS2 (Property_id#, County_name, Lot#, Area, Price)BCNF violation: Area -> Price

LOTS2A (Area, Price)

LOTS2B (Property_id#, County_name, Lot#, Area)

BCNF

BCNF

BCNF


Why is BCNF decomposition lossless

Given non-trivial X -> Y in R where X is not a super key of R, need to prove:

Anything we project always comes back in the join:R πXY ( R ) πXZ ( R ) Sure; and it doesn’t depend on the FD

Anything that comes back in the join must be in the original relation:R πXY ( R ) πXZ ( R ) Proof makes use of the fact that X -> Y


Recap

Functional dependencies: a generalization of the key concept

Partial dependencies: a source of redundancy Use 2nd Normal form to remove partial dependency

Non-key functional dependencies: a source of redundancy

BCNF decomposition: a method for removing ALL functional dependency related redundancies Plus, BNCF decomposition is a lossless join

decomposition

Normalization

04/21/23 28

There is a sequence to normal forms: 1NF is considered the weakest, 2NF is stronger than 1NF, 3NF is stronger than 2NF, and BCNF is considered the strongest

Also, any relation that is in BCNF, is in 3NF; any relation in 3NF is in 2NF; and any relation in 2NF is in 1NF.

Normalization

04/21/23 29

BCNF

3NF

2NF

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

a relation in 3NF is also in 2NF

a relation in 2NF is also in 1NF

First Normal Form

04/21/23 30

The following is not in 1NF

EmpNum EmpPhone EmpDegrees123 233-9876333 233-1231 BA, BSc, PhD679 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

04/21/23 31

EmpNum EmpDegree

333 BA

333 BSc

333 PhD

679 BSc

MSc679

EmpNum EmpPhone

123 233-9876

333 233-1231

679 233-1231

An outer join between Employee and EmployeeDegree will produce the information we saw before

EmployeeEmployeeDegree

Second Normal Form

04/21/23 32

LineNum ProdNum QtyInvNum

InvNum, LineNum ProdNum

InvNum, ProdNum LineNum

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

Qty

InvDate

InvDateInvNum

There are two candidate keys.

Qty is the only non-key attribute, and it is dependent on InvNum

InvLine is only in 1NF

Consider this InvLine table (in 1NF):

Second Normal Form

04/21/23 33

LineNum ProdNum QtyInvNum InvDate

InvLine

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:


InvDateInvNum

Third Normal Form

04/21/23 34

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.

Consider this Employee relation

Is the relation in 3NF? … no

Is the relation in 2NF? … yes

Is the relation in BCNF? … no

Candidate keys are? …

Third Normal Form

04/21/23 35

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 DeptNameDeptNum

Verify these two relations are in 3NF.

Are they in BCNF?

Boyce-Codd Normal Form

04/21/23 36


BCNF is defined very simply:

a relation is in BCNF if it is in 1NF and if every determinant is a candidate key.

student_no course_no instr_no

Instructor teaches one course only.

Student takes a course and has one instructor.

In 3NF, but not in BCNF:

{student_no, course_no} instr_noinstr_no course_no

since we have instr_no course-no, but instr_no is not aCandidate key.

04/21/23 37

course_no instr_no

student_no instr_no

student_no course_no instr_no

BCNF

{student_no, instr_no} student_no{student_no, instr_no} instr_noinstr_no course_no

04/21/23 38


04/21/23 39


InvNum, LineNum ProdNum

InvNum, ProdNum LineNum

There are two candidate keys.

Since every determinant is a candidate key, the relation is in BCNF

This relation is about Invoice lines only.

Qty{InvNum, LineNum} and {InvNum, ProdNum} are the two candidate keys.

inv_no line_no prod_no prod_desc qty

04/21/23 40

2NF, but not in 3NF, nor in BCNF:

inv_no line_no prod_no prod_desc qty

since prod_no is not a candidate key and we have:

prod_no prod_desc.

04/21/23 41

EmployeeDept

ename ssn bdate address dnumber dname

04/21/23 42

Summary

Philosophy behind BCNF, 4NF:Data should depend on the key, the whole key, and nothing but the key!

Philosophy behind 3NF: … But not at the expense of more expensive constraint enforcement!

04/21/23 43

Next Class

Quiz again


cs 405g: introduction to database systems 18. normal forms and normalization

Documents