Object equals Relation

> > 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. Only the terminology and representation differ but they both describe the exact same 'fundamental concept'. 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).

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.

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.

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

Discussion appreciated on whether an object is the same as a relation? Received on Wed Jun 12 2002 - 22:33:19 CEST