Showing posts with label dimensions. Show all posts
Showing posts with label dimensions. Show all posts

Monday, March 26, 2012

How create named set across dimensions...

If I want to create a named set for a set of "accounts" that limits the accounts to a subset based on two other dimensions, how do I do it? I tried...

CREATE SET [Accounts Created in Last 30 Days from NorthEast]
AS {
([Accounts].[Account].Members,
[Sales Region].&[NorthEast],
[Date Account Created].[Is Last 30 Days].&[True]
)

And it returned the right set of subset of accounts, but I ran into two problems:

1) in addition to the account column showing up in query results, it returned the [Sales Region] and [Date Account Created] columns, which in retrospect makes sense because the "dimensionality" of the set includes all three dimensions. and because of this,

2) when I try to use the set in Excel 2007 pivottables, it doesn't show the set in the pivottable list of sets under the accounts dimension.

Any help would be great as I'm kinda stuck right now on being able to easily build excel 2007 reports. Happy Day...

I think Excel only show single hierarchical sets. In order to do what you are looking for, I think you should use the following:

CREATE SET [Accounts Created in Last 30 Days from NorthEast]
AS Exists([Accounts].[Account].Members,
{[Sales Region].&[NorthEast]}*{[Date Account Created].[Is Last 30 Days].&[True]})

HTH,

