Database Reference
In-Depth Information
where the member [Stored member] makes its first (and only) appearance in the out-
line in the hierarchy [high End merchandise]. If you do reorganizations with the data
still in the cube and find your restructures either failing or running inordinately long,
you should test to measure the impact and consider alternatives, such as clearing and
reloading the data, or rethinking your hierarchies to see if the
[DBAg 5]
situation can be
eliminated.
By the way, the
[DBAg 5]
issue can come up when not expected. Suppose you had a
first hierarchy that had 100% of the level-0 members in it and all of the alternates
had a subset of those level-0 members appearing as shared. I have seen cases where
the longest hierarchy (the primary, i.e., the one that determines the bitmap length)
is not this first 100% hierarchy. This type of a situation would occur if an alternate
hierarchy had many more levels than the first. now, if it also has 100% of the level-0
members
and no additional new (nonshared)
members, then there would be no issue.
It would simply become the primary and there would be no nonshared members in
any of the alternates. If it had, say, only 90% of the level-0 members found in the first
hierarchy and a much more detailed set of levels above them than the first hierarchy,
a 90% hierarchy could have a longer bitmap. It would become the primary hierarchy,
and the first hierarchy with its now newly identified 10% would become the second-
ary. Thus, you may expectantly end up with the situation described in the preceding
paragraph.
7.4.3.2 Attribute Dimensions
Attribute dimensions are a powerful tool to use in
your design. unlike a standard alternate hierarchy, they can be used to create a cross-
tab query. using ASosamp as an example, you could generate a report of unit sales
by size, with the products on the rows and the sizes as column headings. If size was
instead modeled as an alternate hierarchy, there would be a [Size] Stored hierarchy
added to the [Product] dimension with the different size classifications appearing
as children of [Size] and the level-0 product members appearing as shared mem-
bers under the appropriate size classification. however, this design would not allow
a cross-tab report of the type described above because it would require members
of the same dimension, [Products], to appear as both row headings and as column
headings.
Therefore, designing your cube with [Size] as an attribute seems the way to go. of
course, you also could make [Size] its own Stored dimension, but then you would have
to add size information to your data load and you would have an increase in the size
of the bitmap. unlike BSo, Attribute dimensions are
not
always calculated dynami-
cally and, therefore do not have the performance penalties they had in BSo. It is not
explicitly stated anywhere, but all
Attribute dimensions are Stored hierarchies
. In fact,
it is stated that
Attribute dimensions are regarded as alternate hierarchies of the base
hierarchy
. now this seems confusing. In the above paragraph, I described alterna-
tive cube designs for [Size], modeling it first as an alternate hierarchy and then as an
Attribute dimension. I then showed that there were advantages to designing [Size] as
an Attribute dimension. But, now I state that Attribute dimensions are regarded as
alternate hierarchies anyway. This confusion stems from the use of the word
regarded.
From the point of view of the bitmap, they are alternates and as alternates are repre-
sented in the bitmap within the same set of bits reserved for the base dimension. It is a
confusing description. maybe Attribute dimensions should be described as “internally
de facto alternate hierarchies,” but that is not a distinction the documentation makes,
