Tips for working with ragged or unbalanced hierarchies
In ragged or unbalanced hierarchies, some members
that are not at the lowest level of the hierarchy may have no descendants
at one or more lower levels. Support for these hierarchy gaps in relational
data sources is limited. More complete support is provided for OLAP
data sources, but some reports may still result in unexpected behavior.
For example, the following may occur:
- Groups corresponding to missing members may appear or disappear
when grouped list reports are pivoted to a crosstab. This happens
with set expressions using the
filter
function, and detail filters on members. - Ragged and unbalanced sections of the hierarchy are suppressed when set expressions in that hierarchy are used on an edge.
- When a crosstab is sectioned or is split into a master detail report, sections corresponding to missing members become empty.
- Cells that were suppressed may still appear in the report output for reports with ragged or unbalanced hierarchies.
Some of these behaviors may be corrected in a future release, while others may be codified as supported behavior. To avoid these behaviors, do not use levels from ragged or unbalanced hierarchies. Instead of using levels, use the descendants, children, or ancestors.
We consider the following scenarios to be safe:
- One or more nested level references on an edge with no modifying expression.
- A hierarchy reference on only one level of one edge.
- One or more explicit members or sets of explicit members as siblings on only one level of one edge.
- Summaries of the previous three scenarios.
In all cases, you should test reports based on ragged and unbalanced hierarchies to confirm that hierarchy gaps are handled correctly.
For more information about ragged or unbalanced hierarchies, see the IBM® Cognos® Framework Manager User Guide.