Re: Object Class and Data Type

From: Eric Kaun <>
Date: Fri, 02 Apr 2004 16:19:50 GMT
Message-ID: <Gogbc.49471$>

"Neo" <> wrote in message
> > > > ... one never sees data type, a base type, defined as a data type!
> > >
> > > It is difficult to see and implement this in RDM because
> > > it's lowest fundamental unit of abstraction (aka relation)
> > > doen't go low enough.
> >
> > Since relation headings are composed of attributes,
> > each of which has a type, it makes no sense to say that
> > "it's lowest fundamental unit of abstraction" is the relation.
> If we agree the "type" of int, char, str, etc is "thing", then we can
> start to model it as follows:
> T_Thing
> 1 int
> 2 char
> 3 str

So int/char/str are subtypes of Thing? Is that what the above shows? Or that you're modeling a Thing with 3 attributes, one of each type?

> But the attributes in T_Thing itself have a type (ie int, str), so how
> does one relate the row's ID to the T_Thing's attribute types?

I'm not sure I understand - the row is a predicate that relates things. At least one of those things (actually, a subset) is a candidate key, upon which all other things are functionally dependent.

> If one
> uses another table, then how does one relate that table's attribute
> types to rows in T_Thing. This problem is recursive and can't be
> represented properly within RDM. If you think otherwise, could you
> show a schema that would.

I'm not sure what the problem is yet.

> Also would you agree that RDM has a "fundamental unit of abstraction"?
> If so what would it be?

It has several: types (domains) and relations. Type is actually a generator - you can define whatever types you like. Types and relations are orthogonal.

There are other concepts here: relation variable versus relation value, and value vs. type, but those are basic. The above are the ones you want for relational.

  • Eric
Received on Fri Apr 02 2004 - 18:19:50 CEST

Original text of this message