Defining Business Rules for Data Access

   

You can use business rules to provide correct and consistent control of your application's data access. Even better, you should expect other applications to use the same business rules, and thereby benefit from the built-in process dependencies and relationships you have provided. In general, business rules that perform data access must be designed thoughtfully to provide self-contained, carefully coordinated processes.

Your application requires data access business rules for any of the following circumstances.

You can use a business rule each time your application inserts, updates, deletes, or views data. Business rules implemented this way provide concise control over the data that can be updated and how it is updated. For example, if your application applies new sales orders to the invoice file, a business rule should automatically check the customer's credit limit before accepting and inserting the sales order line items.

Data validation is the process of verifying field values (Is the numeric field really numeric and within range?) and validating related file values (Does the publisher identification exist in the Publishers file?). By putting all of the data validation routines into business rules, your application can guarantee correct data and easily adapt to future requirements.

Your application may require data access security to control who gets to use your application and how they get to use it. Business rules are an excellent way to manage data access privileges.

If your application needs to trace a complex chain of records as preparation for a decision process, you should use a business rule to simplify the multifile access. Your business rule would automatically find all of the required data structures and repackage them for easy use. For example, suppose your application needs to determine the maximum possible payout for a single procedure in a multiline health care claim. While inspecting the current line item, the beneficiary's entire claim history must be searched for prior use of the identical procedure. Additionally, lifetime and current year-to-date limits must be checked to determine the allowable amount. This kind of multifile access presents an excellent opportunity to create a reusable business rule that consistently and correctly handles the situation.

One of the most common uses for business rules is handling the referential integrity processes for indexed files. Because indexed files (such as VSAM) are typically just raw data storage engines, your application must provide custom code to handle constraints, foreign key deletions, and other common referential integrity issues. Application-based referential integrity can also be appropriate for relational databases, especially in situations where the available triggers, constraints, and stored procedures are either inadequate or too complicated.

For More Information   For more information on maintaining accurate table relationships, see Providing Referential Integrity in this chapter.

Creating data access business rules requires careful planning, especially when considering interaction with existing business rules belonging to other applications. The benefit is that your data is secure, accurate, and easily accessible by not only your application but by other applications as well.

For More Information   For more information on designing business rules as part of your application's logical components, see Defining Application Logic in Chapter 3 of this book.