# Re: Little question for RDM theoristes

Date: Fri, 16 Jun 2006 22:15:29 GMT

Message-ID: <54Gkg.60260$mh.7799_at_tornado.ohiordc.rr.com>

Cimode wrote:

> 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*

"Identifies" is probably a better word than "distinguishes," but the difference is more a design issue than I thought the OP was digging into. As far as a DBMS is concerned, there is no difference.

> 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?*

Yes, there is a mistake here. /relvar/ absolutely means /relation variable/. I was trying to make sense of the /relvalues/ term the OP used, because, as I read the post, it seemed he was speaking more of relation variables than relation values - or relations.

*> 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

Okay, there's a whole world of things a relation is not. But I'd tend to say a relation *is* a set of named attributes defined over a domain of types (heading) and a set of tuples with the same heading (body). And that's 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...

You're right; a RDMBS does.

> 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...
*

I don't think so...

> 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."

*>*

> Again Date has a tradition of vulgarizing and using ambivalent

*> terminology to help educate SQL audiences...FP has told him about that*

*> several hundred times but DATE is a gentleman trying to teach pigs how*

*> to dance...*

*>*

>>>. 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...

It wasn't a straightforward question.

> 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...*

So the "limiting ourselves ... for this discussion" part wasn't included in the version of this that you read, right?

I really don't want to get into sub types and super types and whether operations defined on rationals work on integers. And I didn't want to use words like "promotion" or "implicit conversions" because they would either add confusion or require elucidation. Would it suffice to say that, if one wanted to do arithmetic on two values, they must be of numeric type?

> 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.

*>*

*>*

> B4 jumping to other languages you better review your understanding of

*> RM domain concepts...*

*>*

Received on Sat Jun 17 2006 - 00:15:29 CEST