I am running Analysis Services 2008 R2 and have come across some behavior that I really do not understand and I can't seem to get to the bottom of it. I have a dimension called Segment which is a simple Parent-child dimension where only one of the four top-level members has any children. This one member, has two children. Only leaf nodes have any values.
In the dimension I have used AttributeAllMemberName to allow "All Segments" to be used to refer to the top-level members. There are three dimensions used in the cube: Segment, Country and Year.
When I run:
SELECT {{Descendants([Country].[Global],, SELF_BEFORE_AFTER)}} ON ROWS,
{[Segment].[All Segments].children}*{[Measures].[Volume tonnes]} ON COLUMNS
FROM [Market]
WHERE [Year].[2012]
I see all members on the columns but the one node that has children has an empty column. My understanding is that "children" should show me only one level not two. If, on the other hand I run
SELECT {{Descendants([Country].[Global],, SELF_BEFORE_AFTER)}} ON ROWS,
{[Segment].[(all)].[All Segments].children}*{[Measures].[Volume tonnes]} ON COLUMNS
FROM [Market]
WHERE [Year].[2012]
I see exactly what I would expect; the four top-level children with correctly aggregated values for the one child that has its own children. No grand-children are shown. In either case the right number of rows are displayed.
The only difference between the two queries is that the "[(all)]" level has been explicitly listed in the second query. Given that the "all" member is defined as the only member of the "(all)" level set, these two queries should return the same values but they don't. I must be missing something in the dimension config, but what? Can someone point me in the right direction to fix this? I need the query to work properly without having to use "[(all)]".
To stop this post becoming too bloated, I have posted some screen-grabs of BIDS to my own website to show the configuration of the dimension. There are three attributes and the dimension itself that require configuration but I can only post two links so have linked them all in from this page: http://coolwire.co.uk/share/BIDS.html
The Hierarchy and the Ordering are related to the Key by rigid attribute-relationships.
It all looks okay to me but the problem must be in here somewhere.
Related
I've been dealing with this issue in various ways throughout my time with this dataset in Tableau.
As you can see, the Total count of properties for each city is including properties that have been successfully filtered out of view. Why? The dyn.RANKED Profitable Investments (grouped) variable on the Filter shelf is an attempt to double down on the same as the first line of the Calculated Field - to ignore the unwanted properties in each city. The view ignores them, but the totals do not.
If the Watershed Property pill is removed from the Rows shelf, then the dyn.NumProps_in_City results shown on the table are each the same as the Totals you see here (i.e., despite the first line of the calculated field, properties that do not meet that opening condition are being counted)...despite the view with the Watershed pill knowing not to show them.
Also if the Watershed Property pill is removed from the Rows shelf, then the dyn.RANKED Profitable Investments (grouped) variable on the Filter shelf suddenly only has one category to choose from (i.e., 'INVEST') if you go to edit the filter. Which would be great since that's the category I care about, but not if the counts are including things that are not in that category despite the filter.
Messing around with Include, Exclude, and Fixed in the calculated field doesn't seem to work here since I can't figure out how to get around various aggregate/non-aggregate and/or ATTR errors no matter where I place them. Plus, my incorrect counts are not suffering from an LOD issue - the LOD is correct - it's an issue of not consistently filtering out the unwanted rows at the desired LOD.
Please advise!
Thanks,
Christian
It seems that dyn.Ranked calculated field calculates the value prior to filtering. This may happen if you have used any LOD calculations in the syntax.
Simply right click such fields on filters shelf and click add to context. This will cause LOD calculations to calculate after the filtering.
see this link, the context filters are above the LOD calculations, in order of precedence; but measure filters are below the LOD calcs. Therefore if measures are used as filters, these have to be added to context so that their order of precedence is above such calculations
I have a requirement where report should show measures as "not applicable" if one selects a attribute which is not linked to that measure Group.
1) unrelateddimesnion= 'false' is not solving my problem because i have few default members.
2) I could able to show measure value as "not applicable " by Writing this MDX statement
([Customer].[customer name].[customer name], [measures].[sales forecast]) = 'not applicable'
but with this i have to repeat the same line for each and every attribute present in the dimension ( and also for each and every measure present in the measure Group)
can someone help me Writing the MDX for entire dimension instead for individual attribute. Thanks in advance.
Kind Regards
Mah
Bad news! An MDX script on your cube can't reference such a sub-cube in a simple way. You may have seen the LEAVES(dimension) function for a scope statement but that won't work when one attribute in a dimension has the [All] level and another has a selection. (That is to say the function returns the leaves of the dimension's key attribute). What you can do is use nested scope statements with the outer one filtering down to the list of measures you want to affect. That will at least save you typing a formula num_attributes * num_measures times. The scope statement may even accept the MEASUREGROUPMEASURES function. (When I last used that it only returned visible measures but that's probably what you want anyway.)
It may be easier to link measure group and dimension and let your data sit on the UNKNOWN member. (Or an explicit dummy member.) Then filters against or slices to real customer hierarchy values will exclude your [Sales Forecast] rows and show it as null. That's not something I've done and it'll have ramifications for error processing and you'll have to allow users sight of the unknown or dummy member. So recommend you play with the idea before you rely on it.
I hope this helps some.
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 need to query a cube by a ragged dimension (parent-child). The filter can be multiple nodes at any level.
This works in that it restricts the results to just the 2 supply chains I want...
SELECT [Measures].[Total Revenue] ON COLUMNS
, [Product].[Products].Members ON ROWS
FROM myCube
WHERE
(
{
[Supply Chain].[SupplyChains].&[{c0c62bda-0369-4591-be85-3a7078bc3352}]
, [Supply Chain].[SupplyChains].&[{aca836e9-22ac-4952-8809-3f50aeda6891}]
}
)
I know, guid keys, not my design! The problem is that data that isn't assigned to a specific supply chain is assigned to the top node. If I add the top node to the list, then all data will be returned (since all data is subordinate to it).
Is there a way to return values with a specific member and ignore its children? I'd like to say "return all data assigned exactly to the top node or to the listed supply chains and their children).
Thanks FrankPI, your comment pointed me in the right direction.
I ended up replicating the query in Excel and then examining the generated MDX using the OLAP PivotTable Extensions. Excel allows you to set filters on sub-nodes like what I was trying to do.
What it does is create a set of all nodes that don't have filtered sub-nodes to get everything else. Then for the parents of the nodes with filtered sub-nodes (and all its parents up to the root) it adds to the set those nodes but with the .DataMember function so that only the node value is included (but not its sub nodes). So basically instead of saying what NOT to get, it explicitly says what TO get, listing all other nodes which can be a bit cumbersome but works.