Two table FACT

[Vanessa250919]

Hello community,

I have one question, I just create a new dataset. I have two FACT table and muplite DIM TABLE .

I think it's better to make a constalation schema . But I don't know which relation to use between tables to have consistent data and no duplicate, 1 to 1, many to one ... Simple direction both ...

Calendar & Employee  will be used like link table ? 

thanks in advance for your help 

[v-deddai1-msft]

Hi @Vanessa250919 ,

Star Schema is the best way of designing a data model for reporting, You will get the best performance and also flexibility using such a model.

Your situation is a good fit for the star schema, you can create one to many relationship between your DIM TABLE and Fact table. Keep it single direction and Avoid using many-to-many relationship. 

For more details, please refer to https://radacad.com/power-bi-basics-of-modeling-star-schema-and-how-to-build-it

If this post help, please consider accept it as the solution to help other member find it more quickly.

Best Regards,

Dedmon Dai

[Vanessa250919]

I try to make the same schema, but I have one error message . 

[v-deddai1-msft]

Hi @Vanessa250919 ,

Would you please try to combine these two fact tables into one? If it can't be done, you can try to change the relationship between a fact table and other dimtables from single to both  which will take these tables treated as a single table. For more details, please refer to the similar post:https://community.powerbi.com/t5/Desktop/Relationship-between-multiple-facts/m-p/1133635

If this post help, please consider accept it as the solution to help other member find it more quickly.

Best Regards,

Dedmon Dai

[Vanessa250919]

Hello,

Thanks for your answer, but I have two FACT tables and I don't know the relationship between my two fact tables.

[PaulDBrown]

@Vanessa250919 

In general, you should be creating Dimension tables (including the calendar table) for fields which are common to both fact tables and join the dimension table to your fact tables by a one-to-many (single direction) or one-to-one.

Avoid many-to-many at all costs.

Here is a simple example: