Re: Object Class and Data Type

"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0404012149.444809d1_at_posting.google.com...
> > > > ... 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