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

"James" <jraustin1_at_hotmail.com> wrote in message news:a6e74506.0206131844.2686ef8d_at_posting.google.com...
> > I disagree. I suspect your usage of class is approximately equivalent to
> > type, and I suspect your usage of instance is approximately equivalent
to
> > variable.
> 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.

... doesn't convey much meaning. It's kind of like saying everything is a symbol and then we can replace the above sentences with:

Symbol symbol symbol symbol.
Symbol symbol symbol symbol.
Symbol symbol symbol symbol symbol symbol symbol symbol.

> It could be that an object could have a type which may not necessary
> be the same as data type. What is your definition of type?

A set of values with common semantically equivalent operations and those operations.

> > > But unlike RDB where each tuple in the relation is typically a simple
> > > value,
> >
> > I think you need to reconsider the above statement. A tuple is a set of
> > values and is not a simple value at all.
>
> My understanding of a tuple was weak.
> Is it a set of elements from several domains arranged vertically
> side-by-side?
> Is a record a tuple?

A tuple is logical with unordered attributes and a record is physical with ordered attributes. However, they are otherwise similar.

> If so, my earlier comment was way off.

Okay.

> > > in OODB each instance is actually an object which allows it to have
> > > its own instances.
> >
> > You just lost data independence by exposing physical structure in the
> > logical interface.
>
> Instances(objects) are not independent of their class(object).
> Which physical structure was exposed?

References.

> > Contrast this with Date's and 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?

> > > In OODBs, the class (obj) and its instances (obj) are of the same
> > > type.
> >
> > Here is a perfect example of the confused thinking in the OODB world.
It's
> > not clear at all what a class really is. Is it a type? Is it an object?
An
> > object was defined as an instance of a class above, but now instances
are
> > the same as classes. An object is an instance of an instance? A class is
an
> > object? Doesn't that make an object an instance of an instance of an
> > instance? And so on ad infinitum?
>
> I stated it very poorly.
> I meant class is an object.
> and an instance is also an object.

An object is an instance and an instance is an object. We are back to ad infinitum.

> An object is equivalent to an element in either domain or range.

By this you must mean an object value, because the elements in a domain do not change.

> > 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...

> Do you mean obj.Instantiate & obj.Classify() ?

Nope. Those are non-generic operations defined on a specific type -- in this case the universal supertype.

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.

> > An RDBMS equates type with domain. Each scalar value in the RDBMS is a
value
> > of some domain. Appropriately enough, a domain is approximately
equivalent
> > to the mathematical concept of domain as pertains to relations.
>
> I am confused, I thought a relation always has a domain.
> A domain is used to define a relation.

As near as I can tell, an N-ary relation involves up to N+2 declared types (ignoring inheritance and most specific types). Each attribute of the relation has a type. The tuples have a type and the relation itself has a type.

> > I suggest we drop terms like "class" and "domain" to focus on "type".
>
> Could you define type at the logical level?

Yes. It is a set of values and their associated operations.

> What part does it play in defining a relation?

Type defines the data types of the attributes. The DBMS has a type generator that will create tuple and relation types from the attribute types.

As you can see, it plays a very important part. Received on Fri Jun 14 2002 - 08:06:37 CEST