As query calculated members are not allowed in subselects (SSAS v12), is there any solution to still use them? A session calculated member is not an option, as the same session is shared by multiple callers (which define new calc. members, so a negative interference could occur).
Many thanks in advance.
Related
I'm new to MDX coming from the world of SQL and I am trying to understand the concept of 'ALL'. I am understanding that 'ALL' is a single member, creating a cube with low granularity as far as that dimension is concerned. Is this correct?
What are some examples of SQL that can help me reason about this concept? Of course, SQL uses tables not cubes, but I'm sure there are some similarities which can help me make the connection? Let me try to create an example.
Let's say I have a table with such a schema representing a cube with 3 dimensions:
myTable (dim1_attribute1,dim1_attribute2, dim2_attribute1,dim2_attribute2,dim2_attribute3,
dim3_attribute1,dim3_attribute2,dim3_attribute3)
What kind of SQL would give me an aggregate with 'ALL' granularity on dim3?
'ALL' means that basically you are taking into account all members of that dimension - you are not slicing cube with some particular member of that dimension. In SQL query equivalent would be to omit dim3 from the where clause altogether, so you are not filtering your resulting aggregation with some particular value from dim3 but you are taking all rows into account.
I would like to understand how OLAP-cube operations (i.e. drilling up/down, slicing/dicing and pivoting) and MDX are related.
My current guess is that OLAP-cube operations to MDX are like relational algebra to SQL. However, I do not see how some basic features of MDX correspond to OLAP-cube operations. For example, consider the following query on the demo "Sales" cube that comes with icCube:
SELECT {([Ottawa],[2009]), ([United States],[Feb 2010])} on Rows,
[Measures].members on Columns
FROM [Sales]
How does the use of tuples (e.g. ([Ottawa],[2009])) correspond to an OLAP-cube operation?
Yes, "OLAP-cube operations are what visualization tools are expected to implement". MDX is the query language that is executed against a cube that produces a result. OLAP clients generally run MDX against a cube. "OLAP cube operations" as described in that wikipedia are usually as a result of a person performing adhoc analysis against a cube in an client application.
Cube provide a structure and an access language that usually makes these types of operations easier (or at least faster)
How does MDX relate to a "drill down" operation? for example?
Firstly some MDX has already been run and yielded some kind of view of the cube (generally some rows, some columns, and a measure in the intersection although the MDX language syntax doesn't limit to two axes only).
So a person sees this information and decides to drill down on a single item in the row (this item was previously returned by some MDX). So the OLAP client generates some MDX that provides the drilled down view on the item
It might just add a children MDX function to the item in question. Or it might do it some other way. It depends on the client.
Heres some introductory info on how you can eavesdrop on the interactions between an OLAP client (which one? doesn't matter) and a SSAS cube
https://learn.microsoft.com/en-us/sql/analysis-services/instances/introduction-to-monitoring-analysis-services-with-sql-server-profiler
You can think of the MDX query specifying areas or regions of space within a cube - the tuple is a primary way of giving the processor co-ordinates which correspond to the part of the cube you are interested in.
It is the intersection of the co-ordinates and slices you specify that give you a result.
MDX is strongly related to set theory as the main types withing the cube are dimensions, sets, tuples, members etc.
An MDX query defines a table and for each of the table cell we've a tuple. In your scenario assuming we've two measures ( Meas1, Meas2 ) :
([Ottawa],[2009],[Meas1]) ([Ottawa],[2009],[Meas2])
([United States],[Feb 2010],[Meas1]) ([United States],[Feb 2010],[Meas2])
On this cell tuples you might add the WHERE clause, the SubQuery and the defaults that might be different than ALL (not advised). Remember all is a 'special' member that is ignored.
A tuple defines a single measure, Meas1 or Meas2, this will select the 'fact table' with a measure column, usually a numerical value. The other members are used to select rows in the table performing on them the aggregation defined by the measure ( sum , min, max.... ) on all rows defined by the tuple members, Ottawa and 2009 for example. As whytheq explains, you've a lot of transformations to 'play' with members as you would with sets.
This is the simple vision, as you can use calculated members that define a transformation instead of a simple row aggregation (e.g. Difference with previous year) and some aggregations are a bit more tricky ( open, close...).
But if you understand this well you got a perfect ground to understand MDX.
I'm totally new to MDX language and curios if it capable of doing some sort of work.
There are calculated members that allows you to populate measure dimension with new data. But I have never met a reference to method that creates new dimensions with hierarchies.
For example, I have performed some cluster analysis and want to store result as hierarchy to make queries over calculated clusters. I'm searching for a function that takes predicate, apply it to all members in a slice and assign them new temporal dimension info. Something like the factor function in R.
Is this functionality available for MDX queries?
There is no standard way to create a dimension or hierarchies in MDX. Using calculated members is the usual way to go but this is not the same as creating a 'standard' hierarchy.
I don't know for others vendors but icCube introduced a couple of months Categories (also worth checking the SubCube functions family). They allow to dynamically, after the cube has been loaded, build new hierarchies.
This is really handy when you're doing complex calculations or have many-to-many relations, as calculated members might quickly become a mess.
Ok, so this question is with regard to the use of Dynamic and Static Sets in Analysis Server. It is my understanding that Static Sets are evaluated during the processing of the Cube and don't regard any conditions specified in the WHERE slicer in MDX. Whereas Dynamic Sets are evaluated during the time of Query execution.
I have a cube that has an extremely large number of customer Claim numbers in a Dimension. If my clients wanted to view any number of Measures associated with these Claim Numbers but wanted to look at a range, they'd have to filter a good number of the Claim Numbers.
To alleviate this, I created a Dynamic Set that does nothing more than group several thousand of the numbers into a group that they may use. The problem is that I've seen a great degradation of performance using the Dynamic Sets so I am thinking that a Static Set may suffice for this type of scenario.
So will a Static Set suffice if it is just a set of Dimension members with no calculations contained in it?
At least static sets gives SSAS the ability to cache results; so you might get some performance improvement but rethinking the [Claim] dimension would be better if possible.
I have read about aggregation design tab in ssas.It is telling we can precalculate the aggregation and it will improve the response time.But when i tried that option,i haven't go thorough any step which is showing what kind of aggregation(eg:sum,avg etc) we have to do.In one of the steps, there is an option of specifying count of rows.So aggregation means only count of rows in table?
Other than this we know,there is one calculated measure option using we can specify sum or avg or etc.This also one kind of aggregation right?
So, Can any one please make it clear about there two?
Thank You in advance.. :)
I'm not sure if I understand your question, but the method of aggregation is defined for each measure. See the properties of your measures to know what kind of aggregation method is used.
The estimated row count (of each partition) is used by SSAS to determine the necessary storage space of your aggregation design.