From: eberard@ajpo.sei.cmu.edu (Edward Berard)
Subject: Object-Oriented DBMSs and Ada Applications
Date: 24 Aug 89 13:57:08 GMT [thread overview]
Message-ID: <560@ajpo.sei.cmu.edu> (raw)
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
next reply other threads:[~1989-08-24 13:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1989-08-24 13:57 Edward Berard [this message]
1989-08-25 19:03 ` Object-Oriented DBMSs and Ada Applications Tim King
-- strict thread matches above, loose matches on Subject: below --
1989-08-26 8:04 Erland Sommarskog
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox