Databases Reference
In-Depth Information
number of summarization instances by any number of orders of
magnitude, any discussion about introducing temporality into
data mart dimensions will have to pay close attention to this
potentially overwhelming issue.
Slowly Changing Dimensions
The second development, slowly changing dimensions
(SCDs), provides a limited solution to part of the problem that
bi-temporality addresses, but it is a solution that we believe has
confused and continues to confuse the majority of IT practitioners
about what bi-temporal data management really is. All too often,
when we begin to present bi-temporal concepts, we hear “But
Ralph Kimball solved all that with his slowly changing dimensions.”
A new idea is unlikely to attract much attention if its audience
believes it addresses a problem that has already been solved.
Some clarification is needed, and we hope that, by the end of
this topic, we will have provided enough clarification to disabuse
most IT professionals of that mistaken notion.
But here, we can make two brief points. First of all, SCDs are
uni-temporal, not bi-temporal. They do not distinguish changes
from corrections.
Moreover, SCDs put much of the semantic burden of access-
ing temporal data directly on the end user. She is the one who
has to know where to look for a specific temporal version of an
instance of a dimension. Is it in a different row in the dimension
table? If so, which one? If a date column distinguishes them,
which date column is it? Or perhaps the temporally distinct
instances are to be found in different columns in the same row.
If there are several of them, which column is the one she wants?
Of course, there may exist developer-written code which
translates the user's request into physical access to physical rows
and columns within the dimension. Perhaps, as should be the
case, all the user has to specify, for example, is that she wants,
in the product dimension, a specific sku and, for that sku, the
description in effect on a specific date.
This is an improvement. But all it really does is move the
semantic burden from the end user to the developer and her
hand-written code. It is like the days long ago when assembler
programmers, about to update a set of records in memory, had
to load a starting address in one register, the row length of the
records in another register, the number of records in the set in a
third register, and then code a loop through the set of records
by updating each record, adding the record length to the current
memory location and thus moving on to the next record.
