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.
Related
I am new to Tableau and don't want to mess the database. Is there a safe way to find out the table names from the dataset used to build a tableau dashboard?
Hard to say without seeing what you see but generally, the dimensions on the left panel are organized in a table hierarchy. In the image below you can see three tables. One has been expanded to show the fields (dimensions) used. The other two tables can be expanded by clicking on the >
I have a general question, with regards to planned and actual tables and their merging.
I have a planned table for products and their amounts, and the same for what really exists(actual). There are gaps on both sides, as in, not every planned has an actual and not every actual has a planned. I used a select union to combine the two tables, and I created another column called "type" where I then labeled the figures actual or planned. However I feel that is not a good way of doing things. I also should add that I have a data criteria with the planned table.
Is there a good way of structuring an SQL for the merging of the two tables to view in Power BI??
What you have done is look good, merging 2 tables with a additional column to identify planned/actual, what final output you are planning that matter the most,
if you have achieve your result by doing this, then it is good method.
thanks #msta42a. The secret was simply creating a common key.
I also found that having the two columns in seprate columns rather, than in the same column and seperated by a "type" was easier to deal with in Power BI, especially with regards to creating a trand column or comparison of the two.
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.
I have a simple PowerPivot model with 2 tables:
DimDate & UserTransactions
I have defined a relationship on [Date] between the two tables.
Now, if I create multiple pivot charts in Excel based on both DimDate and UserTransactions (Axis comes from DimDate, Values come from UserTransaction), and then I decide that I want to use a slicer or a timeline tied to DimDate, should I or should I not expect that selecting an item in the slicer/timeline will filter the pivot charts?
The behavior I am seeing is no, it does not by default act upon all pivot charts - to do so, you must right click the slicer, choose "Report Connections", and then place a checkmark on each Pivot Chart that you want associated with the slicer, and they all then react to the slicer selection. This implies that the slicer is acting upon the pivot chart, and not the PowerPivot model itself.
This isn't unreasonable, and in cases could be beneficial (if you don't want all pivots tied to one slicer).
However, on the other hand, this seems a bit dangerous in that it could be extremely easy in a large model to miss associating a slicer with all pivots. Also, it seems inconsistent with the following blog post, which implies that the slicer filtering *is acting upon the PowerPivot model itself, rather than individual pivot tables.
http://tinylizard.com/power-pivot-relationships/
But the most important understanding is that any filters applied to a
lookup table are also applied to related data tables. And, the
reverse is not true. That is where the direction really matters.
It does not matter why this filter is happening. If I have a
relationship between my Calendar table and Sales[SalesDate], it does
not matter “how” a filter got applied to the Calendar table so that
Calendar[Year]=2009… the impact is that the filter will also be
applied to the data table (Sales). It could be from a slicer. It
could be because you put Year on rows. It could be because you wrote
a CALCULATE(). Anything. But, the reverse is not true. A filter on
your Sales table has no impact on your Calendar table. Relationships
have direction.
So:
Is the behavior (that slicers are tied to individual pivot tables, and not tied to the powerpivot model) I am observing the correct (and only) behavior available? You cannot apply filtering at the model level, and therefore what is implied in that blog post is technically incorrect?
Or is there possibly an alternate approach that does support filtering at the model level?
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.