I'm attempting to create a shared date dimensions between two fact tables in Power BI, based off of a relational data source.
Currently, if I include an unrelated dimension in the report, I get numbers duplicated across multiple rows, where they don't really apply.
I'm wondering if there is any way to tell Power BI that certain dimensions cannot be used with certain fact tables, similar to using IgnoreUnrelatedDimensions in SSAS.
Currently the only solution I can find is to create a separate date dimension, so that the two fact tables have no relationship that could be used to join them, however this would mean forfeiting the ability to do any time based comparisons.
Create a combined view of the fact tables with only compatible columns to be used for time based comparison:
In Query Editor, create new queries for your fact tables by
referencing i.e. right click original query and select "Reference".
Then in those "copies" cut out the incompatible dimensions.
Rename columns to align terminology (e.g. Sales Date ==> Transaction Date, Payment Date ==> Transaction Date).
Use "Merge Queries" function to combine the copies using Full Outer Join.
Join this merged view to your date dimension
Related
I need help on this issue as i don't have any experience in Power Bi. I want to join 2 table in Power Bi where it have the same column which is Part_Number. How can i make this 2 table to match by Part Number and return the value?
Recon Table
Inventory Table
I would like to have Part Number, Part Name, QTY, Total Quantity as the result. Hope that i can the clarification i need. Thanks a lot!
For this case you simply must merge the tables. It doesn't look like you have done a lot of research on the matter though, so it's hard to understand exactly what you need help with.
To merge your two tables in Power Query, I would right click in the left hand side menu and select Merge Queries as New.
After that you simply follow the on-screen instructions and select your two tables and their respective key columns. After merging you can choose to disable load of your two original tables to save space in your data model, but this depends on your requirements.
If this was my data model, I would think on why joining these tables are necessary, instead of using these two tables as fact tables, and creating a third table to handle the part number dimension with associated part metadata.
Read the docs: Merge queries in Power Query
I would like two measures that SUM the Sales[Value] for all the Sales[ID] that have a specific StatusID in SalesStatus.
One that can filter on Sales[Date], and one that can filter on SalesStatus[statusDate]
Diagram
Regards,
Anders
In this scenario I would consider modifying your model to have only two tables by combining what appears to be two FACT tables (sales, sales status). Depending on what your data consists of I would either UNION the two tables after joining and then treat the date in your Sales table as another status date (i.e. shipped complete or sale finished, whatever that date represents) OR I would join the two tables and have two relationships to the date table.
This will create a duplicated data issue as you will ideally result in having the value column in your final fact table. If you go with the union option, you can force the user to select a single sales status effectively removing the sales duplication. If you end up with two connections to the date table, you can use the USERELATIONSHIP() function to write the two different sales measures, and the one that uses the date from the Sales table will need some clever tricks to ensure the data does measure does not duplicate. I would try to UNION the tables though.
For more details, I would research what's referred to as SEMI-ADDITIVE fact tables in datawarehousing. There is a great article from SQL BI on the subject. I have tried setting up models like you diagrammed and even if I could get them to work through intense DAX measures, they would produce unexpected results and have poor performance. I find the Semi additive fact table pattern to be a much cleaner solution once you get passed the data duplication that results.
Example:
I have to divide two measures from two different tables. I have created a measure in Table A & created measure-2 in Table B.
When I use matrix visual in Power BI by taking date field in columns and region in rows (for table A&B), I can see the both table values are correct as I am expected.
Ex: Table A 2017-Q1 value by measure1 is 29.2, Table B 2017-Q1 value by measure1 is 2.9.
I have to divide both measures and I need to show the value (divide%) in TableA along with Measure1.
Unfortunately I tried in multiple ways by forming relationship b/w two tables also, But not getting the expected result i.e., 29.2/2.9 we should get 10% but instead of that getting 3%.
Without knowing your data model, it's hard to give a reasonable answer.
https://learn.microsoft.com/en-us/dax/related-function-dax
Your best change of understanding what happens is to learn up on relations, and changes them when needed. The documentation is a great starting point.
Unrelated data plotted in a visual of different data will always aggregate since there is no relation to split your values. The value of 3% is correct, your assumption that you want 10% as an outcome is not valid for your situation.
If you link the dates of table A and the dates of table B to a seperate Calendar, it all would work.
I am attempting to build a data model in Power BI from a data mart (star schema) in SQL Server. This data mart has a fact table and several dimension tables. One of the dimension tables is a date table. I want to load all rows from the fact table. However, I only want to load a subset of the date table. In particular, I want those dates (rows) between the min and max dates in my fact table. This way, when I create slicers and such, I don't have unnecessary dates appearing.
In other BI tools (e.g., Qlik Sense), the usual solution is to first load the fact table into memory, compute and load its min/max dates into another table (also in-memory), set variables from this other table, load the date dimension table (into memory) based on the min/max variables, and finally drop the temporary table from memory so that it doesn't stay in the model and cause problems. This seems like the most efficient solution to me. It only reads the required (as opposed to unnecessary) data from the source dimension table, it doesn't need to perform any joins in the source, and it only reads each table once (as opposed to 2+ times).
How can I achieve this in Power BI? Or, more importantly, is this solution method even possible in Power BI?
I found this solution, but it seems inefficient, as it creates 2 queries (instead of just 1) for the min/max and, moreover, it performs the dimension table filtering after all rows have already been fetched from the source. (In my particular case, this isn't too bad. But, it could be problematic in other situations in which my dimension table is large.)
In Power BI, I am attempting to join a dimension table with a fact table. The dimension table has approximately 1.1M rows in it (a lot I know for a dimension table). All the values are unique. When I attempt to join this to the fact table, PBI automatically creates a M:M relationship. When I attempt to change this to a 1:M, I get a message saying "The cardinality you selected for this relationship isn't valid".
Here is the query that generates the dataset. As you can see, it's impossible for there to be duplicates.
SELECT DISTINCT
[TranDesc] as TransactionDescription
FROM [dbo].[dGLTranDescription];
Why would I get this message?
Try to validate that Power BI seeing values in the dimension table as unique. Depending on your data, source system and PowerBI may see it differently.
Here are suggestions from https://community.powerbi.com/t5/Desktop/The-cardinality-you-selected-isn-t-valid-for-this-relationship/td-p/73470
1.
Create two measures to verify in Power BI:
TotalRows = COUNTROWS('DimTableHere')
DistinctRows = DISTINCTCOUNT('DimTableHere'[DimTableJoinColumnHere])
After create those two measures, place them in two card visuals, if
results are different, it means there are duplicate values in your
Dimension table.
2.
If you had duplicates when first creating relationship and now you don't, deleting the relationship and recreating it may resolve it.
If you have removed duplicates on the relationship column and it still considers it as invalid cardinality, try running Text.Clean on that column prior to duplication removal. I've had a special character but the removal of duplicates on the query, the values counted as different there but once imported they were considered the same.