Database Reference
In-Depth Information
Note
Although we explicitly secured only the Product Categories hierarchy, the list
of subcategories will also be restricted based on the available categories. If you
browse the Product dimension as the bikes_and_accessories_only role,
you will not see any subcategories for Clothing or Components .
You could define different allowed/denied member sets from each dimension
hierarchy depending on the cube. For example, users might want to see only the
current and future years in the Forecast cube, but they will need to see the
previous years' data in the Actual Values cube. Hence, the option to secure
dimension data at database-dimension or cube-dimension level is available.
You can define allowed/denied members on multiple hierarchies of the same dimen-
sion. For example, you could enter an empty set {} in the allowed member set for
the date attribute of the Date dimension to ensure that users cannot browse data
for individual dates. Additionally, you could also specify a set consisting of [May
2005] and [June 2005] within the denied member set under the Month Name
attribute to restrict users from viewing data for these months.
You can secure the measures as you can for any cube dimension; look for measures
dimension under each cube within the Dimension drop-down box. Unfortunately,
we don't have an easy way of hiding calculated measures. If you prefer not to expose
a calculation for browsing, you can remove it from a particular perspective. However,
keep in mind that perspectives are not a security mechanism and, hence, a savvy
user could still access the calculation by referencing it explicitly in MDX queries.
Tip
Yet another alternative is to define a regular measure with its value always set to
NULL or zero and then use a SCOPE statement to overwrite the measure with a
calculation. This way you will have a calculation exposed as a regular measure
that could be secured.
Search WWH ::




Custom Search