I ran the following DMV query on SSAS.
SELECT
[HIERARCHY_UNIQUE_NAME],
[LEVEL_NAME],
[LEVEL_NUMBER],
[LEVEL_CARDINALITY],
[LEVEL_TYPE]
from $system.mdschema_levels
where [DIMENSION_UNIQUE_NAME] = '[DATE]'
AND [CUBE_NAME] = 'Adventure Works'
AND [LEVEL_NAME] <> '(All)'.
I get a lot of unexpected LEVEL_TYPES
I wanted to understand what do the LEVEL_TYPE like 4289, 4578, 4385, 4759 signify? Are they computed algorithmically or is they a documentation resource one can refer to?
These Level_TYPE are determined the "Type" property of the dimension attribute that you set in dimension design window of your SSAS project. In case if you set the Type to regular you get 0 else , if you select from one of the types present you get its identifier. The interesting bit is if the HIERARCHY_UNIQUE_NAME has a attribute hierarchy, it returns the identifier for the attribute hierarchy, if HIERARCHY_UNIQUE_NAME has user hierarchy, then the identifier is returned for the LEVEL_NAME's base attribute. For example in the result below, take a look at the two rows that return 68 in LEVEL_TYPE, the first row is being reported as attribute hierarchy, the second as user hierarchy's level(Notice the Level_Number 3 and the difference between the HIERARCHY_UNIQUE_NAME and LEVEL_NAME)
Edit: Specific type details
4289: type Date,
4578: type QuaterOfYear,
4385: type HalfYearOfYear,
4759: type WeekOfYear
Related
I have a cube with three (relevant) dimensions (quarter, element and qualifier). The measure of interest is score, which is numeric.
The qualifier dimension is sparse, i.e. for each unique combination of quarter and element, the measure score is reported only for one qualifier, for the other members of the qualifier dimension the measure score is blank. Which qualifier is 'active' entirely depends on the quarter and element.
I want to build a table with quarter members as columns and element members as rows. The cell values should be the concatenation of the score measure and the name of that qualifier member (string) for which the score at the relevant intersection of quarter, element and qualifier is not blank.
To make matters more complex, one of the member names of the qualifier needs to be replaced with blanks in the table. There are four distinct members, which should be renamed in the table as follows: the member names '+', '-', '' stay as they are, while the name 'No Qualifier' should become blank, i.e. ''.
Below is an example of the structure I would like to get (note that there should be no '+' or '-' in case the corresponding score is reported in either the qualifier members '' or 'No Qualifier'):
2021Q4
2020Q4
2019Q4
Element 1
3
2+
2
Element 2
1
1
1
Element 3
2
3
2+
Element 4
2-
2-
3
I suppose I would need to create a calculated member, but so far I only get the concatenation and replacement to work with the currentmember function if I include the qualifier dimension explicitly in either rows or columns, which however is not a feasible output structure. Also, changing the underlying cube is not possible (it is maintained by IT).
I am new to cubes and MDX and have already spent two days trying to figure this out by myself. Since this is a work project, I am starting to panic. Any help would really be appreciated!
I have a measure [Measures].[myMeasure] that I would like to create several derivatives of based on the related attribute values.
e.g. if the related [Location].[City].[City].Value = "Austin" then I want the new calculated measure to return the value of [Measures].[myMeasure], otherwise, I want the new calculated measure to return 0.
Also, I need the measure to aggregate correctly meaning sum all of the leaf level values to create a total.
The below works at the leaf level or as long as the current member is set to Austin...
Create Member CurrentCube.[Measures].[NewMeasure] as
iif(
[Location].[City].currentmember = [Location].[City].&[Austin],
[Measures].[myMeasure],
0
);
This has 2 problems.
1 - I don't always have [Location].[City] in context.
2. When multiple cities are selected this return 0.
I'm looking for a solution that would work regardless of whether the related dimension is in context and will roll up by summing the atomic values based on a formula similar to above.
To add more context consider a transaction table with an amount field. I want to convert that amount into measures such as payments, deposits, return, etc... based on the related account.
I don't know the answer but just a couple of general helpers:
1 You should use IS rather than = when comparing to a member
2 You should use null rather than 0 - 0/NULL are effecitvely the same but using 0 will slow things up a lot as the calculation will be fired many more times. (this might help with the second section of your question)
Create Member CurrentCube.[Measures].[NewMeasure] as
iif(
[Location].[City].currentmember IS [Location].[City].&[Austin],
[Measures].[myMeasure],
NULL
);
I'm familiar with how to get member properties into an MDX result-set: create a calculated member using WITH.
The problem is when the member whose properties I want is a measure, not a dimension member. Because the calculated member is created on the Measures hierarchy, I get the dreaded "The Measures hierarchy already appears in the Axis0 axis" error. Here's the query I'm running:
WITH MEMBER Measures.MeasureType AS
Measures.CurrentMember.Properties('MEMBER_TYPE')
SELECT
MeasureType ON 0,
Measures.Members on 1
FROM TheCube
What I'm after is simply a list of all the measures ON 1 (this works, in itself); but with the measure's MEMBER_TYPE showing as the one column ON 0
You can't have members from the same hierarchy on both axes. There are two ways to get rid of this error.
1. Create the calculated member on some other dimension
WITH MEMBER [SomeDimension].[SomeHierarchy].MeasureType AS
Measures.CurrentMember.Properties('MEMBER_TYPE')
SELECT
[SomeDimension].[SomeHierarchy].MeasureType ON 0,
Measures.Members on 1
FROM [TheCube]
2. Have them in a set and not on different axes.
WITH MEMBER Measures.MeasureType AS
Measures.CurrentMember.Properties('MEMBER_TYPE')
SELECT
{Measures.MeasureType, Measures.Members} ON 0
FROM [TheCube]
Discarding the second method as it gives a static value. What's really needed is a cross-tab value. So sticking with first method.
I have a question related to creating a (more efficient) custom Distinct Count Measure using MDX.
Background
My cube has several long many to many relationship chains between Facts and Dimensions and it is important for me to be able to track which members in certain Dimensions do and do not relate to other Dimensions. As such, I have created a "Not Related" record in each of my dimension tables and set those records' ID values to -1. Then in my intermediate mapping fact tables I use the -1 ID to connect to these "Not Related" records.
The issue arises when I try to run a normal out-of-the-box distinct count on any field where the -1 members are present. In the case that a -1 member exists, the distinct count measure will return a result of 1 more than the true answer.
To solve this issue I have written the following MDX:
CREATE MEMBER CURRENTCUBE.[Measures].[Provider DCount]
AS
//Oddly enough MDX seems to require that the PID (Provider ID) field be different from both the linking field and the user sliceable field.
SUM( [Providers].[PID Used For MDX].Children ,
//Don't count the 'No Related Record' item.
IIF( NOT([Providers].[PID Used For MDX].CURRENTMEMBER IS [Providers].[PID Used For MDX].&[-1])
//For some reason this seems to be necessary to calculate the Unknown Member correctly.
//The "Regular Provider DCount Measure" below is the out-of-the-box, non-MDX measure built off the same field, and is not shown in the final output.
AND [Measures].[Regular Provider DCount Measure] > 0 , 1 , NULL )
),
VISIBLE = 1 , DISPLAY_FOLDER = 'Distinct Count Measures' ;
The Issue
This MDX works and always shows the correct answer (yeah!), but it is EXTREMELY slow when users start pulling Pivot Tables with more than a few hundred cells that use this measure. For less than 100 cells, the results are nearly instantaneously. For a few thousand cells (which is not uncommon at all), the results could take up to an hour to resolve (uggghhh!).
Can anyone help show me how to write a more efficient MDX formula to accomplish this task? Your help would be GREATLY appreciated!!
Jon Oakdale
jonoakdale#hotmail.com
Jon
You can use predefined scope to nullify all unnecessary (-1) members and than create your measure.
SCOPE ([Providers].[PID Used For MDX].&[-1]
,[Measures].[Regular Provider DCount Measure]);
THIS = NULL;
END SCOPE;
CREATE MEMBER CURRENTCUBE.[Measures].[Provider DCount]
AS
SUM([Providers].[PID Used For MDX].Children
,[Measures].[Regular Provider DCount Measure]),
VISIBLE = 1;
By the way, I used in my tests [Providers].[PID Used For MDX].[All].Children construction since don't know, what is dimension / hierarchy / ALL-level in your case. It seems like [PID Used For MDX] is ALL-level and [Providers] is name of dimension and hierarchy, and HierarchyUniqueName is set to Hide.
Suppose I have a [Sales] cube which has a [Store] level and a store has a "type" property.
Which query should I use for showing the sum of sales for all the stores of type "Supermarket"?
(e.g. You sold 6M $ in all stores of type "Supermarket")
If you want to access member properties, you can use .properties("propertyname")
You would have to create a custom set which first filtered and then aggregated all the members of the [Store] level which matched the property value "Supermarket".
My MDX skills are a bit rusty...
WITH MEMBER [Stores].[SupermarketSweep] AS 'Aggregate([Filter([Stores].[Store].members, [Stores].currentMember.properties("type") = "Supermarket"))'
SELECT {[Stores].[SupermarketSweep]} ON ROWS,
{[Measures].[Whatever]} ON COLUMNS
FROM [Sales]
If you wanted to use the "type" property in queries you would be better to make it a browseable attribute.