Re: views of binary operations

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1153017368.456165.270950_at_m73g2000cwd.googlegroups.com...
> Consider named views of binary operations on relations.
>
> Given a relational operator "op" and relation variables A and B,
> and a declaration of:
>
> r = A op B
>
> the language evaluates the expression "A op B" and assigns the
> result to r.
>
> However, if we declare this as a view, we do not evaluate A op B
> at the time of the declaration, but instead (re)evaluate A op B each
> time we make reference to r in later expressions.
>
> r = view(A op B)
>
> Is it the case that we want exactly the above, or might we
> want a more fine-grained control? Might we ever want
>
> r = A op view(B)
>
> In other words, the value of A at the time of the declaration and
> value of B at the time of evaluations of r? In which case, we
> then have four possibilities:
>
> r = A op B
> r = view(A) op B
> r = A op view(B)
> r = view(A) op view(B)
>
> (Actual evaluation of the expression is deferred if either of
> the operands is a view.)
>
>
> In other words, when we have a view of a binary relation operation,
> are we necessarily creating a view of the entire expression, or are
> we making views of the operands?
>
> (I am asking in the theoretical sense, and not about SQL per se,
> although if current practice in SQL sheds light on the question,
> I am interested in that as well.)
>
>
> Marshall
>

Other posters have commented on views vs snapshots, and covered most of the ground here better than I'm going to.

My comments about wildcard expansion are an interesting subthread, but a distraction from the main thread.

The word "view" predates the widespread acceptance of SQL. I surmise that it predates SQL itself.

In SQL, consider this:

CREATE VIEW A AS SELECT .....; CREATE VIEW B AS SELECT .....; CREATE VIEW R AS
SELECT .... FROM A,B WHERE...; DROP VIEW B;
CREATE VIEW B AS SELECT .....; The fact that A and B are views is NOT part of the definition of view R. FRom the point of view of the R definition, both A and B are named objects of the generic type (table or view).

I'm not familiar with the usage of the word "snapshot" in the literature, other than in product specific contexts.

Oracle literature uses the term snapshot for what might be called a "materialized view". Some lurkers are bound to point out that this is an oxymoron. I hope you know what I mean anyway.

DEC Rdb literature used the term "snapshot transaction" and the related term "snapshot file" to mean something very different. A snapshot transaction presents the user with a virtual snapshot of the entire databases, without locking any values against other transactions. It maintains consistency for the snapshotter by storing obsolete versions of rows in snapshot files, and keeping them around until no further shapshotters could be interested in them.

In this sense, a DEC Rdb snapshot is a "consistent view of the database, at a certain point in time".

The question you raise, about whether A and view(A) evaluate at different times, is an issue that has surfaced over and over again, in different programming languages.

Consider the simple FORTRAN statement:

X = X +1

It turn out that the two instances of "X" in the above don't evaluate the same way. The first one evaluates to the address of X, while the second one evaluates to the current value of X.

The instruction that retrieves the value of X is generated at compile time, but executed at run time. One could say the same about the instruction that stores the new value of X. But the consequences are different.

In Lisp, a reference to a named variable evaluates to its assigned value. In MDL we decided to have a named variable evaluate to its name, in most contexts, and to use the syntax ".A" for the current value of A.

I recognize that the above is somewhat confused, but I hope its useful anyway.

The important thing is that "lazy evaluation" can take place at different times for:

name to named thing evaluation,

relvar to relation evaluation,

and wildcard expansion.

Choices made by the DBMS builders in this regard can have subtle but important consequnces for the poor dumb designer, like me, who comes along knowing a little theory, but not a lot of theory. It affects when binding happens, and this affect logical data independence.

The above may need to be rewritten completely, but I hope you get the gist. Received on Thu Jul 20 2006 - 12:20:23 CEST