Database Reference
In-Depth Information
Using folders
The two sets of attributes we have described for a Type III dimension,
Current and Previous , are good candidates for being grouped
together in folders using the AttributeHierarchyDisplayFolder
property. Folders can be an important way of improving the usability
of dimensions with large numbers of attribute and user hierarchies.
Modeling junk dimensions
As we've already seen, junk dimensions are built from groups of attributes that don't
belong on any other dimension, generally columns from fact tables that represent
flags or status indicators. When designing an Analysis Services solution, it can be
quite tempting to turn each of these columns into their own dimension, having just
one attribute, but from a manageability and usability point of view, creating a single
junk dimension is preferable to cluttering up your cube with lots of rarely-used
dimensions. Creating a junk dimension can be important for query performance too.
Typically, when creating a junk dimension, we create a dimension table containing
only the combinations of attribute values that actually exist in the fact table—usually
a much smaller number of combinations than the theoretical maximum, because there
are often dependencies between these attributes, and knowing these combinations in
advance can greatly improve the performance of MDX queries that display more than
one of these attributes cross-joined together.
As with a Type II SCD, when building an Analysis Services dimension from a junk
dimension table we will create a key attribute based on the surrogate key of the
dimension, which we can then hide by setting AttributeHierarchyVisible to
False . All other attributes on the dimension can be directly related to this attribute,
unless of course we can be 100 percent certain that attribute relationships can be
defined between other attributes. The attribute relationships might look something
like the following:
 
Search WWH ::




Custom Search