September 24, 200191.2914 R McFadyen1 The objective of normalization is sometimes stated “to create relations where every dependency is on the primary

September 24, 2001 91.2914 R McFadyen 1

The objective of normalization is sometimes stated

“to create relations where every dependency is on

•the primary key,

•the whole primary key, and

•nothing but the primary key”

Database designers are always looking for (OLTP) databases that are as simple as possible - ones that are easiest to keep consistent, ones where the semantics are clear.

Normalization


Certain relation schemas have update anomalies

- they may be difficult to understand and maintain

Normalization theory recognizes this and gives us some principles to guide our designs

Normal Forms: 1NF, 2NF, 3NF, BCNF, 4NF, … are each an improvement on the previous ones in the list

Normalization


Normalization is a process (involves decomposition) that generates tables of higher normal forms.

Denormalization moves from higher to lower forms and is done for performance reasons.

Normalization


Suppose we have

EmployeeProject

Anomalies

EmployeeProject holds information about employees and the projects they work on

•emp_num: employee’s social insurance number•proj_num: a project number•ep_hours: the hours the employee has worked on the project•emp_name: the employee’s name•proj_loc: the location of the project •PK is {emp_num, proj_num}

emp_num proj_num ep_hours emp_name proj_loc


An instance of the table:

emp_num proj_num ep_hours emp_name

EmployeeProject

proj_loc

Anomalies

11 23 6 Jones Edmt

11 36 2 Jones Wpg

11 99 22 Jones Brandon

17 23 5 Smith Edmt

17 36 2 Smith Wpg

17 101 13 Smith Wpg


EmployeeProject

Anomalies

we will have redundant information in the database …

•if more than one employee works on the same project, then the project location is repeated

•if some employee works on more than one project, then the employee’s name is repeated

emp_num proj_num ep_hours emp_name proj_loc


Redundant data leads to

•additional space requirements

•update anomalies

Anomalies


Suppose EmployeeProject is the only relation where the Project Location is recorded

insert anomalies

•adding a new project is complicated, unless there is also an employee for that project

deletion anomalies

•if we delete all employees for some project, then what should happen to the project information?

modification anomalies

•if we update the location of a project, then we must change it in all rows referring to that project

Anomalies


If we design a database with a relation such as EmployeeProject then we will have complex update rules to enforce.

•difficult to code correctly

•will not be as efficient as possible

Such designs mix concepts.

E.g EmployeeProject mixes the Employee and Project concepts

Such designs are (generally) not good for OLTP

Anomalies


Suppose we have a relation R comprising attributes X,Y, …

We say a functional dependency exists between the attributes X and Y,

if, whenever a tuple exists with the value x for X, it will always have the same value for y for Y.

emp_num emp_name

emp_gender

emp_phone

X Y

Employee

Given a specific employee number, there is only one value for name, one value for gender, and only one value for phone

Emp_number is a determinant for emp_name, emp_gender, emp_phone

Functional dependencies

emp_num emp_gender emp_name emp_phone


•a series of normal forms are known that have, successively, better update characteristics

•we’ll consider 1NF, 2NF, 3NF, and BCNF

•a technique used to improve a relation is decomposition, where one relation is replaced by two or more relations. When we do so, we want to eliminate update anomalies without losing any information.

•Our target is BCNF

Normal Forms


The Dependency Diagram

� illustrates a single-attribute PK (simple PK)

� all employee attributes are dependent on the PK

Employee emp_num emp_gender emp_name emp_phone


Partial Dependency

PROJ_CODE EMP_NUM PROJ_NAME HRS_WORKED

� Multi-attribute PK (composite PK)� HRS_WORKED is dependent on the PK� But PROJ_CODE, which is only a part of the PK, determines PROJ_NAME (equivalently, PROJ_NAME is dependent on PROJ_CODE)

Partial dependency


Transitive Dependency

STU_NUM STU_LNAME DEPT_CODE DEPT_NAME

