dbTalk Databases Forums  

Allowed/Denied set inheritence to Cube Dimensions

microsoft.public.sqlserver.olap microsoft.public.sqlserver.olap


Discuss Allowed/Denied set inheritence to Cube Dimensions in the microsoft.public.sqlserver.olap forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Greg Fodor
 
Posts: n/a

Default Allowed/Denied set inheritence to Cube Dimensions - 02-08-2006 , 12:38 AM






I'm running into some problems with the behavior of allowed & denied set
inheritance from Dimension to Cube Dimensions.

I have a simple attribute named ClientID on the User dimension inside of
my database. The User dimension is bound to the User Cube more than
once, for example as "Assigned To User" and "Created By User".

I want to define a role that will allow its members to see only Users
within a certain client (across all the Cube Dimensions.) I tried
defining the Allowed Set to be:

[ClientID].&[123]

where 123 is the client who things should be filtered for the role.

(Note: If I change leave to be "[Users].[ClientID].&[123]" as per the
cube editors's suggestion, I get an error saying that the [Users]
attribute hierarchy cannot be found in the Cube.)

I applied this permission grant on the Users Dimension, but when I try
to browse the data I get an exception saying the "ClientID attribute in
the Assigned To User Dimension has a generated dimension security
expression that is not valid."

So what it seems like to me is that the allowed set "[ClientID].&[123]"
when applied to the CubeDimensions can not be evaluated correctly for
some reason. If I remove this allowed set and then add two new allowed
sets on the cube dimensions:

[Assigned To User].[ClientID].&[123]

to the Assigned To User Cube Dimension, and

[Created By User].[ClientID].&[123]

to the Created By User Cube Dimension, things work fine.

I'm betting there is probably some performance gain by putting this
allowed set on the Dimension level instead of the Cube Dimension level.
Is there some tricky MDX I can do to make sure that the allowed set on
the Dimension level will successfully evaluate to the correct ClientID
member, regardless of what Cube Dimension it is being evaluated for? Is
this some limitation in the security system in that if a certain
dimension is bound more than once then the allowed set inheritance
behavior stops functioning correctly?

I am generating all this stuff programatically, so how I do it does not
really matter so much from a maintenance perspective but I am mainly
concerned about performance. Does SSAS internally compute a 'replica
dimension' for permission checks at the CubeDimension level regardless
if the allowed/denied sets are specified at the Dimension level instead?
Or, does specifying the sets at the Dimension level result in some
performance gains?

Thanks for any help you can give,

-Greg

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.