Designing > Logical database design

DB2 Version 9 for Linux, UNIX, and Windows

DB2 Universal Database Version 9.1 is going out of support as of April 30, 2012. More details are available here: http://www-01.ibm.com/support/docview.wss?uid=swg21575777

Normalization
Normalization helps eliminate redundancies and inconsistencies in table data. It is the process of reducing tables to a set of columns where all the non-key columns depend on the primary key column. If this is not the case, the data can become inconsistent during updates. This section briefly reviews the rules for first, second, third, and fourth normal form. The fifth normal form of a table, which is covered in many books on database design, is not described here. Form Description First At each row and column position in the table, there exists one value, never a set of values. Second Each column that is not part of the key is dependent upon the key. Third Each non-key column is independent of other non-key columns, and is dependent only upon the key. Fourth No row contains two or more independent multi-valued facts about an entity.

First normal form

A table is in first normal form if there is only one value, never a set of values, in each cell. A table that is in first normal form does not necessarily satisfy the criteria for higher normal forms. For example, the following table violates first normal form because the WAREHOUSE column contains several values for each occurrence of PART. Table 4. Table Violating First Normal Form PART (Primary Key) P0010 P0020 WAREHOUSE Warehouse A, Warehouse B, Warehouse C Warehouse B, Warehouse D

The following example shows the same table in first normal form.

Table 5. Table Conforming to First Normal Form PART (Primary Key) P0010 P0010 P0010 P0020 P0020 WAREHOUSE (Primary Key) Warehouse A Warehouse B Warehouse C Warehouse B Warehouse D QUANTITY 400 543 329 200 278

Second normal form

A table is in second normal form if each column that is not part of the key is dependent upon the entire key. Second normal form is violated when a non-key column is dependent upon part of a composite key, as in the following example: Table 6. Table Violating Second Normal Form PART (Primary Key) P0010 P0010 P0010 P0020 P0020 WAREHOUSE(Primary Key) Warehouse A Warehouse B Warehouse C Warehouse B Warehouse D

QUANTITY

WAREHOUSE_ADDRESS

400 543 329 200 278

1608 New Field Road 4141 Greenway Drive 171 Pine Lane 4141 Greenway Drive 800 Massey Street

The primary key is a composite key, consisting of the PART and the WAREHOUSE columns together. Because the WAREHOUSE_ADDRESS column depends only on the value of WAREHOUSE, the table violates the rule for second normal form. The problems with this design are: The warehouse address is repeated in every record for a part stored in that warehouse. If the address of a warehouse changes, every row referring to a part stored in that warehouse must be updated. Because of this redundancy, the data might become inconsistent, with different records showing different addresses for the same warehouse.

If at some time there are no parts stored in a warehouse, there might not be a row in which to record the warehouse address.

The solution is to split the table into the following two tables: Table 7. PART_STOCK Table Conforming to Second Normal Form PART (Primary Key) P0010 P0010 P0010 P0020 P0020 WAREHOUSE (Primary Key) Warehouse A Warehouse B Warehouse C Warehouse B Warehouse D QUANTITY 400 543 329 200 278

Table 8. WAREHOUSE Table Conforms to Second Normal Form WAREHOUSE (Primary Key) Warehouse A Warehouse B Warehouse C Warehouse D WAREHOUSE_ADDRESS 1608 New Field Road 4141 Greenway Drive 171 Pine Lane 800 Massey Street

There is a performance consideration in having the two tables in second normal form. Applications that produce reports on the location of parts must join both tables to retrieve the relevant information.

Third normal form

A table is in third normal form if each non-key column is independent of other non-key columns, and is dependent only on the key. The first table in the following example contains the columns EMPNO and WORKDEPT. Suppose a column DEPTNAME is added (see Table 10). The new column depends on WORKDEPT, but the primary key is EMPNO. The table now violates third normal form. Changing DEPTNAME for a single employee, John Parker, does not change the department name for other employees in that department. There are now two different department names used for department number E11. The inconsistency that results is shown in the updated version of the table. Table 9. Unnormalized EMPLOYEE_DEPARTMENT Table Before Update

EMPNO (Primary Key) 000290

FIRSTNAME

LASTNAME

WORKDEPT

DEPTNAME

John

Parker

E11

Operations Software Support Operations

000320

Ramlal

Mehta

E21

000310

Maude

Setright

E11

Table 10. Unnormalized EMPLOYEE_DEPARTMENT Table After Update Information in the table has become inconsistent. EMPNO (Primary Key)

FIRSTNAME

LASTNAME

WORKDEPT

DEPTNAME

000290

John

Parker

E11

Installation Mgmt Software Support Operations

000320

Ramlal

Mehta

E21

000310

Maude

Setright

E11

The table can be normalized by creating a new table, with columns for WORKDEPT and DEPTNAME. An update like changing a department name is now much easier; only the new table needs to be updated. An SQL query that returns the department name along with the employee name is more complex to write, because it requires joining the two tables. It will probably also take longer to run than a query on a single table. Additional storage space is required, because the WORKDEPT column must appear in both tables. The following tables are defined as a result of normalization: Table 11. EMPLOYEE Table After Normalizing the EMPLOYEE_DEPARTMENT Table EMPNO (Primary Key) 000290 000320 000310

FIRSTNAME

LASTNAME

WORKDEPT

John Ramlal Maude

Parker Mehta Setright

E11 E21 E11

Table 12. DEPARTMENT Table After Normalizing the EMPLOYEE_DEPARTMENT Table DEPTNO (Primary Key) DEPTNAME

Table 12. DEPARTMENT Table After Normalizing the EMPLOYEE_DEPARTMENT Table DEPTNO (Primary Key) E11 E21 DEPTNAME Operations Software Support

Fourth normal form

A table is in fourth normal form if no row contains two or more independent multi-valued facts about an entity. Consider these entities: employees, skills, and languages. An employee can have several skills and know several languages. There are two relationships, one between employees and skills, and one between employees and languages. A table is not in fourth normal form if it represents both relationships, as in the following example: Table 13. Table Violating Fourth Normal Form EMPNO (Primary Key) 000130 000130 000130 000130 000130 000130 SKILL (Primary Key) Data Modelling Database Design Application Design Data Modelling Database Design Application Design LANGUAGE (Primary Key) English English English Spanish Spanish Spanish

Instead, the relationships should be represented in two tables: Table 14. EMPLOYEE_SKILL Table Conforming to Fourth Normal Form EMPNO (Primary Key) 000130 000130 000130 SKILL (Primary Key) Data Modelling Database Design Application Design

Table 15. EMPLOYEE_LANGUAGE Table Conforming to Fourth Normal Form EMPNO (Primary Key) 000130 000130 LANGUAGE (Primary Key) English Spanish

If, however, the attributes are interdependent (that is, the employee applies certain languages only to certain skills), the table should not be split. A good strategy when designing a database is to arrange all data in tables that are in fourth normal form, and then to decide whether the results give you an acceptable level of performance. If they do not, you can rearrange the data in tables that are in third normal form, and then reassess performance. Concept topic This topic is part of: Administration Guide: Planning

Feedback Last updated 2006-10-27 http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.admin.doc/do c/c0004752.htm