<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Data Analysts, Crystal Reports and Sql Reporting Services Consultants &#187; Slowly Changing Dimension</title>
	<atom:link href="http://datamart.org/category/slowly-changing-dimension/feed/" rel="self" type="application/rss+xml" />
	<link>http://datamart.org</link>
	<description>Feel free to ask tough questions relating to Crystal Reports / SQL Reporting Services / SQL  and get answers from Collective intelligence</description>
	<lastBuildDate>Wed, 08 Feb 2012 09:01:54 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Fastly changing dimensions</title>
		<link>http://datamart.org/2009/10/08/fastly-changing-dimensions/</link>
		<comments>http://datamart.org/2009/10/08/fastly-changing-dimensions/#comments</comments>
		<pubDate>Thu, 08 Oct 2009 16:49:36 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Business Intelligence]]></category>
		<category><![CDATA[Fastly Changing Dimensions]]></category>
		<category><![CDATA[Slowly Changing Dimension]]></category>

		<guid isPermaLink="false">http://datamart.org/?p=575</guid>
		<description><![CDATA[This post is about fast changing dimension, for example A customer dimension may have large number of attributes and many rows. It happens sometimes in the &#8220;customers&#8221; are health insurance policy claimants, and other times they are owners of motor vehicles. We found a usefull material on Fast change management of Complex dimensions written by [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://datamart.org/wp-content/uploads/2009/10/changing-dimension.jpg"><img src="http://datamart.org/wp-content/uploads/2009/10/changing-dimension-300x85.jpg" alt="" title="changing-dimension" width="300" height="85" class="alignnone size-medium wp-image-647" /></a>This post is about fast changing dimension, for example A customer dimension may have large number of attributes and many rows. It happens sometimes in  the &#8220;customers&#8221; are health insurance policy claimants, and other times they are owners of motor vehicles. We found a usefull material on Fast change management of Complex dimensions written by Ralph Kimbal. <a href="http://www.ralphkimball.com/html/designtipsPDF/DesignTips2000%20/KimballDT4SuperFastChange.pdf">please visit here to read more</a>, to read bout slowly changing dimensions by <a href="http://datamart.org/?p=172">Datamart.org</a></p>
]]></content:encoded>
			<wfw:commentRss>http://datamart.org/2009/10/08/fastly-changing-dimensions/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Precision and Scale in Sql Server</title>
		<link>http://datamart.org/2009/10/02/precision-and-scale-in-sql-server/</link>
		<comments>http://datamart.org/2009/10/02/precision-and-scale-in-sql-server/#comments</comments>
		<pubDate>Fri, 02 Oct 2009 06:22:24 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[MS Access 2007]]></category>
		<category><![CDATA[Slowly Changing Dimension]]></category>
		<category><![CDATA[SQL Server 2000]]></category>

		<guid isPermaLink="false">http://datamart.org/?p=571</guid>
		<description><![CDATA[We are writing this post because recently we received a query regarding automatic rounding in quantity column. The user was previously using MS Access and they upgraded to SQL Server database. Although solution is simple but sometimes it becomes difficult to resolve when confronting the problem. SQL Server Books online very well addressed the concern [...]]]></description>
			<content:encoded><![CDATA[<p>We are writing this post because recently we received a query regarding automatic rounding in quantity column. The user was previously using MS Access and they upgraded to SQL Server database. Although solution is simple but sometimes it becomes difficult to resolve when confronting the problem.<br />
SQL Server Books online very well addressed the concern and is reproduced below;</p>
<p>Precision is the number of digits in a number. Scale is the number of digits to the right of the decimal point in a number. For example, the number 123.45 has a precision of 5 and a scale of 2.</p>
]]></content:encoded>
			<wfw:commentRss>http://datamart.org/2009/10/02/precision-and-scale-in-sql-server/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Slow Changing Dimensions another perspectives</title>
		<link>http://datamart.org/2009/06/21/slow-changing-dimensions-another-perspectives/</link>
		<comments>http://datamart.org/2009/06/21/slow-changing-dimensions-another-perspectives/#comments</comments>
		<pubDate>Sun, 21 Jun 2009 17:10:58 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Business Intelligence]]></category>
		<category><![CDATA[Data mart]]></category>
		<category><![CDATA[Slowly Changing Dimension]]></category>

		<guid isPermaLink="false">http://datamart.org/?p=393</guid>
		<description><![CDATA[Business intelligence is an analysis about business evidence so that companies can make informed decisions. Facts record transactions, and Dimensions contain information about the transactions, such as customer name, time, weather, product and advertising promotions slowly changing dimensions (SCD) result from the fact that over time, the world changes and dimension values must also be [...]]]></description>
			<content:encoded><![CDATA[<p>Business intelligence is an analysis about business evidence so that companies can make informed decisions. </p>
<p>Facts record transactions, and Dimensions contain information about the transactions, such as customer name, time, weather, product and advertising promotions slowly changing dimensions (SCD) result from the fact that over time, the world changes and dimension values must also be updated to reflect those changes.[1]</p>
<p>Not every dimension is slowly changing and not every slowly changing should be handled in the same way. One example of dimension might be time. Time doesn’t change. October 3 1940 will always be October 3 1940. How ever marriage status, sales district, last names do change.[1]</p>
<p>You don’t necessarily want to update every change in the same way, you might want to maintain history in some changes, overwrite others, or simply detect when a change is attempted. For example, if the sale district for a company is reorganized, to insure to ensure that sales report and queries remain accurate, you might want to keep a record of previous sales district for all salespersons. But customer name happen so rarely and because names are simply identifiers for the same entity, you might want to overwrite last name attribute of customer dimensions. This is a fundamental problem with dimensions. [1]</p>
<p><a href="http://datamart.org/?p=172">Examples of Slow changing Dimensions</a></p>
<p>Source </p>
<p>1-  Preview this book Microsoft SQL Server 2005 Integration Services By Kirk Haselden, Trey Johnson </p>
]]></content:encoded>
			<wfw:commentRss>http://datamart.org/2009/06/21/slow-changing-dimensions-another-perspectives/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Slowly Changing Dimension</title>
		<link>http://datamart.org/2009/05/28/slowly-changing-dimension/</link>
		<comments>http://datamart.org/2009/05/28/slowly-changing-dimension/#comments</comments>
		<pubDate>Thu, 28 May 2009 15:17:48 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Data Governance]]></category>
		<category><![CDATA[Data Mart vrs Data Warehouse]]></category>
		<category><![CDATA[Data Model]]></category>
		<category><![CDATA[Slowly Changing Dimension]]></category>

		<guid isPermaLink="false">http://datamart.org/?p=172</guid>
		<description><![CDATA[The &#8220;Slowly Changing Dimension&#8221; a common problem in data warehousing. Basically, this applies to cases where the attribute for a record varies over time. For Example; George is an employee with XYZ Inc. He first worked at production plant. So, the original entry in the employee lookup table has the following record: Employee ID or Employee Key [...]]]></description>
			<content:encoded><![CDATA[<p><span style="font-size: x-small;">The &#8220;Slowly Changing Dimension&#8221; a common problem in data warehousing.<br />
Basically, this applies to cases where the attribute for a record varies over time. For Example;<br />
George is an employee with XYZ Inc. He first worked at production plant. So, the<br />
original entry in the employee lookup table has the following record:<br />
<strong>Employee ID or Employee Key = 12345, Employee name = George , Department = Production</strong><br />
Later on he was transfered to Purchasing Department on August 2009. How should XYZ Inc. now modify its Employee table to reflect this change? This is the &#8220;Slowly Changing Dimension&#8221; problem.</p>
<p>There are in general three ways to solve this type of problem, and are categorized accordingly;<br />
Type 1: The new record replaces the original record. No trace of the old record exists.<br />
Type 2: A new record is added into the customer dimension table. Therefore, the customer is treated essentially as two people.<br />
Type 3: The original record is modified to reflect the change.<br />
&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;<br />
In Type1 Slowly Changing Dimension, the new information simply overwrites the original information. In other words, no history is kept. In our example, recall we originally have the following table:<br />
<strong>Employee ID or Employee Key = 12345, Employee name = George, Department = Production</strong><br />
After George moved from Production to Purchasing the new information replaces the new record, and we have the following table:<br />
<strong>Employee ID or Employee Key = 12345, Employee name = George , Department = Purchasing</strong><br />
&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;</p>
<p>Type 2: A new record is added into the Employee dimension table. Therefore, the employee is treated essentially as two people. In Type 2 Slowly Changing Dimension, a new record is added to the table to represent the new information. Therefore, both the original and the new record will be present. The new record gets its own primary key.</p>
<p>In our example, recall we originally have the following table:</p>
<p><strong>Employee ID or Employee Key = 12345, Employee name = George, Department = Production</strong></p>
<p>After George moved from Production to Purchasing we add the new information as a new row into the table:<br />
<strong>Employee ID or Employee Key = 67891, Employee name = George , Department = Purchasing</strong></p>
<p>Advantages:</p>
<p>- This allows us to accurately keep all historical information.</p>
<p>Disadvantages:</p>
<p>- This will cause the size of the table to grow fast. In cases where the number of rows for the table is very high to start with, storage and performance can become a concern.</p>
<p><strong><em>When to use Type 2:</em></strong><br />
Type 2 slowly changing dimension should be used when it is necessary for the data warehouse to track historical changes</p>
<p>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-</p>
<p><strong>Type 3- The original record is modified to reflect the change.</strong></p>
<p>In Type 3 Slowly Changing Dimension, there will be two columns to indicate the particular attribute of interest, one indicating the original value, and one indicating the current value. There will also be a column that indicates when the current value becomes active.<br />
In our example, recall we originally have the following table:<br />
<strong>Employee ID or Employee Key = 12345, Employee name = George , Department = Production</strong><br />
To accommodate Type 3 Slowly Changing Dimension, we will now have the following columns:<br />
<strong>Employee ID or Key , Employee Name , Department worked, Current Department, Date</strong><br />
After George moved from Production to Purchasing, the original information gets updated,<br />
and we have the following table (assuming the date of change was August 15, 2009):<br />
 <strong>Employee ID or Employee Key = 12345, Employee name = George , Department Worked = Production, Current Department = Purchasing, Date = August 15, 2009.</strong></p>
<p><strong>Advantages:</strong><br />
- This does not increase the size of the table, since new information is updated.<br />
- This allows us to keep some part of history.<br />
Disadvantages:<br />
- 3 will not be able to keep all history where an attribute is changed more than once.<br />
For example, if George later moves to Quality department on Feb 15, 2010, the purchasing information will be lost. It shou when such changes will only occur for a finite number of time.</p>
<p><a href="http://www.intelligententerprise.com/showArticle.jhtml?articleID=59301280">Please also visit  an article &#8220;Slowly Changing Dimensions Are Not Always as Easy as 1, 2, 3 by Margy Ross and Ralph Kimball&#8221;</a></p>
<p></span></p>
]]></content:encoded>
			<wfw:commentRss>http://datamart.org/2009/05/28/slowly-changing-dimension/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Data mart  and Historical Data</title>
		<link>http://datamart.org/2009/05/11/data-mart-and-historical-data/</link>
		<comments>http://datamart.org/2009/05/11/data-mart-and-historical-data/#comments</comments>
		<pubDate>Mon, 11 May 2009 18:12:31 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Crystal Reports]]></category>
		<category><![CDATA[Data Mart vrs Data Warehouse]]></category>
		<category><![CDATA[Data Transformation]]></category>
		<category><![CDATA[Slowly Changing Dimension]]></category>
		<category><![CDATA[Sql Reporting Services]]></category>

		<guid isPermaLink="false">http://datamart.org/?p=74</guid>
		<description><![CDATA[For example an employee who has been rotated in different departments with different benefits and salary. A data mart allows the company to record the move, and reflects the change in the database. Without record of employee history or this slowly changing dimension, It would be very hard to performance analyses of employee. Over time, [...]]]></description>
			<content:encoded><![CDATA[<p>For example an employee who has been rotated in different departments with different benefits and salary.  A data mart allows the company to record the move, and reflects the change in the database. </p>
<p>Without record of employee history or this slowly changing dimension, It would be very hard to performance analyses of employee. Over time, certain dimensions (employees, products, and customers) will change, and your data integration software must be flexible enough to accommodate these changes and produce an accurate view of business performance.Data integration software must be flexible enough to accommodate these changes.</p>
]]></content:encoded>
			<wfw:commentRss>http://datamart.org/2009/05/11/data-mart-and-historical-data/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

