Transaction Fact Table approach

2
votes

I'm working on financial data mart structure. And I'm having some doubts on whats the better approach to do so. The source system database,Dynamics AX 2009, has three tables for customer transaction. One table for open transactions, where the Customer still needs to pay for service/product; One table for settle transactions, where it holds what the customer have already paid; Finally a table that have all customers transactions, holds transactions from open to settle and also others transactions as customer to bank or ledger accounts.

I thought in two options, first I will maintain a fact table representing the three table, fact for open transactions, fact for any customer transaction and fact for settle transaction. Second is to create a single fact to hold all transactions, to do so I would have to do a full join on three tables. I'm not sure on both approaches, as the first seems to copy tables from production and create the proper dimension. On the Second one I would create a massive fact table, that where data would constantly change, as open transaction are delete on source system when they are settle.

Another doubt, should i create a fact with scd(slowly changing dimension) structure to maintain history data?(star date, end date , flag)

2
data-warehousebusiness-intelligencedimensional-modelingfact-tabledatamart
1. first seems to copy tables from production and create the proper dimension - what do you mean? How does it create a dimension? I think you are confused about the meaning of fact and dimension terms. 2. I would use a single table in the warehouse and update the rows when transactions are settled. Read more about accumulating snapshot fact tables. - Marek Grzenkowicz
Thanks for the comment, what i mean was to transform each produciton table into a fact table and create the dimesions for the facts. - vinomalino

2 Answers

2
votes

It's hard to say from the information given whether this needs to be one or more Fact tables. However, the key point which you should use to decide is whether all of the information is at the same granularity. Consider the grain of your intended Fact table(s) and you should find an answer for whether you need one table or multiple tables.

If all of the information sits at the same grain - i.e. all of the same dimensions apply to all of the measures you are considering putting into the same Fact table - then they can probably all live in the same Fact table. If you're finding that some of the Dimensions wouldn't apply to some of the measures then you probably need to re-think your design. Either you might need multiple Fact tables, or you might need to take all of your measures down to the lowest grain and combine hierarchies into single Dimensions if you currently have them split across multiple Dimensions.

While it's been mentioned that having measures in separate cubes could make it difficult to compare things, keep in mind that you don't need one cube per Fact table. You can have multiple Fact tables in a single cube, and sometimes this is very helpful when you need to be able to compare measures which share some Dimensions but not others. This is far, far better than forcing data which does not have the same grain into one Fact table.

Also, it sounds like what you're trying to model is the sales ledger of an organisation. I'd suggest having a dig around via Google as you may well be able to find materials discussing dimensional data warehouse design for sales ledger structures, rather than reinventing the wheel. If you don't have a decent understanding of the accounting concepts you're trying to model I would especially recommend looking for a reference schema to work from, or failing that doing some reading up on accountancy concepts (and sales ledgers specifically). Understanding the account structure should help you understand what the grain of your Fact table(s) needs to be, how to model the Dimensions, and so on.

This is a really helpful abridged version of Kimball's modelling techniques which discusses grain, and the different types of Fact table, amongst many other topics:

http://www.kimballgroup.com/wp-content/uploads/2013/08/2013.09-Kimball-Dimensional-Modeling-Techniques11.pdf

1
votes

I think you should just use one fact table (one cube) and use a dimension to differentiate between open/settled/etc. transactions. That's what dimensions are for: They help you to categorize your measures and get a specific view on them. This approach will also open much more possibilities to create knowledge with your cube. With separate cubes for open/settled/etc. transactions, it will be harder or not possible to set this data into contrast.

Since the data is changing constantly, you should consider to update your fact table in a given time and rebuild your cube if it needs to.

If you use scd or not really depends on the data you process and what it is used for. Is there a business case claiming it? Is there a technical use? I think this is something you have to decide on your own.