Design a fact table in efficient way

jennifer zen 341 Reputation points
2023-08-20T00:24:22.95+00:00

Hi,

I need some advise on designing a fact table (pic 2). I have 5 tables as below (pic 1). Each table has first two common columns (BranchNames being unique) which I think would go under a dimension table. Table 2 & 5 has one column (middle ones) (It has unique values) could be used as a degenerate dimension (Dont want to create a dimension again to just generate a key for one column) so those will be gothe fact table) and finally, table 3 & 4 has product detail columns(middle ones again) which will come under a different dimension.

The problem I am facing is the records are getting duplicated at the very last three fields in the fact table (coming from table 5) as there is one entry in every column of the three for each unique areacode. So overall the table is becoming a very large one with millions of records. Multipied for each entry.

Note : I want to design the fact table at branch level so I have used the branch key.

Could someone suggest a better design to avoid the issues mentioned above , please?

Thank you in advance!

User's image

User's image

SQL Server Analysis Services
SQL Server Analysis Services
A Microsoft online analytical data engine used in decision support and business analytics, providing the analytical data for business reports and client applications such as Power BI, Excel, Reporting Services reports, and other data visualization tools.
1,344 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Alexei Stoyanovsky 3,416 Reputation points
    2023-08-22T06:38:32.9333333+00:00

    Do distinguish between a large number of records and duplicated records, these are two very different problems. For the only issue you actually mention, the number of rows, this is solely determined by the grain of your fact table, it is the number of existing unique combinations of values in your key column(s). When modeling your data, you start with the analyses it will have to support, which should determine the required grain, and next you model the data at least at that grain, maybe finer. If this means millions of unique rows, then you need a BI solution that can handle them, that's all. FYI, millions of rows is peanuts for Tabular.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.