See also Guidelines for Using XOLAP.
These guidelines apply to XOLAP functionality:
Alternate hierarchies are supported by Essbase Studio when deploying an Essbase model enabled for XOLAP if the join paths for all chains come from the same set of dimension tables. The following example alternate hierarchies use the TBC database to illustrate.
In the following example, the join path to the fact table comes from the same dimension table.
- PKGTYPE (TBC.PRODUCT) - SKU (TBC.PRODUCT) - OUNCES (TBC.PRODUCT) - SKU_ALIAS (TBC.PRODUCT)
In this case, the join path to the SALES fact table is:
TBC.PRODUCT joins TBC.SALES.
In the following example, the join path to the fact table comes from the same set of dimension tables.
- FAMILY (TBC.FAMILY) - SKU (TBC.PRODUCT) - FAMILYID (TBC.FAMILY) - SKU_ALIAS (TBC.PRODUCT)
In this case, the join path to the SALES fact table is:
TBC.FAMILY joins TBC.PRODUCT joins TBC.SALES.
In the following example, the join path to the fact table comes from different dimension tables.
- UDAMKTTYPE (TBC.MARKET) - STATE (TBC.MARKET) - PKGTYPE (TBC.PRODUCT) - SKU (TBC.PRODUCT)
In this case, the alternate hierarchy scenario is not supported because there are two distinct join paths to the SALES fact table:
1. TBC.MARKET joins TBC.SALES
2. TBC.PRODUCT joins TBC .SALES
In the following example, the join path to the fact table comes from different sets of dimension tables.
- FAMILYID (TBC.FAMILY) - INTRODATE (TBC.PRODUCT) - SKU_ALIAS (TBC.PRODUCTDIM) - CAFFEINATED (TBC.PRODUCT)
In this case, the alternate hierarchy scenario is not supported because there are two distinct join paths to the SALES fact table:
1. TBC.FAMILY joins TBC.PRODUCT joins TBC.SALES
2. TBC.PRODUCTDIM joins TBC.PRODUCT joins TBC .SALES
You may tag a dimension with alternate hierarchies as Multiple Hierarchy Enabled in the Essbase Model Properties dialog box, Outline Build tab).
Essbase Studio can create attribute dimensions in Essbase models enabled for XOLAP; however, attribute dimensions must have only one child level.