Comments on: Fact Tables http://blog.todmeansfox.com/2007/08/27/fact-tables/ Supporting decisions through sound data management Thu, 11 Mar 2010 00:13:58 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: Tod McKenna http://blog.todmeansfox.com/2007/08/27/fact-tables/comment-page-1/#comment-13857 Tod McKenna Sat, 27 Jun 2009 05:23:17 +0000 http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-13857 Hi Marius, I'll be sure to post some good examples in another blog post. I think it too long a topic for a comment. Hi Marius, I’ll be sure to post some good examples in another blog post. I think it too long a topic for a comment.

]]> By: Marius http://blog.todmeansfox.com/2007/08/27/fact-tables/comment-page-1/#comment-13812 Marius Mon, 22 Jun 2009 09:18:26 +0000 http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-13812 Hi there. Do you have an example on how to properly load and build an Accumulating snapshot? Thanx, Marius Hi there.

Do you have an example on how to properly load and build an Accumulating snapshot?

Thanx,
Marius

]]> By: Avoid Data Dead Ends and Information Loss « Tod means Fox http://blog.todmeansfox.com/2007/08/27/fact-tables/comment-page-1/#comment-13579 Avoid Data Dead Ends and Information Loss « Tod means Fox Mon, 01 Jun 2009 15:14:09 +0000 http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-13579 [...] level gets you pretty far. You are likely already doing this (especially if you are familiar with transaction grain fact tables). But there are other ways you can lose data, and therefore information. In a follow-up to this [...] [...] level gets you pretty far. You are likely already doing this (especially if you are familiar with transaction grain fact tables). But there are other ways you can lose data, and therefore information. In a follow-up to this [...]

]]> By: Live from Kimball University: Day 2 (SCDs, the Mini, Modeling Process) « Tod means Fox http://blog.todmeansfox.com/2007/08/27/fact-tables/comment-page-1/#comment-13362 Live from Kimball University: Day 2 (SCDs, the Mini, Modeling Process) « Tod means Fox Fri, 22 May 2009 10:32:13 +0000 http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-13362 [...] After a brief case study, Margy took a little more time to go over the different types of Fact table grains. These include the transaction, periodic snapshot, and accumulating snapshot. For more information on the different types, please read my post “Fact Tables“. [...] [...] After a brief case study, Margy took a little more time to go over the different types of Fact table grains. These include the transaction, periodic snapshot, and accumulating snapshot. For more information on the different types, please read my post “Fact Tables“. [...]

]]> By: Tod McKenna http://blog.todmeansfox.com/2007/08/27/fact-tables/comment-page-1/#comment-1948 Tod McKenna Tue, 24 Jun 2008 08:39:25 +0000 http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1948 Hi micaman, I would never mix grains in a Fact table. Your situation sounds like a classic need for 1 transaction-grain fact and 1 periodic-grain fact table. Your daily data, "One row per day of work time" would fit into your transaction-grained fact. Another fact table would contain the average for each month as in "One row per month with average work time". Also, you normally would have a single Time dimension. Create your Time dimension to contain details that match the grain of your transaction fact (one row per day?). Then, create a role-playing dimension on your physical Time table called "DimTimeMonth" (or something similar). This role-playing dimension would simply be a view containing month-specific attributes. As Time and other dimensions (like Employee) are conformed, you can easily "Drill Across" both Fact tables on common attributes. Hope this helps! Hi micaman,

I would never mix grains in a Fact table. Your situation sounds like a classic need for 1 transaction-grain fact and 1 periodic-grain fact table. Your daily data, “One row per day of work time” would fit into your transaction-grained fact. Another fact table would contain the average for each month as in “One row per month with average work time”.

Also, you normally would have a single Time dimension. Create your Time dimension to contain details that match the grain of your transaction fact (one row per day?). Then, create a role-playing dimension on your physical Time table called “DimTimeMonth” (or something similar). This role-playing dimension would simply be a view containing month-specific attributes.

As Time and other dimensions (like Employee) are conformed, you can easily “Drill Across” both Fact tables on common attributes.

Hope this helps!

]]> By: micaman http://blog.todmeansfox.com/2007/08/27/fact-tables/comment-page-1/#comment-1944 micaman Mon, 23 Jun 2008 13:38:24 +0000 http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1944 Can i have different metrics granularity in the same fact table? ex: A metric for daily work time, and another for monthly average time? (for the monthly metric there are no values if we drill to the day)... I've managed to do it with 2 fact, 2 dim and 2 time dimensions, but i guess it's not the proper way. congrats for the good work Can i have different metrics granularity in the same fact table? ex: A metric for daily work time, and another for monthly average time? (for the monthly metric there are no values if we drill to the day)… I’ve managed to do it with 2 fact, 2 dim and 2 time dimensions, but i guess it’s not the proper way.

congrats for the good work

]]> By: Tod means Fox | ETL Subsystem 13: Fact Table Builders http://blog.todmeansfox.com/2007/08/27/fact-tables/comment-page-1/#comment-1847 Tod means Fox | ETL Subsystem 13: Fact Table Builders Tue, 17 Jun 2008 04:45:38 +0000 http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1847 [...] the business process dimensional model. I discussed fact tables already in a previous post (”Fact Tables“), so I won’t repeat myself here. Recently, I also provided a more formal definition of [...] [...] the business process dimensional model. I discussed fact tables already in a previous post (”Fact Tables“), so I won’t repeat myself here. Recently, I also provided a more formal definition of [...]

]]>