Database Design Using Normalization - Database Processing: Fundamentals, Design, and Implementation - page 166

For several reasons, normalization is seldom an advantage for a read-only database.
For one, if a database is never updated, then no modification anomalies can occur. Hence,
considering Figure 4-2, the only reason to normalize a read-only database is to reduce data
duplication. However, with no update activity, there is no risk of data integrity problems, so
the only remaining reason to avoid duplicated data is to save file space.
Today, however, file space is exceedingly cheap, nearly free. So unless the database is enor-
mous, the cost of storage is minimal. It is true that the DBMS will take longer to find and process
data in large tables, so data might be normalized to speed up processing. But even that advan-
tage is not clear-cut. If data are normalized, then data from two or more tables may need to be
read, and the time required for the join may overwhelm the time savings of searching in small
tables. In almost all cases, normalization of the tables in a read-only database is a bad idea.

Denormalization
Often the data for a read-only database are extracted from operational databases. Because
such databases are updatable, they are probably normalized. Hence, you will likely receive the
extracted data in normalized form. In fact, if you have a choice, ask for normalized data. For
one, normalized data are smaller in size and can be transmitted to you more quickly. Also, if
the data are normalized, it will be easier for you to reformat the data for your particular needs.
According to the last section, you probably do not want to leave the data in normalized
form for a read-only database. If that is the case, you will need to denormalize , or join, the
data prior to storage.
Consider the example in Figure 4-5. This is a copy of the normalized STUDENT, ACTIVITY,
and PAYMENT data in Figure 3-18. Suppose that you are creating a read-only database that will be
used to report amounts due for student activity payments. If you store the data in this three-table
form, every time someone needs to compare AmountPaid with ActivityFee, he or she must join
the three tables together. To do this, that person will need to know how to write a three-table join,
and the DBMS will need to perform the join every time the report is prepared.

STUDENT

Figure 4-5
The Normalized STUDENT,
ACTIVITY, and PAYMENT
Relations

ACTIVITY

PAYMENT