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.
Yes I know. I diverted from the initial subject to help adjust communication with erk. I wish to get back to the initial topic I should have called "Are relations of dissymetrical nature". relvar was not what I had in mind. I am dealing with issue of relations as mathematical construct. For analyzing them, I wish them separated by definition from the concept of relvar and relvalue.

> 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 ...
R2 is a new relation, meaning a new mathematical construct product of having some inserting new relvalues to the domain DoR1 that is defined by R1. In that domain, ALL relvalues (tuples) that the relation may have are elements of the domain DoR1.

> > 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 ?
This is a tricky question.
In an abstract sense, the concept of relation R1 can not equate to neither relvalues or relvar. A relation may however be *evaluated* in time to a specific relvalue. A more accurate perspective would be to consider that a relation value as a single possible occurence of a specific relation R1. For instance if ones assumes that relation R1 has a single tuple then single tuple R1(1) is a relvalue of the relation R1. By analogy,consider a function F(x) = 2*x + 2

Such function F may have a value 6 in time when x = 2 but that does not mean the function = 6 (relvalue) or the function = x (relvar) because F(x) = 6 is not function F and F(x) = x is not function F either: F(x) is still defined as (2*x + 2)

> 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. With that said, here comes a rant/ramble :
Maybe the term *relvar* is just a name for variable and such concept exists since mathematical relations have been identified. I rather use the mathematical definition of it than a possible implementation of it.

> 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 ? It takes two numbers, surely.
> Have we suddenly invented a new '+' ? Of course we haven't; what has
> happened is we've elided out a dereference on X. What this really means
> is
>
> X := the_current_value_of(X) + 1
>
> with the obvious read alound meaning of "take the current value of X,
> add one to it, throw the old value away and assign the new value to X,
> assuming that the new value is acceptable according to the constraints
> currently on X (for example, the assignment fails if X is a subrange
> type [1..10] and X was already 10, or X is defined to accept only odd
> or only even numbers)".
>
> Now that we've sussed what a fairly obvious imperative statement
> actually means, it should be obvious that if
>
> INSERT X RELATION { TUPLE { A1 INTEGER(1) , A2
> INTEGER(2) } }
>
> is a synonym for
>
> X := X UNION RELATION { TUPLE { A1 INTEGER(1), A2
> INTEGER(2) } }
>
> it should also be obvious that what we mean is, "take the relation
> value currently indicated by X, union it with the relation value given
> to produce a new relation value, throw away the old relation value X
> used to indicate and assign the new relation value to X, so long as
> that new relation value is acceptable according to the current
> constraints applicable to X."
>
> Unless of course, the designers of Tutorial D fell out of a tree,
> landed on their collective head and chose to make assignments on
> relation variables work completely differently to assignments on any
> other kind of variable in the language. But somehow I doubt that :)
Thank you for this remarks. But I suggest not relying on implementation layer for abstract thinking. Tutorial D or other implementations has pre established semantics and I do not feel confortable using it as proof for mathematical and deductive reasonning.

> Now, having come a very long way for a short cut, hopefully this makes
> clear that
>
> R1 UNION S = R1
>
> makes sense if R1 is a relation *variable*, but it is the nonsense you
> suspect if R1 is a relation *value*.
R1 can neither be equated to relvar nor to relvalue. See analogy about function F(x)

> [ snippage ]
>
> > I see your point but I am not worried about typing. Let's assume that
> > all candidate tuples for INSERT/DELETE are valid.
> >
>
> That would be a pretty big assumption to take; the fundamental
> constraints on a relation variable are the names and attributes of the
> relation values the relation variable can indicate.
In abstract reasonning, one has to make assumptions over constraints to be able to reason because trying to study all parameters of a hypothesis leads to confusion.

