Database Reference
In-Depth Information
The recommended practice for Essbase is to (when possible) create unique member
names in the cubes. It is also a recommended practice, when creating ASo models, to
have as few dynamic dimensions as possible. on your initial deployment of dimension-
ality from Studio, you can violate both of these rules to validate the metadata being sent
to Essbase, as shown in Figure 3.31.
When Studio validates dimension settings and the schema prior to deployment, it
literally validates only those things. Studio does not validate the metadata being sent
to Essbase. If you select unique member names and then try to deploy to Essbase with
duplicate metadata, the deployment fails at the Essbase side, and you need to then start
trouble-shooting to understand why. If you instead allow duplicate members, you can
build all of the dimensionality and validate dimension by dimension in EAS.
Figure 3.32 shows turning off duplicates on a dimension-by-dimension basis after the
duplicate member name enabled cube is deployed.
As long as the outline validates, you know that you do not have a duplicate issue (for
instance) in a given dimension. If you do run into duplicate issues in a dimension, then
Figure 3.31
Duplicate Members enabled.
Figure 3.32
EAS duplicate Member setting.
