Re: Little question for RDM theoristes

From: Cimode <cimode_at_hotmail.com>
Date: 17 Jun 2006 00:09:48 -0700
Message-ID: <1150528188.755083.158300_at_c74g2000cwc.googlegroups.com>


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.
What DBMS? A SQL-DBMS? An RM DBMS?..
Discussing RM issues and definition through understanding of bound to SQL is pure waste of time...Brings confusion more than anything...

> > 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.
So you made a fundamental confusion which makes your following reasonning pure BS...If you pretend conveying some understanding of RM you must commit to precise terminology...

And you got the nerve calling me an idiot!!

> 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?
Again, OP is not a model, it os a set of programming reccuring mechanism for regulating in memory representations...Do not try to build reasonning based on such unstable basis...It can lead only to one thing: confusion

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

So basically you say:
a relation = set of named attribute?
types = heading? Good you just redefined RM!!!!

You are confusing an relvar projection and what a relvar is. You are trying to *force* the characteristics of a projection over the relvar. relvar type has nothing to do with headers which are human interpretation established on a specific projection of a relvar...In fact, only the body (set of tuples) constitute that projection...

A relvar type is the unique combination of:

+ A name
+ set of operators regulating operations that can be carried over relation values
+ domain constraints rules which define that to which arbitrary ensemble of values the relation values can possibly belong.

> >>>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.
So the reasonning is "because people think that way it MUST be true" ..RM is pure mathematics applied to computer science....If people start assuming 1=2 that does not make it true....

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

OF course it was not...This question was BIASED!!! It is a false question based on a false definition of the premise that a relation = relation value!
Trying to answer it just brings more confusion.

> > 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?
It is not a matter of *limiting*...

it's a matter that you wrote a totally false statement stating that 2 scalar types MUST be of same type to allow arithmetic operations between them adn I prove you wrong with sound reasonning...You are just to proud or to idotic to recognize it...

> I really don't want to get into sub types and super types and whether
> operations defined on rationals work on integers.
subtypes and supertype have NOTHING to do with the basic definition of a relation type...

And I didn't want
> to use words like "promotion" or "implicit conversions" because they
> would either add confusion or require elucidation.
Here another proof of your confusion...."implicit conversion" they are totally related to the implementation layer of SQL and are NOTHING in RM...

Would it suffice
> to say that, if one wanted to do arithmetic on two values, they must
> be of numeric type?
WRONG why do you want to limit arithmetics only to numeric values...How about vectorial arrays, complex numbers (they are not numeric values in the traditional sense)...That's why operators are of arbitrary complexity...

> > 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.
It's not that you did not *clarify things*... It's just that you state false assumptions and keep redefining (or try at least) RM according to SQL implementation...RM VS SQL, relvar VS projection of relvar, abstract VS implementation... You have no clue about what RM is...You'd better forget about SQL and do some more intensive reading if you want to truly understand RM. Fabian PASCAL would be a much better reading for you...It's been years he has dumped SQL...

> >>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 - 09:09:48 CEST

Original text of this message