Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Can relvars be dissymetrically decomposed? (vadim and x insight demanded on that subject)
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 - 09:46:16 CDT