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