Re: Can relvars be dissymetrically decomposed? (vadim and x insight demanded on that subject)
Date: 17 Jul 2006 16:14:42 -0700
Message-ID: <1153178082.532754.95950_at_i42g2000cwa.googlegroups.com>
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
> instead of
>
> 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 ...
> 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. 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 :
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
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.
X = X + 1
X := X + 1
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 :)
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
[ 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.
[ 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 ?)
> 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.)
> 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.
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 - 01:14:42 CEST