Re: The (incomplete) Mathematical Foundation of OODBs (XDb)

"James" <jraustin1_at_hotmail.com> wrote in message news:a6e74506.0206142120.34f0783a_at_posting.google.com...
> > > Class is an object.
> > > Instance is an object.
> > > A object can store data of a type.
> >
> > Object is an object.
> > Object is an object.
> > An object can store data of a type.
>
> The 3 new sentences are not equivalent.
> A Class is an object but implies a relation with another object.

If object A points at object B and object B points at object A, does that mean that each is a class of the other?

> A object is just an object and does not imply a relation with another.

What defines the operations for a type?

> > > > Contrast this with Date's & Darwen's proposals in _The Third
Manifesto
> > > > where the logical interface exposes only operators and no physical
> > > > representation. This, of course, allows for any possible physical
> > > > representation gaining us the physical independence we so
desperately
> > > > need for effective data management.
> > >
> > > Same with my object model.
> >
> > You allow any representation of an object and do not rely on pointers?
>
> Each XDb object can do either mode: key or reference.

Then it gives up physical independence.

> Yes, and my model could be thought of as "ad infinitum" in some
> respects.
> Ie, Any person can have any number of children who in turn could have
> any number of children, etc.

Big deal, you've re-invented the network model dbms. If you want to use the accepted terminology, I guess you would need to dig up CODASYL -- if anyone even remembers what that is.

> > > > All this and no generic operators too!
> > > Could you explain/give example of generic operators.
> >
> > Join, restriction, projection, cartesian product, rename, extend,
summarize,
> > union, intersection, difference...
>
> XDb doesn't have such low-level operators. They are rather high level.

You mean it doesn't have such high-level logic operations it only has record at a time navigation.

> > > Do you mean obj.Instantiate & obj.Classify() ?
> >
> > Nope. Those are non-generic operations defined on a specific type
> > -- in this case the universal supertype.
>
> In XDb, obj.Instantiate & obj.Classify() work on any object.

Because every object is a subtype of a common class that defines them.

What generic operation do you have that in any way resembles 'cartesian product' ? ie. That operates on two "objects" of any type returing an "object" of a third derived type. (Here I use "derive" in its broadest sense, and it does not imply inheritance.)

> > Consider three relations: order, order_item, customer. Assume they have
> > appropriate attributes and mean what we would think they mean.
> >
> > Each of the three relations has a different type. The generic operation
> > 'restrict' is defined on all three of those types (and any other
relation
> > type), and the result is the same type as the original relation.
> >
> > The generic operation 'join' is defined on each pair of relation types.
The
> > join between order and order_item will result in a fourth relation type.
The
> > join between order and customer will result in a fifth relation type.
The
> > join between order_item and customer will result in a sixth relation
type. A
> > pair of nested join operations on all three will result in a seventh
> > relation type.
> >
> > The join operation is defined on any pair of relation types and always
> > results in a relation type. Likewise for the other generic operations.
> >
> > Because these operations operate on relations resulting in relations,
they
> > exhibit the important property of closure meaning that we can nest them.
> > i.e. The result of one can become the operand of another.
>
> I'll have to do a little reading here.

Yes, you will. Please, do so.

> XDb does not restrict the data type of an object by it's class.

This only means that your variables are untyped or weakly typed. Received on Sat Jun 15 2002 - 07:33:22 CEST