Re: insert to projection

From: Tegiri Nenashi <tegirinenashi_at_gmail.com>
Date: Fri, 4 Sep 2009 11:37:30 -0700 (PDT)
Message-ID: <28def023-c019-4e36-b86b-4b35805518f1_at_z3g2000prd.googlegroups.com>



On Sep 4, 9:58 am, paul c <toledobythe..._at_oohay.ac> wrote:
> 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?

Proposition: the following view updates are ambiguous:

1. Insert/delete from projection
2. Insert/delete from join (including selection)
3. Insert/delete from union
4. Insert/delete from minus

The only RA operation, that seems to allow view updates is renaming. However, consider

rename( R(x,y), x->y )

Is renaming into the existing attributes allowed (then renaming is projection, which is not updatable)?

I suggest that the idea that we focus on basic relational algebra operators, figure out which updates of these are legitimate, then leverage this knowledge for complex view updates is fundamentally wrong. Consider a "pivot" view:

table Contacts (

   name String,
   email String,
   phone String
)

and the view

select name, email as contact, 'email' as type union
select name, phone as contact, 'phone' as type

This is a perfectly updatable view, yet your approach would fail to discover how to translate its update to the base table. (This pivot operation is a recurrent theme in data exchanges)

Then, there are constraints, "simultaneous" updates of multiple views. There is simply no way a naive analysis (of how RA operations may behave under view update) could possibly provide any insight to the problem. Received on Fri Sep 04 2009 - 13:37:30 CDT

Original text of this message