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

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. 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 ? 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 :)

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

[ 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)

.

Relevant Pages

  • Re: Can relvars be dissymetrically decomposed? (vadim and x insight demanded on that subject)
    ... Ok, accepting the notation, we're fine so far. ... R1 UNION S = R2 ... Does R1 now mean a relvar or a ... "updating a tuple" is really rather sloppy. ...
    (comp.databases.theory)
  • temporal data constraint
    ... RELVAR R_DURING KEY {A, ... That seems like a great solution, but the problem is constraints. ... non-overlapping interval ending at the "since" timestamp ... but I don't know what the maximum interval ending time ...
    (comp.databases.theory)
  • temporal data constraints
    ... RELVAR R_DURING KEY {A, ... That seems like a great solution, but the problem is constraints. ... non-overlapping interval ending at the "since" timestamp ... but I don't know what the maximum interval ending time ...
    (comp.databases.theory)
  • Re: Can relvars be dissymetrically decomposed? (vadim and x insight demanded on that subject)
    ... all occurrences of relvar R1 populate a domain of ... domain of value it would constitute, and the ensemble consituted by the ... I would tend towards the constraints applying to the ... of relvar definition due to restriction of drawing value by data type ...
    (comp.databases.theory)
  • Re: Foreign superkey support
    ... so are relation constraints (i.e. they are ... expressions over only the attributes of a single relvar). ... But a cardinality 1 constraint definitely defines a relation subtype, ... But really, all constraints are all database constraints, ...
    (comp.databases.theory)