<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: It Is Not So Easy to Build a Data Cleansing Logic</title>
	<atom:link href="http://www.dataforge.com/wpblog/index.php/jackie-roberts/it-is-not-so-easy-to-build-a-data-cleansing-logic/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dataforge.com/wpblog/index.php/jackie-roberts/it-is-not-so-easy-to-build-a-data-cleansing-logic/</link>
	<description>Business Intelligence Redefined</description>
	<lastBuildDate>Mon, 14 Mar 2011 23:49:04 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Ken O'Connor</title>
		<link>http://www.dataforge.com/wpblog/index.php/jackie-roberts/it-is-not-so-easy-to-build-a-data-cleansing-logic/comment-page-1/#comment-658</link>
		<dc:creator>Ken O'Connor</dc:creator>
		<pubDate>Wed, 03 Mar 2010 12:33:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.dataforge.com/wpblog/?p=368#comment-658</guid>
		<description>Totally agree Jackie...

Before considering any form of &quot;Transformation&quot;, the &quot;business rules&quot; for the field should be fully understood: 

I would want to have:

1. Business name of the data field(s):
2. Permitted values:
3. Business meaning of each permitted value:
4. Interdependencies with other data:
5. Field precedence:

The &quot;business rules&quot; should be centrally maintained, and visible to the business.
All &quot;Transformation&quot; rules should also be centrally maintained (and not just coded into an ETL script).  
Actual transformations, and exception processing (when input data could not be transformed) should be recorded in an audit trail.   

Regulators will increasingly look for a &quot;Data Audit Trail&quot; - be warned. 

Ken</description>
		<content:encoded><![CDATA[<p>Totally agree Jackie&#8230;</p>
<p>Before considering any form of &#8220;Transformation&#8221;, the &#8220;business rules&#8221; for the field should be fully understood: </p>
<p>I would want to have:</p>
<p>1. Business name of the data field(s):<br />
2. Permitted values:<br />
3. Business meaning of each permitted value:<br />
4. Interdependencies with other data:<br />
5. Field precedence:</p>
<p>The &#8220;business rules&#8221; should be centrally maintained, and visible to the business.<br />
All &#8220;Transformation&#8221; rules should also be centrally maintained (and not just coded into an ETL script).<br />
Actual transformations, and exception processing (when input data could not be transformed) should be recorded in an audit trail.   </p>
<p>Regulators will increasingly look for a &#8220;Data Audit Trail&#8221; &#8211; be warned. </p>
<p>Ken</p>
]]></content:encoded>
	</item>
</channel>
</rss>

