Re: more on delete from join

On Aug 28, 7:42 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>
> It might be interesting for defining an environment that allows the
> language features mentioned to reference an algebra or calculus (which
> don't have a notion of update in the first place), but I don't see why
> normalization needs to be introduced to implement updating of bases nor
> of views.  If it does need to be, then presumably the updating of any
> relation somehow depends on how 'normal' it is.  I don't see what
> triggers have to do with updating either, even though some
> implementations require them.  By the way, why assume that CURRENT_USER
> is not updateable?
>
> When it comes to updating, I'd prefer to use as few concepts as
> possible, named sets of tuples, algebraically expressible constraints
> and a set of algebra operators.  Design matters might determine
> particular results but a logical engine shouldn't distinguish between
> designs, that's what the old hierachical and network systems did.
> Regarding an UPDATE verb, it is probably simpler to do what TTM does and
> assume an algebra that has extend and rename operators.  I suppose a
> dbms that follows a mere algebra could distinguish 6NF relations, but I
> think it would be ponderous to use.

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? Received on Wed Sep 02 2009 - 23:16:00 CEST