Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Enhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.

Reply
knotty
Frequent Visitor

Data Model Query

Hi All, I'm hoping someone can offer some assistance with a query relating to a data model please.  Apologies if this is really basic, I've not long studied Star Schemas and I'm trying to follow best practice:

 

Imagine for example the typical Star Schema model including tables like dim_Customer, dim_Product, dim_Date, fact_Sales. 

 

I want to bring in another table containing data of all customer contact instances (e.g. marketing, tele canvassing, mailshots etc.) which, is essentially a different one to many relationship to dim_Customer.  Does anyone have any suggestions on the best practice method of doing this please?  All the videos and guides I see tend to just append InternetSales with ResellerSales and put all these into one fact table but, in my example above, it's completely different data and I can't see how I'd append it to the existing fact_Sales table.  Am I right to assume that one dimension table should only ever really link to one fact table else I run the risk of indirect many to many relationships?

 

Any help would be much appreciated, thanks!

1 ACCEPTED SOLUTION
AmiraBedh
Super User
Super User

I agree with you : in a typical star schema, one dimension table should only be linked to one fact table to avoid indirect many-to-many relationships, which can lead to issues with data accuracy.

In your case, since the customer contact instances data is a different one-to-many relationship to dim_Customer, it would be recommended to create a new fact table to store this data instead of appending it to the existing fact_Sales table.

You can create a fact table called fact_CustomerContact with its own set of measures and foreign keys to the appropriate dimension tables such as dim_Customer, dim_Date, etc.

When designing the fact_CustomerContact table, you should consider the granularity of the data and what measures you want to track. For example, you may want to track the number of contacts per customer, the type of contact, the date of the contact, the success rate of the contact, etc. You can then create appropriate measures and dimensions in the fact_CustomerContact table.

Once you have created the fact_CustomerContact table, you can link it to the appropriate dimension tables using their foreign keys.

This will create a separate one-to-many relationship between dim_Customer and fact_CustomerContact, which will not interfere with the existing one-to-many relationship between dim_Customer and fact_Sales.

Overall, the key is to maintain the integrity of the star schema and avoid indirect many-to-many relationships. Creating a new fact table for the customer contact instances data will allow you to store and analyze this data separately from the sales data while still maintaining the star schema structure.

 




Proud to be a Power BI Super User !

Microsoft Community : https://docs.microsoft.com/en-us/users/AmiraBedhiafi
Linkedin : https://www.linkedin.com/in/amira-bedhiafi/
StackOverflow : https://stackoverflow.com/users/9517769/amira-bedhiafi
C-Sharp Corner : https://www.c-sharpcorner.com/members/amira-bedhiafi
Power BI Community :https://community.powerbi.com/t5/user/viewprofilepage/user-id/332696

View solution in original post

4 REPLIES 4
knotty
Frequent Visitor

Thanks very much for your response - I'll go ahead and create a second fact table.

AmiraBedh
Super User
Super User

I agree with you : in a typical star schema, one dimension table should only be linked to one fact table to avoid indirect many-to-many relationships, which can lead to issues with data accuracy.

In your case, since the customer contact instances data is a different one-to-many relationship to dim_Customer, it would be recommended to create a new fact table to store this data instead of appending it to the existing fact_Sales table.

You can create a fact table called fact_CustomerContact with its own set of measures and foreign keys to the appropriate dimension tables such as dim_Customer, dim_Date, etc.

When designing the fact_CustomerContact table, you should consider the granularity of the data and what measures you want to track. For example, you may want to track the number of contacts per customer, the type of contact, the date of the contact, the success rate of the contact, etc. You can then create appropriate measures and dimensions in the fact_CustomerContact table.

Once you have created the fact_CustomerContact table, you can link it to the appropriate dimension tables using their foreign keys.

This will create a separate one-to-many relationship between dim_Customer and fact_CustomerContact, which will not interfere with the existing one-to-many relationship between dim_Customer and fact_Sales.

Overall, the key is to maintain the integrity of the star schema and avoid indirect many-to-many relationships. Creating a new fact table for the customer contact instances data will allow you to store and analyze this data separately from the sales data while still maintaining the star schema structure.

 




Proud to be a Power BI Super User !

Microsoft Community : https://docs.microsoft.com/en-us/users/AmiraBedhiafi
Linkedin : https://www.linkedin.com/in/amira-bedhiafi/
StackOverflow : https://stackoverflow.com/users/9517769/amira-bedhiafi
C-Sharp Corner : https://www.c-sharpcorner.com/members/amira-bedhiafi
Power BI Community :https://community.powerbi.com/t5/user/viewprofilepage/user-id/332696

Thanks very much for your response - I'll go ahead and create a second fact table.

YukiK
Impactful Individual
Impactful Individual

If understand your description correctly, that table is your another fact table. Power BI allows multi fact table analysis, meaning, you can have multiple fact tables in a model. Shared dimensions between fact tables allow you to analyze data across multiple fact tables. I think this is the direction you were looking for?

 

Consider giving it a thumbs up and accept as solution if this is helpful!

Helpful resources

Announcements
July 2025 community update carousel

Fabric Community Update - July 2025

Find out what's new and trending in the Fabric community.

July PBI25 Carousel

Power BI Monthly Update - July 2025

Check out the July 2025 Power BI update to learn about new features.