Normalization of Database Tables

Dipresentasikan kembali oleh: SAEPUDIN NIRWAN Matakuliah BASISDATA

Database Tables and Normalization

The process of creating small, stable data structures from complex groups of data is called Normalization Normalization is a process for assigning attributes to entities. It reduces data redundancies and helps eliminate the data anomalies. Normalization is a step-by-step process and works through a series of stages called normal forms:

First normal form (1NF) Second normal form (2NF) Third normal form (3NF) BCNF Fourth normal form (4NF) Fifth normal form (5NF)

The first three steps of normalization, resulting in the first three normal forms are most important For this class, you just need to know the first three normal forms.

Database Tables and Normalization

The Need for Normalization
x

Case of a Construction Company

q

Building project -- Project number, Name, Employees assigned to the project. Employee -- Employee number, Name, Job classification The company charges its clients by billing the hours spent on each project. The hourly billing rate is dependent on the employees position. Periodically, a report is generated. The table whose contents correspond to the reporting requirements is shown on the next slide.

q q

An Access Table Whose Structure Matches the Report Format

Database Tables and Normalization

Problems with the previous database table:
x

The project number is intended to be a primary key, but it contains nulls. The table displays data redundancies.
q

For example employee name and job_class is entered over and over again

The table entries invite data inconsistencies.

q

For example, you might enter Systems Analyst, Sys Analyst or even System Analyst for the same job-class in effect creating three different job classes that imply the same thing.

Database Tables and Normalization

Problems with the previous database table (cont.):
x

The data redundancies yield the following anomalies:

q

Update anomalies. Example: If an employee last name changes the change has to be made (data updated) in multiple locations.

Addition anomalies. Example: Cannot add a new employee unless the employee is also assigned to a project.

Deletion anomalies. If Project_Num 25 is deleted all the related employee information is also deleted.

Database Tables and Normalization

Conversion to First Normal Form
x x

A relational table must not contain repeating groups. Repeating groups can be eliminated by adding the appropriate entry in at least the primary key column(s).

Data Organization: First Normal Form

Database Tables and Normalization

Dependency Diagram
The primary key components are bold, underlined, and shaded in a different color. x The arrows above entities indicate all desirable dependencies, i.e., dependencies that are based on PK. x The arrows below the dependency diagram indicate less desirable dependencies -- partial dependencies and transitive dependencies.
x

Database Tables and Normalization

1NF Definition
x

The term first normal form (1NF) describes the tabular format in which:
q q

All the key attributes are defined. There are no repeating groups in the table. No multi-valued attributes. Every attribute value is atomic. All attributes are dependent on the primary key.

Database Tables and Normalization

Conversion to Second Normal Form
x

Starting with the 1NF format, the database can be converted into the 2NF format by
q

Writing each key component on a separate line, and then writing the original key on the last line and Writing the dependent attributes after each new key. ( PROJ_NUM, PROJ_NAME ) ( EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR ) ( PROJ_NUM, EMP_NUM, HOURS )

PROJECT EMPLOYEE ASSIGN

Second Normal Form (2NF) Conversion Results

Database Tables and Normalization

2NF Definition
x

A table is in 2NF if:

q q

It is in 1NF and It includes no partial dependencies; that is, no attribute is dependent on only a portion of the primary key.
(It is still possible for a table in 2NF to exhibit transitive dependency; that is, one or more attributes may be functionally dependent on nonkey attributes.)

Another Example of 2NF Violation

The primary key for this table is a concatenated/composite key comprising of Emp_ID and Course_Title

Functional Dependencies in EMPLOYEE2

Dependency on entire primary key

EmpID CourseTitle Name DeptName Salary DateCompleted

Dependency on only part of the key

EmpID, CourseTitle DateCompleted EmpID Name, DeptName, Salary

Therefore, NOT in 2nd Normal Form

Resolution to 2nd Normal Form

Decomposed into two separate relations/entities/tables

EmpID

Name DeptName Salary

Both are full functional dependencies

EmpID

CourseTitle

DateCompleted

Database Tables and Normalization

Conversion to Third Normal Form
x

Create a separate table with attributes in a transitive functional dependence relationship.

PROJECT (PROJ_NUM, PROJ_NAME) ASSIGN (PROJ_NUM, EMP_NUM, HOURS) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS) JOB (JOB_CLASS, CHG_HOUR)

Database Tables and Normalization

3NF Definition
x

A table is in 3NF if:

q q

It is in 2NF and It contains no transitive dependencies.

Another Example of 3NF Violation

Entity With Transitive Dependency

CustID Name CustID Salesperson CustID Region All this is OK (2nd NF)

BUT CustID Salesperson Region Transitive dependency (not 3rd NF)

Removing A Transitive Dependency Decomposing The SALES Relation

Relations in 3NF

Now, there are no transitive dependencies Both relations are in 3rd NF

Steps in Normalization

Normalization and Database Design

Database Design and Normalization Example: (Construction Company)
x

Summary of Operations:
q q q q

The company manages many projects. Each project requires the services of many employees. An employee may be assigned to several different projects. Some employees are not assigned to a project and perform duties not specifically related to a project. Some employees are part of a labor pool, to be shared by all project teams. Each employee has a (single) primary job classification. This job classification determines the hourly billing rate. Many employees can have the same job classification.

Normalization and Database Design

Two Initial Entities:
PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL, JOB_DESCRIPTION, JOB_CHG_HOUR)

Normalization and Database Design

Three Entities After Transitive Dependency Removed
PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL, JOB_CODE) JOB (JOB_CODE, JOB_DESCRIPTION, JOB_CHG_HOUR)

The Modified ERD for The Contracting Company

Normalization and Database Design

Creation of the Composite Entity ASSIGN

Normalization and Database Design

Attribute ASSIGN_HOUR is assigned to the composite entity ASSIGN. Manages relationship is created between EMPLOYEE and PROJECT.

PROJECT EMPLOYEE JOB ASSIGN

(PROJ_NUM, PROJ_NAME, EMP_NUM) (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL, EMP_HIREDATE, JOB_CODE) (JOB_CODE, JOB_DESCRIPTION, JOB_CHG_HOUR) (ASSIGN_NUM, ASSIGN_DATE, PROJ_NUM, EMP_NUM, ASSIGN_HOURS)

The Relational Schema for The Contracting Company

Normalization
Normalization is a part of good database design. However, Normalization results in more tables necessitating more joins when queries are run. Sometimes this causes a conflict in the following two goals: x Good database design x Access speed. If faster access is desirable, the organization may not want normalization through the third normal form. If that is the case, it is important to understand, that there may be insertion, deletion and/or update anomalies in tables that have not been normalized through the 3NF.