From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!wuarchive!brutus.cs.uiuc.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard
From: eberard@ajpo.sei.cmu.edu (Edward Berard)
Newsgroups: comp.lang.ada
Subject: Object-Oriented DBMSs and Ada Applications
Keywords: OODBMS, Ada, CASE
Message-ID: <560@ajpo.sei.cmu.edu>
Date: 24 Aug 89 13:57:08 GMT
List-Id: <comp.lang.ada>

I realize that, at present, there may be relatively few Ada
applications which require the use of a database management system
(DBMS), but I expect the number will grow. For those of you that like
to think ahead, consider the ramifications of the following problem:

	You are about to begin a new development effort. This effort
	will require some form of a DBMS. You have selected Ada as the
	development language, and you have decided to use an
	object-oriented approach to the life-cycle.

	At some point during development, you realize that your
	software talks about object and classes, and your DBMS, being
	relational, doesn't understand these things. At first, you
	consider constructing an object-oriented interface to the
	DBMS. However, either the performance degradation introduced
	by the interface is intolerable, or you don't have the time or
	the resources to actually go about building the interface.

	Someone on your staff does a little bit of research and
	suggests that an object-oriented DBMS (OODBMS) potentially
	solves your problems. Your overall application now appears
	consistent, i.e., your software talks about objects and
	classes, and your DBMS also talks about objects and classes.
	There is no need to construct an object-oriented interface,
	and the possibilities of performance degradation is lessened.

For the moment, let us ignore the (major) problems of introducing an
OODBMS into your organization, e.g., staff training, changing of
business practices, and what do you do with all those data modelers.
What are you going to do about the following?:

	1. Your search turns up a number of OODBMS vendors. However,
	   none of these vendors has an Ada interface to their OODBMS.
	   In fact, you can't seem to find anybody in the Ada
	   community who is working with the OODBMS vendors on the
	   possibility of such an interface.

	2. You consider the possibility of writing your own Ada
	   interface to a vendor's OODBMS. However, you soon discover
	   that the vendor has been heavily influenced by C++. C++ has
	   a few things that do not directly map into Ada, and lacks
	   many object-oriented features that Ada provides, e.g.,
	   metaclasses.

	3. Being in the Ada community you have a (possibly forced)
	   reverence for standards. You discover that there are
	   precious few standards for OODBMS, including such things as
	   a standard query language. This means that you may have a
	   lot of re-writing to do every time you consider switching
	   OODBMS vendors, e.g., you need to go to a platform not
	   currently supported by your OODBMS vendor.

	4. You find ways to overcome most of the aforementioned
	   problems, but suppose you are working on a government
	   contract. The government has encouraged you in your choice
	   of an object-oriented approach, but proceeds to throw up a
	   bunch of roadblocks to your use of an OODBMS, e.g., many
	   government standards require the use of a relational DBMS
	   and SQL.

I would strongly suggest that members of the Ada community become
involved with OODBMS vendors, research, and standardization efforts.
If some of you are already involved, and it doesn't violate company
policy, it might be very worthwhile to publicize your efforts. [Of
course, I assume that the Software Engineering Institute is already
doing something with OODBMSs.]

It might also be interesting to examine existing and planned
government standards to see if they easily allow for the introduction
of OODBMSs, and any associated changes in procedures and
documentation. [Choice of an OODBMS will also impact such things as
the choice of an independent verification and validation (IV&V)
contractor, contractor qualifications assessment, and auditing
procedures.]

For those of you involved with computer aided software engineering
(CASE): Many CASE products involve the use of some form of persistent
information, and are thus based on some type of (possibly primitive)
DBMS. If a CASE tool supposedly supports an object-oriented approach,
there are some OODBMS related questions, e.g.:

	- If the CASE product makes use of some form of DBMS, and
	  claims to truly support an object-oriented approach, there
	  may be some significant performance penalties, and
	  unnecessary complexity if the DBMS is not an OODBMS.

	- If the CASE product offers external interfaces to DBMSs, can
	  the CASE product interface to an OODBMS.

Discussions of these, and other, OODBMS issues are taking place with
increasing frequency outside of the Ada community. I strongly believe
that the Ada community needs more visibility and involvement with
OODBMS issues.

				-- Ed Berard
				   (301) 353-9652