Re: Little question for RDM theoristes

From: Cimode <cimode_at_hotmail.com>
Date: 17 Jun 2006 04:35:56 -0700
Message-ID: <1150544156.292943.81160_at_p79g2000cwp.googlegroups.com>


Still waiting for a response...

J M Davitt wrote:
> 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.
>
> Too, it may be that the OP was using language with which I'm unfamiliar;
> I've never seen the word /schema/ used in Date's writings, but I have
> seen it in others. Is it the case that the OP meant the "types of
> types" when he asked about "the values of different types" being
> "relvalues?" I didn't think so. But, who knows?
>
> > 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 - 13:35:56 CEST

Original text of this message