� All student attributes are dependent on the PK� But DEPT_CODE determines DEPT_NAME (or

DEPT_NAME is dependent on DEPT_CODE, a non-key attribute

Transitive dependency


BCNF

•all determinants are candidate keys

INV_NUM LINE_NUM PROD_CODE PROD_TITLE CUS_NUM LINE_UNITS

Example, consider:

Partial dependency



BCNF - all determinants are candidate keys


Determinants:

prod_code prod_title

inv_num cus_num

inv_num, prod_code line_units

Three determinants, but only one is a candidate key. Therefore, not in BCNF


BCNF - all determinants are candidate keys


Three determinants:

•prod_code

•inv_num

•{prod_code, line_units}

but only one is a candidate key.

Therefore, not in BCNF

A table with these

attributes will have a lot

of redundancy.


Decomposition

We can decompose the single table into three tables where there will be

no unnecessary redundancy

no loss of information - we can join the three to have what we had before

no loss of dependencies

INV_NUM LINE_NUM PROD_CODE

PROD_TITLE

LINE_UNITS

INV_NUM CUS_NUM PROD_CODE


Decomposition

Each of these tables is in BCNF

INV_NUM LINE_NUM PROD_CODE

PROD_TITLE

LINE_UNITS

INV_NUM CUS_NUM

PROD_CODE



Consider:

This table is not in 2NF because it has a partial dependency: CUS_NUM is dependent on INV_NUM

Partial dependency


First Normal Form (1NF)

Each row/column intersection contains one and only one value, rather than a set of values

All attributes are dependent on the primary key


EMP_NUM EMP_LNAME EMP_FNAME EMP_DOB

This table is in 1NF.

Question to answer later: is it in 2NF? 3NF? BCNF?


Consider




This table is in 1NF.

Question to answer later: is it in 2NF? 3NF? BCNF?

Consider


The Second Normal Form (2NF)

� Meets 1NF requirements

� Does not contain partial dependencies

� But may contain transitive dependencies


Decomposition

A table can be decomposed into two or more tables. Ideally, this involves:

•no loss of information•all information previously available can be obtained by joining the new tables - a lossless decomposition

•no loss of dependencies•a dependency-preserving decomposition



Consider:

This table is not in 2NF because it has a partial dependency: CUS_NUM is dependent on INV_NUM

Partial dependency



Consider:

We need to decompose the table - move the partial dependency to a new table. I.e. Invoice information belongs elsewhere.

Partial dependency


Decomposition

create a new table

don’t lose any information (can still derive)

INV_NUM LINE_NUM PROD_CODE PROD_TITLE LINE_UNITS

INV_NUM CUS_NUM

No partial

dependencies

present!


The Third Normal Form (3NF)

� Meets 2NF requirements

� Does not contain transitive dependencies


Consider:

Because of the transitive dependency, this table is not in 3NF


INV_NUM LINE_NUM PROD_CODE PROD_TITLE LINE_UNITS

We need to decompose the table - move the transitive dependency to a new table. I.e. Product information belongs elsewhere.


INV_NUM LINE_NUM PROD_CODE LINE_UNITS

Decomposition

create a new table

don’t lose any information (can still derive)

There is no transitive

dependency here!PROD_CODE PROD_TITLE


The Boyce-Codd Normal Form (BCNF)

� Meets 3NF requirements� Every determinant in the table is a candidate key� Focus is on determinants


Example

consider the following functional dependencies and table structure

city, streetname postalcode

postalcode city

city streetname postalcode

Note that this table does have redundant data, and from a theoretical perspective, would have anomalies associated with it.

Address


Example

city, streetname postalcode

postalcode city

city streetname postalcode

Let us consider the more formal/complete definitions in the 91.3902 text, and then ask:

What are the non-key attributes?

What is the primary key?

What is the normal form of Address?

Address


From the 91.3902 text: A relation R is in 2NF if every nonprime attribute of A is not partially dependent on any key R.

nonprime: an attribute is nonprime if it is not a member of a candidate key.prime: an attribute is prime if it is a member of a candidate key.

city streetname postalcodeAddress

In our example, there are no nonprime attributes

Hence the table is in 2NF


From the 91.3902 text: A relation R is in 3NF if, whenever a functional dependency x --> A holds in R, either

a) X is a superkey of R, orb) A is a prime attribute of R.

One of the things that this says is: if a nonprime attribute A is dependent on some attribute, that determinant must include the key.


In our example, there are no nonprime attributesHence the table is in 3NF


Is every determinant a candidate key?

NO


Hence the table is not BCNF

What decomposition would preserve dependencies and have BCNF tables? Is this a practical example?

Documents

September 24, 200191.2914 R McFadyen1 The objective of normalization is sometimes stated “to create relations where every dependency is on the primary