penny stock | currency convertor

Consider first those rule-tuning options that are transparent

The best kind of tuning for rules, as for databases, are tuning options that are transparent to human actors, programmers, and application components requiring rules. These may include caching mechanisms, for example. Since each product is very different, refer to your product-specific manuals for insights on these kinds of tuning options.

In general, keep in mind that, if your functionality and performance are acceptable, do not engage in tuning rules. That's because the tuning options below, while done to provide missing functionality or improve performance, do so at a cost. The cost is a loss of some characteristic of your ideal rule design. Your ideal rule design was based on the quality criteria in this chapter. Overtuning rules, like overtuning a database, is not always a benefit.

Guideline 12.11.2

Consider last those rule-tuning options that are not transparent.

If transparent rule-tuning options are insufficient for meeting rule functionality and performance, there are three nontransparent ways to tune the rule design itself. You can move rule enforcement to another tier, duplicate rule enforcement on another tier, or change the rule template for specific rules or rule patterns.

Step 12.12: Tune the Rules by Moving Rule Enforcement to Another Tier

This step suggests you consider moving your rules enforcement, which is not necessarily transparent. A very common approach to moving rule enforcement out of the rules layer is to put it into the DBMS layer. This is common practice for rules that are very easily supported by the DBMS, such as uniqueness enforcement through use of a unique index. With some commercial rules products, referential integrity rules can be enforced either through the rules product or through DBMS functionality.

To understand your options, consider the following possibilities for where you can enforce a rule outside the rules layer:

• Application-specific layer: This refers to application code for this
application that is not shared with other applications. This code is usually
procedural code (such as C++, Java, Visual Basic, and so on).

• DBMS layer:

o Domain definition: This is database code intended to be shared among applications that share the database. It defines data types, lengths, and sometimes value restrictions on domains.

o DBMS table definition: This too is database code intended to be shared among applications that share the database. It defines column types, lengths, sometimes value restrictions on columns (uniqueness, not null, values), and sometimes relationship restrictions (referential integrity rules).

o DBMS view definition: This is database code defining a virtual table to be shared among applications if they specify use of the same view.

o DBMS trigger: This is database code intended to be shared among applications that defines code to be executable automatically when a table or column is operated on. It is typically written in declarative code.

o Method in shared object class: This is code intended to be shared among other applications because it is in an object shared across applications. That is, you can use this as a mechanism for creating shared, standard maintenance logic for specific data structures.

Table 12.3 summarizes the advantages and disadvantages of enforcing rules in the various tiers.

Let's make some comments about Table 12.4 .

For computation rules, recall that a computation is a statement providing an algorithm on numeric data for arriving at the value of a term. The algorithm can include arithmetic functions (add, subtract, multiply, divide), aggregate functions (minimum, maximum, average, mean, and so on), scientific functions (sin, cosine, and so on), and a counting function.

If the computation involves large data volumes (many rows, wide rows, many tables), the DBMS is likely to outperform a rules engine in manipulating such data. The third choice for computations is to create a method in a shared object. This would be appropriate if you are building your own rules capability. In this case, you can create an object class for the target table and include a method for materializing the computed value. Make sure that any other methods that change input values to the computation will invoke this method to recompute the computed value. This computation logic, because it is likely in procedural code, is probably difficult to change.

Recall that a constraint is a complete statement that expresses an unconditional circumstance that must be true or not true for the business event to complete with integrity. For the design discussion, consider that there are two very basic types of constraints. There are basic data integrity constraints that have been traditionally included in logical data models and in RDBMS products. There are also complex data integrity constraints that usually involve more sophisticated logic and data from multiple tables.

There are various DBMS facilities for implementing constraints. DBMS domain definition can be used to specify domain constraints shared across related columns. DBMS table definition can be used for referential integrity, primary key, column constraints such as uniqueness and null constraints and value constraints. DBMS index definition can enforce uniqueness on an alternate key. DBMS trigger definitions can enforce complex constraints.

For constraints, a very common compromise (usually due to rules product limitations and performance considerations) is to enforce traditional data integrity constraints (primary key constraints, referential integrity constraints, uniqueness constraints, non-null constraints, and value checks) in the DBMS while enforcing complex constraints (multitable constraints) in a rules layer. Keep in mind, however, that this solution has disadvantages: A change in some rules require a database definition change; these rules cannot be shared across DBMS products without recoding its DBMS implementation. Another common practice is to enforce attribute validation in the presentation layer.

For constraints, a shared method in an object is appropriate if you are building your own rules capability. You can create a method in each object class relating to a table and enforce all constraints for the table through methods in the related object class. However, the constraint's truth-value will not automatically change when related data values change unless the design effort ensures that related methods (that update related data) also invoke the proper method.

Recall that a guideline rule is a complete statement that expresses a warning about a circumstance that should be true or not true. A guideline does not force the circumstance to be true or not true, but merely warns about it, allowing the human to make the decision. Hence, a guideline rule is much like a constraint rule but does not automatically prevent the business event from completing successfully.

Some commercial rules products cannot support guideline rules. Guidelines are not easily enforced in the DBMS, except through triggers that issue warning messages and roll back a database update. Therefore, the second choice is to create a shared object class and include guideline rules in a method or methods within that object class.

Recall that an inferred knowledge rule is a complete statement that tests conditions and upon finding them true, establishes the truth of a new fact. These are, perhaps, the most interesting rules to the business rules approach.

It is difficult to implement inferred knowledge rules in the DBMS. Most likely you would need to code triggers and you would probably need to store the resulting value physically so that it could be reused.

Instead, then, consider creating a shared object class for the table in which the inferred value belongs and creating a method for inferring it. Again, you may need to code all other methods that change related values so that they call the appropriate method to reinfer the value should any of those related values change.

Recall that an action enabler is a complete statement that tests conditions and upon finding them true, initiates another business event, message, or other activity.