Databases Reference
In-Depth Information
warehouse will be able to guarantee that summaries of transactions by
calendar groupings and business cycle groupings do not experience date-
based anomalies. So, before joining any transactions to dates, first validate
the referential integrity of all the time-based tables. Each date should join
to one and only one month, each month should join to one and only one
quarter, each quarter should join to one and only one year, and so on. In
that way, each moment in time directly joins with one and only one mem-
ber of each hierarchical grouping.
rAlPh kImBAll's vArIAtIoNs of tIme vArIANce
Ralph Kimball, one of the pioneers of data warehousing, designed three
variations of Time Variant data. They each have their application in deci-
sion support. A data warehouse may include all three or only one of these
variations. Regardless, the designers of a data warehouse should under-
stand all three to make an educated decision whether to include them.
type 1—All history looks like Now
Type 1 Time Variant data is actually invariant. That is to say, the enter-
prise objects and their properties or attributes do not vary as time changes.
Instead, all the history of the enterprise looks exactly like the enterprise
looks right now. Even if you know that some aspects of the enterprise have
changed, as far as Type 1 Time Variant data is concerned, nothing has ever
changed. The enterprise has always been exactly as it is now.
After so much discussion of Time Variant data, including the price of
gasoline and replenishment cycles, you might find the concept of Type 1
Time Variant data to be a bit curious, if not completely useless. To the con-
trary, Type 1 Time Variant data is indeed useful because not all decisions
are made based on the objects and their properties or attributes in effect
as of a moment in time. Many decisions in an enterprise are based on the
current state of the enterprise. For those decisions, a data warehouse can
consume significantly fewer resources by presenting the enterprise only
in its current state. Rather than expend the resources necessary to join
each and every transaction to the enterprise objects and their properties
or attributes in effect at the moment of the transaction, a data warehouse
can join all the transactions to the current set of enterprise objects and
