Re: more on delete from join

On Sep 1, 8:03 am, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:
> On Sep 1, 3:17 am, "Joe Thurbon" <use..._at_thurbon.com> wrote:
>
> 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".

I see no reason to think this, and I don't see that you've supplied any reason to think this. View updates are just a way of writing updates; nothing about their nature is different than regular updates. Are regular updates abductive? I would say certainly not.

I also disagree with the notion that the database state before an update is a "premise" and the state after is a "conclusion." Any premises are table values; any conclusions are query results; any inference rules are relational operators. Classical logic has no analog of any imperative operation, therefore any labeling of an update with a term from classical logic is unjustifiable.

And if it still looks like guessing to you, you still haven't grasped the concept. Is solving systems of _linear_ equations "guessing?" No; it is a process that is entirely deterministic and arithmetically sound. The identical qualities hold under the idea of solving systems of relational expressions.

> 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'}}
> View C:= 'A UNION B'
>
> ... what coherent interpretation is there for:
>
> INSERT INTO C VALUES {{C1='X'}}
This same example again? This is not "incoherence"; this is underconstrainedness, a perfectly well understood and expected phenomenon.

To repeat: some systems of equations are overconstrained, some are underconstrained, and some are uniquely constrained. This example is underconstrained; it has no unique solution. We should be astonished if we did *not* find trivial examples of underconstrained and overconstrained systems.

> In the "treat the insert as assignment" perspective,

This is just a complication; a distraction. Pick a set of imperative operators as primitives and discuss from there. There is no value, indeed there is only obfuscation, to be obtained from picking a set of primitives and then defining derived imperative operators from those primitives and putting your examples in the derived terms. Keep it simple. It will work for the derived operators if and only if it works for the primitives, or else your derivation is fundamentally broken.

> 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.

This argument assumes its conclusion.

> 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.

"Expression" is not a type. You seem to have a fundamental misunderstanding of what types are.

> 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.

Then you have failed to understand the situation.

I like to use *really* simple examples wherever possible:

Consider a view V on table A defined as just table A as it is. Insert a tuple into view V. How many possibilities are there for how to handle this? "Exactly one" is not "infinitely underspecified."

> 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'}}
> ...

Finding under- or over-constrained examples demonstrates nothing whatsoever. These are expected and understood; indeed, they are practically mandatory. In fact, all your counterexamples are of underconstrainedness; you haven't even managed to find any overconstrained examples yet, which is further evidence that you don't see the big picture at all. (To say nothing of the fact that you haven't come up with any examples that work.)

If you want to critique the idea, you must either develop it fully yourself or else wait for someone else to develop it, and then at a bare minimum do some case analysis on the two systems to see how they handle various cases. I am not suggesting you do this, but I am claiming that doing anything less isn't doing anything at all.

And let me ask a further question: in this hypothetical analysis, or even in the examples you've given here, *how* exactly are you justifying you arguments either for or against a certain outcome? I claim what you are doing is simply naive solving of systems of relational equations. If that isn't what you are doing in your justification, then just what *are* you doing?

Marshall Received on Wed Sep 02 2009 - 07:54:21 CEST