view updates (was something else)

From: Aloha Kakuikanu <aloha.kakuikanu_at_yahoo.com>
Date: 3 Nov 2006 17:44:27 -0800
Message-ID: <1162604666.934966.76430_at_m7g2000cwm.googlegroups.com>


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. We can insert the record into the RealPeople table or not insert. Either action would not change the view. With the constraint the insertion of {(name=TeGiriNeNashi)} is unambiguisly NOOP.

What is a constraint? It is just some equation in relational algebra. For some reason, view updates literature completely ignores a simple fact that the problem is formulated not for a single view, but a set of views. A single view changes often don't have enough information to unambiguously solve the problem. In the above example we have 2 views:

RealPeople
union
{(name=TeGiriNeNashi)}

and

RealPeople
intersect
{(name=TeGiriNeNashi)}

we just want to say that the second view is always empty.

I know, there is a whole complementary view approach, but as algebraically motivated person I have no problem considering a system of view equations instead of a single equation.

So if we have views V_1, V_2, ...
defined in terms of base relations R_1, R_2, ...

V_1 = V_1(R_1, R_2, ...)
V_2 = V_2(R_1, R_2, ...)

...

all what we need to do is to solve the system in terms of R_1, R_2, ...

R_1 = R_1(V_1, V_2, ...)
R_2 = R_2(V_1, V_2, ...)
...

This should be done formally, by applying laws of relational algebra. (Unlike classic algebra, however we face tremendous difficulties solving equations in RA.)

Now, look what the view update problem become. It is just a view maintenance problem! Received on Sat Nov 04 2006 - 02:44:27 CET

Original text of this message