Databases Reference
In-Depth Information
coNclusIoN
Figure 11.8, using Simple Instance Keys, and Figure 11.9, using
Compound Instance Keys, display a data warehouse that has a set of
Type 1 “present state” dimension tables, a set of Type 2 “historic state”
dimension tables, and a fact table that joins to both sets of dimension
tables. The Type 1 “present state” dimension tables join via Entity Keys.
The Type 2 “ historic state” dimension tables join via Instance Keys.
The fact and summary tables join via the method indicated by the set
of dimension tables to which they join in an individual query. The
result of these three sets of tables is a data warehouse that can pres-
ent the events and transactions of the enterprise in their present and
historic context.
Conceivably, a d ata warehouse can use a m ixture of Simple and
Compound Instance Keys. In practice, such a m ixture of Simple and
Compound Instance Keys can be very confusing. For that reason, if pos-
sible, a d ata warehouse should be designed using only Simple Instance
Keys or only Compound Instance Keys. If that unilateral design is not an
option, then a naming standard should be adopted to identify the time
variant key of each table. Because every dimension table, including each
Type 1 table and every Type 2 table, will retain its Entity Key and Instance
Key, a table with a Simple Instance Key will look very similar to a table
with a Compound Instance Key. The data warehouse users should not be
required to profile the data in every dimension table to determine its key
structure before using each table. For that reason, the best approach is to
unilaterally use one Instance Key design (either Simple or Compound) or
a naming standard that distinguishes the two from each other.
