Re: The Fact of relational algebra (was Re: Clean Object Class Design -- What is it?)

."Bob Badour" <bbadour_at_golden.net> wrote in message news:cd3b3cf.0110171907.ab2108d_at_posting.google.com...
> danp_at_romaxtech.com (daniel poon) wrote in message
news:<aebcb9af.0110141213.78145e62_at_posting.google.com>...
> > Very well put. They do indeed store axioms.
> > I know how you would express "the factorial of 1 is 1" in an rdbms,
> > but how would you express the proposition that "the factorial of n is
> > equal to n multiplied by the factoral of (n-1)"
> > 1!=1
> > n!=n*(n-1)!
>
> Either recursively or iteratively as an operation on some suitable
> domain or domains.

This is not possible in SQL, so I presume you are talking about another implementation of rdbms.

> > > > Relational databases cannot directly represent a mathematical set in
the
> > > > data model.
> > >
> > > Your statement is false, and apparently based on ignorance of the
topics you
> > > discuss. Relational databases directly represent mathematical sets in
a
> > > number of different ways. Domains represent sets. Relations represent
sets.
> > > Constraints represent sets.
> >
> > But OO systems only represent sets in ONE way.
>
> Actually, OO systems represent sets many ways. References (or
> pointers) identify sets. Classes represent sets. Messages represent
> sets. Collections represent sets.

Mathematitians use Sets and Functions to describe anything and everything. Just coz Sets are used in the definition, does not mean that what is being defined IS set theory. For example the definition of a FSM (finite state machine) is

-A set of input events
-A set of output events
-A set of states
-A function that maps states and input to output
-A function that maps states and inputs to states (which is called a state

This does not mean FSM is Set theory. Similarly sets are used to describe relational algebra. This does not mean relational algebra is set theory.

 > And everything is
> > represented using that same construct. (By sets, I don't mean
> > collection classes, bags, lists, dictionaries etc).
>
> Those are all sets, though, and OO represents them each differently.

My point of bringing up collection classes was to say that they are not part of the discussion ;-)

> > > > OO databases store classes directly.
> > >
> > > Is this really true? I realize that some ODBMS products store classes
as
> > > instances of metaclasses, but I do not think this is inherent to all
OO
> > > databases. I find it much more accurate to state that "OO databases
store
> > > object instances directly." Relational dbmses are OO dbmses because
they
> > > store object instances identified by a combination of relation name,
> > > candidate key value and column name.
> >
> > When I said that OO dbms store classes directly, I meant that they
> > store the extension of the classes directly.
>
> While some OODBMS languages/products expose an extent or extension set
> for every class, some do not.

Yes, I think there has been a trade off for performance. But basically the original OO concept is that every class has an extent.

> > > > Classes are mathematical sets (with
> > > > certain restrictions I know) and are first class objects.
> > >
> > > Classes, in non-relational dbmses, are not sets. Sets and set elements
do
> > > not have locations or references.
> >
> > OK, to side step one possible side debate, lets assume our computer
> > has an infinitely big hard drive with infinately long pointer address
> > space. Therefore physical location or other implementation issues are
> > not relevant.
>
> The assumption does not address the problems of physical location in
> the logical interface.

Run that past me again...

> > Now please say again why you can't reference a set or the elements of
> > a set?
>
> Sets and values do not have location. One can reference them
> conceptually. A relational dbms references them logically.
> Navigational systems incorrectly and problematically equate physical
> reference with logical reference.

Whats the problem. We have an infinitly big hard disk, with infiniately big references. I can't see how location would cause a problem.

> > > > The class called
> > > > 'Object' is the same as U, the universal set. The fact that classes
are
> > > > subclasses of other classes is directly represented (some might say
too
> > > > directly).
> > >
> > > Not all OO products and languages have a universal "Object" class. Of
those
> >
> > Im not arguing for a particular OO product. Im arguing about how the
> > OO model is similar to Set theory.
>
> The relational algebra is set theory.

Oh, I can hear Russell turning in his grave.

> > > that do, the only universal property of Object is location. IE. One
> > > references instances of the Object class, and one cannot operate on
values
> > > of the Object class without a reference.
> >
> > The only property of the Universal Set, U, is that everything belongs
> > to it.
>
> Which makes it useless from data management and application
> programming points of view. The class "Object" is not the same as the
> universal set. The only commonly agreed property of the various
> "Object" classes is location, but values have no location.

The class Object is immensly useful for building systems. So is the base class of any class heirarchy.

> In a dbms, logical identity is a logical replacement for location.

I know how that works, thank you. And work it does. But as a system it has assumptions that make it unsuitable for representing set theoretic constructs.

> > The only property of the Object class is that everything is an
> > instance of it.
>
> If that were the only property, it would be useless for data
> management and application development. As I mentioned previously, the
> only commonly agreed property of "Object" classes among systems that
> define one is location.

see above

> > See the similarity?
>
> No, I do not. The CPU of my computer is an element of the universal
> set, but my computer does not have a CPU object type. The atoms the
> CPU comprises are likewise elements of the universal set, but my
> computer does not have any atom object types either.
>
>
> > > > Although this only happens in the strictest form of the sense while
the
> > > > object is being constructed, the basic idea is there in an OO
system, that
> > > > objects exist independant of the relationships it belongs to.
> > >
> > > How do you reconcile the above statement with your believe that all
things
> > > are subtypes of Object? How does an object instance exist independent
of its
> > > type or class?
> >
> > In three senses this is true. Firstly, in terms of physical
> > organisation, homogenous objects are not stored contiguously like they
> > are in rdbms.
>
> The relational model imposes no restrictions on storage. Your
> statement is fatuous and does not answer my question.
>
>
> > Secondly, you don't have to know exactly what class an object belong
> > to to be able to manipulate it.
>
> The relational model allows polymorphism too, and your observation
> does not answer my question.

Not the one Ive used.

> > Thirdly, they just are independent of class and type!!! Its a
> > fundamental assumption.
>
> Really? An object instance has no relationship to its type or class?

I didn't say it has absolutely no relationship to its class. I said it is independant of its class.

> You have avoided answering the question. If all object instances must
> have a relationship to the Object class in order to exist, how can
> object instances exist independent of their relationships?

Because everything must be by definition a member of the Universal set. Its all a question of definitions and assumptions. OO systems have different definitions and assumptions to rdbms and procedural programming languages.

Daniel Received on Thu Oct 18 2001 - 11:50:38 CEST