Business Intelligence Network business intelligence resources

Blog: David Loshin

« The Primary Performance Metric | Main | Analytics: Excessive Demand! »

Simple Overloading

I recently came across a curious overloaded use of a database table attribute: one column, called "Verification Status Code" contained a code indicating the result of a process of verifying the connection between a customer identification number and a supplied customer name. The attribute took on some values such as:

"The customer identifier and name were correctly verified as identical to our records"
"A corrected identifier was provided for the supplied customer name"
"The customer identifier and name were matched using the ALPHA process"
"The customer identifier and name were matched using the BETA process"
"The customer identifier and name could not be verified"

Apparently, the codes used indicate two pieces of information. The first is whether the name and identifier were correctly verified within the system or not, and the second was the process used to correctly verify the data. This suggests an embedded business rule associated with the application, in that it first checks to see whether the code is one that indicates verified data, and then it performs different actions based on which process was used.

Anyone have any other experiences with this kind of overloading? Let me know - I will add this as a rule class to my business rule-based data quality techniques. Email me (loshin@knowledge-integrity.com)

  Posted by David Loshin on November 22, 2005 12:34 PM |

Comments

I'm quite familiar with this and similar overloading techniques. I believe they are common

in the programming of legacy systems and have usually been implemented to avoid redesign or

because the designer believes that it will be more efficient to store fewer values

associated with some sort of process or transaction audit record. The case is usually that

it creates headaches for the programmer and gross inefficiencies when processing this audit

data for reporting or ETL purposes.
My question is in regards to the scope of your data quality practice: is it within your
purview to track perceived or possible impact of such data quality issues and to make
design-level (re-engineering) recommendations for mitigating the risk of such circumstances?

Posted by: Eric | December 15, 2005 8:08 AM

The question is more about whether the reference dta set in question is one that should bemanaged as an enterprise asset, in which all of managers of the applications that use the value domain agree to the meaning associated with that value domain (end associated encodings). Since that does impact data quality, teh simple answer is yes, there should be design-level recommendations when reengineering to ensure that all master reference data is subject to a data standards process.

Posted by: David Loshin | December 15, 2005 11:30 AM

Post a comment