Re: relative complement?

> Thanks for that reply.  I do agree with your definition of complement
> which is quite a practical one although there are others possible.  I
> asked the question just to try to understand the technicalities of what
> McGoveran said and deliberately avoided mention of UNION which I think
> is an idiosyncrasy

I looked up "idiosyncracy" in order to understand what is precisely meant by that term and found that it seems to refer to "a way of thinking (or a way of seeing things, or a way of looking at the world - or certain aspects of that world-) that is "peculiar" and "eccentric" and "pertains quite individually to the person holding those isiosyncratic ideas/points of view/...

> that commonly misleads as well as view updating which
> I have no problem with, at least conceptually, although I realize that
> many, many others have big problems with.

The problem(s) you refer to is, I presume, "how to do(/support) it". It is -imo quite clearly- a problem for implementers (implementors ?) (and possibly for the community of academic researchers researching the issue). I fail to see how the set of implementers (UNION the set of academic researchers researching the issue) can be described as being "many, many others".

> My own suspicion is that

Apologies, but how do you match "widespread", with "idiosyncratic", given the meaning of the latter term I found in not-really-suspect sources ?

> tendency to think in terms of target relvars

If you accept the idea that "view updating" is a problem for the (DBMS) implementers, how is it possible to NOT think of view updating in terms of target relvars ? In fact, target relvars are all there really is to the problem. The user targets a non-physically-existing relvar (a non-base relvar), the machinery has NOTHING BUT base relvars to satisfy the users's request. The implementer has to see to it that what he does to the base relvars he has to his avail, will correctly reflect the user's request. That's why Date came up with the Assignment Principle, which would prohibit, a.o. and e.g., any arbitrary insert into A MINUS A.

> and disconnected, abstract notions of insert and delete rather than in terms
> of asserting and recording both true and untrue statements.

But aren't INSERT/DELETE and ASSERT TRUE/ASSERT FALSE really just "appearances in different form" of one and the very same thing ?

If so, how can you be thinking in terms of either, "rather than" in terms of the other ?

> In that sense I can side with McGoveran when he saids "the problem ... goes
> away"

I can't. The only way in which the "problem" of "finding a unique transformation" REALLY goes away, is by declaring it not to be a problem.

IMO, that causes problems of its own.

(Well, I should amend that here. The other way that the "problem" goes away, is by solving it, of course, as is the case with any problem. Such a solution now has become conceivable, methinks, but it can be labeled "naive", and is therefore probably still infeasible in all but the simplest of settings.)

PS

Do you plan to attend in Newcastle ? Received on Fri Mar 18 2011 - 17:15:16 CET