Data at all level do not match after applying security

Question

Hi ,
We are implementing the security and observed following.
1. Data is loaded in the cube correctly and report shows up the data correct at all level.
2. Now we apply the security which which will restricts the users to see some members according to the role they are mapped to.
3. When we create a report we are seeing the values at second and all below level to be correct but the value at all level still shows same as got in step 1.This means that the value is not dynamically aggregated while creating the report.
Also we checked that the values are not precomputed at all level for any dimension.
Any pointers to resolve this?
Thanks in advance.
Thanks
Brijesh

Answer 1

John, A sureshot way to simulate the relational aggregation for various users (who have vpd) applied on the fact information is to create the AW for each user. That way the scoping of dimension hierarchies and/or facts occur on the relational source views and each user only sees the summation of the visible values in the AW. You can use (local) views in each user's schema on the appropriate AW and make the application access seamless across all the user schemas. Such a solution may be a bit redundant (leaf data present in multiple AWs increasing load time) but should work in all environments since it does not involve any tweaking of internal objects via custom olap dml.
+++++++++++++
Regd implementing the approach to have a single AW servicing multiple users but also allow for individual users to see only their data (for both base and summary data).. This can be done in 10gR2. We have used this approach with a 10gR2 AW based on suggestions from people who were in the know :)
Please note the disclaimers/caveats..
* Works for 10gR2 with no foreseeable way to port this onto 11g when olap dml object manipulation is prevented by the lock definition (lockdfn) keyword.
* Custom code needs to be run at startup.. Preferably in PERMIT_READ program alone since this way any changes made by any of the restricted user(s) do not get saved/commited. This is the manner that sql query on AWM using vpd (say) would work.
* OLAP DML Code is very dependent on the nature of the cube structure and stored level setting.
* This approach provides for a neat and nifty solution in the context of a PoC/demo but the solution performs a (possibly exhaustive) cleanup of stored information during the startup program for each user session. And since this happens in the context of a read only session, this would happen every time for all user sessions. So be sure to scope out the extent of cleanup required at startup if you want to make this a comprehensive solution.
*********************** Program pseudo code begin ***********************
" Find out current user details (username, group etc.) using sysinfo
limit all dimensions to members at stored levels
limit dim1 to members that user does *not* have access to.
NOTE: This can lead to perf issues if PROD dimension has thousands or millions of products and current user has access to only a few of them (2-3 say). We will have to reset the stored information for the majority of products. This is undo-ing the effects of the data load (and stored summary information) dynamically at runtime while the users request a report/query.
limit dim1 add descendants using dim1_parentrel
limit dim1 add anscestors using dim1_parentrel
limit dim1 keep members at stored levels alone... use dim1_levelrel appropriately.
same for dim2 if reqd.
"If we want to see runtime summation for stores in North America (only visible info) but see the true or actual data for Europe (say).. then we need to clean up the stored information for stores in North America that the current user does not have access to.
Scenario I: If Cube is uncompressed with a global composite.. only 1 composite for cube
set cube1_meas1_stored = na across cube1_composite
set cube1_meas2_stored = na across cube1_composite
Scenario II: If Cube is uncompressed with multiple composites per measure.. 1 composite per cube measure
set cube1_meas1_stored = na across cube1_meas1_composite
set cube1_meas2_stored = na across cube1_meas2_composite
Scenario III: If Cube is compressed but unpartitioned..
set cube1_meas1_stored = na ... Note: This can set more cells as null than required. Each cell in status (including cells which were combinations without data and did not physically exist in any composite) get created as na. No harm done but more work than required. The composite object may get bloated as a result.
Scenario IV: If Cube is compressed and partitioned..
Find all partitions of the cube
For each partition
Find the <composite object corr to the partiton> for cube
set cube1_meas1_stored = na across <composite object corr to the partiton>
"Regular Permit Read code
cns product
permit read when product.boolean
*********************** Program pseudo code end ***********************
The cube in our aw was uncompressed/partitioned (Scenario I).
It is more complicated if you have multiple stored levels along a dimension (possible for uncompressed cubes) where you apply security at an intermediate level. Ideally, you'll need to reset the values at load/leaf level, overwrite or recalculate the values for members at all higher stored levels based on this change, and then exit the program.
HTH
Shankar