Re: Thus spoke SQL3 (on OO)

"Robert B. Easter" wrote:

> SQL3 does not appear to really have an object model. Rather, it
> appears to be a hierarchial model on top of the relational model.

It seems like it amounts to the same thing to me. A bit like me saying
"A circle is the set of points equi-distant from a point", and someone
else arguing "No, a circle is the graph of points represented by the
formula x^2 + y^2 = n". At the end of the day they amount to the same
thing I think.

The other thing is that some SQL3 statements seem to revert to the
object model -
"If [the table being altered] is a supertable, then an <add column
definition>, without further Access Rule checking, is effectively
performed for each of its subtables, thereby adding the column as an
inherited column in these subtables."

> So, it says that every subtable family (or member of) has exactly one
> maximal (root) supertable. This seems to make clear that multiple
> inheritance is not allowed. The picture of this hierarchy is inverted
> trees with the roots at maximal supertables with subtables branching
> down, EXTENDing the supertable.

"Effectively, components of all direct supertype representations are
copied to the subtype's representation with same name and data type. To
avoid name clashes, a subtype can rename selected components of the
representation inherited from its direct supertypes"

Notice it says "all direct supertype", which says to me you can multiple
_direct_ supertypes. Also note the "name clashes". How can you have name
clashes without multiple inheritance?

> Only one table can be specified in the UNDER clause, which prevents the
> following possibility:
>
> (1) subtable_a UNDER maximal_supertable
> (2) subtable_b UNDER maximal_supertable
> (3) subtable_abc UNDER subtable_a, subtable_b
>
> (3) is not allowed, but if it where, then subtable_abc would still have
> had only one maximal supertable. If allowed, it would have inherited
> maximal supertable twice.

If allowed, it doesn't mean it would inherit "maximal_supertable" twice.
It would have inherited it once through two routes. Like virtual
inheritance in C++. It some cases it could mean though that there is not
one maximal supertable though. If A inherits from B and C, you can't say
which is the maximal supertable. Don't know what those guys were
smoking, but whatever it is I want some.

> These effects describe a sharing of properties (columns) among the super and
> subtables. A row in a supertable may be part of a single row in 0 or 1 of its
> subtables (if I got it right) - a 1:1 relationship if any. The subtable and
> supertable are linked together in the tree hierarchy and are not independent
> after creation. The subtable extends additional attributes onto the supertable.

i.e. The object model expressed in a convoluted way?

> Since INHERITS, as it is implemented now, is like SQL3's UNDER, maybe
> it should NOT allow multiple inheritance and should strive to become
> UNDER if SQL3 is a good idea.

Renaming it UNDER might be ok. Breaking multiple inheritance would be
pretty silly, even if this is what SQL3 says (which I doubt).

> If the other object-oriented methods, like CLONES and ASSIMILATES (or whatever
> you want to call them), is ever wanted in PostgreSQL, then looks like some other
> standard(s) will have to be drawn from. I have not looked at the ODMG 3.0
> (standard) yet. But maybe it has the missing capabilities. Is ODMG 3.0 an
> international standard? I'd like to just download it and read it, but
> looks like you have to buy it for $39.95.

The best way to get an overview of ODMG is probably do go to the poet
database web site and download their documentation. I say poet because
they are one of the few with an OQL implementation. But ODMG is not so
much focused on query language and you could go to other ODBMS web sites
like Versant and look at documentation for the interfaces.