Showing posts with label dimension. Show all posts
Showing posts with label dimension. Show all posts

Monday, March 26, 2012

Read property of "selected" dimension member (AS 2005 filter)

Hello there

I am using Richard Kutchaks CellsetGrid though this issue is of a general kind. I want to filter on a hierarchy. This filtering occurs as a subcube. I intend only to chose one member at a time. The thing is that I want to read the property "level" from the chosen (filtered) member. I can't use currentmember since no member is actually chosen, but the filtered hierarchy points at a member.

Is there a way to catch that member and through that actually read properties of it? I don't care if it fails when more than one member is chosen.

This code worked when I used the old way of filtering which cannot be used with CellsetGrid:

CASE WHEN [Prisme Dimension].[Hierarki Prisme Budget].currentmember.LEVEL.NAME = [Anvisning].[Hierarki Anvisning].currentmember.Properties("Level")

THEN 1

ELSE 0

END

This is the code that the CellsetGrid fires (with me modifying the calculated member so you can see partly what I want to achieve:

WITH MEMBER [Measures].[Test2] AS

'tail(EXISTING [Anvisning].[Hierarki Anvisning],1).item(0).name'

SELECT

{[Measures].[Test2]} ON COLUMNS

from

(Select

{{[Anvisning].[Hierarki Anvisning].[Anvisning 2].&[2]&[1]}

}

on 0 from [writebacktest]) CELL PROPERTIES VALUE, FORMATTED_VALUE, FORE_COLOR, BACK_COLOR

Background for interested folks:

Each member of a organisation has a property with the name of a level of another dimension. I want to combine these two things. When a user choses a organisation member, it automatically gets the other dimensions level and will, when the user drillsdown to that level, active a action. This action is the key to enable input of forecasts (they should only be made on the level that is given by the organisation's property).

Johan

I actually found out by extensive search in this forum, the very answer. It doesn't fit perfectly but it is an answer. This MDX will work. Notice how I've added the filtered dimension once again in the query. This is not supported out of the box in the CellSetGrid which unfortunately is the only "MDX Compatibility=2" viewer I've got. SQL 2005 tools are not level 2 compatible (funny enough).

WITH MEMBER [Measures].[Test2] AS

'tail(EXISTING [Anvisning].[Hierarki Anvisning],1).item(0).Properties("Level")'

SELECT

{[Measures].[Test2]} ON COLUMNS,

[Anvisning].[Hierarki Anvisning].[Anvisning 2] ON ROWS

from

(Select

{{[Anvisning].[Hierarki Anvisning].[Anvisning 2].&[2]&[1]}

}

on 0 from [writebacktest]) CELL PROPERTIES VALUE, FORMATTED_VALUE, FORE_COLOR, BACK_COLOR

//Johan

|||

What we should tell Richard, is that CellSetGrid should modify its query generation to do the same thing as Excel 2007 does. When there is a single member selected - use WHERE clause. I.e.

WITH MEMBER [Measures].[Test2] AS

'tail(EXISTING [Anvisning].[Hierarki Anvisning],1).item(0).Properties("Level")'

SELECT

{[Measures].[Test2]} ON COLUMNS

from [writebacktest])

WHERE [Anvisning].[Hierarki Anvisning].[Anvisning 2].&[2]&[1]

CELL PROPERTIES VALUE, FORMATTED_VALUE, FORE_COLOR, BACK_COLOR

|||

Well, this issue has learned me a bit about the new query practices. Richard has been so kind to expose his sourcecode. I thought of actually to try to see how I could modifiy the query methods myself. It might be that I need to add more dimensions and so it should be possible to set a query parameter: Use Where Clause and Use Subcube.

//Johan

sql

Monday, February 20, 2012

Ratio Calculation based on calculations from two different dimensions

I am trying to come up with a way to calculate a ratio that is based on the values from two different dimension calculations. The values are based on how a person responded to a question on a survey. I have one calculation that I can get with the following MDX statement:

select {Measures.[Brand Usage Last Try 2-6]} on columns,

non empty([brand usage].[brand label].children) on rows

from cube

RESULTS:

Brand Usage Last Try 2-6

Brand 1

164.277

Brand 2

208.513

Brand 3

131.193

(The [Brand Usage Last Try 2-6] measure is the Measures.Weight aggregate calculation for people that responded with a value from 2 to 6 for a particular brand).

The second calculation is the following:

with member measures.hrd as ([Brand Awareness].[VarResponse].[Var3].&[hrd].&[heard_of_brand], [Measures].[Weight])

select {measures.hrd} on columns,

non empty([brand awareness].[brand label].children) on rows

from cube

RESULTS:

hrd

Brand 1

301.601

Brand 2

462.385

Brand 3

361.533

I need to be able to take the calculation from the first one and divide it by the value for the second calculation based on brand. I tried using the linkmember to retrieve the values based on the brand, but it is not returning the results that I expected.

with member measures.hrd as ([Brand Awareness].[VarResponse].[Var3].&[hrd].&[heard_of_brand], [Measures].[Weight])

member measures.hrdlnk as (measures.hrd, linkmember([Brand Usage].[Brand Label].currentmember,[Brand Awareness].[Brand Label]))

member measures.ratio as (iif(measures.hrdlnk > 0, measures.[brand usage last try 2-6]/measures.hrdlnk, null)*100)

select {measures.[Brand Usage Last Try 2-6], measures.hrd, measures.hrdlnk,

measures.ratio} on columns,

non empty([brand usage].[brand label].children) on rows

from cube

RESULTS:

Brand Usage Last Try 2-6

hrd

ratio

Brand 1

164.277

301.601

54.47

Brand 2

208.513

(null)

(null)

Brand 3

131.193

271.332

48.35

Somehow the first brand ratio calculation comes out right, but that is the only one. Both of these dimensions reference a brand dimension. Each dimension, [Brand Awareness] and [Brand Usage], contain questions and potential responses for each type of brand in the brand dimension. Both dimensions have a hierarchy that I created [VarResponse] in them that is based on the type of question [Var3] (which is the first three characters of the Variable name) and then the response [Category Name].

"Both of these dimensions reference a brand dimension. Each dimension, [Brand Awareness] and [Brand Usage], contain questions and potential responses for each type of brand in the brand dimension." - could you explain how dimension usage is configured for the cube, in terms of these 3 dimensions and the [Measures].[Weight] measure group? Assuming that [Brand] has a regular relation to the fact table, and that [Brand Awareness] and [Brand Usage] each has a many-to-many relation to the measure group, there may be unintended interaction when computing hrdlnk, so try this:

member measures.hrdlnk as (measures.hrd, linkmember([Brand Usage].[Brand Label].currentmember, [Brand Awareness].[Brand Label]), [Brand Usage].[Brand Label].[All])

|||

This calculation did work and produced the results that I was looking for, thank you so much.

In regards to the configuration, the brand table is linked to each of the dimension tables, awareness and usage. The brand table does not directly relate to the fact table. The dimension tables, awareness and usage have a regular relationship to the fact table and they both have a key designated in the table. This is how it is currently configured.

Brand (Brand_ID) -->Brand Awareness (Brand_Awareness_ID, Brand_ID)

-->Brand Usage(Brand_Usage_ID, Brand_ID)

-->Fact Table(Date_ID, Respondent_ID, Brand_Awareness_ID, Brand_Usage_ID)

The granularity within the fact table is not what I am typically used to, so this is kind of an odd setup.

Rapidly Changing Dimension

Hi All,
I'm trying to figure out how I would best model the following situation
:
I'm trying to model a retailing case which is fairly easy except for
one mind boggling thing (at least for me). I'm having a SKU dimension
of around 150.000 unique products which is already a SCD Type 2 for
some attributes. In addition I'm willing to track changes of the sales
and purchase price. However these prices change almost weekly for quite
a lot of these products leading to a huge dimensional table when using
type 2.
As this is a numerical attribute I'm thinking about putting it into the
fact table; However first of all my fact table will grow with a couple
of gigs (around 1 billion rows) and secondly as not every product is
sold every day I do not have the possibility to view price over a
period on a day to day basis.
A second option would be to have a separate fact table (and olap cube)
and making a linked measure for both prices. However I don't know how
to fetch the correct price in the basic cube when the price-cube does
not have the same granularity of the date dimension but more of a
start-end date structure.
Anyone some brilliant ideas? I ran out of mind juice on this one.
Hello DePuurt,
I would put the sales price in the fact table, and use type 1 to track
the current price in the product dimension. This should solve the day
to day price reporting and give you the changes of sales price over
time.
I also put a post together ages ago on different forms of type 2
implementation.
Check out:
http://bi-on-sql-server.blogspot.com...-changing.html
Hope it helps,
Myles Matheson
Data Warehouse Architect
http://bi-on-sql-server.blogspot.com/
|||A good idea, certainly valid.
However, I still have the issue on reporting the sales price over a
period of time. I want to be able to give a full price history of a
specific product over time; even if the thing didn't sell at all;
Unless I do you a complete full blown type 2 on the product dimension
I'm still not able to do this. An option would be to split the price of
the product dimension and have a subdimension tacking it. This tracking
dimension would have the natural key and the start/end date and both
prices. Creating a join with the original product dimension would yield
the exact information BUT now it's not in the cube if I go for OLAP.
Actually it all comes down to the desired functionality. Having a big
dimension table is the meast desired option in the main cube (sales
analysis), but is actually achievable when I accept the performance
drop. A second option yielding the same functionality would be to
create a second cube on prices. This means building one on the product
dimension with tracking dimension on price and this for the same date
granularity as the main cube. Using the lookup function the user
wouldn't notice it and performance would not be hindered when running
SQL reports. MDX is actually still quite fast, so I can take a small
hit (llokup) there. The last thing would be to go for your option, thus
limiting the possibilities for reporting price over time.
Thanks a lot,
DP.
|||Hi DePuurt,
150K rows in a dimension table is nothing to be worried about....on a
recent project we had a 20M row dimension table...LOL!
But you are seeing one of the problems with type 2 dimensions when they
change quickly.....one client of mine had 90M rows in his customer
dimension table linking to 6B rows in a summary fact table...obviously
every question was slowed down...
The answer is to maintain history for type 2 dimensions without
maintaining it in the type 2 dimension table...
We do this all the time for big clients.
Peter
www.peternolan.com

Rapidly Changing Dimension

Hi All,
I'm trying to figure out how I would best model the following situation
:
I'm trying to model a retailing case which is fairly easy except for
one mind boggling thing (at least for me). I'm having a SKU dimension
of around 150.000 unique products which is already a SCD Type 2 for
some attributes. In addition I'm willing to track changes of the sales
and purchase price. However these prices change almost weekly for quite
a lot of these products leading to a huge dimensional table when using
type 2.
As this is a numerical attribute I'm thinking about putting it into the
fact table; However first of all my fact table will grow with a couple
of gigs (around 1 billion rows) and secondly as not every product is
sold every day I do not have the possibility to view price over a
period on a day to day basis.
A second option would be to have a separate fact table (and olap cube)
and making a linked measure for both prices. However I don't know how
to fetch the correct price in the basic cube when the price-cube does
not have the same granularity of the date dimension but more of a
start-end date structure.
Anyone some brilliant ideas? I ran out of mind juice on this one.Hello DePuurt,
I would put the sales price in the fact table, and use type 1 to track
the current price in the product dimension. This should solve the day
to day price reporting and give you the changes of sales price over
time.
I also put a post together ages ago on different forms of type 2
implementation.
Check out:
http://bi-on-sql-server.blogspot.co...r.blogspot.com/|||A good idea, certainly valid.
However, I still have the issue on reporting the sales price over a
period of time. I want to be able to give a full price history of a
specific product over time; even if the thing didn't sell at all;
Unless I do you a complete full blown type 2 on the product dimension
I'm still not able to do this. An option would be to split the price of
the product dimension and have a subdimension tacking it. This tracking
dimension would have the natural key and the start/end date and both
prices. Creating a join with the original product dimension would yield
the exact information BUT now it's not in the cube if I go for OLAP.
Actually it all comes down to the desired functionality. Having a big
dimension table is the meast desired option in the main cube (sales
analysis), but is actually achievable when I accept the performance
drop. A second option yielding the same functionality would be to
create a second cube on prices. This means building one on the product
dimension with tracking dimension on price and this for the same date
granularity as the main cube. Using the lookup function the user
wouldn't notice it and performance would not be hindered when running
SQL reports. MDX is actually still quite fast, so I can take a small
hit (llokup) there. The last thing would be to go for your option, thus
limiting the possibilities for reporting price over time.
Thanks a lot,
DP.|||Hi DePuurt,
150K rows in a dimension table is nothing to be worried about....on a
recent project we had a 20M row dimension table...LOL!
But you are seeing one of the problems with type 2 dimensions when they
change quickly.....one client of mine had 90M rows in his customer
dimension table linking to 6B rows in a summary fact table...obviously
every question was slowed down...
The answer is to maintain history for type 2 dimensions without
maintaining it in the type 2 dimension table...
We do this all the time for big clients.
Peter
www.peternolan.com