Mosha (http://www.mosha.com/msolap)

|||

First, thanks a ton for the quick response. It really helped me understand more about Exists.

Second, I tried this, but it doesn't seem to be working the way I'd expect it. For example, if I run the following query:

SELECT
{[Sales Region].Members} on columns,
{[Accounts Created in Last 30 Days from NorthEast] } on rows
FROM [CUBE]

I would expect it to show only accounts along the rows where the region is the NorthEast because that's how the set was defined. It doesn't. When I do this, it lists many more accounts in other regions. It appears as though any time I include the set in a query it ignores the "filter" dimensions that I put in the exists if they aren't attributes of the [Accounts] dimension...in this case the [Sales Region] and [Date Account Created] dimensions. Am I missing something or do I need to move every attribute from the related dimensions into the [Accounts] so they are attributes of [Accounts]. Seem like this would totally defeat the reason for having broken out the dimensions in the first place.

Thanks for any help can give as I'm kinda frustrated with this one......

|||

Indeed, Exists only works with attributes from the same dimension, because it performs join based on the dimension table. If you have separate dimensions, then the only table to use for join is the fact table, in which case you need to use NonEmpty function if you want to take into account calculations inside the cube, or Exists(,,measuregroupname) function if you want to go purely after the fact table (the latter is more rare). More discussion on this subject is here: http://www.sqljunkies.com/WebLog/mosha/archive/2006/10/09/nonempty_exists_necj.aspx

So assuming NonEmpty, your query would be

WITH SET [Accounts Created in Last 30 Days from NorthEast] AS

NonEmpty([Accounts].[Account].Members, {[Sales Region].&[NorthEast]}*{[Date Account Created].[Is Last 30 Days].&[True]})

SELECT
{[Sales Region].Members} on columns,
{[Accounts Created in Last 30 Days from NorthEast] } on rows
FROM [CUBE]

HTH,

Mosha (http://www.mosha.com/msolap)

|||

WOW...thanks again for quick reply.

Is this true if have snowflaked dimensions? Right now I have it where

FACT > [Accounts]

[Accounts] > [Sales Region]

[Accounts] > [Account Date Created]

Is the root of all my pain that I haven't designed this so...

FACT > [Accounts]

FACT > [Sales Region]

FACT > [Account Date Created]

I was assuming that because Accounts is related directly to the other dimensions that this would work.

I REALLY DO APPRECIATE YOUR HELP.

|||

Exists works inside dimension regardless whether it is snowflake or not. Based on your schema, it seems like you should've defined Sales Region and Account Date Created as attributes inside Accounts dimension, not as separate dimensionss

Wednesday, March 21, 2012

How concatenate members from 3 virtual dimensions using MDX

Hello,
There is a big problem - my client made 3 virtual dimensions (Year, Quarter,
Month) from single time dimension and wants to use them, because the
graphical interface in Excel is more friendly for end-users to have 3
dimensions (i.e. 3 separate tabs).
But in the same time we need to make MDX queries with time series with MDX
formulas like YTD, LastPeriod and so on. These formulas need full time
dimension.
I wonder there is possibility to concatenate all 3 members from virtual
dimension and use that aggregate as member for real Time dimension. For
example if user selects 2005 year, I Quarter and February from virtual
dimensions, we can assume, that member from real dimension could be
[2005].[I].[February], but how make that member and submit it to
formula for
later use.
In SQL we have possibility to construct SQL queries dynamically, and what
about MDX.
ErnestasJust an idea -
StrToTuple(
IIF( < original tuple >.Item(0).Dimension IS [VYear] AND < tuple
>.Item(0).Dimension IS [VQuarter] AND < tuple >.Item(0).Dimension IS
[VMonth], < Parse the unique names to create your real unique name using
VB
functions>, TupleToStr(<original tuple> ) )
)
"Ernestas" <sysojevas@.delfi.lt> wrote in message
news:efUjpNHNFHA.244@.tk2msftngp13.phx.gbl...
> Hello,
>
> There is a big problem - my client made 3 virtual dimensions (Year,
> Quarter, Month) from single time dimension and wants to use them, because
> the graphical interface in Excel is more friendly for end-users to have 3
> dimensions (i.e. 3 separate tabs).
>
> But in the same time we need to make MDX queries with time series with MDX
> formulas like YTD, LastPeriod and so on. These formulas need full time
> dimension.
>
> I wonder there is possibility to concatenate all 3 members from virtual
> dimension and use that aggregate as member for real Time dimension. For
> example if user selects 2005 year, I Quarter and February from virtual
> dimensions, we can assume, that member from real dimension could be
> [2005].[I].[February], but how make that member and submit it
to formula
> for later use.
>
> In SQL we have possibility to construct SQL queries dynamically, and what
> about MDX.
>
> Ernestas
>|||Correction:
StrToTuple(
IIF( < original tuple >.Item(0).Dimension IS [VYear] AND <
tuple.Item(1).Dimension IS [VQuarter] AND < tuple >.Item(2).Dimension IS
[VMonth], Parse the unique names to create your real unique name using
VB
functions>, TupleToStr(<original tuple> ) )
)
"Elad" <elad> wrote in message news:OZh2t9HNFHA.2372@.TK2MSFTNGP10.phx.gbl...
> Just an idea -
> StrToTuple(
> IIF( < original tuple >.Item(0).Dimension IS [VYear] AND < tuple
> [VMonth], < Parse the unique names to create your real unique name usi
ng
> VB functions>, TupleToStr(<original tuple> ) )
> )
>
> "Ernestas" <sysojevas@.delfi.lt> wrote in message
> news:efUjpNHNFHA.244@.tk2msftngp13.phx.gbl...
>

Friday, March 9, 2012

How can only certain objects (dimensions, cubes) be deployed?

How can only certain objects (dimensions, cubes) be deployed?

From Visual Studio I would like to deploy individual items like a dimension or cube without all of the changes in the other objects being deployed.

I don’t see any way to do that. Every time one thing gets deployed, all changes get deployed.

Visual Studio sends a Message Box Stating that the whole SSAS Database will be overwritten on the server and asks if you want to deploy or not.

We have multiple developers working and it has become a problem. We can’t deploy just those changes that are ready without overwriting the whole database.

I feel your pain...I have the same issues here (even though I'm the only developer on our BI apps). One possibility could be to have your developers work directly on the dev analysis server and add objects there. Then, you can use SSMS to individually process objects (dimensions, partitions, measure groups, etc). I'm also going to try deploying all my changes to a "staging" Analytics Database, which could be swapped out with the production DB when necessary.

It'd be great if there was a set of best-practices around the complete SSAS lifecycle.|||

While the underlying XMLA commands do support deploying single objects like a cube or dimension, it can get a bit difficult to manage due to the dependancy relationships between the various objects.

Probably a better approach with multiple developers would be to use a version control system. This way you could check-in your changes and do a "get latest" to make sure you are deploying the latest version of all the objects.

Although having said this, by remarkable coincidence I have been working on an add-in for Visual Studio that lets you deploy only the calculation script for a cube. It would probably be technically possible to extend this to deploy just a cube or dimension, but I am still concerned about the effect that this may have on dependant objects if you had multiple developers working on the same database. I still think it would be worth looking into using a version control system.

|||

We use Visual SourceSafe. The situation is as follows:

I have the Time dimension checked out and am making changes. Bob has the CashRecxeipts cube checked out and is making changes.

If I finish 1st and am ready to deploy the new Time dimension, it will invalidate all cubes that use the Time dimension. Bob will have to get the latest version of the Time dimension and fix the relatoinships for it in the CashReceipts cube before he deploys his changes.

If Bob deploys without getting the latest version of the Time dimension he will overwrite my changes.

Also, I have to modify all cubes that use the Time dimension and check their relationships to the Time dimension before I can deploy. I can't modify the CashReceipts cube because Bob has it checked out. I am at a standstill.

It is very difficult to coordinate with developers when we are in different cities.

|||

I don't see any easy answer to your question.

In your scenario, it might be possible to write something that would deploy just the altered time dimension and just the CashReceipts cube, but if you did this the CashReciepts cube would still be broken if it was not first adjusted to cater for the changes in the time dimension.

One approach that is sometimes employed (not with SSAS as far as I know, but the theory would still apply) is to have only one person (or process) that deploys to the server. They do a "get latest" from Source Safe, check that everything builds and then deploys, if anyone wants to get something new onto the server they have to check their changes in and let this person know. Ideally each developer should have their own local copy of the DB, preferrably with a small set of data so that they can process it quickly and test their changes before checking them in.

There are even tools that exist for platforms like .Net and Java, that will check the latest code out of the version control system when a new checkin is detected and build and deploy. I don't think any of these tools have hooks to SSAS, but most of them are fairly extensible. CruiseControl.Net http://ccnet.thoughtworks.com/ is one example, if you search for "Continuous Integration" you should be able to find others.

Mark Garner http://mgarner.wordpress.com/ has done some posts on his blog about applying these sorts of principles to Data Marts http://wordpress.com/tag/agile-data-warehouse/

|||

Darren,

Thanks for your suggestions and information on tools and procedures. They are good ideas and should prove helpful.