Some Discussion of HPM
PP85 - 90
Business Rules


Business Rules.  When working with databases, particularly when first designing them, it is very important that they have data that reflects how the business or organization really works. 

Business rules are derived from the policies, procedures, functions, and other business objects and state constraints on the organization.  They are statements that define or constrain some aspect of the business.  They are intended to assert business structure or to control or influence the behavior of the business.  Rules prevent, cause or suggest things to happen.

This definitions are still somewhat vague and yet involved.  So, as is usual, I will try to make sure I give plenty of examples to help people get much more sense about what these largely abstract statements are intending to say.

Some examples of business rules are

  • people that have purchased a membership get into the museum for free
  • the children in families that have purchased memberships get a reduced rate on their summer camps
  • children of full time employees of the university get their tuition for free
  • children of full time employees of the university get their tuition for half price
  • people that donate more than $200 per year get their memberships for free
  • people are allowed to return any products they have purchased within the last 30 days if they have their receipt
  • people that fly with our airline get preferred seating
    • based on what is available
    • based on how much they've flown with us in the last year
  • if the package is in our store by noon we will have it to any location that has a post office within its zip code within the United States within 24 hours
  • any stock sales made online during the trading day will get the price of the stock at the end of the day if the sale is not made earlier
  • this database will focus on data collection relating to environmental laws for waste disposal
  • people cannot receive food from the food bank more than once each month
  • customers who maintain $1000 or more in their checking account will not be charged for checking
  • all of our customers are allowed up to three free withdrawals using their ATM card per month
  • we have an agreement with Clee Bank to allow our customers to be charged only $.25 per ATM transaction

The book has some other examples.

The truth is, in their general sort of high minded somewhat abstract way I think HPM do a real nice job on this section.  Though, I definitely want to hear your views.  Professors can have their tendencies to choose books they like and not be all that good on choosing books that are the best for students.

But HPM states there are three main things you need to do as a business analyst.

  • identify and understand the business rules that govern data
  • represent these rules so that they can be unambiguously understood by information systems developers and users
  • implement those rules in database technology

I have plenty of experience trying to figure out the business rules of organizations.  It can be one of the most challenging aspects of doing database, software, network and security development.  In my mind and experience developing systems that help an organization much more effectively reach their goals is very important.

Now I'm trying to decide on which consulting experiences I want to focus other than those I'm already using as cases.

I worked on a client database system that was going to be housed on a small LAN within a medical testing facility.  I was a subcontractor to someone who knew they guy who was running two such facilities in the Boston Massachusetts area.  Trying to make sure the forms and tables underlying the forms were appropriately configured was probably the most difficult aspect of the work.  Fortunately, using Access to quickly develop prototype forms that we could put in front of the owner and key users really helped the process.  This way we could get constant feedback about what the eventual end users really wanted to see and how they wanted it laid out.  As we were doing this we were able to develop more and more of the business rules.

Trying to get clients to come up with their own business rules really isn't particularly easy.  When HPM describes surfacing business rules as a continually ongoing process I definitely agree them.  This is even more difficult for an external consultant to do unless the organization has had some previous preparation and experience.  I also like how they use the word surfacing, because it really is like they emerge in some sort of raw form from the psyche of those you are working with.

HPM goes on to reference Halle which states

  • Business rules are a core concept in an enterprise because they are an expression of business policy and guide individual and aggregate behavior.  Well structured business rules can be stated in natural language for end users and in a data model for system developers.
    • it is obviously important to be able to communicate with both audiences
  • Business rules can be stated in terms that are familiar to end users.  Thus end users can define and then maintain their own rules.
  • Business rules are highly maintainable.  The yare stored in a central repository and each rule is expressed only once, then shared throughout the organization.  Each rule is discovered and documented only once, to be applied in all systems development projects.
  • Enforcement of the business rules CAN be automated through the use of software that can interpret the rules and enforce them using integrity mechanisms of the DBMS.
    • this bullet seems a bit to blue sky for me - but I think it is a highly desirable and at least sometimes attainable goal
    • many authors can come off as if they are marketing a particular product they sell or trying to give more importance to a line of research they pursue.  I think it does sound potentially useful and important.  But I have learned over time to be skeptical about these sorts of claims when they sound too strong.

Scope of Business Rules.  We really do need to focus on business rules that impact an organization's databases.  I like the little table HPM have in the book so I am summarizing it here.


Characteristic Explanation
Declarative A business rule is a statement of policy, not how it is enforced or conducted.
Precise Each rule must have a clear and singular interpretation.
Atomic The rule makes one statement, not several.  No part of a rule can stand on its own as a rule.
Consistent A business rule must not contradict other rules.
Expressible A business rule must be able to be stated in natural language.  Which I think is a bit extreme.  Often times you really want to use mathematical formulations.  For example, computing commissions on sales is something that will likely be better expressed in more mathematical terms.
Distinct Each rule must not repeat another rule.  But they may refer to each other.
Business Oriented There need to be ways to state the rules in ways that people within the organization can understand.  You want the businesses to take ownership of their business rules as they are stated.


Gathering Business Rules.  We've already talked about this some.  But you never know when such rules will surface.  They might be in meeting notes or human resource policy statements or reports from data collection sessions or interviews or marketing brochures or ...

There needs to constant effort towards clarifying the rules and making them comprehensible.