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.
Related
I have sums of table columns as measures but for multiple tables. I combined them as sums of measures. On the pivot sheet i want to drill trough but i can't because it belongs to only one table. Are there any better solution for measure combinations? Thank You!
I assume by the "drill through" you mean what happens when you double click a cell in the pivot. Also, I assume that you've built a star schema with most of the measures in the centre table, and all the tables are keyed together.
You're not going to like this one, but the drill through is determined by the table you associate the measure with, and the records of just that table are returned; so the drill through is actually fairly limited. Each measure can be associated with any table, not just the one it uses, so if there is one table you want to drill into, you could associate all the measures with that.
But that's probably not really what you want. The only solution I've found is to create a pivot with the same slicer dependencies that contains all the fields you want on the drill down, and only those ones - so you've got a detail version of the main table on a different sheet. The other thing you might consider is shutting down the drill down functionality by creating an empty table, and associating all the measures with that.
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 am creating a Data Warehouse and have hit a interesting problem...
I have DimQualification and DimUnit tables. A unit is a part of a qualification.
However some units are optional. In stating all available units in the DimUnit table i am puzzled by how best to show the customers choice.
FactAttendance - The attendance on the qualification
Would it be best to put multiple rows in the fact table (qualification and units taken) or is there another option?
The other option, besides putting multiple rows in the fact table, is to have a single row for each fact in the fact table, and a separate column for each unit. The column would be a count of the number of that unit associated with that fact. Something like this:
FactID Unit1Count Unit2Count Unit3Count ...
I have looked at a few things now and have decided that there is a way to achieve this without the reduction in speed which multiple rows in the fact table would create.
Instead of having the multiple rows for each unit I am going to create another fact table which holds all the units chosen then from the FactAttendance table we can immediately and efficiently identify the units chosen.