SSAS dimension data restriction by role advanced denied member rule - sql-server-2012

I have a Plant dimension used with multiple SSAS cube MOLAP measure groups which has 1000's of members in the dimension, each have a related region id property of 1,2,3 or 4.
The dimension is related to the measure groups by both region id & plant code, when I deselect all members for the Region Id property in the role's Dimension Data Tab and select only a few of them I end up with the below MDX in the advanced tab:
{[Plant].[Region Id].&[1]&[1001], [Plant].[Region Id].&[1]&[1002]}
This MDX is showing both the region id and plant code.
The dimension data changes each week and the members will change, I do not want to select 1000s of members to restrict these plants by Region Id for a security role, especially when these will change over time.
How can I apply a rule to restrict this data by the Region Id i.e. RegionId LIKE 1?

Related

Performance consideration and design a dimension that partition a cube

As we know When a cube is built, tuples are created by dimensions and some aggregations applied. Know I faced with a special type of dimension that it's members aren't collectable. For example please consider actor type dimension:
Code Desc
----------------------------------
1 Vendor
2 Employee
3 Unemployed
The point is that I never want to aggregation for Vendor or Employee or Vendor or Employee or Unemployed. My problem is just about comparing these items with together. I only want to compare Vendor with Employee or Employee with Unemployed. So I think in cube there are some aggregations that I don't need to them.
Is there any way to handle this dimension? Is there any dimension type?
Thanks
For the beginning you don't need ALL member in attribute hierarchy, so you could set IsAggregatable property to false.
But, this will not prevent aggregation if you select for example two members (Employee and Vendor) in the filter. For this purpose you will need some kind of scope assignment against your dimension.

SSAS Dimension Sorting While Browsing In Excel

I have a SSAS cube which I browse in Excel, The problem is order of dimension. I Have a dimension named accounts which has hierarchy to show list of accounts, but excel shows accounts in alphabetical order based on there name, while I want them to be displayed based on the key field that is AccountID.
Further If I share this cube in Power BI as a dataset, and let users connect this dataset through Excel, can control the order of sorting while browsing the same in excel.
Are you talking about the order of attributes in the dimension?
AccountID AccountName
1 Credit
2 Automobile
3 Lease
Your current order is Automobile, Credit, Lease but you want it as depicted in the table?
If so you need to set the "order by" attribute in the individual attributes to "Key" instead of "Name", with Key being AccountID and Name being AccountName.
(In SSDT: Rightclick the dimension attribute -> Properties, the 10th entry or so)

SSAS - relationship/granularity

I have 2 fact tables with a measure group each, Production and Production Orders. Production has production information at a lower granularity (at the component level) productionorders has information at a higher level (order level with header quantities etc.).
I have created a surrogate key link between the two tables on productionorderid. As soon as I add Prod ID (from productiondetailsdim) to the pivot table it blats out the actual qty (from prod order measure group) and I cannot combine the qty's from the two measure groups.
How can I design the correct relationship between the two? Please see my dim usage diagram. Production Details is the dim that links the two fact tables, at the moment DimProductionDetails is in a fact relationship with Production. I'm not sure what the relationship should be with Production Order (it is currently many to many).
Please see example data between the two tables:
I have to be able to duplicate this behaviour:
Do you want the full actual qty from prod order measure group to repeat next to each product? If so a many-to-many relationship is right. I suspect once I explain how that many-to-many works you will spot the problem.
When you slice full actual qty from prod order measure group by product from the Production Details dimension it does a runtime join between the two measure groups on the common dimensions. So for example, if for if order 245295 has a date of 1/1/2015 while the production details for order 245295 have dates of 1/8/2015 then the runtime join will lose rows for that order and actual qty will show as null. So compare all the dimensions used on both measure groups and ensure all rows for the same order have the same dimension keys for those common dimensions. If for example dates differ then create a named query in the DSV that selects just the dimension columns from the production fact table which match the order fact table. Then create a new measure group off that named query and use the new measure group as the intermediate measure group in your many to many dimension. (The current many to many cell in the dimension usage tab should say the name of the new measure group not the existing Production measure group.)
Edit: if you want the actual qty measure to only show when you are at the order level and be null at the product level then try the following. Change the many-to-many relationship to a regular relationship and in the dialog where you choose how the fact table joins to the dimension change the dimension attribute to ProductionOrder_SK (which is not the key of the dimension) and choose the corresponding column in the fact table. Then left click on the Production Order measure group and go to the Properties window and set IgnoreUnrelatedRelationships to false. That way slicing actual qty by work center or by an attribute that is below grain in the Production Details dimension will show as null.

SSAS Aggregation on Distinct ID

I wish to change the default aggregation from SUM to SUM on Distinct ID Values.
This is the current behaviour
ID Amount
1 $10
1 $10
2 $20
3 $30
3 $30
Sum Total = $90
By default, I am getting a sum of $90. I wish to do the sum on distinct ids and get a value of $60. How would I modify the default Aggregation Behavior to achieve this result?
Design your data as a many-to-many relationship: create one table/view having one record per ID and the amount column from the data shown in your question (the main fact table), and one table/view having one record per record of your data as shown in your question, presumably having another column, as otherwise it would not make any sense to have the data as shown in your question). This will be the m2m dimension table. Then, create a bridge table/view having the id of the m2m dimension table and your ID column.
Then create the following AS objects: A measure group from the main fact table, a dimension on column ID of the same table (in case there is no other column making a dimension table meaningful, in that case, you would better have a separate dimension table having ID as the primary key). Create a dimension from the m2m dimension table, and a measure group having only the invisible measure "count" from the bridge table. Finally, on the "Dimension Usage" tab of Cube Designer, set the relationship between the m2m dimension and the main measure group to be many to many via the bridge measure group.
See http://technet.microsoft.com/en-us/library/ms170463.aspx for a tutorial on many-to-many relationships.

SSAS dimension member grouping

I am new to SSAS and i have a problem with the dimension members for which i haven't been able to find a solution. Is it possible to group dimension members like:
Member 1
Member 2_1
Member 2_2
Member 2_3
Member 3
...
so that the user browsing the cube will see only Member 1, Member 2, Member 3.
You could group the dimension members on the way into the cube (within your etl or views), but you will have to group the related fact records for it to make sense. If the dimension should be treated as the collected set and not subdivided this would be preferable.
Alternatively, if the sub dimension values make sense on their own and should be persisted alongside, you could create a hierarchy of members within SSAS relating the sub values to your desired parent value.