Читать книгу Leveraging SAP BRFplus in Big Data Scenarios - Tom Zamir - Страница 12

Higher-order logic

Оглавление

As a rule author, you should always inspire to fashion the rules in a high-order logic, as this will pay dividends in the construction phase as well as in the maintenance phase. High-order logic is a tricky concept to describe. Officially, a high-order logic quantifies over sets. In contrast, quantifying over individuals is considered first-order logic, which is the lowest order. Similarly, quantifying over sets of individuals is considered second-order logic, quantifying over sets of sets of individuals is considered third-order logic, and so on.

In the context of business rules, a high-order business rule is a rule that does not explicitly enumerate all the applicable use cases (i.e., all the members of all the sets used). Instead, it addresses a more abstract decision that is common to several (potentially many) use cases. Consequently, the higher-order rule might become less trivial but can dramatically increase maintainability thanks to compactification. Nesting expressions as criterion columns in a decision table expression can be an effective way to construct high-order business rules. Take for example the simple rule that was shown earlier:

 If age < 18, then ‘cannot purchase online’.

Even this simplistic form of if-then rule uses a logical set for the decision process. Instead of enumerating every possible age, this rule splits the entire superset of all ages into two categories (subsets) and makes a statement about one of them (an if-then-else rule would also make a statement about the other category). Formally, the rule can be written as follows:


The symbol is a quantifier that means for every or for all. The formal notation above is read, “for all ages smaller than eighteen, ‘cannot purchase online’ applies”. The quantifier is always applied to a set. In this case, the set can be formally written as follows:


This states that minors is the set of all ages such that age is smaller than eighteen. It is then possible to rewrite the former statement as follows:


This statement is read as, “for all ages that are members of the set ‘minors’, ‘cannot purchase online’ applies”.

Perhaps a better way of constructing the business rule is to first define the minors set, as follows:

 If age < 18, then ‘minor’.

The definition of minor can have implications on numerous activities, not just on a purchasing activity. A business rule that would grasp more than one activity by using the set defined above could be considered as a second-order rule.

Example business need

Aligned with the strategy of increasing its income, the shopping site may decide to give the young visitors an incentive to make their parents buy them what they are not allowed to buy for themselves.

To implement the above logic, the decision table illustrated by Table 1.1 is possible.


Table 1.1: Second-order activity restriction business rule

What we did was create a set of minor-related activities. This set makes use of the minors set. We can further generalize this decision table by thinking about other population types that are defined by age, like senior citizens:

 If ‘age’ > 65, then ‘senior’.

Instead of two distinct if-then rules for defining seniors and minors, the population type determination may be defined as another decision table (see Table 1.2) which defines a set of age-related population types:


Table 1.2: Population type determination

Formally, this can be written as follows:


This is a set of sets. We can then nest the last table inside that of the activity restriction business rule (see Table 1.3). By doing so, we get an even higher order business rule (let us call this the third order).


Table 1.3: Third-order activity restriction business rule

In this way, we can avoid maintaining different decision tables for different population types that are most likely to share common activities. We can try to split the different activities into population-related categories in an attempt to grasp the entire list of activities in a single (but deep) decision table. In formal notation, it may look something like this:


Sometimes, however, there is a limit to the effectiveness of the set creation technique in terms of compactification. For example, assume that there are millions (!) of activity types and there is no effective way to divide them into more concise sets of activity clusters (subsets) with a common denominator. In other words, an attempt to do so will yield a set of sets such that the size of the superset would be at best half the size of the initial list of activities. In that case, the table would end up being very large (around 500,000 rows) and thus very difficult to maintain. It would also be inefficient, as we will learn in Chapter 3.

This situation calls for a different technique that will help us reach the next level of generalization. This new technique for gaining even higher order logic will be discussed in Chapter 4.

Leveraging SAP BRFplus in Big Data Scenarios

Подняться наверх