stock investment | forex trading strategies

Determine if You Need to Alter Your Data Definitions

Some of these products have limitations on their ability to process multitable rules regarding how distant (across tables) a rule can reference terms. Therefore, if you have a rule with terms that are too distant in your database design, you may need to define that data from one table to another or to aggregate up to a higher level (such as for aggregate functions). You will need to determine whether such values need to be persistently stored or not. Again, confer with your database designer.

Most data-change-oriented rules products either require that values materialized by rules be persistently stored or recommend that this be so. You need to define to the rules product the data referenced by the rules. Often the data turns out to be your relational tables. You need to define, usually via a modeling technique, the terms that you will reference in the rules. Sometimes you can provide to the product your physical database design model from your data modeling environment.

Step 12.6.4: Define the (Revised) Data Design to the Rule Product

While most products allow you to define the data structure using the product's capabilities, it is best to feed your physical design structure directly from your modeling tool into the rules product. The modeling tools usually provide more sophisticated functions to assist with modeling, including model integration capabilities.

Step 12.6.5: Determine How to Express Rules Declaratively

Even if you used the rule templates in this book or devised your own, you may need to translate these into rule product syntax.

Step 12.6.6: Enter the Rules into the Product

Using the product's interface, enter rules. Sometimes you can write the rules directly and sometimes you can use drag-and-drop facilities for doing so. If you have a rules repository separate from the rules product, you will also want to be sure you enter the rules into the rules repository or create an interface between them.

Note USoft uses standard ANSI SQL as the specification language for

explicit business rules, making it very easy to map to any relational database.

Note Versata captures and implements business policies and

requirements using declarative rules that are written in structured English, not procedural code. The rules need to be identified during analysis and then applied to the relevant data objects, attributes and relationships.

Step 12.6.7: Determine if Some Rules Need to Be Coded Procedurally (Such as in Java)

Some products may lack a full set of operators for all possible calculations and logical phrases. You may need to implement very sophisticated algorithms in procedural code.

Step 12.6.8: Test the Rules

This is the fun part. You can do this by entering data into the default user interfaces that the product automatically creates for you. Or you can spend more time designing the interface.

Case Study: Step 12.6 — Design for Rules for a Commercially Available Data-Change-Oriented Rules Product

Case Study Instructions:

- If you chose a data-change-oriented rules product, walk through the design steps. Use two rules as an example:

o For enrolling a member: A member must be between 6 and

o For invoicing a guardian: A guardian's monthly invoice is equal to the sum of the monthly charges of the guardian's members.

Case Study Solution:

Solutions for Versata Inc.'s product and USoft Inc.'s product are shown in the next chapter .

Step 12.7: Design for Rules in a Homegrown Data-Change-Oriented Rules Capability

There are various ways you can build your own simple data-change-oriented rules capability. Let's review the logic behind a data-change-oriented rules capability.

If you recall, a business event is serviced by a business process, which consists of a flow of tasks and supported by screens or Web pages. The system behind the process processes input, as any other system, until it arrives at a point of updating persistent data. The data-change-oriented rules capability is invoked automatically when there is a request to update persistent data. The rules capability correlates the data structures targeted for update to rules that protect those structures from contamination.

So, for example, if the system were attempting to change a salary field, the rules capability would execute all rules associated with that update. These would include perhaps a constraint on the new versus old salary value, any constraints on the maximum or minimum value, and so forth. If the application were attempting to create an order, the rules capability would execute computation rules for determining violations of credit limits as well as those used to determine special pricing. It would compute taxes and shipping fees and it would verify that referential integrity rules are followed. If rules are violated, the database update is disallowed and the rules capability sends back an error message, which indicates the violated rule or rules.

Keep in mind that if you develop your own rules capability, the need for your own rules repository is even greater because you will not be using a rules product that provides a repository function.