# Re: Little question for RDM theoristes

Date: 16 Jun 2006 13:29:59 -0700

Message-ID: <1150489799.541632.260080_at_f6g2000cwb.googlegroups.com>

I have heard lots of BS about RM but this one makes it all...

J M Davitt wrote:

*> U-gene wrote:
*

> > Two relations (relvalues) exists. These relations have different

*> > headers (schemas). Are these relvalues the values of different types?
**>
**> Precisely stated, a relation consists of a *heading* and a body.
*

> The mere fact that two relations have different names distinguishes

*> them.
*

WRONG...the name just *identifies* the relations for logical
handling... what *distinguish* and *define* them is a unique
combination of characteritics carrying onto

Whether two relations, differing only in name (i.e., having

> identical headings) should exist in a database is a question of

*> properly orthogonal design. But would two such relations be of the
**> same type? Yes, they are the same relation type.
*

Again the premice of equating relation to

> The *relvars* (relation values) of these constitute the bodies of the

*> relations.
*

relvars stands for relation variables...
Are so mentally impaired that you believe the /*var*/ part of relvar
was meant for value?

The level of confusion is total

a relation is not a relation variable

a relation is not a relation value

a relation variable is not a relation value

*>
*

> > IMHO all relvalues have the same type and the headers is just data. May

*> > be it is special kind of data which is different from rel.bodies' data.
**>
**> This is going to get confusing; type is an over-used term. On the
**> one hand, the RM stores and manipulates data stored as scalar types,
**> possibly held in tuple types, and possibly held in relation types.
*

WRONG..First, a model does not store...

Second, a relvar has arbitrary type not just scalar type at logical
level...only projections of relvar could eventually lead to such
conclusion...

So what you say is basically

RM = relvars = projection of relvar...

You are pretty much confusing everything....That's the effect of seeing
RM through SQL prism...

> These are the general types defined in the RM described by Date. The

*> question then becomes, "What type of data may be stored in a scalar
**> type?" (See how 'type' crept in there twice?) The answer would be,
**> "There are boolean scalar types and user-defined scalar types. The
**> user-defined types of scalar types probably include integers,
**> rationals, and characters."
*

> > . But persons exist who think in other way - if relvalues have

*> > different headers they are values of different types. So I'll glag to
**> > hear your opinions.
**>
**> Yes - and no. All relations are of the same type simply because they
**> are all of relation type: they all have a heading and a body. Whether
**> two relations - or relation expressions - are union-compatible depends
**> on whether or not they have the same heading. In other words, if they
**> have the same heading, the types of relation type are the same.
*

Do you think RM and predicate theory is based on such ambiguous answers
such as YES and NO to a specific question about relvar...

Already stated this question is totally biased because it wrongfully assumes relation = relation value..The rest is just crap...

> This isn't really much of a stretch: For example, two scalar type

*> variables must be of the same type if we wish to do arithmetic with
**> them. Limiting ourselves to integers for this discussion, both scalar
**> variable types must hold data of integer types.
*

What a stupid idiotic statement!!!

So basically what you say is that it is not possible to add a value
drawn from a sub domain1 of integers defining type1 to some other value
drawn from sub domain2 of integers defining type2....? Or do you
consider type1 = type2 no matter what?

Here is the proof that you have no clue about RM and mathematical
domain concepts....They are essential to understand RM...

And you got the nerve to pretend to be trivial!! (*not much of a stretch* part) ...Of course stating BS is always trivial...

> I realize this doesn't completely clarify things but type, on the

*> one hand, describes the form in which data are held and, on the
**> other, describes the values of the data.
**>
**> Other languages have similar difficulties: the choice of the words
**> 'type' and 'class' in C, for example, seems arbitrary. So too the use
**> of words like 'declare' and 'define:' in C and assembler, they seem to
**> have each other's meanings. And in the world of algorithms, the giants
**> Knuth and Sedgewick use 'pre-order' and 'post-order' to describe the
**> opposite of what the other means.
*