Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: <1989Aug11.143036.24703@odi.com>
Date: 11 Aug 89 14:30:36 GMT
References: <3560052@wdl1.UUCP> <408@odi.ODI.COM> <3324@rtech.rtech.com>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 130
In-reply-to: dennism@menace.rtech.COM's message of 9 Aug 89 17:13:28 GMT

In article <3324@rtech.rtech.com> dennism@menace.rtech.COM (Dennis Moore (x2435, 1080-276) INGRES/teamwork) writes:

   |Many CAD and CASE applications currently don't use any existing DBMS,
   |relational or otherwise.  Or if they do, they only use it at a high
   |level of granularity, or for peripheral functions.  Few or none of
   |them use a relational DBMS to store, say, individual transistors, or
   |whatever are the small elements in which the program primarily deals.
   |Since they're not using a relational DBMS now, there's no issue of
   |"staying with an evolving rdb".

   This is common disinformation that OODB companies have been spreading in
   an attempt to generate a "need" for their product.  

If you intend to use comp.databases as a forum for insult and
invective rather than information and discussion, I won't continue to
reply to your postings.

						       Most CASE companies
   use RELATIONAL databases at the hearts of their products.  For instance,
   Cadre (teamwork) have used a number of commercial databases on different
   platforms, and are forging a MUCH CLOSER relationship with my company (RTI).
   IDE (Software through Pictures) uses an in-house RDBMS called TROLL, and are
   forging a MUCH CLOSER relationship with Sybase.

I stand by my statement, above.  The largest U.S. CASE company, Index
Technologies, does not use any DBMS in its product.  They have
carefully considered the question and decided that existing DBMS
technology is inadequate for what they want to do.  The major ECAD
companies do not use any RDBMS for anything, or at least not for
anything at the heart of their systems.

To explain what I mean by this, consider the following questions:

Can you name one serious ECAD system in which each gate and each wire
of a schematic is represented by one or more tuples in a relational
database system?  That runs simulations or design rule checks by accessing
the relational database system for each circuit element?

Can you name one serious CASE system in which each, say, box and
connection of a dataflow diagram is represented by one or more tuples
in a relational database system?  That refreshes its video display by
accessing a relational database for each of these little elements?

This isn't generally done because (a) the performance would be
unacceptable, and (b) the amount of programming needed to translate
between the datatypes and computational constructs of a relational
database and of a programming language would be too painful.

Those CAD systems that are built on relational databases use them
almost exclusively for selection, and sometimes for projection, but
perform or precompute joins in the program memory of the design tools.
Such tools read the appropriate chunk of the database at startup, and
build internal record and pointer structures from it in virtual
memory.  Thus, a design session starts by copying one part of the disk
into another.  At the end of the session, the internal structures are
converted back to tuples and written to the database.  This loading
and unloading can be very slow compared to the time to make small
change in a design.  Most CAD systems don't even work this way: they
store their data in files, in the operating system's file system.

   Many databases have substantial object-oriented features;  

Unfortunately, the phase "object-oriented" is used to cover so many
different areas that it's hard to conduct a meaningful conversation
about what "object-oriented database" means.  Certainly, you can store
strings representing SQL strings in a relational database.  Certainly,
you can add "rule" and "trigger" features to a relational database
system.  And these are useful, and people will use them.

However, the introduction of these features still won't result in each
gate and each wire being represented as an element in the database
system.  The really interesting data like gates and wires will still
have to be stored in files in a file system, just as they are now in
every real ECAD system.

In the view of the people in the OODBMS companies, we will have
succeeded when there is no longer any need for a CAD/CASE company to
use the operating system's file system for anything at all, and when
the CAD/CASE tool can be written in a single, unified language, with
no translation between normalized relational tuples on the one hand,
and a programming language with its type system on the other hand.
And all this without performance degradation.

A particular requirement is that fetching a data value out of the
database system must be as fast as fetching a component of a structure
(record) in the programming language.

That's what I really mean by "object-oriented database system".  A
relational system with extra added "object-oriented features" like
rules and triggers, while it has its uses, does not solve the problem
that we are trying to solve.  Those "features" are beside the point;
beside our point, anyway.  These problems cannot be solved by taking a
relational database system and adding some new "features".

We have presented our ideas to a range of leading CAD, CASE, and
related companies.  Many of them are very interested in seeing such a
system, and most realize that they aren't likely to get it from
relational database technology.  The leading technical people at these
companies are quite sophisticated about software technology; they
can't be "fooled" by simplistic "disinformation".  Being
sophisticated, they are of course skeptical of all future claims until
they see real working systems.  But they also have a good
understanding of what exists now, and why it works the way it does.

In fact, several of these companies, who can't wait for the new
OODBMS's and obviously can't be sure when those new system will
appear, have been working on in-house solutions, usually very
specialized OODBMS's (in the sense that I use the term) tailored for
their own application.  They realize that their in-house systems are
stopgap measures, and hope to replace them with a more general,
complete, tuned commercial OODBMS product at some point.  They would
not be doing this if they saw the solution coming soon from the
relational companies.  (The solution to the problem I'm talking about
-- not to the ones that you're talking about, for which relational
technology works OK.)

Certainly many CAD/CASE systems will still need to communicate with
relational database systems, since a lot of important data is and will
be stored in RDBMS's.  OODBMS's will not replace RDBMS's, and are not
trying to.  Rather, they are trying to answer new needs that will not
be answered by RDBMS's.  The mature, advanced CAD/CASE systems of the
future will use both kinds of database system.

For anyone interested in a deeper discussion of these points, I
recommend a short paper called "Making Database Systems Fast Enough
for CAD Applications", by David Maier.  It's in an excellent anthology
entitled "Object-Oriented Concepts, Databases, and Applications",
edited by Won Kim and Frederick Lochovsky, ACM Press/Addison Wesley
1989, ISBN 0-201-14410-7.  It's a new book and should be relatively
easy to find.