The Business Rules Conceptual ModelThis page contains Chapter 2 of the paper "Defining Business Rules ~ What Are They Really?", produced by the Business Rules Group. Other formats in which this paper is available are described in Defining Business Rules -- What Are They Really? (Abstract & Table of Contents)
The subsections in this chapter are:
Business rules can appear in many guises. They may be described in many different forms, both formal and informal. It is the purpose of the Business Rules Project to provide a basis for stating an organization's business rules formally and rigorously. With this in mind, certain underlying principles can be stated:
The statement of business rules needs an explicit expression, either graphically or as a formal (logic-based) language. Currently, modeling notations are available for some of the kinds of business rules. For example, structural rules may be represented by any of several flavors of entity/relationship (or "object class") diagrams. Responses to events may be shown via essential data flow diagrams <4> or as entity life history diagrams. <5> There are fewer notations available, however, to describe action assertions. Most notable of these few are Object Role Modeling (ORM) <6> -- derived from the Nijssen Information Analysis Method (NIAM) -- and the Ross Method <7>, discussed later in this paper. Others could be developed.
As the formalization of business rules becomes part of the commonly practiced systems analysis process, it is desirable for there to be a single, coherent representation for all the kinds of business rules. This would yield a single formal representation of all aspects of an enterprise's structure and operations. While this sounds overly ambitious, it should be reasonable, as a minimum, to seek more coherent links between the notations now in use for entities, event responses, and constraints, even if the individual notations are not changed.
Conceptually, the representation of constraints can be thought of as an extension, for example, to entity/relationship diagram notation -- adding constraints to the structural elements of a diagram. After all, the entities in a conceptual model represent things of significance to an organization, and it is reasonable for constraints to be described in terms of those things. Yet, while integration of concepts is a desirable goal, achieving an integrated representation was not the focus of this Business Rules Project. Our document is intended to describe the nature of business rules, regardless of how they might be portrayed.
Note that a business rule is declarative, not procedural. It describes a desirable, possible state that is either suggested, required, or prohibited. It may be conditional -- that is, if something is the case, something else must or must not be the case. It does not, however, describe the steps to be taken to achieve the transition from one state to another, or the steps to be taken to prohibit a transition.
The Business Rules Conceptual ModelTo express the concepts and structure of a business rule formalism, the Business Rules Project has described the structure of a business rule itself as a conceptual model, in the form of an entity/relationship (E/R) diagram. That is, the model presented in this document defines what a business rule is and what kinds of rules there are.
The IDEF1X notation <8> was chosen for the business rule model notation since it is a documented, public information modeling standard, but other conceptual modeling conventions could also have been used. Appendix B provides an overview of the notation used in this paper.
The business rules model is organized around the following topics, presented in the next four chapters of this document:
Go to... Top of page | Next chapter | Table of Contents | BRG Home Page
Copyright ©2001, the Business Rules Group. All rights reserved.