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

From: Cimode <cimode_at_hotmail.com>
Date: 17 Jul 2006 07:46:16 -0700

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).  By
```
characterizing 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

Original text of this message