Suppose we have views u, w defined as relational expressions over base
tables x, y, z:

u = f(x,y,z)
w = g(x,y,z)

Let's assume this system of equations is invertible, that is we can
solve it and express x, y, z as functions of u, w:

x = r(u,v)
y = s(u,v)
z = t(u,v)

Then, the system of views u,w is updatable. Given the new database
state reflected in the relations u, w, we can calculate base relations
by leveraging above expressions. One can object that it wouldn't be a
practical solution; on the plus side, however, increments and
decrements never enter the picture!

Tegiri Nenashi wrote:

I think as soon as one starts using functions to describe relations it's
easy to loose track of important details. In the above u=f(x,y,z) could
result in a an rva, If I understand what you're saying, to invert it,
you'd have to back and make x an rva too but once you do that u becomes
a kind of nested rva and you'll recurse forever!

Also, if one accepts that relational assignment is really what 'update'
means, increments and decrements don't enter the picture in the first
place. .

On Sep 6, 12:29*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I fail to see the nesting. Let assume u is a join of x, y, z:

u = x ^ y ^ z

while u is a union

w = x v y v z

To invert it we we to express x in terms of some relational operations
over u and w. This is possible only if the system is not under- (or
over-) constrained, and as we already established it is (even in the
simpler case involving 2 relvars: x and y).

There is no assignment -- the equality sign means identity relation.

On Sep 6, 12:06*pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
It seems to me that whether a particular update will succeed on a
particular
view depends not only on the view but on the specifics of the update
operation as well. That is, whether an update will succeed or not
is a dynamic, or runtime issue, and not a static, compile-time issue.


Marshall

"Marshall" <marshall.spight (AT) gmail (DOT) com> wrote

On Sep 6, 12:06 pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
PMFJI. I'm trying to combine this latest response with what Brian said in
his latest response (about permitting NULLs in some attributes and
providing default values in others.) Let me duck the issue of NULLS at
least for the moment. Let's say that all attributes the base relvars and
not in the projection have a default value. This makes the projection view
"invertable" even though without the default value it would not be
invertable.


So now my question is, can business rules such as default values (in the
case of insert into projection) or triggers that implement a delete from
join predictably and uniquely be expressed as "equations"? Is it possible
that a system of equations that describe views in terms of base relvars and
also describe business rules, including constraints, might always be
"invertable". Well, it's more complicated than what I ve expressed, but I
don't want to get all tied up in knots. The point is to ask whether there's
always a way to make a non invertable system invertable by adding more
rules.

On Sep 8, 9:35 am, "Walter Mitty" <wami... (AT) verizon (DOT) net> wrote:
And what is default value in relational terms? Suppose we have
relation x over attributes p and q, and the q attribute is "default".
Then, we essentially have a union of two(!) base relations:

1. A restriction of the original binary relation x, where no tuple
contains default value
with
2. y ^ [q] default, where y is some unary relation with attribute p.

In other words we have a view

x v (y ^ [q] default)

Then, I'm not quite convinced that the view

(x v (y ^ [q] default)) v [p]

is updatable. The "default" is just some value, which constraints
would specifially instruct the relational system that it behaves like
default?

Walter Mitty wrote:
....
Well I think if one wants to avoid nulls (good!), using default values
might need so much catering in apps that what Vadim says would make much
more sense, if I understand him, define base projections.

I'm not against that because it is so apt, ie., if there is a need to
insert to projections, then there is a need for base projections.

For me, the big updating problems are join delete and union insert, the
only reason I brought up projection insert was that I'm curious about
other forms besides conventional tables and relvars. Also, if the world
ever sees join delete and union insert straight, which I don't think it
does now, there might be interesting implications (I mean interesting in
the sense of applications profiting).

"Vadim Tropashko" <vadimtro (AT) gmail (DOT) com> wrote

I think that depends on how a default constraint is expressed logically.

For a table (x,y,z) that neither allows nulls nor has default constraints,
the predicate could be Pxyz. If the table were to have a default constraint
for y, what would the logical expression for the table become? Isn't it

(Pxyz xor Pxdz) or (Pxyz and (y = d))?

If it is, then I think a view over (x,z) should be updatable.

<snip>

Mr. Scott wrote:
My attitude is that if it can't be expressed in an algebra it shouldn't
be implemented. Not saying there isn't a way, but I don't know how to
express defaults as a constraint nor algebraically. Seems to me a union
is always involved, perhaps an exclusive one as you suggest, but the
main thing is that I don't know how to do it without declaring a base
relvar with attributes x and z, (so it wouldn't be a view). I'd be
happy to be corrected!

On Sep 10, 4:31*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I am quite sympathetic to the impulse but I think that's too strict.
If we'd been following that stricture up to now, we wouldn't have
been able to use any relational systems at all! Up until Vadim's,
no relational "algebra" has actually been an algebra, strictly
speaking.

And there are other ways to approach semantics besides
algebraic. There exists axiomatic semantics, operational,
denotational, etc. In fact, algebraic semantics, my personal
favorite, does not seem to be very widely used.


Marshall