Database Reference
In-Depth Information
In the preceding screenshot, we can see an amber warning triangle telling us that
by selecting a non-key attribute, the server may have trouble aggregating measure
values. What does this mean exactly? Let's take a look at the attribute relationships
defined on our
Time
dimension again:
If we're loading data at the
Quarter
level, what do we expect to see at the
Month
and
Date
level? We can only expect to see useful values at the level of the granularity
attribute we've chosen, and for only those attributes whose values can be derived
from that attribute; this is yet another good reason to make sure your attribute
relationships have been optimized. Below the granularity attribute, we've got the
same options regarding what gets displayed as we had with dimensions that have no
relationship at all with a measure group: either repeated values or null values. The
IgnoreUnrelatedDimensions
property is again used to control this behavior.
Unfortunately, the default
True
setting for
IgnoreUnrelatedDimensions
is usually
not the option you want to use in this scenario (users usually prefer to see nulls
below the granularity of a measure in our experience) and this may conflict with how
we want to set
IgnoreUnrelatedDimensions
to control the behavior of dimensions
which have no relationship with a measure group. There are ways of resolving this
conflict such as using MDX Script assignments to set cell values to null or by using
the
ValidMeasure()
MDX function, but none are particularly elegant.
Non-aggregatable measures - a different
approach
We've already seen how we can use parent/child hierarchies to load
non-aggregatable measure values into our cube. However, given the problems
associated with using parent/child hierarchies and knowing what we now know
about measure groups, let's consider a different approach to solving this problem.
Search WWH ::
Custom Search