By Elliot King
Business rules are what define and constrain the critical elements of databases
by controlling the information to be captured. Business rules define each column
in a database; under what conditions data should be entered into a specific
column and the relationship between different data elements.
In some ways, business rules provide the logical structure of the database,
determining what the data elements are and how they fit together. For example,
if a database was thought of as a house, business rules would define what
constitutes a window, how windows fit into walls, and, as importantly, how
windows are to be used. A more real-world example might be–nobody under the age
of 18 may open an account.
Accurate, concise, consistent and precise business rules are essential for two
primary reasons. They guide expectations of what should be contained in a
database. Let’s say you are capturing data via a Web form. Business rules will
define what fields will be required. Or imagine that you want to launch a direct
marketing campaign aimed toward people who are unmarried. Business rules would
dictate which marital status categories, perhaps single, divorced, widowed–to
The problem with business rules is that they usually are developed all over the
organization and there are a lot of them. They can be found in user guides,
system documentation and data entry guidelines. Business rules can be developed
by a host of different people including subject matter experts and systems
developers. And they specify data at a very granular level, such as an employee
termination date must be later than an employee hire date.
Often the first step in a data quality program is to consolidate an
organization’s business rules. Data can then be audited according to the
complete set of rules, mistakes can be defined and corrected, or the rule in
question can be refined.
To paraphrase Shakespeare, the problem sometimes is not in the data, dear
Brutus, but in the rules.