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

I agree, my description was not complete.

I have revised my definitions in the thread titled "OOPs! Object is the foundation of a Relation"

> What exactly is an instance?
> What exactly is a class?

See new thread.

> For instance, see Chris Date's recent article at
> http://www.pgro.uk7.net/c_substit.htm (One can navigate to this as an
> Article under the title "What Does Substitutability Really Mean? Part 1" in
> the Content section of http://www.dbdebunk.com/ -- in case the site moves to
> a new provider.)

Thanks.

> > Each instance can store a value of variant type.
> Isn't this the same as a weakly typed variable?
Yes, required to achieve object orthogonality. A domain can contain elements that must be represented by variou data types.

> > Class and instances are approximately equivalent to the mathematical
> > concept of single-column relation.
>
> 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.

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?

www.xdb1.com/Data.asp & www.xdb1.com/DataTypes.com

> > 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?
If so, my earlier comment was way off.

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

> That might work well in your application programming
> environment, but it sucks for data management.

You mean like schema evolution (changing classes)? If so, how could it be so easy in XDb?
www.xdb1.com/HowTo/ChangeCls.asp

> 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.
At the logical level, no physical representations. See new thread.

> > ********************************************************************
> > Summary:
> > Pure OODB and RDB are fundamentally based
> > on the same mathematical concept of relations.
>
> OODB and RDB are fundamentally based on the same mathematical concept of
> domains; however, OODB lacks the very important concept of relation. The
> OODB model is the equivalent of nouns without sentences.

> > In RDB, it is relation/values.
>
> In an RDBMS, all data are logically accessed as strongly typed values in
> relations as described above. This empowers the DBMS with the might of
> modern mathematics -- set algebra or equivalently first order predicate
> logic to be exact.

My understanding of relation was not complete.

> > In OODB, the equivalent is class/instances.
>
> Your particular brand of OODB exposes all data as weakly typed, named
> variables as described above. It has no equivalent of either set algebra or
> predicate logic, and it exposes physical structure in the logical interface.

At the physical level, an object must be able to store variable data types to remain orthogonal. Without orthogonality you end up with today's typical rdbs.

> > 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 equivalent to an element in either domain or range.

> All this and no generic operators too!
Could you explain/give example of generic operators. Do you mean obj.Instantiate & obj.Classify() ?

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

>
> I suggest we drop terms like "class" and "domain" to focus on "type".

Could you define type at the logical level? What part does it play in defining a relation? Received on Fri Jun 14 2002 - 04:44:17 CEST