The Data Warehouse Development Life Cycle
Oracle Data Warehouse Design
DE-NORMALIZING ONE-TO-MANY DATA RELATIONSHIPS
With Oracle and the rule-based optimizer, this type
of complex join guarantees that at least one table is read front to
back using a full-table scan. This is a shortcoming of Oracle’s
rule-based optimizer because an SQL optimizer should always avoid a
full-table scan whenever indexes are present--and full-table scans
are very expensive. This situation might be avoided by using Oracle
hints with the cost-based optimizer to determine the optimal path to
this data. A hint is an extension of Oracle’s SQL that directs the
SQL optimizer to change its normal access path. For more detailed
information on optimizing full-table scans and using hints, refer to
Chapter 13, Tuning Oracle SQL.
What if your goal is to simplify the data structure by removing
several of the one-to-many relationships? Adding redundancy imposes
two requirements. You need additional space for the redundant item,
and you need a technique to update the redundant item if it changes.
One solution is to build a table of columns that rolls the CITY and
STATE tables into the CUSTOMER table. For example, Table 4.1 assumes
that the STATE table contains 50 rows, the CITY table contains 2,000
rows, and the CUSTOMER table contains 10,000 rows.
Table 4.1 Redundancy matrix to determine optimal normalization.
Column
Size
Duplication
Total Space
Change
state_bird 10
10,000
100,000
Rare
state_flower 10
10,000
100,000
Rare
region_name 2
10,000
20,000
Never
cost_of_living 8
10,000
80,000
Quarterly
city_mascot 10
10,000
100,000
Rare
In Table 4.1, you can see that the CITY and STATE tables can be
removed entirely for a total savings of 400,000 bytes (see Figure
4.4).
Figure 4.4 De-normalized E/R model sales database.