On Aug 28, 7:42*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Your mention of 6NF got me thinking. The examples I've seen of
problems with updateable views tend to involve union (particularly of
similar but distinct relations), join and projection. Is view
updating still a problem in a database where POFN and POOD apply to
base relvars, and every view restricted to 6NF?

Nilone wrote:
....
I don't know. I think Pascal and McGoveran are able to think much
deeper than I can. Suspect I'll need to make a lot more mistakes before
I see their point. One thing that troubles me is that they seem to
assume a kind of discipline that is separate and external to relational
algebra, but I don't know how to say why it bothers me.

On Thu, 03 Sep 2009 01:12:02 +1000, Marshall <marshall.spight (AT) gmail (DOT) com>
wrote:

I agree. Although when I have a bit of time on my hands I would like to
see how far the analogy can be pushed.

Cheers,
Joe

On Thu, 03 Sep 2009 04:23:48 +1000, paul c <toledobythesea (AT) oohay (DOT) ac> wrote:

I'm afraid I don't understand what you mean.

Cheers,
Joe

On Thu, 03 Sep 2009 04:26:46 +1000, Walter Mitty <wamitty (AT) verizon (DOT) net>
wrote:

Yep, that's what I was trying to say - thanks for putting it more clearly.

I had intended it only as an analogy.

There may be a formal relationship, of course, but I won't pretend that I
have figured one out.

Cheers,
Joe

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


<quote>
I guess I see what you mean, but strictly speaking it doesn't seem
to fit the definition. In abductive reasoning, one knows a -> b, and
b, but one doesn't know that it was in fact a that implied b. Whereas
with a view, we do know.
</quote>

Do we?

For an insert into a union view, one knows a -> c \/ b -> c and c, but one
doesn't know whether it was in fact a or b or both that implied c.

For a delete from a join view, one knows ~a -> ~c \/ ~b -> ~c and ~c, but
one doesn't know whether it was in fact ~a or ~b or both that implied ~c.

On Sep 2, 9:50*pm, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:
The mixing of propositional vs. predicate logic terminology, along
with the
use of terms that were not intended to describe imperative operations,
is too unclear for me to disentangle. If you want to use these terms
these ways, I can't stop you, but I don't agree that it's good usage
of the terms. But ultimately, what terms we use is of little
importance;
it's the semantics that is important. If you wanted to respond to some
of my semantic points, that might be interesting.


Marshall

Joe Thurbon wrote:
In C = A JOIN B, there may be 'spurious' tuples in A or B that aren't
implied by tuples in C. Many people talk about delete from join as if
those tuples must somehow be involved but by definition, the join view C
= A JOIN B does not necessarily consist of tuples that are implied by
the logical expression:
(A AND B) OR (A AND NOT (A AND B)) OR (B AND NOT (A AND B)).

(This could be put loosely as (A JOIN B) UNION (A MINUS C) UNION (B
MINUS C).)

I think it is actually one of these expressions that people are talking
about when they say delete from join isn't possible. But they don't
actually say so, Instead they pretend what they are dealing with is A
AND B . To be fair, some people do talk about 'delete through join',
but I think that's misleading and not the same as 'delete from join'! I
believe the correct expression for 'delete from join' is merely A AND B.
The spurious tuples never appear in the extension of A AND B, so they
could hardly be deleted. Nor could one insert such spurious tuples to a
join because then they wouldn't be spurious.

What about preserving spurious tuples? If a language requires relvars,
I believe the correct way to approach delete from join would be to
define five relvars instead of the three mentioned, as well as various
constraints so that the starting position for 'delete d from c' is
actually a join and not the unions or disjunctions above. The relvars
involved in the join will point to subsets of A and B that are disjoint
from the spurious tuples. Two other relvars would contain the spurious
tuples, each disjoint from A and B When all the relvar constraints are
made mutual, I think it will be seen that the complement of A AND B that
is so constrained is in fact NOT A AND NOT B. I believe this is what
McGoveran called 'relative complement'.

I think projections of the union of those five relvars are the logical
values of the resulting A and B relvars and no 'guessing' will be involved.

Of course one can take the starting position that one doesn't want to
update views, which to me has as much justification as sayhing that
views can't be stored, ie., none as far as I'm concerned. I would
rather have same behaviour for all relvars, not two. But if people
insist, I wish they would start with an accurate definition, not the
misleading one.