Topic 5.

2: Normalization and Database Design

The tables shown in Figure 5.6 in unit 5.1 were created to illustrate how normalization procedures can produce good tables from poor ones. Important points highlighted were: Normalization should be part of the database design process Make sure that proposed entities meet required normal form before table structures are created Many real-world databases have been improperly designed or burdened with anomalies if improperly modified over time You may be asked to redesign and modify existing databases ER diagram o Provides the big picture, or macro view, of an organizations data requirements and operations o Created through an iterative process Identifying relevant entities, their attributes and their relationship Use results of Normalization to identify additional entities and attributes Normalization process may yield additional entities and attributes to be incorporated into the ER diagram. It focuses on o the characteristics of specific entities o a micro view of the entities within the ER diagram Difficult to separate normalization process from ER modeling process Two techniques should be used concurrently

To illustrate the proper role of normalization in the design process, reexamine the operations of the contracting company whose tables were normalized in the preceding section 5.1. From the companys operations, two entities are initially defined: PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL, JOB_DESCRIPTION, JOB_CHG_HOUR)

These two entities constitute the initial ER diagram shown in Figure 5.10.

After creating the initial ER diagram shown in Figure 5.10, the normal forms are defined: PROJECT is in 3NF and needs no modification at this point. EMPLOYEE requires additional scrutiny. The JOB_DESCRIPTION defines job classifications such as System Analyst, Database Designer, and Programmer. In turn these classifications determine the billing rate, JOB_CHG_HOUR. Therefore, EMPLOYEE contains a transitive dependency. The removal of EMPLOYEEs transitive dependency yields three entities as shown in Figure 5.11.

To represent the M:N relationship between EMPLOYEE and PROJECT, you might think that two 1:M relationships could be used - an employee can be assigned to many projects and each project can have many employees assigned to it (see Figure 5.12). Unfortunately, this representation yields a design that can not be correctly implemented.

Because the M:N relationship between EMPLOYEE and PROJECT cannot be implemented, the ERD in Figure 5.12 must be modified to include the ASSIGNMENT entity to track the assignment of employees to projects, thus yielding the ER diagram shown in Figure 5.13. The ASSIGNMENT entity in Figure 5.13 uses the primary keys from the entities PROJECT and EMPLOYEE to serve as its foreign keys.

Note that the ASSIGN_HOURS attribute is assigned to the composite entity named ASSIGNMENT. Because detailed information about each projects manager is likely needed, the creation of a manages relationship is useful. Finally, some additional attributes may be created to improve the systems ability to generate additional information. The ER diagram represents the operations accurately, and the entities now reflect their conformance to 3NF. The combination of normalization and ER modeling yields a useful ER diagram, whose entities may now be translated into appropriate table structures. The final database contents are shown in Figure 5.14.

Concept Check
Explain how Normalization technique support the entity relationship modeling process in database design?