Re: Jan's well-defined view updates definition

Thanks for updating the subject-line.

Mikito Harakiri wrote:
> "Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
> news:jWo9b.22053$NH3.1410149_at_phobos.telenet-ops.be...

>> >> No, this is an illegal update because you are trying to insert a tuple
>> >> into
>> >> a relation that cannot have such a tuple. This makes sense because
>> >> your view is your ontology so the only thing that you can tell the
>> >> database
>> >> is
>> >> that someone is no longer with sales. It's the user with the
>> >> marketing-view
>> >> that should tell the database that this employee is now with
>> >> marketing.

Sure. But it's

deltaV = (
  update TrEmps
  set dept = 'marketing'
  where dept = 'sales'
)

that is illegal, i.e., not well-defined. The view definition acts as a constraint here. There is not update that you can do on the base tables that would change the view in the way that is specified by deltaV.

> This update is "projected" into the view but the projection
> looses some information. For example,
>
> deltaD = (
> delete from Emps
> where dept = 'sales'
> )
>
> would be indistinguisheable from the above update. You suggest restoring
> the lost information by accepting the second update as "natural"
> translation of
>
> deltaV = (
> delete from TrEmps
> )

Indeed. But actually I'm not transforming anything. All I do is look at the logical consequences of what the user has told the database. It is crucial that we regard the view as a set of facts and interpret updates as additions of deletions of facts to a certain predicate. Anything else would be heresy. :-)

> My position is that we restore missing information by considering more
> views. For example, suppose we have
>
> Q1 = (SELECT name
> FROM Emps
> WHERE dept = "sales"
> )
> Q2 = (SELECT name
> FROM Emps
> WHERE dept <> "sales"
> )
>
> and
>
> deltaV1 = (
> delete from TrEmps
> )
>
> (It might be a good idea to switch notation here from TrEmps to V1)
>
> deltaV2 = no change
>
> Then
>
> Q * (delete from Emps where dept = "sales") =
> = <deltaV1,deltaV2>
>
> (Here we have multiple relations on both sides of the equation, therefore
> I swithed to notation that uses "vector" of deltas).

and the fact that you like geometry has nothing to do with this? :-)

> We see that Q is updateable for that particular combination of deltas, but
> it wouldn't be updateable for
>
> deltaV1 = no change
>
> deltaV2 = (
> delete from V2
> )

Why not?

> Hence, "local invertibility".

So if we make the view big enough then your definition allows the updates that my definition already allowed for the smaller view. Why does the view have to be so big? Why do you want to be so strict? What is the intuition behind your restriction besides that the math looks cute (which is IMO actually not unimportant)?

• Jan Hidders