Re: view updates (was something else)

paul c wrote:
> Aloha Kakuikanu wrote:
> > paul c wrote:
> >> Aloha Kakuikanu wrote:
> >>> NENASHI, Tegiri wrote:
> >>>> Jan Hidders wrote:
> >>>>> Do you know of any results that might be interesting for database
> >>>>> theory and could not already be shown with good old set theory?
> >>>> The categorical sketches to use for universal view updatability:
> >>>>
> >>>> Michael Johnson and Robert Rosebrugh.
> >>>> Universal view updatability
> >>> They claim to solve view updatability? OK, I have a table RealPeople
> >>> with one attribute Name and the view
> >>>
> >>> CDTPosters =
> >>> RealPeople
> >>> union
> >>> {(name=TeGiriNeNashi)}
> >>>
> >>> and a constraint
> >>>
> >>> RealPeople
> >>> intersect
> >>> {(name=TeGiriNeNashi)}
> >>> =
> >>> {}
> >>>
> >>> Is the CDTPosters view updatable?
> >> I like that example, but can you come up with one that doesn't involve a
> >> constraint? (I think constraints muddy the waters and at worst confuse
> >> us with un-related questions.)
> >
> > I would argue that constrants clarify the picture. Without this
> > constraint when adding the record {(name=TeGiriNeNashi)} into the
> > CDTPosters view we have ambiguity. ...

>

You probably have in mind the ambiguity of updating the view "A union B".

I refer to ambiguity in more general sence. We insert a tuple into a view, and yet there is more than one way to update the base table all having the same result in the view.

> In this case, there seems to be only one.

In this case we can ether update the table, or do nothing.

> I would
> like to see an example with two.

OK, how about

CDTPosters =
RealPeople
union
Impostors

This is ambiguous view, right? However, if we also have the following view

DoubleIdentityPosters =
RealPeople
intersect
Impostors

then the update transaction reflected on both views can be translated back to the base relations. Received on Sat Nov 04 2006 - 03:39:18 CET