Comments on: The Financial Data Mart - Part 4

By: Siva

Siva — Mon, 14 Jul 2008 22:44:23 +0000

very helpful,Thanks for the information Kiriti!!

By: Kiriti

Kiriti — Wed, 11 Jun 2008 19:51:18 +0000

The best practice is to use dimension keys that are generated while loading the dimensions to the warehouse. However, you should also keep a column (call it source_record_id) that is mapped to the code_combination_id to keep the original reference to the source. Similarly, use generated dimension keys for company, accounts , cost center dimensions in the fact table, but keep the original flex_value_id in the dimension (load it to a source_record_id reference column). Make sense?

By: Greg

Greg — Fri, 23 May 2008 05:36:32 +0000

Thanks for information. I have a question about the gl_code_combinations table in your diagram above. I see it used to construct the chart of accounts, account, company, and cost center dimensions, and wanted to know how if the gl_code_combinations.code_combination_id is used to keep the relationship between the fact and dimension tables, or does the the fact table get assigned new foreign keys to each dimension taking place of the code_combintion_id’s? I really enjoyed the post. Thanks.

By: Mike

Mike — Sun, 20 Jan 2008 00:09:46 +0000

For financial data marts I would argue there is an ‘Accounting’ dimension that you allude to here. For example, it might contain a hierarchy that shows Accounting Basis (e.g., GAAP, Tax, etc.)>Financial Statement>Business Segment>Financial Statement Line>Ledger>GL Account>GL Entry>Subledger>Subledger Entry>Subledger Entry Line Item, etc. The detailed postings fact and balances fact tables would be organized along this dimension along with Time Dim, Product Dim, and Portfolio Dim. Do you agree?

By: Eric

Eric — Thu, 27 Sep 2007 22:07:29 +0000

Thank you! Looking forward to reading Sales Data Marts articles!