Quantcast
Channel: SQL Server Analysis Services forum
Viewing all articles
Browse latest Browse all 14337

SSAS - dimension security defined on multiple attribute hiearchies building the levels of user defined hiearchy

$
0
0

Hello all

I need to define dynamic dimension security on an Organization dimension

Our Organization dimension has three user defined hierarchies: Geography, Management, Service

The access right of a specific user is defined as the combination of members from three attribute hierarchies (one from each user-defined hierarchy).

Management                        Geography                          Service

ManagementLevel1             GeographyLevel1                ServiceLevel1  

ManagementLevel2             GeographyLevel2                ....

ManagementLevel3             GeographyLevel3

....                                        ....

Say for example User1 has access to:

-  members(a,b) from AttributeHierarchy of Level3 of Geography

- member(c) from AttributeHierarchy of Level2 of Management

- member(d,e) from AttributeHierarchy of Level2 of Service

User2 has access to

-  members(f,g) from AttributeHierarchy of Level5 of Geography

- member(h) from AttributeHierarchy of Level4 of Management

- member(i,j) from AttributeHierarchy of Level2 of Service

Until now to set dimension security we used the attribute hierarchies corresponding to the lowest level across users to set dimension security

This would mean in the above example

AttributeHierarchy corresponding to level 5 of Geography

AttributeHierarchy corresponding to level 4 of Management

AttributeHierarchy corresponding to level 2 of Service

We have three bridge table which map users with their corresponding allowed members.

With this methodology we are obliged to derive all the corresponding members at the level where security is defined. Additionally we can only benefit from aggregation that are bellow or on the same level as security.

As you can imagine we experience performance problems.

The idea arose that maybe we could define security at several levels, so that each user comes in at the highest possible level (we could then benefit from more aggregations).

This would oblige us to create one bridge table per level.

The problem with that method is that each level where security is defined must return members for a particular user. If we start to populated the security bridge table of each level for each user we will end up with an even worse solution in my opinion.

I think that it could only be beneficial if we define security at one place (e.g. highest possible level) per user.

If we create an entry only in the bridge table of the highest possible level then the dynamic security expression of lower levels will return an empty set

Example:

If a user is allowed to see a whole subarea (several countries) and we create entries in the subarea bridge table then we will be fine with the members returned from the dynamic expression defined on the AttributeHierarchy Subarea
If we do not create any entries at the country level the security expression will return an empty set. Like this we will end up with no access rights.

Is there a way to make SSAS understand that the highest is what we need? What should one do under those circumstances?

Another possibility would be to create additional roles (one per level combination). Users would be given access right just over one role


Viewing all articles
Browse latest Browse all 14337

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>