Normalization

Database Design – Lecture 8

Normalization

2

Lecture Objectives

Review basic rules for converting Entities to Tables

Review how to address Relationships between entities

Overview of Normalization

3

Converting ERD into Relational Database Model

Entities to Tables1. Create a separate table for each entity and

consider all the attributes you defined in ERD as the table columns

2. Define a unique identifier as the table PK. Could be an existing attribute that can be used for PK otherwise create a generic PK.

3. Do not include derived attributes in the tables.

4. Ensure all attributes are atomic.5. Create a new table to support multi-valued

attributes.

4

Converting ERD into Relational Database Model

Relationships1. For 1:M connectivity, include the PK of the

’1’ as an FK attribute in the ‘M’ table. Add additional attributes to the ‘M’ table, as required.

2. For M:N connectivity, create a bridge table. Include the PKs from both entities as a composite PK in the bridge table. These attributes will also be FKs in the bridge table. Add additional attributes to the bridge table, as required.

5

Converting ERD into Relational Database Model

Relationships3. For Strong-Weak relationship, include PK of

strong entity as part of the PK of the weak entity, thus giving it a composite primary key. It will also be an FK in the weak entity.

4. For Supertype/Subtype relationships, create a new entity. Attributes unique to the subtype are moved to the new table and are removed from the supertype entity. Both entities will have the same primary keys.

6

Converting ERD into Relational Database Model

Relationships5. For recursive relationships (1:1, 1:M), add

additional attributes as required. For M:N recursive relationship, create a new entity with a composite primary key. Create a primary key for the new entity and make a composite primary key using it and the primary key from the ‘1’ entity. The primary key from the ‘1’ will also be a FK in the new entity.

7

Normalization

Normalization can be used in two ways: As a process to validate the table structures

created through the conversion of entity relationship diagrams to relational tables

As a process to create entities from table structures created by user views

8

Normalization

Normalization is a process for assigning attributes to entities Reduces data redundancies Helps eliminate data anomalies Produces controlled redundancies to link

tables Works through a series of stages called

normal forms Works with views of data

9

Database Tables and Normalization

Normalization stages 1NF - First normal form

Eliminate repeating groups Identify PK result is functional dependency

2NF - Second normal form Eliminate partial dependencies

3NF - Third normal form Eliminate transitive dependencies

BCNF – Boyce-Codd normal form Eliminate dependencies whereby a non-key

attribute can identify a key attribute.

10

Need for Normalization

Figure 5.2

possible primary keys?

• Table entries have data inconsistencies (note blank entries)• Table displays data anomalies:

• Update - Modifying JOB_CLASS• Insertion - New employee must be assigned project• Deletion – If an employee is deleted, other vital data lost

11

Conversion to 1NF

Repeating groups must be eliminated Proper primary key developed

Uniquely identifies attribute values - rows (functional dependency)

12

Data Organization: 1NF

Figure 5.2

Eliminate repeating groups – populate every cell of the ‘table’.

13

Conversion to 1NF

Identify dependencies Desirable dependencies based on primary

key Less desirable dependencies

Partial (later) based on part of composite primary key

Transitive (later) one nonprime attribute depends on another

nonprime attribute

14

Dependency Diagram (1NF)

A B C d e f

First Normal Form: identify dependencies

Transitive Dependency (non-key attribute depends on another non-key attribute)

Note: Capital letters refer to primary key, lower case letters refer to attributes.

Partial Dependency: attributes dependent on part of the primary key

15

Dependency Diagram (1NF)

A B C d e f

First Normal Form: identify all dependencies

Transitive Dependency (non-key attribute depends on another non-key attribute)

Functional Dependency: A, B, C, d, e, fPartial Dependency: A, d, eTransitive Dependency: d, f

Partial Dependency: attributes dependent on part of the primary key

16

Data Organization: 1NF

Figure 5.2

Eliminate repeating groups – populate every cell of the ‘table’.

17

Dependency Diagram (1NF)

PROJ_NUM

EMP_NUM

PROJ_NAME

EMP_NAME

JOB_CLASS

CHG_HOUR

HOURS

Functional Dependency: each attribute is uniquelyidentified by, or is dependent on the primary key.

Primary key is a composite primary key and is made up of PROJ_NUM and EMP_NUM

EMPLOYEE_PROJECT (PROJ_NUM (pk), EMP_NUM (pk), PROJ_NAME, EMP_NAME, JOB_CLASS, CHG_HOUR, HOURS)

18

1NF Summarized

All key attributes defined No repeating groups in table All attributes dependent on primary key

(functional dependency)

EMPLOYEE_PROJECT (PROJ_NUM (pk), EMP_NUM (pk), PROJ_NAME, EMP_NAME, JOB_CLASS, CHG_HOUR, HOURS)

19

Dependency Diagram Continued

PROJ_NUM

EMP_NUM

PROJ_NAME

EMP_NAME

JOB_CLASS

CHG_HOUR

HOURS

1NF 2NF

20

Conversion to 2NF

Start with 1NF format: Write each key component on separate line Write original key on last line Each component is new table Write dependent attributes after each key

PROJECT (PROJ_NUM (pk), PROJ_NAME)

EMPLOYEE (EMP_NUM (pk), EMP_NAME, JOB_CLASS, CHG_HOUR)

EMPLOYEE_PROJECT (PROJ_NUM (pk, fk), EMP_NUM (pk, fk), HOURS)

Attribute of hours is dependent on composite primary key

21

2NF Summarized

In 1NF Includes no partial dependencies

Attributes dependent on a portion of primary key

Still possible to exhibit transitive dependency Attributes may be functionally dependent

on non-key attributes

22

Dependency Diagram Continued

PROJ_NUM

EMP_NUM

PROJ_NAME

EMP_NAME

JOB_CLASS

CHG_HOUR

HOURS

1NF 2NF 3NF

23

Conversion to 3NF Create separate tables to eliminate transitive

functional dependencies Identify any additional attributes needed in new table

JOB (JOB_CLASS (pk), JOB_DESCRIPTION, CHG_HOUR)

PROJECT (PROJ_NUM (pk), PROJ_NAME)

EMPLOYEE (EMP_NUM (pk), EMP_NAME, JOB_CLASS (fk))

EMPLOYEE_PROJECT (PROJ_NUM (pk, fk), EMP_NUM (pk, fk), HOURS)

New attribute

24

3NF Summarized

In 2NF Contains no transitive

dependencies

25

Normalization and Database Design

Normalization should be part of the design process

E-R Diagram provides macro view Normalization provides micro view of

entities Focuses on characteristics of specific entities May yield additional entities

Difficult to separate normalization from E-R diagramming

Business rules must be determined

26

Normalization Steps

1NF All key attributes are defined No repeating groups All attributes are functionally dependent on

the primary key

2NF Table is in 1NF No partial dependencies

27

Normalization Steps

3NF Table is in 2NF No transitive dependencies New PKs identified where appropriate