Re: Possible problems with Date & McGoveran View Updating

"Bob Badour" <bbadour_at_golden.net> wrote in message news:EFF7b.835$w14.77012067_at_mantis.golden.net...
> I question the assumption of convenience. In the case of an insert to a
> project view, how would one resolve the ambiguiety without default values?
> Can one express the equivalent as a constraint where a constraint is a
> transformation that equates to a constant?

Suppose we have projection view update

table X (

    x1 integer,
    x2 integer
)

view V1 as
select x1 from X

insert into V1 values (5);

Here we are, once again, at our main ambiguity problem. Now, it is possible that the system has another view

view V2 as
select x1+x2 from X

or maybe even

view V3 as
select x2 from X

Knowing what is the result of database update on view V1 alone is not sufficient. But if we know what accompanying changes on view V2 are, then we can solve ambiguity! Even more trivially so if we know what view updates effect on V3 is. Knowing view update effect on any one of the views V1, V2, or V3 is not sufficient, but knowing the effect on any two of them could be interpreted unambiguously.

You suggested that knowing view update effect on more than one view is unrealistic assumption. I have at least one practical case: update happeing in the database A, which must be mapped into update in the database B in the database integration application. Here we have perfect information about what is any transaction effect upon all the views. Otherwise, databases can't be updated in sync.

In short, we have a database, and a set of views. We watch "projection images" of "authentic" database update through the views. If we don't have enough watching windows, we can't restore the update "image". Received on Wed Sep 10 2003 - 19:24:39 CEST