From: gfabian@cti.com (Greg Fabian)
Subject: Re: Relational Systems set back DP by at least 10 yrs.
Organization: Comprehensive Technologies Int., Inc.
Date: Mon, 13 Apr 1992 12:55:15 GMT

I read with mirth Mr. Baker's letter in the April CACM.  I am sure that there
will be many interesting responses to his letter in upcoming issues.  Having
worked with all three data base models (S2K, Image, Unify), I can say that,
for my purposes and the applications that I have worked on, the relational
approach has provided the simplest, most logical data model (most of the
applications I work with are financial management systems for the government).

It is true that to effective use of an RDBMS requires a good data base design.
I have inherited several "flat file" applications that were "slapped" 
together.  No allowances were made for referential integrity.  Erroneous and
redudant data were the rule, not the exception, to these applications.  Sure,
a report could be generated in record time, but the data were unreliable.  The
amount of effort required to scrub the data was excessive and pulled effort
away from making the application better.

I have also used indexed-file based designs mostly because a RDBMS (or other
DBMS) was not available.  These ISAM file-based applications usually followed
a relational approach, but had the following drawbacks:

   - No centralized data dictionary.  Program/system documentation had to 
     suffice.

   - No ad-hoc query capability.

   - Manual, rather than automatic, inforced referential integrity.  If the
     programmer "forgot" about a look-up file, index, etc., the check wasn't
     done.

In short, these system required a lot of maintenance and, because some of them
were poorly designed in the beginning, we had to live with the initial short-
comings as the applications evolved.

I am very curious about OODBMS, but I really do not see a tremendous difference
between them and a RDBMS.  I tend to decompose things into objects anyway.  In
a way, the process of normalization is the "compartmentalization", i.e.,
grouping of data elements into (object) classes.  (For example, a building is an
object that has rooms containing computers made of components for an ADP
inventory application.  Each item is a different type of object or class that
ultimately comprises the inventory.)   I do believe that an OODBMS will 
provide us with tools to handle wierd data types, like sound, video, etc.

Whatever the future brings, what you should really look out for is a DBMS that
assists (not hinders) you in translating your data model into an automated
design that provides for data accuracy (integrity), easily documented and 
maintainable, extensible, and has good front-end application development tools.

Now all we need are client/server, distributed DBMS running over a modular
graphics/object based operating systems/GUI that really does allow the network
to become the system.  But that's a subject for another newsgroup.

   G. Fabian
   CTI, Inc.
   gfabian@cti.com
--------------------------------------------------------------------------------
   Opinions expressed are those of my own. 
   Nobody is responsible for anything.
-------------------------------------------------------------------------------