Re: Can relvars be dissymetrically decomposed? (vadim and x insight demanded on that subject)

Tony D wrote:

> OK, I'm going to chime in a bit here, because I think we've strayed
> from the initial question of non-symmetrical decomposition onto a
> question on the nature of variables.
>
> Let's go :
>
> Cimode wrote :
>
>

>>I see your point.  Lets try to formulate this differently...
>>Suppose a relation R1 on which a single tuple is added.  Let's consider
>>there 10 tuples identified as R1(1), R1(2)...R1(10) ..R1 would then be
>>expressed as
>>
>>R1 = R1(1)  UNION R1(2) UNION R1(2).......UNION R1(10)
>>

>>Now let's consider a *candidate* tuple (candidate as valid for
>>insertion in terms of uniqueness, constraints respect, and NON NULL)
>>added called S (for the moment let's not assume it is already a value
>>of R1).  The point that seems quite clear to me is that the result of
>>the INSERT produces a new relation..

>>Look below
>>
>>The insert would be expressed as
>>R1(1)  UNION R1(2) UNION R1(2).......UNION R1(10) UNION S
>>S being NON NULL
>>it would be equivalent to
>>R1 UNION S = R2

>>instead of
>>R1 UNION S = R1
>>else it would be in contradiction with S being NON NULL
>>

Your last statement above overlooks logical independence. A relvar is not a piece of memory, and it can be a mathematical, logical, referentially-transparent-placeholder-shorthand-for-an-expression variable. What, after all, is a view if not a relvar and not a mathematical, logical,
referentially-transparent-placeholder-shorthand-for-an-expression variable?

  With that said, here comes a rant/ramble :
>
> One of the many things to hate about imperative, stateful languages is
> the constant and gleeful elision of dereferencing. Let's look at a
> simple example before moving on to relations and relvars per se.
> Consider the following fragment, quite acceptable to a C or FORTRAN
> compiler :
>
> X = X + 1
>
> This is, on the face of it, utter madness. X is X; how can it possibly
> be "X + 1" ? Let's take out one source of complaint; the '=' operator.
> Quite obviously, we are not asserting an equality, so let's use a
> different operator - Pascal's ':=', say. So we get
>
> X := X + 1
>
> to be read aloud as "x becomes x plus 1". But this also has a problem;
> since when was '+' defined on variables ?

Since algebra.

[snip]

> Endnote: completely (well, almost completely) by chance, my copy of
> Date's Introduction (7th ed.) is open at page 133, which ends with :
>
> "... we should now add that to talk, as we have just been doing, of
> "updating a tuple" (or set of tuples) is really rather sloppy. Tuples,
> like relations, are values and cannot be updated (by definition, the
> one thing you cannot do to any value is change it). In order to be able
> to "update tuples", we would need some notion of a tuple variable or
> "tuplevar" - a notion that is not part of the relational model at all !
> Thus, what we really mean when we talk of "updating tuple t to t'," for
> example, is that we are replacing the tuple t (the tuple value t, that
> is) by another tuple t' (which is, again, a tuple value). Analogous
> remarks apply to phrases such as "updating attribute A" (in some
> tuple). In this book, we will continue to talk in terms of "updating
> tuples" or "updating attributes of tuples" - the practice is convenient
> - ***but it must be understood that such usage is only shorthand, and
> rather sloppy shorthand at that.***" (add'l emphasis mine)
>
Received on Tue Jul 18 2006 - 02:20:19 CEST