Time to start discussing the second big step in our database modernization methodology: moving business rules to the database. It’s going to be an interesting trek, and I hope you join me in it!
The previous four TechTips (you might want to re-read those articles, starting here) covered the conversion of DDS files to DDL objects, which is the first of three database modernization steps (convert the DDS files to DDL objects, move business rules to the database, and take advantage of DB2’s advanced functionalities). The general idea is that you’ll gain a lot with these steps, in terms of performance, database user-friendliness, and flexibility. It’s not an easy path, and some steps may sound a bit weird (yes, I can imagine what you’re thinking about step two, which I’ll start explaining in this TechTip), but it’ll make sense in a while.
Move Business Rules to the Database
During your analysis of the database relations, you probably realized that your programs have a lot of code just to enforce data consistency and referential integrity. If you followed the steps proposed in the last four TechTips, you should have a nice list of programs and the database rules they enforce. It’s now time to start moving those rules—and more, as you’ll see in a bit—from the programs to the database.
Depending of the age of your application, you might find that up to 80 percent of the lines of code deal with database relationships and database validations, according to a study performed by the company responsible for the AO Foundation product (I’ll get back to this brilliant piece of software in future TechTips). Removing this code from your programs and integrating it in your database will not only further increase performance, but also make your code (even) more readable and maintainable. Moving from OPM to ILE and segregating the monolithic programs into more manageable programs and service programs already increased the IT staff’s productivity and the application’s performance and agility. This is the next logical step. Let’s start with the easiest part: database relations and validations.
Putting Database Validation in the Database
Let’s approach this process with the same mindset applied to everything else in modernization: think big and start small. Pick a program or set of programs designed to maintain the data of one of your application’s least important master files. A significant part of the program’s code probably deals with field-level validations and consistency between files (master-detail relationships are a good example). That’s what needs to be moved to the database. The consistency between files, typically used in situations where a record in a file cannot be deleted (or have some of its fields changed) if a corresponding record or set of records exists in another file, might require several I/O operations. In that case, the code can get messy really quickly. This can be moved to the database in the form of referential integrity constraints. (I’ve written about constraints in an earlier article, which you can find here).
Depending on the specific situation, you might need different keywords. Let’s do a quick overview:
- If you need to ensure that no duplicate keys exist on a certain file, you’ll need to use the UNIQUE keyword (similar to the DDS keyword of the same name) or the “more SQLish” PRIMARY KEY in the CREATE or ALTER TABLE statement.
- If you need to need to restrict the possible values of a field to a range or list of admissible values, see IBM’s DB2 for i Reference manual section on table creation. You’ll find a check constraint example. Even though it’s a simple example, it should be enough for you to wrap your head around the principle and adapt it to your needs. I’ll probably discuss CREATE and ALTER TABLE in my other TechTip Series (“SQL 101”) at some point in the future.
- Use a referential constraint to enforce business rules related to data dependency, such as the impossibility of creating an order for a client that doesn’t exist in the database. This too is something that you can apply via CREATE and ALTER TABLE statements.
To see how this last item can be enforced, consider a client table named CLIENT_MASTER and an order table called ORDER_MASTER. Assuming that both tables already exist in library MYAPPDB, the following simple statement replaces whichever validations you have in your program and enforces them on all attempts to update or delete records from the order master file, regardless of their origins:
ALTER TABLE MYAPPDB/ORDER_MASTER
ADD CONSTRAINT OrderMst_CliNbr_Constraint
FOREIGN KEY (CLINBR)
REFERENCES MYAPPDB/CLIENT_MASTER (CLINBR)
ON DELETE RESTRICT
ON UPDATE RESTRICT
This is particularly useful when you have external accesses to your database with the permissions to change it accessing the IBM i’s database via ODBC, such as a PC application that manipulates order records.
There are many other validations and actions you can perform using referential constraints. You need to carefully analyze each particular business rule and determine what the best course of action is.
Coming Up Next
In the next article I’ll continue this discussion and address the moving of the database input and output operations from your programs to somewhere else—a “thing” called I/O Server. Again, this might sound weird, but you’ll see it’s worth it!
Until then, feel free to comment on, agree with, or disagree with this article using the Comments section below.