Building Basic Dimensions and Cubes - Expert Cube Development with SSAS Multidimensional Models - page 50

The benefits of doing this are:

• Certain MDX functions such as YTD() are time aware , and will not need you

to specify certain parameters if you have a dimension marked as type Time

• Semi-additive measures, that is, those with their AggegationFunction

set to AverageOfChildren , FirstChild , LastChild , FirstNonEmpty ,or
LastNonEmpty , will perform their special types of aggregation on the first
Time dimension related to a measure group

Creating user hierarchies
User hierarchies, the multilevel hierarchies that you create in the central Hierarchies
pane in the Dimension Editor, can best be described as being something like
views on top of attribute hierarchies. They allow you to take two or more attribute
hierarchies and combine them into a more complex drillpath. For example, you
could take your Year , Month , and Date attributes and combine them into a single
hierarchy with Year , Month , and Date levels, so that the user could then easily drill
from a year down to see all the months in that year and from a month down to all the
dates in that month.

When Analysis Services 2005 was first released and developers started coming to
grips with the concept of attribute hierarchies and user hierarchies, one question
that came up quite frequently was, "Should I expose attribute hierarchies or user
hierarchies to my users?". As usual, the answer is that it depends. There are pros and
cons to each and you'll probably end up using a mixture of both types of hierarchy.
User hierarchies are more user-friendly because drilling down is just a matter of a
double-click. On the other hand, rigidly defined drillpaths might be too limiting,
and users might prefer the flexibility of being able to arrange attribute hierarchies
whichever way they want. Certainly there are some things you can't do with user
hierarchies, such as putting different levels of the same hierarchy on different axes
in a query. For you as a developer, user hierarchies have some benefits. They make
writing the MDX for certain types of calculation easier (members in a multilevel user
hierarchy have meaningful "parents" and "children"), and "natural" user hierarchies,
which we'll talk about next, are materialized on disk and so offer query performance
benefits and also make the aggregation design process much easier.

If you do create a user hierarchy, you should definitely set the Visible property
of its constituent attribute hierarchies to False . If you have too many hierarchies
available for a user to choose from in a dimension, you run the risk of confusing the
user, and having the same members appear more than once in attribute hierarchies
and user hierarchies will make matters worse. Simplicity is a virtue when it comes to
dimension design.