SSAS MDX Namedset issue with hierarchy - ssas

I'm using some MDX to create a named set in SSAS.
I have a hierarchy of Company, Group, Store
I'm trying to filter out a number of specific Store members.
I've used the Descendants function, as below, to do that, however it then doesn't have any proper hierarchy (expand and collapse etc) when viewing it in Performance Point. Any ideas? Is there a way of doing it without breaking the hierarchy?
Namedset:
Descendants([Company].[Company Hierarchy], [Company].[Company Hierarchy].
[Stores])
- [Company].[Company Hierarchy].[Stores].[Store1]
- [Company].[Company Hierarchy].[Stores].[Store2]
- [Company].[Company Hierarchy].[Stores].[Store3]

What you have looks ok. As an alternative maybe see if the following works:
EXCEPT(
[Company].[Company Hierarchy].[Stores].MEMBERS
,{
[Company].[Company Hierarchy].[Stores].[Store1]
,[Company].[Company Hierarchy].[Stores].[Store2]
,[Company].[Company Hierarchy].[Stores].[Store3]
}
)

Try using HIERARCHIZE around the set.
HIERARCHIZE
(
Descendants
(
[Company].[Company Hierarchy],
[Company].[Company Hierarchy].[Stores]
)
- [Company].[Company Hierarchy].[Stores].[Store1]
- [Company].[Company Hierarchy].[Stores].[Store2]
- [Company].[Company Hierarchy].[Stores].[Store3]
)
msdn reference for hierarchize

Related

Sum part of hierarchy based on second attribute from same dimension

so I have this dimension which has a ragged hierarchy. The hierarchy is nice to navigate but a royal pain to search in (Excel is the front end, so you have to search manually in all 12 or so levels).
We created a separate "search" attribute with all the members of the hierarchy to search in - however, in this flat list the leaves will contain the proper data but the intermediate nodes will of course not be rolled up (in lack of hierarchical information)
My idea was to put a formula on the flat list to go look up its equivalent member in the hierarchy and get its value from there.
Here's what I have - both approaches don't work unfortunately:
With
------ APPROACH 1: DESCENDANTS
Member [m1] As
Sum(
Descendants(
Filter(
[Dimension].[Hierarchy].Members
, [Dimension].[Hierarchy].Properties("Key") =
[Dimension].[Flat List].CurrentMember.Properties("Key")
),, LEAVES), ([Measure].[MeasureHierarchy].CurrentMember, [Measures].[Amount]))
------- APPROACH 2: StrToMember + CHILDREN
Member [m2] As
Sum(
StrToMember("[Dimension].[Hierarchy].&["+
[Dimension].[Flat List].CurrentMember.Properties("Key")+
"]").Children,
([Measure].[MeasureHierarchy].CurrentMember, [Measures].[Amount])
)
Select
{ [m1], [m2] }
On 0,
[Dimension].[Flat List].&[838]
dimension properties member_key
On 1
From [Cube]
Where [Measure].[MeasureHierarchy].[SomeMeasure]
Both will always return null - if I query the Hierarchy directly, it works - just not if I use the flat list
Any ideas?
figured it out myself - had a spark of inspiration tonight :-D
the answer is as simple as:
with member
[m1] as
(
StrToMember("[Dimension].[Hierarchy].&["+
[Dimension].[Flat List].CurrentMember.Properties("Key")+
"]")
, [Dimension].[Flat List].[All]
)
...
Maybe that will help someone else too

Using Multiple Descendants in the same crossjoin

