Designing Relational Databases - High-Performance Web Databases: Design, Development, and Deployment - page 403

tables. The result is a database design in which the tables no longer corre-
spond in a one-to-one manner to the entities of your logical data model.

The most active properties in Ron's Real Estate Business, for example,
are his beach properties. Thus when Ron needs information about proper-
ties, he usually joins the PROPERTY table with the BEACH-PROPERTY
table. As his business grows and the number of properties increases, he
discovers that performance of this join degrades in spite of placing indexes
on foreign keys and storing rows in foreign-key sequence. A designer may
decide to combine the PROPERTY table with the BEACH-PROPERTY table
to avoid this join because the only reason to join these tables is to deter-
mine how far the properties are from the beach. The resulting PROPERTY
table would have five columns instead of four and the BEACH-PROPERTY
table would no longer exist.

However, there are some negative implications of this action. Specifi-
cally, the PROPERTY table would become larger (i.e., it would include one
more column for each row). Combining these two tables would increase
the occurrences of nulls, because rows representing mountain properties
have no value for the new attribute NUMBER-BLKS-OFF-BEACH. The rela-
tional database would no longer be consistent with the logical data model,
which has five entities but four tables. Enforcement of business rules per-
taining to property deletions would be more complex in that deleting a
beach property requires a deletion of only the PROPERTY table, whereas
deleting a mountain property requires the deletion of both the PROPERTY
and the MOUNTAIN-PROPERTY tables. Users would have to recode existing
commands that reference the BEACH-PROPERTY table so that the com-
mands refer to the PROPERTY table. Exhibit 3 depicts all 13 steps in the
relational database design process.

CRITICAL SUCCESS FACTORS FOR A RELATIONAL DATABASE DESIGN
METHODOLOGY

There are many ways to go about designing relational databases in addi-
tion to the steps described in this chapter. At the very least, a designer will
want to supplement these steps with product-specific techniques for the
environment and with other practical tips learned through experience.

In applying, developing, or adapting a relational database design meth-
odology, it is important to ensure that the design approach:

• Provides a step-by-step procedure. The design methodology should in-

clude guidelines to assist a novice designer and should supplement
them with organizational standards addressing naming conventions,
documentation, and resource utilization. It should also provide a list
of contacts for education and support.