Re: insert to projection

From: Mr. Scott <>
Date: Mon, 7 Sep 2009 01:23:08 -0400
Message-ID: <>

"paul c" <> wrote in message news:J%Oom.43977$PH1.40579_at_edtnps82...

> Mr. Scott wrote:

>> "paul c" <> wrote in message
>> news:uskom.43824$PH1.21867_at_edtnps82...
>>> Mr. Scott wrote:
>>>> "paul c" <> wrote in message 
>>>> news:DGbom.42669$Db2.5159_at_edtnps83...
>>>>> Why do implementation languages not allow this?  Surely not for 
>>>>> logical reasons?  We can delete from projection because NOT Pa implies 
>>>>> NOT Pab, eg., <NOT> R{a} -> <NOT> R{a,b}.  Logically, we can insert to 
>>>>> projections because Pab implies Pa.  Isn't the problem really a 
>>>>> language deficiency?
>>>> I don't understand.  Is the binary predicate P somehow related to the 
>>>> unary predicate P, and if so, how exactly?
>>> Sure it is, the truth of the tuple <a 1, b 2> implies the truth of the 
>>> tuple <a 1> and the falsity of the tuple <a 1> implies the falsity of <a 
>>> 1, b 2>, as far as a relation R with predicate P is concerned. 
>>> Projection means quantification and vice versa, what's the problem? 
>>> (Could it be that predicates aren't recorded?).

>> Can you express the relationship formally? Something about your
>> explanation doesn't seem right. There can be a row <a 1> in the
>> projection if and only if there is a row that is a superset of <a 1> in
>> the table. That works out to something like,

>> Px iff (exists y exists z Pyz /\ (x = y))

>> But this actually denies insert to projections because it is not enough
>> to know that there is at least one z, it is necessary to know which z or
>> set of z's there are for a given x, unless you want to introduce nulls.
> What I wrote could be taken wrong.  When I said that "logically" we can 
> insert to a projection it would be have better to say that several 
> projections are inserted when we insert <a 1, b 2, c 3>, eg., R{a} or <a 
> 1> but the converse isn't logical. It's a starting position for figuring 
> out a language definition that would allow insert to projection.  I didn't 
> mention rows and tables because I think they are probably not part of a 
> solution.

In general, a conclusion follows from a set of premises, not the other way around. Sometimes there is only one set of premises from which a conclusion follows, and it is only then that the corresponding view update should be deemed permissible. The underlying criteria for permitting an operation on a view has to be a one-to-one mapping from the set of conclusions into the power set of premises. Received on Mon Sep 07 2009 - 07:23:08 CEST

Original text of this message