Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Can relvars be dissymetrically decomposed? (vadim and x insight demanded on that subject)

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

From: Bob Badour <>
Date: Tue, 18 Jul 2006 00:20:19 GMT
Message-ID: <7PVug.11807$>

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)

> Ok, accepting the notation, we're fine so far.
>>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..

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

> Yes-ish; but what is R2 ? Is it a new relation value, or a relation
> variable ? I think you mean it's a new relation value, so your
> statement is correct; but ...
>>instead of
>>R1 UNION S = R1
>>else it would be in contradiction with S being NON NULL

> Well, it depends on what is meant by R1. Does R1 now mean a relvar or a
> relation value ?
> Aside : I should say before I start that Tutorial D (which is the main
> source, I suspect, for many of us of the term "relvar") is an
> imperative language, so in that context a relvar is just another,
> ordinary, 3GL, name-for-a-piece-of-memory variable. It isn't a
> mathematical, logical,
> referentially-transparent-placeholder-shorthand-for-an-expression
> variable.

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.


> 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 Mon Jul 17 2006 - 19:20:19 CDT

Original text of this message