In fact, there is more than one type of normalization. Each step in the normalization process ends with a specific result called anormalized form. There are five standard normalized forms, which are referred to as first normal form (1NF), second normal form (2NF), and so on. The normalization process that we describe briefly in this sec-tion results in third normal form (3NF), the most common type of normalizasec-tion.
Explaining the complete concepts that lie behind the different normal forms is beyond the scope of this chapter and book.
Data Design | 103 1. Identify the objects your application needs to know (the entities). Examples of
entities, as shown in Figure 4-3, include employees, locations, and jobs.
2. Identify the individual pieces of data, referred to by data modelers as attributes, for these entities. In Figure 4-3, employee name and salary are attributes. Typi-cally, entities correspond to tables and attributes correspond to columns.
3. As a potential last step in the process, identifyrelationshipsbetween the entities based on your business. These relationships are implemented in the database schema through the use of a combination known as aforeign key. For example, the primary key of the DEPARTMENT NUMBER table would be a foreign key column in the EMPLOYEE NAME table used to identify the DEPARTMENT NUMBER in which an employee works. A foreign key is a type of constraint;
constraints are discussed later in this chapter.
Normalization provides benefits by avoiding storage of redundant data. Storing the department in every employee record not only would waste space but also would lead to a data maintenance issue. If the department name changed, you would have to update every employee record, even though no employees had actually changed departments. By normalizing the department data into a table and simply pointing to the appropriate row from the employee rows, youavoid both duplication of data and this type of problem.
Normalization also reduces the amount of data that any one row in a table contains.
The less data in a row, the less I/O is needed to retrieve it, which helps to avoid this performance bottleneck. In addition, the smaller the size of a row, the more rows are retrieved per data block, which increases the likelihood that more than one desired row will be retrieved in a single I/O operation. And the smaller the row, the more rows will be kept in Oracle’s system buffers, which also increases the likelihood that a row will be available in memory when it’s needed, thereby avoiding the need for any disk I/O at all.
Finally, the process of normalization includes the creation of foreign key relation-ships and other data constraints. These relationrelation-ships build a level of data integrity directly into your database design.
Figure 4-3 shows a simple list of attributes grouped into entities and linked by a for-eign key relationship.
104 | Chapter 4: Oracle Data Structures
However, there is an even more important reason to go through the process of designing a normalized database. Youcan benefit from normalization because of the planning process that normalizing a data design entails. By really thinking about the way the intended applications use data, you get a much clearer picture of the needs the system is designed to serve. This understanding leads to a much more focused database and application.
Gaining a deep understanding of the way your data will be used also helps with your other design tasks. For instance, once you’ve completed an optimal logical database design, youmust go back and consider what indexes youshould add to improve the anticipated performance of the database and whether youshould designate any tables as part of a cluster or hash cluster.
Since adding these types of performance-enhancing data structures doesn’t affect the logical representation of the database, youcan always make these types of modifica-tions later when yousee the way an application uses the database in test mode or in production.
Constraints
Aconstraint enforces certain aspects of data integrity within a database. When you add a constraint to a particular column, Oracle automatically ensures that data vio-lating that constraint is never accepted. If a user attempts to write data that violates a constraint, Oracle returns an error for the offending SQL statement.
Constraints may be associated with columns when you create or add the table con-taining the column (via a number of keywords) or after the table has been created with the SQL command ALTER TABLE. Since Oracle8, the following constraint types are supported:
NOT NULL
Youcan designate any column as NOT NULL. If any SQL operation leaves a NULL value in a column with a NOT NULL constraint, Oracle returns an error for the statement.
Unique
When you designate a column or set of columns as unique, users cannot add val-ues that already exist in another row in the table for those columns, or modify existing values to match other values in the column.
The unique constraint is implemented by the creation of an index, which requires a unique value. If you include more than one column as part of a unique key, you will create a single index that will include all the columns in the unique key. If an index already exists for this purpose, Oracle will automatically use that index.
Constraints | 105 If a column is unique but allows NULL values, any number of rows can have a NULL value, because the NULL indicates the absence of a value. To require a truly unique value for a column in every row, the column should be both unique and NOT NULL.
Primary key
Each table can have, at most, a single primary key constraint. The primary key may consist of more than one column in a table.
The primary key constraint forces each primary key to have a unique value. It enforces both the unique constraint and the NOT NULL constraint. A primary key constraint will create a unique index, if one doesn’t already exist for the specified column(s).