cpl@bhpmrl.oz.au (Paul Lloyd) (08/07/90)
Some weeks back I posted a query re Ingres' Object Management Extension. I was
basically after someone who may have it, or have trialled it in beta, to pass
on their comments on how it worked and its strengths and weaknesses. One major
concern that I had was that I had heard that the objects had to be linked into
the dbms's kernel. For me this seemed to make it difficult to determine where
a problem might lie - in the object itself or in the dbms - and I was concerned
that this confusion may result in a poor, or at least very iffy, software
maintenance situation. My responses were meagre, but at least they were
consistent. In between time, I have contacted Ingres here in Australia, and
have done a bit of searching for myself. I pass on here a summary of my
findings, with some comments which may be of help to you. I stress, however,
that I have no practical experience of this product.
Object Management Extension licence fees are around 50% of the base product's
fee. It appears that you have to define your objects and its operators in a
supported 3GL - I have only seen C mentioned, so far. For the licence fee you
get a manual with (I am told) copious examples and the tools to link the new
object and its operators into the Ingres kernel so that it is recognizable by
the SQL query analyzer. In this way you can have your own data types (as
complex as you can manage?) and the operators to process them just as
recognizable to SQL as date and time data types are now. Note that you can
redefine the standard SQL operators for your object. In addition to the tools,
you get the services of a consultant from Ingres who will review your data type
definitions and operators to ensure that they conform to the Ingres object's
requirements as given in their manual. I am not sure whether you can go ahead
and link your object in without this consultant; it would seem prudent to me to
avail yourself of this consultancy service since you have paid for it and it
should be a hedge against problems later. At present I have no indication of
how effective the support is, and whether the issue of confusion over sources
of dbms problems is easily resolvable.
By way of a critique, allow me offer the following comments:
(1) This product does not make Ingres an object-oriented database (and I think
Ingres is careful not to suggest this).
(2) The "objects" you define provide a form of data abstraction and
encapsulation, but do not have inheritance and (therefore) polymorphism.
(3) The encapsulation of the "methods" (operators) is not standard practice
for object-oriented systems. You, in fact, bind them to the dbms kernel,
not to the "objects" themselves. This is tantamount to binding the
methods to the compiler rather than binding them to the objects in a
typical object-oriented programming language.
(4) The placing of the "objects" in the kernel has the distinct advantage of
allowing those objects and their associated operators to be available
across all of databases, and hence, across all applications. The problems
associated with global data types are generally lower than with global
data variables in application development. However, I can see some
disadvantages in this approach which would require careful management:
(i) A priority on careful definition of these objects is required so that
conflicts do not occur where logically similar objects may need
different definitions in different databases and applications - you
would need to define them with different names even though one would
normally use/think of them by the common logical name. For example,
one may use a POINT object to represent Cartesian coordinates in one
system, and Polar coordinates in another.
(ii) As should always be the case, full and careful documentation of the
objects and their operators is required, and therefore should only be
handled by the dbms system manager's staff - you may run into problems
if you have more than one dba with authority to generate "objects",
and it should never be offered to "knowledgeable/experienced" users
without careful supervision and coordination.
(5) These "objects" do, however, provide a means of implementing the domain
concept of the relational data model (RDM), and possibly extending it. In
this way, Ingres' move seems appropriate as it represents a positive step
by a RDBMS vendor towards full support for the RDM. This point is made
also by Pascal in Database Programming & Design, May 90, p.73. When this
is taken in association with their Knowledge Management Extension product
which supports referential integrity and business rules in the database,
Ingres is looking quite progressive - where vendors should have been some
time ago, particularly for decision support applications?
While I have made a number of reservations about the approach used by Ingres
in their Object Management Extension product, I find it attractive and would
like to explore it further! However, the price might be prohibitive just at
the moment, let alone the resources and time to do it justice. I have no
idea how this Extension might affect performance. Can anyone enlighten, or
add further comment??
--
/\/\ Paul Lloyd, EDP Systems Superintendent
/ / /\ BHP Melbourne Research Laboratories
/ / / \ 245 Wellington Rd Mulgrave Vic 3170 AUSTRALIA
/ / / /\ \ Phone : +61-3-560-7066 ext:7375
\ \/ / / / Fax : +61-3-561-6709
\ / / / ACSnet : cpl@bhpmrl.oz.au
\/\/\/ Internet: cpl%bhpmrl.oz.au@uunet.uu.net