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