THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Printer-friendly

E-mail to friend

The Decision Model – December 2009

“Bottom Up”

Published: December 1, 2009

Portions of this article are drawn from the book, The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis, LLC. This article consists, in part, of abstracts from the book; directly quoted passages, diagrams and tables are cited, and are copyright © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.

Introduced in our September column, the Decision Model adds simplicity and rigor to the way we view, leverage and automate business rules in much the same way as the relational model did for data.

September’s column presented the Decision Model specifically for TDAN readers. If intriguing, perhaps three more questions come to mind. (1) How is building a Decision Model similar to building a logical data model? (2) More importantly, how is it different? (3) How are the differences reflected in the Decision Modeling steps? Below, you will also learn that a Decision Model contains “business information” not normally found in logical data models, but which is of utmost business importance.

Question #1: How is Building a Decision Model Similar to Building a Logical Data Model?

It probably comes as no surprise that the modeling steps and skill sets are remarkably similar. For starters, we can create both models using a bottom-up or top-down approach, and variations in between. Below we contrast the bottom-up approach for each model.

Bottom-Up Data Models

A bottom-up approach to data modeling starts from data elements and unearths the normalized model behind them. At the risk of oversimplifying, consider these four general steps:

1. Collect a list of data elements within scope.
   
   
2. Decompose them into atomic data attributes. (Name and define them, of course).
   
   
3. Normalize them. (Normalization groups attributes together in an inherent indisputable manner. In reality, not everyone always thinks our normalized entities are indisputable, but we have normalization principles on our side. Some of us have scars to show for it!).
   
   
4. Connect normalized structures to each other based on natural relationships among them.
   

A purely bottom-up approach requires that we know the attributes before we can reveal the intrinsic and hidden normalized data structures holding them together. More popular today is a top-down approach – by which we first take a guess at the normalized data structures and refine our guess as we find attributes. (In our next column, we’ll cover this for data and decision modeling.)

Bottom-Up Decision Models

Similarly, a bottom-up approach to Decision Modeling starts from business rule statements and unearths the normalized model behind them. (Without the Decision Model, most business rule approaches both start and end with a list of business rule statements. Sometimes these are connected to data or object models, process models and use cases, but they are not represented in a model of their own.) To simplify, consider the following similar steps:

1. Collect a list of business rule statements within scope.
   
   
2. Decompose them into atomic business logic statements.
   
   
3. Normalize them. (Decision Model normalization groups together atomic business logic statements in one and only one indisputable way. Luckily, in practice, we have not met with resistance to normalized business logic structures, quite the contrary!)
   
   
4. Connect normalized structures together based on natural relationships among them.
   

It is as familiar as that.

Question #2: More Importantly, How is it Different?

As intriguing as these similarities are, the differences are even more so. Data and business logic are different intellectual assets with different purposes and characteristics. Each remains elusive and intangible without its own model. It makes sense that their native structures and principles are different.

In step 1 above, we collect business rule statements not data elements. In step 2, we decompose into atomic business logic statements not atomic data attributes. In step 3, we normalize conditions and conclusions not attributes. In step 4, we connect normalized structures with inferential integrity, not referential integrity.

We now need to define (a) business logic and business logic statement, (b) business logic assertion, (c) conditions and conclusions, (d) atomic business logic statement, (e) Decision Model normalization, and (f) inferential integrity.

(a) Business Logic and Business Logic Statement

In the Decision Model, business logic is simply the means by which a business derives conclusions from facts. Therefore, a business logic statement is merely an expression of conditions (testing facts) that lead to a conclusion (resulting in a new fact) as in Figure 1.


(b) Business Logic Assertion

Figure 2 is a simpler but equivalent representation.


Figure 2 is shorthand stating that when condition assertions are true, the conclusion assertion is inferred to be true. Further, a business logic statement in the Decision Model is independent of the grammar with which we express it. We could use the “when…then” form, “if...then” form or we could state it in other declarative forms such as “The ….shall...” and so on. The Decision Model does not require a particular grammar. Therefore, we can express the content of a Decision Model in any way that works for a given audience. Of utmost importance is that the Decision Model represents the underlying logic in an atomic and precise manner, without ambiguities – just like a data model does for data.

So, a business logic assertion (condition or conclusion) is composed of Facts Types (nothing more than attribute types), Fact Values (attribute values), and operators. We use the phrases “fact types” and “fact values” (rather than attribute types and values) because business people see business logic as testing and resulting in facts.

An operator is a symbol connecting two parts of an assertion. Conventional operators are:


(c) Conditions and Conclusions

If a business logic assertion plays the role of a condition, it is an assertion that tests for truth. If it plays the role of conclusion, it is an assertion that becomes true if the condition assertions are true.

So, condition and conclusion assertions have identical structures as shown in Figure 3.


Table 1 has examples of assertions. Any of these could be a condition or a conclusion in a business logic statement.



Notice that an operand can be a fact value, fact type, or formula. In Table 1, we have:

