0% found this document useful (0 votes)
69 views

Database Design: Normalization

The document discusses database normalization. It begins by reviewing how to convert entity relationship diagrams into relational database tables. It then discusses the different normal forms including 1NF, 2NF, and 3NF. 1NF defines attributes and primary keys, 2NF removes partial dependencies, and 3NF removes transitive dependencies. The goal of normalization is to organize data to reduce redundancies and anomalies by bringing tables to these normal forms through a series of steps.

Uploaded by

r_nirmala2035
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
69 views

Database Design: Normalization

The document discusses database normalization. It begins by reviewing how to convert entity relationship diagrams into relational database tables. It then discusses the different normal forms including 1NF, 2NF, and 3NF. 1NF defines attributes and primary keys, 2NF removes partial dependencies, and 3NF removes transitive dependencies. The goal of normalization is to organize data to reduce redundancies and anomalies by bringing tables to these normal forms through a series of steps.

Uploaded by

r_nirmala2035
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 27

Database Design Lecture 8

Normalization

Lecture Objectives

Review basic rules for converting Entities to Tables Review how to address Relationships between entities Overview of Normalization

Converting ERD into Relational Database Model

1.

Entities to Tables
Create a separate table for each entity and consider all the attributes you defined in ERD as the table columns Define a unique identifier as the table PK. Could be an existing attribute that can be used for PK otherwise create a generic PK. Do not include derived attributes in the tables. Ensure all attributes are atomic. Create a new table to support multi-valued attributes.
3

2.

3. 4. 5.

Converting ERD into Relational Database Model

1.

Relationships
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. 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.
4

2.

Converting ERD into Relational Database Model

3.

Relationships
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. 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.
5

4.

Converting ERD into Relational Database Model

5.

Relationships
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.

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

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
8

Database Tables and Normalization

Normalization stages

1NF - First normal form


Eliminate repeating groups Identify PK result is functional dependency Eliminate partial dependencies Eliminate transitive dependencies Eliminate dependencies whereby a non-key attribute can identify a key attribute.
9

2NF - Second normal form

3NF - Third normal form

BCNF Boyce-Codd normal form

Need for Normalization


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

Figure 5.2

10

Conversion to 1NF

Repeating groups must be eliminated


Proper primary key developed

Uniquely identifies attribute values - rows (functional dependency)

11

Data Organization: 1NF

Figure 5.2

Eliminate repeating groups populate every cell of the table.


12

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

13

Dependency Diagram (1NF)


First Normal Form: identify dependencies
Partial Dependency: attributes dependent on part of the primary key

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

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

Dependency Diagram (1NF)


First Normal Form: identify all dependencies
Partial Dependency: attributes dependent on part of the primary key

Functional Dependency: A, B, C, d, e, f Partial Dependency: A, d, e Transitive Dependency: d, f

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

15

Data Organization: 1NF

Figure 5.2

Eliminate repeating groups populate every cell of the table.


16

Dependency Diagram (1NF)


PROJ_NUM
EMP_NUM PROJ_NAME EMP_NAME JOB_CLASS CHG_HOUR HOURS

Functional Dependency: each attribute is uniquely identified 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)

17

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)

18

Dependency Diagram Continued


1NF
PROJ_NUM EMP_NUM PROJ_NAME EMP_NAME

2NF

JOB_CLASS
CHG_HOUR HOURS
19

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 20

2NF Summarized

In 1NF Includes no partial dependencies

Attributes dependent on a portion of primary key Attributes may be functionally dependent on nonkey attributes

Still possible to exhibit transitive dependency

21

Dependency Diagram Continued


1NF
PROJ_NUM EMP_NUM PROJ_NAME EMP_NAME

2NF

3NF

JOB_CLASS
CHG_HOUR HOURS
22

Conversion to 3NF

Create separate tables to eliminate transitive functional dependencies Identify any additional attributes needed in new table
New attribute

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)

23

3NF Summarized

In 2NF Contains no transitive dependencies

24

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
25

Normalization Steps

1NF

All key attributes are defined No repeating groups All attributes are functionally dependent on the primary key Table is in 1NF No partial dependencies

2NF

26

Normalization Steps

3NF

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

27

You might also like