Forum Discussion
Data model / star schema
Hi ethan_lim -
Did you mistype the relationships between Fact 1 and Dim 1-4 ? Usually Dim-to-Fact is 1-to-Many (you have them all as Many-to-1)
Assuming that is a typo, in Power BI, there isn't really a physical distinction between Dimension and Fact tables - just how they are used once in the data model. Your schema looks like it should for fact data that is parent/child/child (e.g. Invoice --> Purchase Order --> Purchase Order Line).
Hope this helps
David
You can keep them if you wish, but since your tables are already linked by one-to-many relationships you don't really need them. You can use the actual columns in filters/slicers/measures as is. Filters and slicers contain distinct values by definition.
It would be different if you needed to "bridge" tables using a common field, or if the tables didn't allow one-to-many relationships, but that doesn't seem to be your case.
Having said that, if your data contains dates, creating a "Date Table" (as a Dimension Table) is considered a "best practice" and (general consensus) a "must have" (especially important if you are going to use Time Intelligence functions).
The "Date Table" should include consecutive dates (and whatever other columns: month, month name, year etc) and cover the whole range of dates included in your dataset.
based on your description, I would venture that the DIM tables in your depiction are redundant
Hi Paul,
Thanks for replying,
Why would the dimensions be redundant in this case, wouldn't the dimensions would still be used for filtering in the model?
You can keep them if you wish, but since your tables are already linked by one-to-many relationships you don't really need them. You can use the actual columns in filters/slicers/measures as is. Filters and slicers contain distinct values by definition.
It would be different if you needed to "bridge" tables using a common field, or if the tables didn't allow one-to-many relationships, but that doesn't seem to be your case.
Having said that, if your data contains dates, creating a "Date Table" (as a Dimension Table) is considered a "best practice" and (general consensus) a "must have" (especially important if you are going to use Time Intelligence functions).
The "Date Table" should include consecutive dates (and whatever other columns: month, month name, year etc) and cover the whole range of dates included in your dataset.