A Fear of Relationships

A Fear of Relationships
by Thom Kolton

Relationships are a part of life. With our family, our loved ones, our boss and colleagues, our community, relationships are the glue that binds us to our world.

Yet once established, we don't tend to dwell on the nature of these relationships --- unless they change significantly. Which is precisely the way it should be. Relationships are not important unto themselves, but are a means by which we create our surroundings and build our lives.

For business organizations, relationships are important because they define the operating structure of the company. The relationship between organization and customer, between departments, between staff, between other organizations; it is the establishment and use of these relationships that permit a business to do what it's suppose to do, namely, make money.

In the 1970's, Dr. Edgar F. Codd, then on staff with IBM, presented a paper describing how business relationships could be used by a computer to facilitate data access and manipulation. The theory was a hit, and today there is a plethora of relational database products on the market. In fact, the RDBMS model and Structured Query Language (SQL) have become de facto standards in the information technology industry.

Object oriented database management systems (OO-DBMSs) began to spring up a few years ago. Most commercial vendors haven't adopted this technology exclusively, though, opting instead for a hybrid which incorporates objects into relational technology. In fact, the next version of SQL, SQL-3, due out sometime in 1998, incorporates such things as support for video, audio, and graphics data types. Embraced by such companies as IBM, Oracle, Informix and Sybase, and running mission-critical business applications, it appears that relational technology is going to be around for a long time.

Yet, a part of the TPF industry remains somewhere between weary and skeptical of RDBMSs. How can this be, you might wonder?

Well first, in terms of speed, RDBMSs have not always had a stellar reputation in the industry. The first products to market were painfully slow. But over the years, improvements in both software and hardware technologies have enabled RDBMSs to support organizations' mission-critical applications, and to take a lion share of the database market as well.

Now some readers might be thinking, "Oh, yeah? Well, a RDBMS running on some other platform couldn't replace TPF in my shop!" Perhaps, perhaps not. Keep in mind that even though vendors strive to raise performance levels of their RDBMS products, they are constrained by the architecture of the OS. If yours is a large shop running several thousand transactions a second, this is the reason you are using TPF. Here, Greyhound RDBMS might be your best bet for database management. If your transaction volume is, say, 400 per second, look out because someone in the front office just might be planning to replace your system --- and perhaps you.

Second, there are just some plain old TPF-biased people out there with either misconceptions or a lack of knowledge about relational technology. The fact is that TPF programmers have always supported data relationships, albeit by hard-coding these relationships into application programs.

For the sake of argument, let's use an airline reservation scenario. Let's say that the format for a telephone number must be a valid 3-letter city code, followed by three numerics, a hyphen, three more numerics, another hyphen, then four numerics, and possibly followed with free format text.

To do this manually, these business rules must be written into a program. Using a RDBMS, the fields and their properties are defined to the database. Now, when the CEO informs the CIO that European telephone numbers cannot be entered into the database and Sales is unable to sell, it's crucial to fix the problem quickly. With a RDBMS, the database definition can be easily changed without program modification, permitting Sales to sell and, perhaps, saving the CIO's job. If the business rules are embedded in the program logic, time-consuming program modifications will be necessary, and there might just be an opening for a CIO position.

Again using the airline analogy, consider data such as remarks, itinerary segments, OSI and SSR information, etc. These datum are physically related to each other because they are stored within the same PNR. But there is actually an unwritten logical relationship between them: they all relate to the same passenger(s) for a given trip.

Third, there are some wrong assumptions about the physical requirements of RDBMSs. Many believe that a RDBMS dictates high overhead. Not necessarily so. There are many implementation variables to consider, such as locking techniques, logging requirements, record partitioning, etc. The rule of thumb is that the amount of overhead is based upon the overall complexity of the database. And many of the TPF databases out there are a lot less complicated than programmers would like to believe.

If you were to look at Greyhound RDBMS for TPF, you might notice two significant characteristics. One, the database layout is very much standard fare for TPF and easy to understand. Two, because the database plan contains step-by-step instructions (logical, not machine) on how to resolve a database request, the overhead can be negligible and replaces pages and pages of programmer- written code. Consider that when you're modifying a package or reorganizing the database.

Finally, most people find change scary. To give up data manipulation control to a "black box" can be a frightening thought. After all, some programmers see their value to the organization based upon their technical prowess. Although this may be true for some, the greatest asset of applications programmers is their keen knowledge of the business they support and their ability to translate user needs into viable business applications quickly.

So, have you had any good relationships lately?