Re: Object equals Relation

From: Richard MacDonald <macdonaldrj_at_worldnet.att.net>
Date: Thu, 13 Jun 2002 04:38:16 GMT
Message-ID: <Xns922BF175BEE6macdonaldrjworldneta_at_204.127.36.1>


jraustin1_at_hotmail.com (James) wrote in news:a6e74506.0206121233.58c1c700 _at_posting.google.com:

>> > What does an OODB-model lack
>> > that prevents it from being as expressive as a RDB-model?
>> 
>> Relations.

>
> I think I now understand, and agree, the fundamental basis of
> databases is the 'fundamental concept' described by a relation.
> According to relational terminology: a relation is a set of related
> things.
>
> An example, of a relation is the "concept of a Marble" and 3 marbles.
> In this case we have
> Thing1: Marble
> Thing2: M1
> Thing3: M2
> Thing4: M3
>
> It am certain that the concept described by a relation is the very
> same concept described by an object.

As long as your object is of type "RelationalSet", then yes :-/

> Only the terminology and
> representation differ but they both describe the exact same
> 'fundamental concept'.

Objects can define "sets of one" as something different than a set. Arguable whether this is better or worse. Otherwise, little wrong with the relation<->class / relvar<->instance idea.

> The object terminology/representation is
> preferrable and tends to a clearer understanding because the
> orthogonality of "my" oo terminology/model is in line with the
> orthogonality of the 'fundamental concept' at hand. In fact, I would
> agrue that the non-orthogonal relational terminology has hindered the
> comprehension and implementation of the 'fundamental concept' by many
> people. A ubiquitious, example of such is the current implementation
> of typical rdbs whose potentials are significantly crippled by the
> lack of orthogonality present in the 'fundamental concept'. Today's
> oo/oodbs are a "stab" at getting past those limitations.
>
> Below is "my" core oo model which, I am proposing, describes the same
> 'fundamental concept' described by a relation:
>
> 1. An object represents a thing (a value, a word, a person, a car, a
> sound, a picture, a movie, a smell, a feeling, an idea, the concept of
> a Marble, M1, M2, M3, etc).
> 2. An object(Marble) can have instances(M1, M2, M3).
> 3. An instance(M1) is an object that has a class(Marble).
> 4. A class(Marble) is an object that has an instance(M1).
>
> What seems like a circular definition is exactly what is required to
> represent the orthogonality present in the 'fundamental concept' which
> is that an instance(object M1) can itself have instances(object M1a,
> M1b, M1c).

Are you proposing to abandon the idea that a collection and an item in that collection are "different"? That is what I am reading from your (2). Also, shouldn't (2) be written: "An *instance* (Marble) can have instances(M1, M2, M3)"?

> Consider the results described below of non-orthogonal(typical rdbs)
> vs orthogonal(XDb) implementation of the 'fundamental concept'.
>
> There exist "the concept of marble" and 3 marbles. To represent this
> in
> rdbs, we create a table named T_Marble and add 3 records and set their
> values to M1, M2, M3. Similarly, in XDb, we create an object and set
> its data to Marble and instantiate three objects and set their data to
> M1,
> M2, M3. In rdbs, we use non-orthogonal 'containers': table to hold
> T_Marble and record fields of to hold M1, M2, M3. A table is not
> orthogonal to a field. In XDb, we use orthogonal 'containers': objects
> to hold Marble, M1, M2, M3. Class and instances are both objects.

You created an "object" and set its data to Marble. Is this an instance or an instance of class, i.e., a Class? (As a Smalltalker, I have no problem with this latter idea -- in fact, I often write class-side code to do keep track of all instances, etc -- but you need to be more explicit if this is what you are suggesting.)  

> Now consider the case when there exists marbles M1a, M1b and M1c which
> are related to M1. In rdb, we create a table "T_M1" with 3 records
> M1a, M1b, M1c. To represent the relationship (not the same a relation)
> between T_Marble.M1 and marbles in table T_M1, we add a foreign key in
> T_M1.

Are you suggesting the M1A, M1b, and M1c are "subtypes" in the sense of inheritance? That kind of relationship? Are you suggesting that the relationship is something like "marbles M1a, M1b and M1c are all currently residing in my bag"? I think you're thinking about the subtype relationship.  

> Contrast the above with the orthogonality of XDb. We make 3 instances
> of object "M1" and set their data to M1a, M1b and M1c.

You forgot to include that you also created the object/instance "M1" and its relationship to "M". Less orthogonality and more mirror-ality :-)

> Discussion appreciated on whether an object is the same as a relation?

Pretty close, but as Date might say: "close is still very different" :-) Try (1) adding a RelationalSet interface to your Object class and (2) writing class-side code to manage your instances, and you can get many significant differences ironed out. More importantly, you can learn some things and gain an understanding of how the two can work together. But as far as claiming that an object is the same as a relation, a theorist is going to say "no hell no" and be correct.

Also, you'll have to tighten up on relation vs. relvar "relationvariable".

Have you read the third manifesto? A must-read on this subject, but hardly the last word -- the authors are too lacking in practical knowledge of OO languages to finish the matter. (Several cases of "OO cannot do this" claims which are easily rebutted with "can do and do quite easily with a good OO language".). Received on Thu Jun 13 2002 - 06:38:16 CEST

Original text of this message