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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online