How to hide measure or a scope if user choose certain dimension or go to certain dimension hierarchy level?
Thanks.
Try something like this in your MDX script:
FREEZE([Measures].[My Measure], [Product].[Subcategory].[All]);
([Measures].[My Measure], [Product].[Product].Members, [Product].[Subcategory].[Subcategory].Members) = null;
Freeze ensures the next statement won't null out the category level totals. The next statement bulls out that measure for the whole product dimension up to the subcategory totals but not above.
Note this is fine for nulling out meaningless numbers but isn't a security feature. A savvy user could do a drillthrough command to get the product level numbers. Or a savvy user could connect in a special way and clear the whole MDX script for his session so he sees the detailed product data.
For a more secure approach:
If you can null out product data for all measures then setup role based security. In dimension data security only grant access to member Subcategory.All only but uncheck visual totals on the advanced tab so that the subcategory grand total is the real total.
Or setup a second slimmed down Product dimension that only has the top levels not the detailed product levels. Then only tie that dimension to this measure group.
Or create a second measure group that does a group by in SQL and joins to the Product dimension only at the Category level. Thus there is no detailed data only rollups. Then with security control whether a used sees the detailed measures or the summary measures.
On measure properties you can set set visible property to false for the measure you want to hide. Another option is to use perspective and choose again what you want to hide or not.
Related
I have two tables in my Ticket Management Application, "ExpositionPeriods" and "OrganisedVisits".
ExpositionPeriods - Defines the periods for which tickets can be purchased.
OrganisedVisits - Stores the tickets purchased information.
In the example below, we have 5 periods available, and tickets have been purchased for 2 of the periods.
The customer wants a report which shows "Number of visitors against each available period". That means if, for any period which doesn't have a visitor, the report should show "0" for that period. Something like this.
So far so good. Since the production database is humongous (~500 GB), it is not advisable to report on this database directly. Things turn to be challenging when I create an OLAP cube out of this schema and try to achieve the same report functionality in the cube. It seems the cube actually performs an action similar to SQL INNER JOIN as opposed to a LEFT OUTER JOIN and hence I do not see those Periods for which there are no tickets sold.
Is this how SSAS actually behaves? Am I missing out any particular setting that will indicate the SSAS engine to process the cube in a different manner so as to include the missing periods as well? Please note, end customers don't have access to MDX/DAX scripts, they can only use the cube by drag-drop measure and dimensions like in Excel pivot table.
In your image the browser is carrying out a non empty on rows on the date dimension. If you want to show the dates with no visitors then select the option to show empty cells.
You can define such scope in "calculations" as
SCOPE
([Measures].[Visitors]);
THIS=IIF(ISEMPTY([Measures].[Visitors]),0,[Measures].[Visitors]);
END SCOPE;
So you have zeros instead of nulls and side effect. You or customer can't hide empty cells, cause now it's not empty enough.
I have built a small data warehouse using the Adventure works database. I have deployed it to SQL Studio Manager. I have written my first MDX query
select
customer.[full name].members on rows,
order (measures.[sales amount],asc) on columns
from [Adventure Works DW2012]
Please see the screenshot below:
I understand that the top level of the hierarchy are dimensions i.e. Customer, Date, Due Date, Interne Sales, Order Date, Product and Ship Date. I understand that dimensions have attributes. For example: Model Name, Product Line, Product Name are attributes of the Product dimension and Product Model Lines is a hierarchy of the Product dimension.
What is meant by: Financial; History and Stocking?
You've come up against something I think is a genuinely confusing and ill-designed aspect of SSAS.
You're correct that Model Name, Product Line and Product Name are attributes of the Product dimension. But what you're seeing here (in your screenshot) is hierarchies called Model Name, Product Line and Product Name.
These are not "hierarchies" in the sense that most people use the term (a structure with more than one level). They're the "attribute hierarchies" based on the attributes of the same name. They only have one level two levels. (EDIT: as whytheq pointed out, they have one leaf level, and almost always also have an "All" level).
(EDIT) Product Model Lines is a "real" (aka "user") hierarchy, with multiple levels apart from the All and leaf levels, based on multiple attributes.
Financial, History and Stocking are "folders". They get "created" by the setting of any AttributeHierarchyDisplayFolder property of any Attribute in the Dimension design (or the DisplayFolder property of any "real" hierarchy). They have nothing to do with any dimension structure - they're just for display convenience. Probably necessary because, as becomes clearer the more I try to explain it, the structure of Dimensions in SSAS is really unnecessarily complicated.
You can hide the "attribute hierarchies" from client applications (e.g. Excel) by setting the AttributeHierarchyVisible property of the attribute to False. But they'll still show up in the MDX "helper" screen you're looking at.
Just a bit of background info:
I have dimension table which uses SCD2 to track user changes in our company (team changes, job title changes etc) See example below:
I've built an Analysis Services Cube and created all the necessary hierarchy's for the dimensions and it works well when navigating and drilling down through the fact table.
The problem I have is with the filters on the PerformancePoint dashboard. As I'm using the User Dimension table with it's multiple instances of users it's showing duplicates up in the list. I can understand why as the surrogate ID is being referenced on the Dimension. But if I choose the first instance of the A-team I will see all their sales for a particular period and if I choose the second instance I will see all their sales for a different period.
What is the best way to handle this type of behavior? Ideally I'd like to see a distinct list of teams in alphabetical order and when I choose the team name it shows all of their data over time.
I've considered using MDX query filters but I'd like to see if there's anything I haven't thought about.
I realise this isn't an easy and quick question but any help would be appreciated!
The answer was simple after having a trawl through my User Dimension table on the Cube.
Under my user dimension I added 2 duplicate attributes to my attributes list ("Team Filter" is a copy of "Team", "User Filter" a copy of "User Name") these will be used only for filtering the dashboard.
Under the attribute properties for each duplicate I then set AttributeHierarchyOptimizedState to "Not Optimized", I also set their AttributeHierarchyVisible to false as I'd shown the two duplicate attributes in the hierarchy window in the middle.
Deploy your Cube to the server and go in to PerformancePoint. Create a new MDX Filter (this image shows the finished filter)
This is the code I used, it only shows dimension members which have a fact against them (reduces the list a considerable amount) and by using allmembers at the dimension it also gives me the option to show "All" at the top of the list.
Deploy the new filters and now you can see the distinct list of users and teams, works perfectly and selects every instance (regardless of the SCD2 row)
I have a writeback partition working pretty well in a cube. The users access it through Excel 2010. At the moment there are 3 measures in the cube. I'd like to only give users access to writeback to 2 of them while being able to read all 3. Is there a way to accomplish this? I'm very much an MDX novice if MDX is involved. Thanks in advance.
The failproof way to prevent those users from writing to your measure is by including those in a special Role with writeback access. In the tab "Cell Data", check the box "Enable read/write permissions", and in the field below "Allow reading and writing of cube content" you can set an expression to limit the write measures, such as:
(Measures.CurrentMember IS [Measures].[X] OR Measures.CurrentMember IS [Measures].[Y])
In the upper field, that enables read access, allow access to all three measures:
(
Measures.CurrentMember IS [Measures].[X] OR
Measures.CurrentMember IS [Measures].[Y] OR
Measures.CurrentMember IS [Measures].[Z]
)
They will have a weird message saying that the cell was blocked, but at least you'll prevent them from writing to your beloved measure.
Another approach would be: create a Calculated measure ([Measures].[ZZ]) based on the one you want to hide ([Measures].[Z]). SSAS won't let the user writeback on a calculated measure. Make sure you hide the original by marking it VISIBLE = 0.
#mmarie is correct...if the measures are all in the same partition, then you'll need to move the 2 for writeback into a separate measure group. You can do this by creating separate views in the relational DW or via named queries in the DSV. Since both measure groups will have the same dimensionality (because they are based on the same table) SSDT will give you a warning - just ignore it ;-)
In my cube there are certain measures which are non-additive, however I can compute a value for every drill down level. Unfortunately the computation is too complex for it to be done in in Analysis Services.
If I precompute the drill down levels I'm interested in, I have to put those values into a separate fact-table / measure group for each drill down level, or don't I? Is it possible to do this in a way that is transparent to the end user? So it should look like there is only one fact table and SSAS automatically selects the value from the correct fact table based on the drill-down level?
I found the answer in a Microsoft forum: http://social.msdn.microsoft.com/Forums/en-US/sqlanalysisservices/thread/d5998b23-936b-4e7b-b593-bd164b20c022
On the Calculate tab you can define a scope statement:
In this really trivial example, internet sales amount will be shown when reseller sales amount is chosen (at calendar quarters).
scope([Measures].[Reseller Sales Amount], [Date].[Calendar].[Calendar Quarter]);
this=[Measures].[Internet Sales Amount];
end scope;