Database Design: Normalization
Database Design: Normalization
Normalization
Lecture Objectives
Review basic rules for converting Entities to Tables Review how to address Relationships between entities Overview of Normalization
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.
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.
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.
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
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
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
Normalization stages
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
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
11
Figure 5.2
Conversion to 1NF
Identify dependencies
Partial (later) based on part of composite primary key Transitive (later) one nonprime attribute depends on another nonprime attribute
13
Note: Capital letters refer to primary key, lower case letters refer to attributes.
14
15
Figure 5.2
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
2NF
JOB_CLASS
CHG_HOUR HOURS
19
Conversion to 2NF
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
Attributes dependent on a portion of primary key Attributes may be functionally dependent on nonkey attributes
21
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
23
3NF Summarized
24
Normalization should be part of the design process E-R Diagram provides macro view Normalization provides micro view of 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
27