<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Fact Tables</title>
	<link>http://blog.todmeansfox.com/2007/08/27/fact-tables/</link>
	<description>Business Intelligence, Data Warehousing, SQL, Visual FoxPro.</description>
	<pubDate>Fri, 21 Nov 2008 00:15:21 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2</generator>

	<item>
		<title>By: Tod McKenna</title>
		<link>http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1948</link>
		<author>Tod McKenna</author>
		<pubDate>Tue, 24 Jun 2008 08:39:25 +0000</pubDate>
		<guid>http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1948</guid>
		<description>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!</description>
		<content:encoded><![CDATA[<p>Hi micaman,</p>
<p>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, &#8220;One row per day of work time&#8221; would fit into your transaction-grained fact. Another fact table would contain the average for each month as in &#8220;One row per month with average work time&#8221;.</p>
<p>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 &#8220;DimTimeMonth&#8221; (or something similar). This role-playing dimension would simply be a view containing month-specific attributes. </p>
<p>As Time and other dimensions (like Employee) are conformed, you can easily &#8220;Drill Across&#8221; both Fact tables on common attributes.</p>
<p>Hope this helps!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: micaman</title>
		<link>http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1944</link>
		<author>micaman</author>
		<pubDate>Mon, 23 Jun 2008 13:38:24 +0000</pubDate>
		<guid>http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1944</guid>
		<description>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</description>
		<content:encoded><![CDATA[<p>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)&#8230; I&#8217;ve managed to do it with 2 fact, 2 dim and 2 time dimensions, but i guess it&#8217;s not the proper way.</p>
<p>congrats for the good work</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tod means Fox &#124; ETL Subsystem 13: Fact Table Builders</title>
		<link>http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1847</link>
		<author>Tod means Fox &#124; ETL Subsystem 13: Fact Table Builders</author>
		<pubDate>Tue, 17 Jun 2008 04:45:38 +0000</pubDate>
		<guid>http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-1847</guid>
		<description>[...] the business process dimensional model. I discussed fact tables already in a previous post (&#8221;Fact Tables&#8220;), so I won&#8217;t repeat myself here. Recently, I also provided a more formal definition of [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] the business process dimensional model. I discussed fact tables already in a previous post (&#8221;Fact Tables&#8220;), so I won&#8217;t repeat myself here. Recently, I also provided a more formal definition of [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tod means Fox &#124; Dimension Tables</title>
		<link>http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-123</link>
		<author>Tod means Fox &#124; Dimension Tables</author>
		<pubDate>Mon, 17 Sep 2007 15:26:04 +0000</pubDate>
		<guid>http://blog.todmeansfox.com/2007/08/27/fact-tables/#comment-123</guid>
		<description>[...] my post, Fact Tables, I discussed three types of fact tables as defined by their grain: transactional, accumulating, and [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] my post, Fact Tables, I discussed three types of fact tables as defined by their grain: transactional, accumulating, and [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
