I come from a long line of application programmers who were data-driven procedural programmers. For years, I exclaimed, There ought to be a file. Then I quickly slapped together a database file and began to maintain it with an ever-growing number of application programs. Soon, that file, which my fellow programmers and I created in our self-described brilliance, became unwieldy and unmanageable because it is maintained in dozens, or even hundreds, of procedural programs. Yet I, as well as that long line of application programmers that preceded me, knew of techniques that resolved the problems of unmanageable database files. Those techniques were proper database design and modular programming. What my fellow programmers and I needed to was develop active databases. So let me explain how you can use techniques that you are already familiar with to create an active database.
The Normal Way
Youve all heard about database normalization techniques. You know that while fourth- normal form is academically correct, third-normal form works best for real-world applications. So, Im not going to preach normalization, but I must mention normalization because an active database must be truly relational. A recent database technique to also consider is the use of user-defined fields, which are known as distinct types. With the use of distinct types, the database developer gains complete control over what types of operations are supported by columns declared as distinct types.
The next step to building an active database is to create constraints and triggers to ensure the integrity of your data. Constraints are rules about how data values can change. Verify and validate data values with such things as column defaults, value checks, data ranges, NOT NULL clauses, and unique constraints. Constraints are also used to ensure referential integrity of associated records from subordinate files using primary and foreign key relationships.
With the database defined, the next step is to add triggers. Triggers are processes that are invoked by the database before and after certain events such as inserts, updates, and deletes. Im know Im not telling you anything new, but I want to reiterate what Midrange Computing has said for years: Triggers are a powerful facility for ensuring database integrity.
One of the most optimal ways to implement modular programming is through the use of user-defined functions. Just like constraints and triggers, user-defined functions
should be created during the construction of the database. User-defined functions are invoked from SQL statements from within application programs, thus decreasing the requirement for procedure code within those applications.
Stored Procedures
The final technique used in the construction of an active database is stored procedures. Because stored procedures can be implemented in languages like RPG, COBOL, CL, and C, stored procedures allow your shop to leverage the use of your existing applications and application programmers. In addition to creating stored procedures with a legacy language, I also want to recommend the use of the SQL Stored Procedure Language (SSPL). Along with the file capabilities of SQL, you also have conditional logic, powerful cursor control, error handling, and local variables. SQL works on IBMs DB2 UDB everywhere, and SSPL is also very close syntactically to the SSPL of Oracle, Sybase, Microsofts SQL Server, and Informix.
SSPL is a combination of the strength of standard SQL and a number of procedural commands: CASE, IF, ITERATE/LOOP, FOR, LEAVE, REPEAT WHILE, and BEGIN/END. Your SSPL programs can create variables with DECLARE and modify them with SET. SQL experts will also tell you of the performance benefits of SSPL's dynamic SQL with PREPARE, EXECUTE, and EXECUTE IMMEDIATE.
I've trained several groups of RPG programmers in SSPL programming and many of them are amazed at how quickly they can create powerful programs with SSPL. One trainee in particular mentioned "It seems you really should attempt to write a program first in SSPL before resorting to RPG. And if you do opt for the RPG, the SSPL acts as well- developed psuedo-code."
You can create a SSPL program in a number of ways:
You can key the SSPL source to an AS/400 source file member and use the Run SQL Statements (RUNSQLSTM) commands to compile the SSPL program.
You can key the SSPL into OS/400s interactive SQL, which has the added advantage of interactive syntax checking.
Or, you can use Operations Navigator.
Regardless of the method, the SSPL source is converted into a C program with embedded SQL and then compiled; with the current version of OS/400 (V4R5), this means your OS/400 machine will have to have a C compiler. (Note that future OS/400 versions may remove the requirement of the C-compiler licensed program.)
Empowerment
You probably already know most of the techniques that Ive covered. But I think that many of you, like me, are so used to procedural programming that you havent taken the time to design active databases. Howard F. Arner, Jr., one of MCs database experts, once told me that code moves to data, which means that algorithms, over time, are replaced with active databases. The most optimal application design is one that has the least amount of code.
LATEST COMMENTS
MC Press Online