What is a Business Rule?
Posted: Fri Apr 04, 2003 8:35 am
The term "business rule" gets bandied about quite a bit in data quality circles. In most of the data cleansing world, a business rule is a pattern that a particular data item must match. In the data profiling world, a business rule entails a pattern, a set of relationships, or a range of acceptable values.
My thought is that all of these are correct, but the term "business rule" really means something quite broader as it applies to data quality. A business rule is a statement about what constitutes the set of valid values for a set of data elements.
Notice that it's not just a statement about a particular field. A business rule can have a single "parameter" that defines the behavior of a field, but it can also extend to many fields across a record, a join of several records, or even an aggregate of tables or an entire database. For example, a business rule could say that the average of a column formed by the join of several tables will never exceed 150.
Business rules also include algorithmic statements. I think most DQ vendors would claim that they support business rules because they can define a pattern that a data element must match, inclusion in a set of lookup tables, or a simple expression. But real world data is never that simple. To really support business rules, you have to be able to handle the IF-THEN-ELSE and FOR-NEXT cases. For example, a business rule could be as complex as "If the value of Column A = 1, then the value of Column B must be in the range of A-D, otherwise Column B must be blank and Column C must be computed by taking half of the average of Column D from another table using Column E on the first table as the key to the lookup table." That's a fairly tough pattern to write even in the most sophisticated pattern matching environments, but it's a very easy snippet of code to write in almost any programming language.
Your thoughts?
My thought is that all of these are correct, but the term "business rule" really means something quite broader as it applies to data quality. A business rule is a statement about what constitutes the set of valid values for a set of data elements.
Notice that it's not just a statement about a particular field. A business rule can have a single "parameter" that defines the behavior of a field, but it can also extend to many fields across a record, a join of several records, or even an aggregate of tables or an entire database. For example, a business rule could say that the average of a column formed by the join of several tables will never exceed 150.
Business rules also include algorithmic statements. I think most DQ vendors would claim that they support business rules because they can define a pattern that a data element must match, inclusion in a set of lookup tables, or a simple expression. But real world data is never that simple. To really support business rules, you have to be able to handle the IF-THEN-ELSE and FOR-NEXT cases. For example, a business rule could be as complex as "If the value of Column A = 1, then the value of Column B must be in the range of A-D, otherwise Column B must be blank and Column C must be computed by taking half of the average of Column D from another table using Column E on the first table as the key to the lookup table." That's a fairly tough pattern to write even in the most sophisticated pattern matching environments, but it's a very easy snippet of code to write in almost any programming language.
Your thoughts?