0
votes

This query gives me sales of one store:

select
[measures].[sales] on 0
from [MyCube]
where [store].[store].[042]

However, if I move the slicer to inside of the subquery, it gives me sales of all stores.

select
[measures].[sales] on 0
from (select
  from [MyCube]
  where [store].[store].[042]
)

How to understand the mechanisms behind this difference? This is also noted in this article, but without much explanation.

----EDIT----:

I tried various things and read around for a while. I'd like to add a question: is there a scenario in which the where clause in sub-select does filter the result?

This query gives me sales of all stores in state MI (store [042] belongs to MI):

select
[measures].[sales] on 0
from (select
  [store].[state].[MI] on 0
  from [myCube]
  where [store].[store].[042]
)

Thinking of 'inner query only filters if the filtered dimension is returned on an axis', the theory is proved wrong if I do this:

select
[measures].[sales] on 0
from (select
  [store].[state].members on 0
  from [myCube]
  where [store].[store].[042]
)

The sub-select still returns one state MI, but the outer query returns sales of all stores (of all states).

----EDIT 4/13----:

Re-phrasing the question in AdventureWorks cube with screenshot. Query 1: sales of one store Query 2: it returns sales of all stores if where clause is in the sub-select. Query 3: the two answers I got suggested that we select the dimension in an axis - here is the result - we get all cities.

AdventureWorks cube

2
The way I use subselects is just (SELECT blah ON 0, foo ON 1, bar ON 2 ..... FROM cube) with as many axes as is required. I've never played with the WHERE clause - what does msdn say about this?whytheq
I've added a little more in terms of the WHERE clause to the bottom of my post.whytheq
hi - the script of the subselect of your second query is not valid - if you try running that independently it will fail as there are no axes in the SELECTwhytheq
your third and fourth scripts do not specify a cube - so not sure how they are working at all?whytheq
if you add the cube into your third and fourth subselects then they are still not valid as you cannot use [Store] on rows or columns if it already in the Where clause.whytheq

2 Answers

1
votes
select
[measures].[sales] on 0
from (select
  from [MyCube]
  where [store].[store].[042]
)

The above query reduces the scope of stores just to the member [042]. Make note that sub-select is executed before the actual select. So, when it comes to the select, the engine just sees a cube which has all the members in all the dimensions; but only the member [store].[store].[042] in the store dimension. It's as if the cube has been kept intact every where else but sliced off on the Store dimension.

If you go a step ahead and add the store on to one of the axes, like

select
[measures].[sales] on 0,
[store].[store].members on 1
from (select
  from [MyCube]
  where [store].[store].[042]
)

you would see that although the member [All] appears in the output, it actually is just comprised of only one store.

In essence, the [All] is a special member which is calculated with respect to scope of the cube. It reflects the combined effect of all the members in the cube.

In SQL terms, it is similar to:

select sales, store as [All] from 
(select sales, store from tbl where store = '042') tbl

Even though you see Sales----All, it is but a reflection of sales for store [042]

1
votes

Here are some other good references concerning sub-select and slicer debate:

http://bisherryli.com/2013/02/08/mdx-25-slicer-or-sub-cube/

https://cwebbbi.wordpress.com/2014/04/07/free-video-on-subselects-in-mdx/

Chris Webb's video being located here:

https://projectbotticelli.com/knowledge/what-is-a-subselect-mdx-video-tutorial?pk_campaign=tt2014cwb

This should still leave an All member:

SELECT 
  [measures].[sales] ON 0
FROM 
(
  SELECT 
  FROM [MyCube]
  WHERE 
    [store].[store].[042]
);

...but the member [All] of the Store hierarchy will only now be made up of [store].[store].[042]. You can see this by adding the Store hierarchy onto ROWS:

SELECT 
  [measures].[sales] ON 0,
  [store].MEMBERS ON 1
FROM 
(
  SELECT 
  FROM [MyCube]
  WHERE 
    [store].[store].[042]
);

This is the AdvWorks version similar to the reference in your question:

SELECT 
  {[Measures].[Order Count]} ON 0
 ,[Subcategory].MEMBERS ON 1
FROM 
(
  SELECT 
    {
      [Subcategory].[Subcategory].&[22]
    } ON 0
  FROM [Adventure Works]
);

It returns the member from the sub-select and the All member adjusted to take account of the subselect:

enter image description here

In the references article why is the [All] less than the sum of the other two - this is not down to the subselect but is in connection with the measure that he has chosen [Measures].[Order Count] which is a distinct count. If you take away the subselect you see exactly the same behaviour of the All member being less than the sum of the other subcategory members (I've marked the point at which the total of the parts becomes higher than the All member):

SELECT 
  {[Measures].[Order Count]} ON 0
 ,Order
  (
    [Subcategory].MEMBERS
   ,[Measures].[Order Count]
   ,bdesc
  ) ON 1
FROM [Adventure Works];

enter image description here

Order Count: on 1 order there might be several Product Subcategories - hence this behaviour.


Edit

This query of yours:

select
[measures].[sales] on 0
from (select
  [store].[state].members on 0
  from TestCube //<< added this!
  where [store].[store].[042]
)

This inner script is not valid? Using the same dimension on an axes and the WHERE clause is not valid:

select
  [store].[state].members on 0
from TestCube
where [store].[store].[042]

Edit2

An mdx script returns a cube, which may be sliced or not sliced, but nevertheless it returns a cube. The WHERE clause is used to slice the cube that is returned. If we were using a third party tool then the dimension added to the WHERE clause would go into a combobox - with say Cliffside selected. BUT the user could effectively select Ballard from that combobox - it is just a slicer. The WHERE clause is not changing the cube that is returned by the mdx script, it is just affecting what is displayed in the cellset. WHERE is valid within a subselect. It is part of the definition: https://msdn.microsoft.com/en-us/library/ff487138.aspx
I've never found a use case for a subselect's WHERE clause.


Edit3

This link will explain things:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/ccb66ac3-0f9a-4261-8ccc-b6ecc51b6f07/is-where-clause-pointless-inside-a-subselect?forum=sqlanalysisservices

As Darren gosbell says in the answer to this question:

https://msdn.microsoft.com/en-us/library/ff487138.aspx it says that:

The WHERE clause does not filter the subspace.