> [ snippage ]
>
> > Let's forget relvar and relvalue for the moment and focus on the
> > relation (I should have called this thread accordingly). The question
> > is that if one considers that the INSERT of a new tuple is the
> > possibility for the relvar to hold a new value does it hold it for
> > relation R1 or does it hold for a new relation R2. The answer seems
> > clear to me.
> >
>
> If this means what I think it means, then there is a new relation
> value, R2. (Date usually uses "relation" as a shorthand for "relation
> value"; is that also what you mean ? I'm a little concerned by the
> opening "let's forget relvar and relvalue for the moment and focus on
> the relation" that you might be using "relation" differently. Is that
> so ?)
I do not feel confortable with a lot of Date's *shorthands* in defining terminology for SQL audiences. I consider them as an effort for vulgarization of RM concepts that sometime leads to add more confusion than anything else. R2 is a new relation that is the product of adding through INSERT the relvalue S to relation R1.

> > At abstract level of reasoning, I am not convinced that relations can
> > *only* be characterized by their values or operations. I do not feel
> > confortable with *create new* concept because it is not really and idea
> > of creating a new instance but a whole new relation.
> >
>
> How else would you characterise relations ? What do you think or
> suspect is missing ? (This is probably the most important question in
> the exchanges so far, I think.)
You are right this is the question on which I have been chewing on the last few years with some interesting observations. What I believe current relation definition are missing are definitions, operators and tools that can specify their nature and interaction at relation level.   To clarify the problem at hand I will use an example.

For the rest of the example, let's suppose all attribute data types are integers.

For instance, assume relation R1{A1, A2} with 2 tuples noted R1(1) and R1(2) and
relation R2{2, 3} containing single tuple R2(1).

As a consequence of the above assumptions R1(1) = {3, 4}
R1(2) = {4, 2}
and
R2(1) = {2, 3}

If we INSERT relvalue R2(1) to R1 then the operation would produce R3 being a new relation that is neither R1 nor R2. The operation is usually expressed as UNION between R1 and R2 that produces a relation R3

R1 UNION R2 = R3 R3 single occurrences could be expressed as

R3(1) = {3, 4}
R3(2) = {4, 2}
R3(3) = {2, 3}

As you can notice above, R1, R2 and R3 are characterized as being a part of the operation R1 UNION R2 = R3. But what else could be said of R1(x), R2(x), R3(x)? How could these expressions of the relation can be specified independently from the operations they perform.

You can also notice that relations are also characterized by the relvalues that allowed to build up the UNION. But what about the structural aspect of relations. So the question is how do we define relations independently from the relvalues. For instance, the function F(x) = 2*x +2 expresses the function independently of some specific value because the variable x could represent any value to which function F can be evaluated. A similar effort of expression should be done for relations in the sense that expression should be done independently from operations performed and possible relvalues the relation may have.

Such area is indeed at the limit of current understanding of RM issues.  Which is why mathematical insight on the problem is necessary (which gets us back at the initial topic).

> > Suppose for instance R1 constitute a domain on which values can be
> > drawn. It necessarily has a limited number of values. Don't you think
> > adding a new value changes fundamentally the nature of the R1 defined
> > domain and therefore is possible if and only if a new domain and a new
> > relation R2 are created?
> >
>
> But R1 isn't a type - it *has* a type, but it isn't a type itself. The
> *type* of R1 would constitute a new domain, as that would describe
> which relation values could be considered to be of that type.
For the moment, forget typing and consider only domain definition. R1 relvalues are the element that define Domain DoR1. N relation data types could later *derived* from DoR1 by applying restrictions on DoR1 extraction. But typing is not at the moment the issue that is interesting.

> 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 !
I know this definition but I don't feel confortable with it as it contradicts initial Codd's postulate and defeats the purpose of application of mathematical relations to RM. What he calls *tuplevar* is nothing but relvar some relation R1. I suspect it is a word of caution because lots of work needs to be done for better specification of relations.

> 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)
Date's word of caution is significant that some aspects of relations should be specified. To my knowledge, Date's has not gone far enough for that but that does not make it outside of Codd's intent of what RM should be: a direct application of math. Question is: are mathematical relation a sufficient math tool to characterize sufficiently the nature of relations on a mathematical perspective. I personally believe not which is why ensemblist math seems to be helpful. Received on Tue Jul 18 2006 - 12:09:40 CEST