I have a SET of members of some dimension, let's say [Dim].[Dim].[Dim]. Then I wrote a query that returns all the elements from this dimension for 2016 year of some measure, let's say there are 5 of such.
The next step that I want to make is to find first one member in this dimension with the same name (as CurrentMember in row) but for 2015 year. As result, I want to calculate some measure with regards to 2015-member, not 2016's.
So the problem is in scope - I can't GENERATE such set because CurrentMember's function scope will be equal to GENERATE's scope so I am unable to extract actual current member that is on row now and for which I want to find "same previous by name" members.
Am I able to do this with plain MDX or should I go with some workaround like finding such "same" elements in t-sql view and making child-parent relations in cube by hand? The second approach I think is very undesirable and ugly.
Thanks.
Is there a reason you can't just use .PrevMember on the Time (Year, I guess) dimension?
WITH MEMBER [Measures].[SomePrevYearCalculation]
AS ([Time].[Year].CurrentMember.PrevMember,[Measures].[AMeasure])
SELECT
{[Measures].[AMeasure],[Measures].[Some2015Calculation]} ON 0,
[[Some complicated dimension stuff]] ON 1
FROM Cube
WHERE [Time].[Year].[2016]
Or are you dealing with a dimension that has multiple duplicate Names at leaf-level, so that you can't match the 2015 to 2016 figures by the actual dimension member?
Related
All of the measure that I want to cumulative has the same formula. So, is there any way to use the thing like function or any thing in calculate measure to resolve this issue?
There are two ways to achieve your aim:
1- the first solution is based on using the business intelligence wizard to add time intelligence to your solution.
The time intelligence enhancement is a cube enhancement that adds time calculations (or time views) to a selected hierarchy. This enhancement supports the following categories of calculations:
List item
Period to date.
Period over period growth.
Moving averages.
Parallel period comparisons.
The wizard will let you chose the calculations and measures you want to apply.
Visit : https://learn.microsoft.com/en-us/analysis-services/multidimensional-models/define-time-intelligence-calculations-using-the-business-intelligence-wizard
Visit : http://www.ssas-info.com/analysis-services-articles/62-design/2465-ssas-time-intelligence-wizard
2- Use a dimension table to calculate your calculations, this solution is more complicated, but very powerful and one of the best practices.
The first step is to create a new physical dimension, with real
members for each of the calculations we're going to need. We don't
actually need to create a table in our data warehouse for this
purpose, we can do this with an SQL view like this
CREATE VIEW DateTool AS SELECT ID_Calc = 1, Calc = 'Real Value' UNION ALL SELECT ID_Calc = 2, Calc = 'Year To Date'
Next, we need to add this view to our DSV and create a dimension based
on it. The dimension must have one hierarchy and this hierarchy must
have its IsAggregatable property set to False. The DefaultMember
property of this hierarchy should then be set to the Real Value
member. Giving this dimension a name can be quite difficult, as it
should be something that helps the users understand what it does –
here we've called it Date Tool. It needs no relationship to any
measure group at all to work.
Our next task is to overwrite the value returned by each member so
that they return the calculations we want. We can do this using a
simple SCOPE statement in the MDX Script of the cube:
this code let you create the YEAR-TO-DATE aggregation for all your measures.
SCOPE ([Date Tool].[Calculation].[Year To Date]); THIS = AGGREGATE ( YTD ([Date Order].[Calendar].CurrentMember), [Date Tool].[Calculation].[Real Value]); END SCOPE;
Visit:https://subscription.packtpub.com/book/big_data_and_business_intelligence/9781849689908/6/ch06lvl1sec35/calculation-dimensions
Can someone please explain the below Essbase code to me please? This is my first time looking at any Essbase code and I'm getting a bit confused as to what it is actually doing.
FIX(&Mth, &Yr, &Version,
"Sector1","Sector2", #relative("Source Code",0), #relative("Channel", 0) )
FIX("AccountNo","DepNo")
DATACOPY "1A11"->"A-500" TO "1BCD"->"C-800";
ENDFIX
ENDFIX
From what I have googled the following is my understanding:
Creates a new command block which restricts database calculations to this subset.
Passes the following members into the command to be used:
Mth
Yr
Version
Returns the following fields:
Sector1
Sector2
returns the 0-level members of the Source Code member - meaning it returns the members of the Total Source Code without children (no other dimensions)
returns the 0-level members of the Channel member - meaning it returns the members of the Channel without children (no other dimensions)
Begins a new command block and passes the following members into the command to be used:
AccountNo
DepNo
Copies the range of cells 1A11, A-500 over to the range 1BCD, C-800
The above is what I understand from the oracle documents on each of the functions, but I can't actually figure out what is happening.
Welcome to the world of Essbase; it can be a little daunting at first especially if you're new to the concept of multidimensionality. You are on the right track regarding analyzing your calc script.
Try not to think of the FIX statement as a command block, per se. A FIX is used to select a portion of cells in the cube. Every single piece of data in your cube has a particular address that consists of one member from every dimension, plus the actual data value itself. For instance, a cube with the dimensions Time, Year, Scenario, and Location might have a particular piece of data at Jan->2018->Actual->Washington. The number of possible permutations of data in a cube can quickly get very large. For instance, if you're organization has 4 years of data, 12 months in a year, 100 locations, 10000 accounts, 3 versions, and 10 departments, you are talking about 4 * 12 * 100 * 10000 * 3 * 10 = 1.4 billion different potential addresses (cells) of data – and that's actually fairly small for a cube, as they tend to grow much larger.
That said, FIX statements are used to narrow down the scope of your calculation operation, rather than operating on the ENTIRE cube (all 1.4 billion cells in my hypothetical example), the FIX essentially restricts the calculation to cells that match certain criteria you specify. In this case, the first FIX statement restricts the calculation to a particular month, yr, version, sectors, sources, and channels. Note that the ampersand on Mth, Yr, and Version means that a substitution variable is to be used. This means your server or cube has a substitution variable value set, such as the variable Mth = "Jan" and Yr = "FY2018" and Version might be "Working" or "Final" or something similar. I would guess that Sector1 and Sector2 are possibly two different members from the same dimension. #RELATIVE("Source Code", 0) is a function that finds the level-0 members (leaf/bottom-level members in a dimension, that is, members that do not have children below them) of the specified member.
In other words, the first FIX statement is narrowing the scope of the calculation to a particular month in a particular year in a particular version (as opposed to all months, all years, all versions), and for that particular month/year/version (for either Sector1 or Sector2) it is fixing on all of the level-0/bottom/leaf members in Source Code and Channel dimensions.
The next FIX statement just further narrows the current scope of cells to calculate on in addition to the outer FIX. It's not uncommon to see FIX statements nested like this.
Lastly we get to the part where something actually happens: the DATACOPY. In the given FIX context, this DATACOPY command is saying that for EACH cell in the current FIX, copy values from the source to the destination. DATACOPY is a little more straightforward when it's just DATACOPY "Source" TO "Target" as opposed to using the inter dimensional operator (->)... but this is perhaps more easily understood in terms of the time/year dimensions. For example, imagine the data copy was written like this:
DATACOPY "FY2018"->"Dec" TO "FY2019"->"Jan";
In this DATACOPY I'd be telling Essbase that for the given FIX context I would like to copy values from the end of the year (data values where the year is FY2018 AND the month is Dec) to the beginning of the next year (data values where the year is FY2019 AND the month is Jan). Your DATACOPY is working in a similar fashion, but using cost centers or something else. It all just depends on how the cube is setup.
I have dimension with hierarchy A - B and a time dimension.
I have made 3 different filters from that dimension in Performancepoint 2010, to use as cascading filters.
Cascading works fine, but sometimes dimension members are valid depending on the time dimension and cascading filters will give many "empty" members.
Ie. Jan 2010 only B1,B2 and B3 show measures, others members (B4,B5..) show empty.
How i can connect time dimension to cascading filters so it will only show the valid members at that current time?
I got it using NonEmptyCrossjoin - MDX function.
This function returns a set that contains the cross product of one or more sets, excluding empty tuples and tuples without associated fact table data.
In my SSAS cube, I've several measures defined in MDX which work fine except in one type of aggregation across time periods. Some don't aggregate (and aren't meant to) but one does aggregate but gives the wrong answers. I can see why, but not what to do to prevent it.
The total highlighted in the Excel screenshot below (damn, not allowed to include an image, reverting to old-fashion table) is the simplest case of what goes wrong. In that example, 23,621 is not the grand total of 5,713 and 6,837.
Active Commitments Acquisitions Net Lost Commitments Growth in Commitments
2009 88,526 13,185 5,713 7,472
2010 92,125 10,436 6,837 3,599
Total 23,621 23,621
Active Commitments works fine. It is calculated for a point in time and should not be aggregated across time periods.
Acquisitions works fine.
[Measures].[Growth in Commitments] = ([Measures].[Active Commitments],[Date Dimension].[Fiscal Year Hierarchy].currentMember) - ([Measures].[Active Commitments],[Date Dimension].[Fiscal Year Hierarchy].prevMember)
[Measures].[Net Lost Commitments] = ([Measures].[Acquisitions] - [Measures].[Growth in Commitments])
What's happening in the screenshot is that the total of Net Lost Commitments is calculated from the total of Acquisitions (23,621) minus the total of Growth in Commitments (which is null).
Aggregation of Net Lost Commitments makes sense and works for non-time dimensions. But I want it to show null when multiple time periods are selected rather than an erroneous value. Note that this is not the same as simply disabling all aggregation on the time dimension. The aggregation of Net Lost Commitment works fine up the time hierarchy -- the screenshot shows correct values for 2009 and 2010, and if you expand to quarters or months you still get correct values. It is only when multiple time periods are selected that the aggregation fails.
So my question is how to change the definition of Net Lost Commitments so that it does not aggregate when multiple time periods are selected, but continues to aggregate across all other dimensions? For instance, is there a way of writing in MDX:
CREATE MEMBER CURRENTCUBE.[Measures].[Net Lost Commitments]
AS (iif([Date Dimension].[Fiscal Year Hierarchy].**MultipleMembersSelected**
, null
, [Measures].[Acquisitions] - [Measures].[Growth in Commitments]))
ADVthanksANCE,
Matt.
A suggestion from another source has solved this for me. I can use --
iif(iserror([Date Dimension].[Fiscal Year Hierarchy].CurrentMember),
, null
, [Measures].[Acquisitions] - [Measures].[Growth in Commitments]))
CurrentMember will return an error when multiple members have been selected.
I didn't understand much of the first part of the question, sorry...but at the end I think you ask how to detect if multiple members from a particular dimension are in use in the MDX.
You can examine either of the two axes as a string, and use that to form a true/false test. Remember you can use VBA functions in Microsoft implementations of MDX.
I suggest InStr(1, SetToStr(StrToSet("Axis(1)")), "whatever") = 0 as a way to craft the first argument of your IIF.
This gets the set of members on axis number one, converts it to a string, and looks to see if a certain string is present (it returns the position of that string within the other). Zero means not found (so it returns true). You may need to use axis zero instead, or maybe check both.
To see if multiple members from the same dimension were used, the test string above would have to be more complicated. You want to know if whatever occurs once or twice. You could test if the first occurance of the string was at the same position as the last occurance (by searching backwards); though that could also mean the string wasn't found at all:
IIF(
InStr(1, bigstring, littlestring) = InStrRev(bigstring, littlestring),
'used once',
'used twice or not at all'
)
I came across this post while researching a solution for my own issue with grand totals of calculated measures over time when filters are involved. I think you could have fixed the calculations instead of suppressing them by using dynamic sets. This worked for me.
I am working on SQL Analysis service to provide ad hoc reporting in my application. I have created a time dimension to use in my cube. It has some predefined attributes. e.g. Month of year. It is having values like Month 1, Month 2, etc. while I want January for Month 1, February for Month 2, etc...
Can any one please suggest me some work around it??
As I am newbie to SSAS, Sorry if I am missing something very silly....
When you work with attributes in SSAS, there are two properties that affect the members of that attribute. The first property - which is set by default when you create the attribute - is KeyColumn. The column that you use here determines how many members are in the attribute because processing generates a SELECT DISTINCT statement based on this column. It's a good idea if you use an integer value here for better performance.
It sounds like perhaps you have a month number for your attribute here, which is good. Except that you want to display a month name. In that case, you set the NameColumn property with the column in your data source view that contains the month name. This produces the label that you see when you browse the dimension.
That said, it's usually not a good idea to have just a month number or month name because you probably want to create a hierarchy to roll up months by year and you won't be able to do that with just a month name. I wrote a blog post describing how to set up a date dimension that might help you: http://blog.datainspirations.com/2011/05/11/sqlu-ssas-week-dimension-design-101-2/