It’s time to talk about database modernization methodology. Because each scenario is a little (or a lot) different from the others, you’ll have to adapt these steps to your particular situation.
Most database modernization scenarios have a few things in common, which allows you to follow the three-step methodology presented in this section, with a few tweaks. This methodology is just a set of tasks and guidelines that you’ll need to adapt to your particular scenario.
Keep in mind that nothing is written in stone, and your knowledge of your particular context is of paramount importance to a successful modernization process. It’s important that you understand each step and adapt it to your needs. Although there are only three steps, they are complex and require detailed explanation. This means that the discussion of this methodological approach will span over several articles, so bear with me while I explain each step with enough detail for you to understand its core and adapt it to your application’s context.
You might find that you can safely skip one or more of them, while the others are mandatory to reap the benefits of the modernization process. Also keep in mind that you’ll be repeating these steps quite a few times, because you shouldn’t try to modernize the whole database at once. Start with the files that support the most important functionalities of the application. Once you’re done with those, repeat the process with the next group of files, and so on until you’re done.
These are the three steps:
- Convert the DDS files to DDL objects.
- Move business rules to the database.
- Take advantage of DB2’s advanced functionalities.
The general idea is that you’ll gain a lot with these changes, 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), but it’ll make sense in a while. Bear with me, and I’ll explain it all in greater depth over the next pages.
Let’s start with the first step, which seems self-explanatory…but it’s not.
Step One: Convert DDS Files to DDL Objects
Before converting your database from DDS to DDL, you really should take the time to understand, document, and analyze it. Even though you think you know your database, there will be some surprises (more on this next), and you need all the information you can get from your database before you move on.
This will be a time-consuming process, but it will pay off later. The result of this “detective work” will serve as the basis for the rest of the modernization process. In order to tackle such a complex and important step, you need to establish some sort of working process. Let’s go over a possible approach to this working process, which you should repeat for each library of your application that contains files.
Discover and List Existing Files
Depending on the application’s age, the process of discovering and listing existing files can be easy or extremely time-consuming. Older applications will require greater efforts. For instance, your application’s database might still contain program-described files (remember them from the old days?) that you’ll need to map into your database model. Don’t worry too much about them right now—just document their existence and move on.
Besides these ancient files, you might have some other peculiarities in your environment, which you’ll need to document. These oddities might include the following:
- “Ghost files”—These are empty shells. They only exist to be used as a base for a temporary file in QTEMP for a program to store data while it’s running.
- Output-only physical files—These are usually printout-turned-into-file-to-be-exported-to-PC-format files. They are somewhat similar to the previous ones, but they retain their content (the output of a certain program) after the program ends, even though their data has no direct relationship to the rest of the database.
- Logical files with selections—These files, which are often used as a way to speed up a program’s execution, might present a challenge later in the process, so be sure to locate all of them.
- Other oddities—Here’s where the knowledge of your specific environment comes in. You or someone on your team should have an idea of what other unusual stuff you have in your database. List everything, even if it doesn’t sound important.
Once you have listed all the files and what they’re used for, you’re ready to move forward.
Figure Out and Map Implicit Relationships Between Files
Again, this depends on the application’s age. I’d say that the probability of the relationships between the files not being in the database itself, but in the programs that maintain the data, increases with the age of the application’s database. It’s true that you can enforce referential integrity via logical files based on more than one physical file, but this is seldom used. You’ll need to map all of those relationships thoroughly because that will help you change your programs later, freeing them of the referential integrity tasks that they perform now.
That’s something to do later. For now, the idea is to convert the DDS files to DDL objects, and nothing else. This too will be a time-consuming and tedious task, but you can make it slightly less boring by drafting your Entity Relationship Diagram at the same time, which will be the topic for the next TechTip.
Stay on Course
At this point, you might be tempted to start drawing your existing database’s physical model, using IBM Data Studio, which I mentioned in the previous TechTip, for instance. Don’t do it! Legacy application databases are often a collection of seemly unrelated flat files, connecting to each other via the RPG programs that use them. There’s so much duplication, garbage, and outdated stuff that you’ll be wasting your precious time drawing a diagram. At this moment, concentrate on what you have to do to modernize other aspects of the database. As I mentioned before, next time around I’ll explain how you can start preparing to organize your database, by defining or refining the definition of a few things so that you can finally implement step 1 of the methodology: convert your files from DDS to DDL.