Database Reference
In-Depth Information
Finally, before I leave the topic of Attributes, pay close attention to the issue of the
Implied Share of the top level of an attribute dimension. most cubes are designed such
that every base member is
supposed
to be given an attribute association. When this is not
done, it is often because of a failure in the metadata build process. For instance, returning
to our auto manufacturer example, a new color option was added, but was not included
in the metadata, so the new Skus that were created were not able to associate to this new
color and, therefore, have no color. two problems result from this situation: (1) queries
against [All Colors] will yield the wrong results (as they do not have a color), and (2) que-
ries against [All Colors] and some other Attribute will be slow. This second situation arises
because in the original case (before the addition of the “bad” unassociated Sku) where
every level-0 member of the base dimension is in the primary hierarchy and every one
of those level-0 members has an association to the [All Colors] dimension, [All Colors]
becomes an implied shared alias of the top member of the base dimension primary hier-
archy. As such, a query against [All Colors] and any other attribute of the base dimension
is not really a query against “two Attribute Dimensions” and, therefore, performed well.
now consider the same query against [All Colors] and some other base dimension
attribute after the addition of the “bad” (no color attribute) Sku. The member [All
Colors] is no longer an implied share, so now the query
really is
a two-attribute query
and will perform poorly.
The solution is to make sure that this failure in metadata creation never occurs. I also
refer you to Crisci's Chapter 6
where he defines a query to test for this condition
.
I also
suggest that as a backup, care should be exercised when defining partitions or smart
slices. If an Attribute dimension is to be hidden from a user, then it
should not be refer-
enced
in the smart slice definition. This will avoid exposing users to incorrect results for
an Attribute that they do not even know exists.
Finally, it is a recommended best practice to include in an attribute dimension, such
as [All Colors], a member such as [no Color] to be used as a default color when the color
is unknown.
7.4.3.3 The Compression Dimension
now that you have left BSo, you thought you were
done with Dense and Sparse, but not quite. In BSo, you would tend to group those
dimensions that were commonly queried together as Dense dimensions. Then, starting
in version 5, the “Dynamic Calc” tag added the ability to delay the intra-Dense Block
calculations until retrieval time. The objective became to find the set of dimensions
with the most calculations. As memory became cheaper, the size of the dense block of
data in most designs increased—to save more time during the cube calculation phase.
This was an example of a rule my father (a hardware designer beginning in the late
1940s) taught me when I was 12 years old:
Pop's rule: “Computers do arithmetic very fast, but they don't like to run errands.”
I might not have understood what that really meant when I was 12, but I understood
enough of his explanation to remember the rule (he actually had me write numbers on
slips of paper and put them on a table in the next room). he told me that I was allowed to
retrieve numbers one at a time. Even at 12, I could add faster than I could run; I learned
that lesson quickly. It will always be faster to read two numbers (A and B) from a disk
