Re: relative complement?

From: paul c <anonymous_at_not-for-mail.invalid>
Date: Fri, 18 Mar 2011 17:49:39 -0700
Message-ID: <201103190049.UTC.im0ujl$8c0$1_at_tioat.net>


On 18/03/2011 5:00 PM, Erwin wrote:
> On 18 mrt, 22:44, paul c<anonym..._at_not-for-mail.invalid> wrote:
>
>> But every time I've tried to imagine what the database
>> looks like that they suggest has views that are ambiguous where certain
>> assertions are concerned, I see no ambiguity, just arbitrary biases.
>
> There might be a difference between what _YOU_ see when you look at
> that database, and what the _DBMS_ sees when it "looks" at that
> database.
>
> _YOU_ are likely to look at that database with at least a background
> awareness of what the _EXTERNAL_ predicates of the relvars are, plus
> probably also with some awareness of what the "external predicates" of
> the constraints on that database are. The _DBMS_ cannot do such a
> thing. All the DBMS can do is to observe that "there are n (say, 3)
> base relvars involved in this view, and there are m (say, 17) database
> constraints involved with any of those n relvars, and the nature of
> those database constraints can be really just anything". I have come
> to be more and more convinced of the notion that getting a DBMS to
> provide sensible support for view updating will require that DBMS to
> "understand" constraints in exactly the same way as a human
> "understands" them. And that's a tall order.
>
> And if you could explain to me _what it is that you see_ (I mean the
> "external predicate things" that you see), when you look at a
> database, in such a way that you can define it (what you see) in
> _formal, mathematical, algebraic, calculus_ terms, then I would start
> implementing and become a wealthy man in no time at all (after my
> implementation work is done, of course).

I think that's a good description of the opposite of what I suggest! What I think the hard part is, as far as implementation is concerned, is ignoring what I might happen to know about the 'external' predicate and devise an engine that applies user assertions only to what is recorded but at the same time, all that is recorded! If a language supported a user asking which UNIONS are both empty and non-empty, the answer should be none. If a language were not to support that query that would be an example of a language that makes answering what I think is an important question what you call a 'tall order'! Received on Sat Mar 19 2011 - 01:49:39 CET

Original text of this message