• Fact values: average, 700, Blue, Preferred, etc.
  
  
• Fact Types: Person Likelihood of Defaulting on a Loan, Policy Effective Date, and Two Months Sales, etc.
  
  
• Formula: [weight (kg) / [height (m)]2
  

In the Decision Model, business logic statements must be atomic.

(d) Atomic Business Logic Statement

Reducing business logic to its atomic form (as with data) is what First Normal Form is about. It delivers only one representation of the business logic and eliminates ambiguity of meaning. The latter ensures that we can analyze the logic for precision, completeness, and consistency and that we represent it in its most manageable form.

So, in the Decision Model an atomic business logic statement is one that:

• Consists of zero to many conditions
  
  
• Leads to a conclusion about a single fact type
  
  
• Each condition is an atomic logical expression about an atomic fact type, and
  
  
• Conditions are ANDed together, never ORed.
  

Figure 4 diagrams an atomic business logic statement with three conditions, joined by ANDs, and leading to a conclusion about a single fact type. We represent atomic business logic statements as normalized rows in two-dimension structures.


(e) Decision Model Normalization

Normalization in the Decision Model is similar to that in the relational model, with deliberate differences. We summarize Decision Model normal forms below under Step 3, but interested readers will find full details in the book.

Question #3: How are the Differences reflected in the Decision Modeling Steps?

Let's now revisit our original four steps, refining them for the unique characteristics of business logic (versus data).

Step 1: Collect a list of business rule statements within scope.

We start by seeking statements that allude to the business deriving conclusions from facts. We might find them in conversations, documents, or even program code. Assume we gather five statements as follows:

• A person who has a poor employment history, a poor mortgage situation, and a high miscellaneous loans assessment is highly likely to default on a loan.
  
  
• A person who has a good employment history is not likely to default on a loan.
  
  
• A person who has a poor employment history, a poor mortgage situation, and a low miscellaneous loans assessment is moderately likely to default on a loan.
  
  
• A person who has less than one year at their current employer and fewer than three jobs in the past five years is considered to have a good employment history.
  
  
• A person who has less than one year at their current employer and more than eight jobs in the past five years is considered to have a poor job history.
  

Step 2: Decompose them into atomic business logic statements.

We next identify condition and conclusion fact types and corresponding business logic assertions. We recast them into structures with zero to many condition fact types leading to one conclusion fact type where the conditions are always ANDed together.

The first three statements above reference one conclusion fact type: Person’s Likelihood of Defaulting on a Loan. The last two statements refer to another conclusion fact type: Person’s Employment History. We create a two-dimensional structure, called a Rule Family, for each of these.

The first three statements contain three condition fact types leading to a conclusion about a Person’s Likelihood of Defaulting on a Loan: Person’s Employment History, Mortgage Situation, and Miscellaneous Loans Assessment. The last two statements refer to two condition fact types leading to a conclusion about a Person’s Employment History: Person’s Years at Current Employer and Number of Jobs in Past Five Years. We add these as conditions as column headings in the appropriate Rule Family and populate the rows as in Table 2.


Step 3: Normalize them.

Decision Model Normalization, similar to (but different from) data normalization, ensures that no conclusion is partially dependent on the populated conditions (second normal form, Rule Patterns) and that there are no transitive dependencies among conditions (third normal form).

At the same time, we ask the following:

• Do all decision makers agree with these conditions leading to these conclusions?
  
  
• What exactly does Person Employment History mean? What are values other than Poor?
  
  
• What does Person Mortgage Situation mean? What are its other possible values?
  
  
• What about Person Miscellaneous Loans Assessment? Which kinds of loans are included and excluded?
  
  
• What does Person Likelihood of Defaulting on a Loan mean and what are its possible values?
  
  
• What if Person Employment History is not Poor? What rows are needed in this Rule Family?
  

Step 4:Connect normalized structures based on natural relationships among them.

In steps 1-3, we formed individual normalized Rule Family structures, such that each by itself is simple and predictably created. Each Rule Family is easy to understand, comprises atomic pieces, and is free from ambiguity.

Step 4 focuses on how Rule Families connect to each other based only on the inherent nature of the business logic within them.

If you look closely, these two Rule Families relate to each other in an obvious way. Specifically, a conclusion fact type in one (i.e., Person’s Employment History) is a condition fact type in another. This is an inferential relationship and functions much like a referential relationship in a logical data model. Like a referential relationship, an inferential relationship is a logical connection, not requiring physical pointers, hashing, indexes, or any other specific implementation in automated solutions. The Decision Model protects its integrity (as the Relational Model does for foreign keys), and we call it an inferential key.

The inferential relationship is the self-defining glue that binds together Rule Families in a Decision Model. The web of Rule Families begins to weave itself, creating an entire model of business logic that has only one representation. So, at the end of step 4, a first cut populated Decision Model emerges. As with a logical data model, we can choose to represent only its structure, not its content, in a special diagram. Figure 5 contains such a diagram consisting of these two Rule Families. They are connected with an inferential relationship. The labels represent fact types. The top fact type in each Rule Family is the name of its conclusion fact type. The other fact types are condition fact types. There is significance to placing fact types below the solid or dotted line and to the Px labels, not covered here.

Hidden Knowledge Revealed

This brings us to the concept of interim knowledge. In Table 2, the value of the conclusion fact type Person’s Employment History is determined, not by referencing persistent data, but by executing business logic in an inferentially related Rule Family. This means it is a transient conclusion – an interim piece of knowledge – and we may not need to store it. Such transient data values are not often included in logical data models, let alone in databases. Interim knowledge is the glue that holds together Decision Models. But, more importantly, it is critical to the means by which the business makes importance decisions, and it has been hidden until now!

Decision Model Bottom-Up Summarized

The book contains details on the 15 principles and methodology behind the Decision Model. For now, steps 1–6 below correlate to the seven structural principles.







Ken Orr states, “There is, within business logic, an inherent structure just as there is an inherent structure that Dr. Codd had detected in data almost 40 years earlier.” (Ken Orr, Foreword to The Decision Model a Business Logic Framework Linking Business and Technology)

As data professionals, TDAN readers bring a level of maturity to the discovery and delivery of Decision Models. And this is exciting. In our next column, we create a Decision Model from the top down.

More information on The Decision Model book, training, experiences and white papers are at www.TheDecisionModel.com.