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

Date: 17 Jul 2006 07:46:16 -0700

Message-ID: <1153147576.247669.30780_at_i42g2000cwa.googlegroups.com>

erk wrote:

*> Cimode wrote:
**> > [snipped]
**> > I suspect a harmless communication problem here. Relations are N
*

> > dimensional, there is no doubt about that. I refered to projections of

*> > relations in a specific point in time.
**>
**> I think there are established terms for what you mean; in Date's
**> writings he frequently distinguishes between relvars and relvals
**> (although he uses the latter less frequently). The term "projection" is
**> a different concept, and time has nothing to do with it.
*

I see your point. I use the term *projection* in as *encoding* or
*representation* as an RTable. I consider this representation as
varying over time and operations made on and with the relation.

> A relvar can have different values at different points in time - like

*> any variable. The values are relvals (of course).
*

What you said is logically correct but I would not say it that way. A
relvar holds different values over time because the relations expressed
by relvars have a *behavior* that changes over time (Caution: behavior
has nothing to do with OO fuzzy concepts, it is meant in a mathematical
function describing sense). For instance, some relvar may be used to
express several relations the same way the variable *x* may express
several functions. And of course, x may *hold* different values
(relvalues in RM) over time.

> Every

*> UPDATE/INSERT/DELETE is, I believe, syntactic sugar for an assignment
**> like R = R op X op Y op ..., where R is being assigned the result of
**> applying operations to itself, with other relVALs as parameters (e.g.
**> an insert is a union of R with a single-tuple relval).
*

I see you point and I thank you for this example which will help
clarify the issue. It is correct to assume that an INSERT (operation)
is the union of a relation R1 and single-tuple relval BUT that says
something only about the INSERT operation not about the R1. The
question I am trying to raise is HOW does the insert operation impact
R1. For instance, if you consider the function F(X) = A(X) and you add
the value B to F(X), you are basically doing a translation making a new
function T(X) = F(X) + B = A(X) + B In this case, the result of adding
B to the function can be expressed (characterized) as a mathematical
translation (jumping from F(X) to T(X)). It says a lot about the
function F(X) behavior and may help describe it better over time. The
challenge of this thread is to do a similar effort on relations. For
instance, an interesting question raised would be: is an INSERT
operation equivalent to a translation in relational perspective?
Overall, how does a relation R1 *changes* when an INSERT, UPDATE,
DELETE operation is made on it? Characterizing such change would help
describe better relations themselves.

> Sorry if I'm repeating the obvious; I think the terminology is getting

*> in the way. And I'm still not sure what your goal is in
**> "characterizing" relvars, as distinct from relvals.
*

Basically, to work at relation abstract mathematical level as opposed
to operational level in RM.

For instance, if one considers the function F(x) = A(x) + B.... such function is expressed as an equality using 1 relvar (in this case *x*), 2 operators (in this case *X* and *+*) and 2 values (a and b). Bycharacterizing relation R1, I mean how would it be possible to express in a similar fashion some relation R1 (NOT a the relvar but the relation itself) using as relvalues domains and some operator.

> A relvar is simply

*> a variable that can "hold" values of the same type. Several relvars can
**> be created with identical definitions (obviously their predicates
**> (real-world semantics) are different, but in all other ways they can be
**> identical), so relvars do have types, and a relvar with constraints has
**> at least 2 types: one including the constraints, and the supertype
**> without the constraints.
*

No agument here. A matter of perspective (a different angle on the
same problem). See above.

*> - Eric
*

Received on Mon Jul 17 2006 - 16:46:16 CEST