Why do implementation languages not allow this? Surely not for logical
reasons? We can delete from projection because NOT Pa implies NOT Pab,
eg., <NOT> R{a} -> <NOT> R{a,b}. Logically, we can insert to
projections because Pab implies Pa. Isn't the problem really a language
deficiency?

On Sep 4, 9:58*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Proposition: the following view updates are ambiguous:
1. Insert/delete from projection
2. Insert/delete from join (including selection)
3. Insert/delete from union
4. Insert/delete from minus

The only RA operation, that seems to allow view updates is renaming.
However, consider

rename( R(x,y), x->y )

Is renaming into the existing attributes allowed (then renaming is
projection, which is not updatable)?

I suggest that the idea that we focus on basic relational algebra
operators, figure out which updates of these are legitimate, then
leverage this knowledge for complex view updates is fundamentally
wrong. Consider a "pivot" view:

table Contacts (
name String,
email String,
phone String
)

and the view

select name, email as contact, 'email' as type
union
select name, phone as contact, 'phone' as type

This is a perfectly updatable view, yet your approach would fail to
discover how to translate its update to the base table. (This pivot
operation is a recurrent theme in data exchanges)

Then, there are constraints, "simultaneous" updates of multiple views.
There is simply no way a naive analysis (of how RA operations may
behave under view update) could possibly provide any insight to the
problem.

Tegiri Nenashi wrote:
....
Since when does RA have views?

....
Since when does RA have updates?

On Sep 4, 10:52*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
View is a named RA expression.

I understood this thread was about view updates. Projection view to be
exact.

Tegiri Nenashi wrote:
In other words, view is a language device. RA has no ambiguity, so if
your chosen dbms language allows ambiguous results, it is due to your
choice of language, just as Russell's paradox was due to the language he
chose.

A base is a named RA expression, so what is the logical difference?

On Sep 4, 12:12*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Yes, guilty with sloppy language. The other thread has already
established the term "underconstrained" rather than "ambiguous". So my
thesis is that all simple relational expressions are underconstrained
from view update perspective.

Let's get back to the main point. I'm suggesting that analysis of
simple relational expressions update won't be useful. Suppose a view
is composition of join, selection, and projection. Each of these can
violate some restrictions that you would propose based on analysis of
basic relation updates. Yet, the view can still be updatable.

Tegiri Nenashi wrote:
....
That's more like it. Now it's a matter of either using the recording
form available or if that is thought deficient, coming up with a
different recording form. Even if for some arbitrary reason one doesn't
want to update views, it remains instructive to construct an equivalent
set of bases and ask what results those would produce. Then ask why the
view should be any different. From an RA perspective a view
"expression" is no different than a base constraint, such as a key
constraint or any other one could dream up. In fact, a base "update" to
a constrained table arbitrarily (and conventionally) "chooses" to
replace only the value of one of the several relations involved. If a
language is based on a convention that says only named expresssions can
have their values replaced, I wouldn't argue with that. Maybe part of
the problem is that many people think an implementation language
implements relational algebra, when all it needs to do is not violate
RA, eg., by introducing ambiguity.

paul c wrote:
....
I meant "can always have their values replaced".

Tegiri Nenashi wrote:
Yes, there is no point in trying to be so precise that the people in the
audience here who actually have some influence over the evolution of
dbms's, at least in the way they choose to use dbms's, have no idea what
the topic really is. I think "update" is a language notion, not an
algebra notion, but a lot of people seem to assume it's the latter. If
insert to projection means asserting an implication, all you need is a
language that allows you to assert an implication so I say why not play
the ball where it lies?

(For somebody like me who started programming with some pretty arcane
physical file systems, the word "update" itself is a big problem, being
either too casual for any meaningful insight ora misleading sop to 1959
file system lingo which can be dangerous because of what the word meant
then, such as the inability to "update" a physical key with those file
systems, some people still think keys have something to do with updating
when a language that follows RA is involved. Other people think
relational languages actually implement relational algebra.)

paul c wrote:
..... If
Should have said "assert the value of an implication".