This page contains Chapter 4 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:
The first kind of business rule to be discussed is the structural assertion. A structural assertion is a statement that something of importance to the business either exists as a concept of interest or exists in relationship to another thing of interest. It details a specific, static aspect of the business, expressing things known or how known things fit together. Structural assertions are frequently portrayed graphically as entity/relationship diagrams.
As shown in Figure 5, structural assertions are of two kinds: terms and facts.
A business term is a word or phrase that has a specific meaning for a business in some designated context. Each business term must be used in at least one context, and each context may be the use of one or more business terms with some defined meaning attached. For example, business terms in the context of EU-Rent's car rental business might include 'rental request,' 'reservation,' 'booking,' etc.
Common terms are words in everyday language using their commonly-accepted meaning. Specifically, common terms are part of the basic vocabulary ñ for example, 'car,' 'city,' etc. ñ and are taken as axiomatic to avoid writing circular definitions. Both business terms and common terms are used as terms in constructing sentences, that is, statements of business facts.
The difference between a common term and a business term is that a business term must be defined explicitly in terms of one or more facts. (Each fact may be used in the definition of one or more business terms.) The definition of a common term is generally understood and need not be defined explicitly.
A fact asserts an association between two or more terms. That is, it expresses a relationship between the terms. A fact involves two or more terms, and a term may be in one or more facts. Note that a fact is not limited to a simple binary pairing of terms. Indeed, some facts must be expressed by compound associations with more than two components. For example, "a customer may request a model of car from a rental branch on a date" is a fact that includes four terms: customer, car model, rental branch, date. Also note that, in this case, the request is not for a particular car but for any car of a particular model. This fact defines the business term 'model rental request.'
An occurrence of object role is needed to depict each semantic role that a term plays in a fact. That is, each term may be the player of a semantic role as one or more object roles, and each object role must be the use of one term in one fact. For example, in a company's sales area the fact that there is a relationship between the terms 'customer' and 'contract' could be established (shown graphically in Figure 6). There would be two object roles in this fact ñ one asserting that the term 'contract' may be the player of a semantic role as an object role that is part of the fact, and another asserting that the term 'customer' may be the player of a semantic role as an object role that is part of the fact.
A fact often has multiple ways of being stated. Even in a binary fact there can be at least two expressions of the fact ñ one describing it in each direction. In the customer/contract example, it is both the case that "each contract may be with a customer," and that "each customer may be the renter in many contracts." These two sentences describe the same underlying fact.
In the business rules model, this is represented by the entity text ordering. That is, each fact may be expressed as one or more text orderings, where a text ordering portrays one possible wording of a fact. Each of the two sentences about contract/customer and each of the three sentences about model rental request would be a text ordering about their respective facts.
In our car model example, the original sentence above could be restated in various other text orderings, for example:
Each text ordering must be composed of one or more phrases, where each phrase must be a sequential use of one of the object roles that is part of the fact. (Conversely, each object role of the fact must be described by one or more phrases.) In addition to identifying the sequence of the object role in the text ordering, the phrase also provides the text (with a marker) and specifies the syntactic role of the object role (e.g., subject, object).
For example, "Each customer may be the renter in many contracts" is one text ordering of the underlying fact portrayed in Figure 6. The phrase 'each customer' describes the object role ('customer' doing the buying) as the 'subject' in this text ordering of the fact. This phrase further specifies that 'customer' occurs in 'position 1' in this ordering, and it provides the text phrase as "each <>" (where <> represents the marker for the term).
Then, in the second text ordering for the same fact ("Each contract may be with many customers"), the same term, 'customer,' appears in a different object role ('customer' as the 'object' of the contract) and this object role is described by another phrase ñ one that specifies it as the 'object' in the sentence, its position as '2,' and its text with marker as "may be with many <>."
Note the parallel structures between a fact being expressed as one or more phrases (via text orderings), and a fact being composed of one or more object roles. While it is not shown graphically on the model, it is the case that there must be exactly one phrase that is part of a text ordering for every object role that is part of the fact expressed as that text ordering.
Note also that one attribute of text ordering could be 'source.' That is, such an attribute would indicate whether an occurrence of text ordering came from a user or not. text orderings from users could readily be used to feed back the analysis to users: "This is what you said. Is it correct? Here is another way of saying the same thing. Do you agree?"
Previously, we classified a term into a business term or a common term. Figure 7 shows that a term may also be classified in another way ñ as a type (defining abstract categories of things like 'car model,' 'walk-in rental,' 'customer,' etc.) or as a literal (describing instances of things, such as 'General Motors,' or '5000').
A type is a named abstraction of a set of instances or values, while a literal is a specific value or instance. Business rules most often are stated in terms of types but occasionally need to make reference to specific values or instances.
A special type of sensor is a clock, one that reports the passage of time. It always has one value ñ the 'current time.'
Finally, we will postulate that for any given concept, a single term is designated as the word that labels it. (This assumes, for this discussion, a single natural language such as English). Given this 'base' term as a reference point, we can then assert that other terms may be synonyms of this base term. That is, each term may have one or more other terms as its synonyms. Conversely, each term may itself be a synonym of one or more other terms.
Facts may be classified in two different ways, as shown in Figure 8. The first classification distinguishes between a base fact (which is simply asserted) and a derived fact (whose value is computed or inferred from other business rules). The second classification distinguishes a fact as one of three types: attribute, participation, or generalization.
A fact may be either a base fact or a derived fact. A base fact is simply recorded as something that is the case.
A derived fact is an assertion that is constructed from other assertions. It may be a computed value, or it may be a 'view.' For example, one fact may be that 476 is recorded at point 321-C in a processing plant at 3:46 p.m. on January 14. From this can be derived the fact that 476 gallons of kerosene are in inventory in tank 234 at 3:46 p.m. on January 14. Similarly, measurements may be taken for volume and flow past a processing point, and from this is derived the mass of material that passed that point during a specified period of time.
Each derived fact must be derived using a derivation ñ an inference or a mathematical calculation that may be either a mathematical calculation (as in the 'mass' example) or an inference (as in the inventory example). Each derivation must be based on one or more other business rules, and a business rule may be used in any number of derivations. Depending on the approach taken, properties of derivation could be the formula involved or simply the name of an algorithm that carries out the derivation.
In the car rental example, a base fact could be:
Derived facts could be:
A derivation used to derive this derived fact would be:
Derived facts and derivations are discussed further in Chapter 6.
A second classification distinguishes a fact as one of three types:
An attribute expresses a fact in which a term describes some aspect of another term. A generalization expresses a type of fact in which one term (a type) describes a subset of occurrences of another term (also a type).
Example attributes for our rental car business might be:
Example generalizations might be:
A participation expresses a fact in which a set of terms are associated in some sense that is meaningful to the business ñ for example, "a car model may be requested by many customers," or "a car may be rented by many customers," (but only one at a time). This is a relationship of the sort that would typically appear in a conceptual model, probably further augmented by a constraint, such as 'one or more' or 'no more than one.'
A participation, in turn, is one of three general kinds:
Example participations (aggregations) for our rental car business might be:
Example participations (roles) might be:
Example participations (associations) might be:
The following summarizes the definitions of the concepts relating to Structural Assertion:
Go to... Top of page | Next chapter | Table of Contents | BRG Home Page
Copyright ©2001, the Business Rules Group. All rights reserved.