Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!network!ucsd!ucbvax!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!odi!jack
From: jack@odi.com (Jack Orenstein)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: <1989Aug14.140128.15094@odi.com>
Date: 14 Aug 89 14:01:28 GMT
References: <3560052@wdl1.UUCP> <411@odi.ODI.COM> <19@dgis.daitc.mil>
Reply-To: jack@odi.com (Jack Orenstein)
Organization: Object Design Inc., Burlington, MA
Lines: 77

In article <19@dgis.daitc.mil> jkrueger@dgis.daitc.mil (Jonathan Krueger) writes:
>jack@odi.com (Jack Orenstein) writes:
>>I assume that by "extended rdb" you mean a relational database system
>>that permits instances of object classes to be stored in fields of
>>tuples, instead of just numbers and strings.
>
>What advantages of this approach would you see over support for
>domains and abstract data types?

I don't have Codd's 1970 paper in front of me, but in his 1979 paper
on RM/T, Codd defines a relation as a subset of D1 x ... x Dn, where
each Di is a domain. He then defines a relational database as a
collection of relations whose defining domains are simple, i.e.
"nondecomposable by the database management system".

Several relational DBMS vendors go beyond this definition, and provide
non-simple domains, in the same way that many vendors of Pascal
compilers add features that go beyond the language definition.

I'm not sure what distinction you're drawing between an extended
relational DBMS and one storing domains and ADT (instances). Simple
domains are accomodated by Codd's definition of the relational model.
ADTs and object classes require, in addition, the capability to refer
to functions of the ADT or object class from the query language.  The
set of all instances of an ADT or object class are certainly
comparable to a domain, but the procedural part of these constructs
might violate the "nondecomposable" requirement. This is a bit fuzzy
to me - how is nondecomposable defined? I cannot make a convincing (to
me) argument explaining why stacks are any more or less decomposable
than ints. 

If your question is about ADTs vs. object classes, I see a couple of
differences. First, an ADT is defined axiomatically, e.g. pop(push(s:
stack, x: int)) --> s, while an object class is more of a programming
language construct. (Of course, any practical implementation of an ADT
facility is not axiomatic.) Second, object classes are usually
associated with language features such as inheritance, polymorphism,
and other ideas that have turned up in various combinations in recent
languages.

The comparison that I am more interested in is relational (plus
objects or ADTs) vs. OO DBMSs. There are at least three aspects to
this comparison:

	1. From the point of view of an application developer, what is
           the correct paradigm of database usage: host language +
	   DBMS (as is currently the situation with relational DBMSs)?
	   A database programming language in which certain constructs
	   - relations - have special properties such as
	   persistence)? A persistent programming language?

	2. Performance issues - this has been the focus of much of
	   the recent discussion.

	3.  What role can the relational model play in
	    "non-traditional" (CAx) applications? Suppose that you
	    have a persistent programming language for use in 
	    developing CAx applications, and that you were interested
	    in extending the language by adding, in some form, 
	    operations of the relational algebra. How would this
	    be done? Would you add a relation data type as a builtin
	    type? Could it be an object class? Would all relations be
	    of the same class, or would there be a different class for
	    each tuple type? What happens when a join is done? An
	    alternative is to draw an analogy between relations and
	    functions, or relations and object classes. A natural join
	    would then generate a new function or object class.

As someone working on an OO DBMS product, the marketplace determines
issues 1 and 2, and the performance requirements are so strict that
they influence just about every other issue. 3 is primarily of
academic interest to me, as I'm interested in how the relational and
OO models relate to one another.


Jack Orenstein
Object Design, Inc.