I have the following problem. I have a cube where I want some measures aggregated across all dimensions, but one set of measures should exclude one non-time dimension from aggregation. Specifically I have the following case: A consolidated Premium / Claim fact table containing [Written Premium] and [Loss Incurred]. There are Policy and Claim dimensions. [Loss Incurred] should aggregate across both dimensions, however [Written Premium] should not aggregate over Claims.
Is there a good way to do this with MDX? All of my research has come up blank, only telling me how to set up parent-child hierarchies and Account types. Am I just attempting something that SSAS is not well suited to handle?
Related
Good afternoon everyone, I have some problem with the result of aggregating a calculated member in a cube. Namely: I have two groups of measures Sales and Product, where I have two measures the sales qty and the product weight, I need to calculate the qty of products sold in kg.
I created a calculated member where I multiplied these two measures.
I understand that it would be more correct to implement this immediately in the fact table, but there are some difficulties with this.
I found many examples using the SCOPE operator, but there are also problems with this, as in DSV, I use not tables, but named queries, and I can’t create a named calculation on the fact table in, can there be any other solutions to the problem?
An example picture is presented below.
Thank you in advance.
my picture link is in a comment
question about measures in ssas tabular. Is it better to have the physical measure in the fact table as a column and then do a simple sum measure? e.g
Imagine the scenario I have a measure called Income in the fact table, but the user wants to see ProductA income, Product B income as individual measures (not using income measure with product dimension, which yes gives the same result)
Or is it better to do a dax calculation with a sum and filter based on the product dim. e.g. Product B Income:= CALCULATE(SUM('fact'[Income]);VALUES('Product Type dim');('Product Type dim'[Product Tye] ="ProductB"))
I have tried both methods and both return the same result... just want to know what would be best practice here. (fact table around 300million rows)
The fewer the measures the more performant your report will be in the end. I would recommend, in this situation, just sticking to a simple sum() measure and applying it each product. This would be the most efficient approach, doing a calculation on 300 million rows whilst filtering and invoking Values will definitely slow you down.
DC07 How are end users viewing your model? Are they using it in PowerPivot (excel) or PowerBI? I would suggest performing those calculations in either the visualization element (PowerBI) in PowerPivot as a method of displaying the calculation.
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 have two cubes
Computer Engineering
Environmental Science.
Both cubes have a same Date dimension.
I have two scorecards, each for Computer Engineering and Environmental Science as shown in following figure. I would like to have a result as shown in the figure.
I have a drop down filter which uses Date dimension from Computer Engineering cube. This filter works perfectly for filtering KPIs of Computer Engineering Scorecard since Date dimension and measures are from same cube. But it is not able to filter KPIs from Environmental Science cube because the Date dimension in filter and measures in KPIs are from two different cubes.
I have tried following ideas.
LinkMember - LinkMember MDX function can get equivalent member from different dimension but within the same cube. It is limited to only one cube.
LookupCube - By using a LookupCube MDX function on first cube, I am able to get the measures of second cube on it. But these measures don't pivot over Date dimension from first cube.
Linked Objects - I added measures from second cube to the first cube as linked objects, but it did not create dimension usage relationship with Date dimension from first cube. Thus unviable.
I don't want to create a gigantic single cube.
Please help me suggest a solution or work around. Thanks in advance.
I'm wondering why Linked Objects didn't help. Let's create everything step by step.
Here is structures of two cubes, which I used:
Virtual cube creation:
The major disadvantage of this method:
You can't just add a measure to one of cubes, which are used in a Virtual cube.
You have to re-link the cube to avoid this error.
Hope this information helps.
Patron Revenue Cube:
In one of the calculated measures “Acutal Gross Profit”, there are four measures used as
“[Measures].[Acutal Win]-[Measures].[Operator Pay]-[Measures].[Redeeming Dollars]-[Measures].[Redeeming Comp]”
The first two measures belong to vw_fact_patronrevenue view and the other two belong to vw_fact_patronredemption view.
Those two views do not have any foreign key relation to each other. They are related through dimension views.
To verify the calculated measure, I need to get the
column_names for the select statement (which I have),
table/view (i also have them)
joining column_names (which I don’t have, and how do I figure out which columns do I need for not-directly-related tables)
There are however some columns which are common to both tables
I would suggest that you don't need to write a single SQL statement to test your calculated measure. What you should do is to test each of the 4 raw measures, either independantly or in their measure groups.
When you know the 4 raw measures are correct you can then test your calculated measure "inside" the cube by displaying it alongside the 4 raw measures and checking that you have the arithmetic right.