Jan's well-defined view updates definition
Date: Mon, 15 Sep 2003 13:47:08 -0700
Message-ID: <OHp9b.28$lB2.172_at_news.oracle.com>
"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.
You don't have any constraint on the base table. Therefore,
deltaD = (
update Emps
set dept = 'marketing'
where dept = 'sales'
)
is legal. 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
)
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).
deltaV1 = no change
deltaV2 = (
delete from V2
)
> That doesn't matter, the definition would still define a trivial property.
> As I already said, you can always take for Q^-1 the function that maps any
> relation (or any tuple, if you change the definition) to X.
Answered in the old thread. Received on Mon Sep 15 2003 - 22:47:08 CEST