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.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale