Re: more on delete from join

On Sep 1, 3:17 am, "Joe Thurbon" <use..._at_thurbon.com> wrote:
> On Tue, 01 Sep 2009 14:33:07 +1000, Mr. Scott <do_not_re..._at_noone.com>  
> wrote:
>
>
>
>
>
>
>
> > "Marshall" <marshall.spi..._at_gmail.com> wrote in message
> >news:3f70f7cf-4770-4a66-a978-33ca1dd6ced0_at_u20g2000prg.googlegroups.com...
> > On Aug 30, 11:52 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
>
> > <snip>
>
> > <quote>
> >> > Some systems of equations are overspecified, some are underspecified,
> >> > and some are uniquely specified. Which one of those do you think
> >> > might be a good candidate for the kind of view update that
> >> > would succeed? Would fail?
>
> >> I don't think systems of equations apply to view updates, because view
> >> updates involve more than one state of affairs, the state before the
> >> update
> >> and the state after. Systems of equations are either independent of  
> >> state
> >> or involve one and only one state, so I don't think they are even  
> >> relevant
> >> to the problem of view updates.
>
> > To me, the question is, do my ad hoc view update rules give
> > better results, or does my equation solving approach work
> > better? My expectation is that the latter is true, but as I said,
> > I haven't worked out all the detail yet.
> > </quote>
>
> > While I am still uncomfortable with the idea of the premises of an  
> > argument
> > following from its conclusion,
>
> This pattern of inference is quite well studied. It is called Abductive  
> Inference. It is the oft overlooked cousin of deductive and inductive  
> inference.
>
> Doctors are very fond of it.
>
> Deduction: Given a and a->b infer b
> Induction: Given a and b, infer a -> b,
> Abduction: Given b and a->b, infer a
>
> It is often known by the highly technical term 'guessing'.
>
> http://en.wikipedia.org/wiki/Abductive_reasoning
>
> Cheers,
> Joe- Hide quoted text -
>
> - Show quoted text -

EXACTLY! It's the point I've been trying to make all along - view updates amount to abductive reasoning, which, as Joe put so eloquently, is "guessing".

Which is why I think attempts to formalize the concept will result in incoherence for even trivial examples. Looking at the following:

Relvar A := {{C1='Y'}}
Relvar B := {{C1='Z'}}
Relvar E := {{C2='A'}}

... what coherent interpretation is there for:

INSERT INTO C VALUES {{C1='X'}} In the "treat the insert as assignment" perspective, I still just see type violations (apologies to Bob, I'm just not understanding how a view can be assigned relation values without actually being a base relation variable).

INSERT INTO C VALUES {{C1='X'}}

==> C := C UNION {{C1='X'}}
==> C := 'A UNION B' UNION {{C1='X'}}
==> C := {{C1='Y'}} UNION {{C1='Z'}} UNION {{C1='X'}}
==> C := {{C1='Y'}, {C1='X'}, {C1='Z'}}

By this interpretation, the view C is being assigned a value of type "relation value" - in which case, it no longer seems to be a view at all, but a base relvar. Contrast this assignment with the original type-correct assignment, VIEW C := 'A UNION B', where C is being assigned a value of type "relation expression", to see my point more clearly.

But the "treat as system of equations" approach is equally problematic. The idea seems to be, "dervie from the view-update statement a system of equations, and find a solution such that all database variables are assigned values and all derived equations evaluate to true."

Unfortunately, the only system of equations I can derive from this insert statement is infinitely underspecified* [see NOTE below] - and would be so for ANY insert/update/delete of ANY view.

INSERT INTO C VALUES {{C1='X'}}
==> C = C UNION {{C1='X'}}
==> A UNION B = A UNION B UNION {{C1='X'}} This system of equations entails virtually no constraints at all: it can be solved if we set A := {{}} and B:= {{C1='X'}}. In fact, it's solved if we insert *anything* into A and anything into B, as long as we include tuple {{C1='X'}} in at least one of them. Furthermore, as long as we put {{C1='X'}} into either A or B, we can even solve this system of equations with inserts and deletes of tuples to or from any other relation variable in the database, e.g. E:= {{C2='P'}}.

*[NOTE]: okay, it's not necessary "infinitely" underspecified. Technically, the solution space would be on the order of the product of the domain size of all attributes of all relvars in the system, so the solution space would only be infininte if at least one attribute type had an infinite domain.

Looking at an even simpler example, we encounter the same problem: VIEW F := 'E';
DELETE FROM F {{C2='B'}} This yields the system of equations
E = E MINUS {{C2='B'}}
which is solved by any of these assignments:

E := {{}}
E := {{C2='A'}}
E := {{C2='A'}, {C2='Q'}}