I'm trying to use multiple members within the same dimension (in the same crossjoin) to have level 0 descendants.
I'd like it to be somehting like this:
Crossjoin(
{Descendants(
[LB_PL_HOME],[LOB].levels(0)
)
,Descendants(
[LB_PL_OTH],[LOB].levels(0)
)
},
Only I can't get the syntax to work.
Any ideas on how to do this?
This is not going to work:
Descendants(
[LB_PL_HOME]
,[LOB].levels(0)
)
Well I assume it won't work as it doesn't look like [LB_PL_HOME] and [LOB] are related - you're only allowed to find members at a specified level for a member within the same dimension. e.g. for a specified Year I would be allowed to find the members at the Day level, as Year and Day are related.
If [LB_PL_HOME] and [LOB] are from different dimensions then you could do something like this:
NonEmpty(
[LOB].levels(0).MEMBERS
,[LB_PL_HOME]
)
Your next problem is that you're not allowed to crossjoin members from the same hierarchy but you could chuck them all into the same set:
{
NonEmpty(
[LOB].levels(0).MEMBERS
,[LB_PL_HOME]
)
,NonEmpty(
[LOB].levels(0).MEMBERS
,[LB_PL_OTH]
)
}

Mondrian - why do I need explicit level to reference a member in a hierarchy?

If I want to reference a member in a hierarchy in a Mondrian MDX query (using Mondrian 4.4), I have to reference the level explicitly in the expression. For example, in SSAS I can do something like
[Customer].[Customer Geography].[Canada]
but in Mondrian I have to add the name of the first hierarchy level explicitly
[Customer].[Customer Geography].[Country-Region].[Canada]
Where should I be looking to troubleshoot? My hierarchy is simple, with only two levels and hasAll="false".
In SSAS when you write this [Customer].[Customer Geography].[Canada] I believe that it is short-hand for this:
[Customer].[Customer Geography].[All].[Canada]
These two scripts give the same result:
SELECT
[Customer].[Customer Geography].[All].[Canada] ON 0
FROM [Adventure Works];
SELECT
[Customer].[Customer Geography].[Canada] ON 0
FROM [Adventure Works];
So if your hierarchy has no [All] member the members will be children of the highest level. I think SSAS will assume the highest level even if you do not explicitly state it but it looks like mondrian needs it explicitly adding in to your mdx.

Why does EXISTS return tuples with some nulls included

I must be misinterpreting the function EXISTS.
Why does the following return lots of customers with null revenues?
What function should I be using or am I right to use EXISTS but need to use it differently?
WITH SET [CustomerSet] AS
EXISTS(
[Customer].[Customer].MEMBERS,
(
[Date].[Date - Calendar Month].[Calendar Month].&[201312],
[Measures].[Revenues])
)
select
[CustomerSet] on columns
from [ourCube]
Try wrap Date, Revenues in NONEMPTY
NONEMPTY (
[Date].[Date - Calendar Month].[Calendar Month].&[201312],
[Measures].[Revenues])
)
Ok - EXISTS basically mimics auto-exists behaviour without having to include two levels of a cross-join in the resulting cellset. If the two arguments are not from the same dimension then auto-exist behaviour does not occur - this is the reason for the failure of my original script. There is an optional third argument, which is very useful in this situation, and creates a context using a chosen measure group for auto-exist behaviour:
WITH SET [CustomerSet] AS
EXISTS(
[Customer].[Customer].MEMBERS,
[Date].[Date - Calendar Month].[Calendar Month].&[201312],
"Revenues Measure Group"
)
SELECT
[CustomerSet] ON COLUMNS
FROM [ourCube]

How can I determine whether dimensions are related?

I am developing a query builder application that generates MDX and trying to get customer counts from a cube using the following, which works just fine:
WITH MEMBER MEASURES.X AS (
{ [Customer].[Gender].[Female]},
[Customer].[Customer].Children
).Count
SELECT Measures.X ON 0 FROM [Adventure Works]
However, if the user drags in a dimension that is not related to the customer like:
WITH MEMBER MEASURES.X AS (
{ [Customer].[Gender].[Female]},
{ [Employee].[Status].[Active], [Employee].[Status].[Inactive]},
[Customer].[Customer].Children
).Count
SELECT Measures.X ON 0 FROM [Adventure Works]
the count result obviously becomes incorrect.
Is there a way to determine whether a dimension is related to the customer so that I can exclude it from the generated MDX query?
This information can be retrieved from the cube through AMO. The Cube class contains all the cube metadata you'll need.
Solved the problem by using the Exists( Set_Expression1 , Set_Expression2 [, MeasureGroupName] ) function. No need to manually determine which dimensions are related. The Exists function filters out the unrelated tuples, leaving only the
{ [Customer].[Customer].Children, [Customer].[Gender].[Female]} set to do the count over.
Here is the MDX:
WITH MEMBER MEASURES.X AS Exists(
[Customer].[Customer].Children,
{[Customer].[Gender].[Female]}
*
{[Employee].[Status].[Active], [Employee].[Status].[Inactive]}
).Count
SELECT Measures.X ON 0 FROM [Adventure Works]