Re: A different definition of MINUS, Part 3
- From: paul c <toledobythesea@xxxxxxxx>
- Date: Fri, 19 Dec 2008 12:47:40 -0800
vadimtro@xxxxxxxxx wrote:
....
Let's move on to other cases. Oracle treats a join view as updatable
under the following conditions:
*The DML statement must affect only one table underlying the join.
*For an INSERT statement, the view must not be created WITH CHECK
OPTION, and all columns into which values are inserted must come from
a key-preserved table. A key-preserved table is one for which every
primary key or unique key value in the base table is also unique in
the join view.
*For an UPDATE statement, all columns updated must be extracted
from a key-preserved table. If the view was created WITH CHECK OPTION,
then join columns and columns taken from tables that are referenced
more than once in the view must be shielded from UPDATE.
Let's restrict the scope to updates only. Here is a proposition I
translated these conditions to:
x ^ R00 = dx ^ R00 & % x and dx have the same headers
(x ^ y) ^ R00 = dz ^ R00 & % x ^ y and dz have the same headers
(dx ^ x) v R00 = R00 & % dx disjoint with x
(dx ^ y) v R00 = R00 & % dx "doesn't affect" y
(dz ^ (x ^ y)) v R00 = R00 & % dz disjoint with x ^ y
dx = dz v (x ^ R00) -> % dx is a projection of dz
(x v dx) ^ y = (x ^ y) v dz. % Then, application of increments
% on the base relations
% is the same as increment
% on join view
QBQL exhibits the following counter example
dx =
{<y=a,x=0,>,<y=b,x=0,>,<y=b,x=2,>,<y=c,x=0,>,<y=c,x=1,>,<y=c,x=2,>,}
dz =
{<y=a,x=0,>,<y=b,x=0,>,<y=b,x=2,>,<y=c,x=0,>,<y=c,x=1,>,<y=c,x=2,>,}
y = {<y=a,x=1,>,}
x = {<y=a,x=1,>,}
so it must be that I interpreted "The DML statement must affect only
one table underlying the join" wrong...
I think it's a shame that you had to go to make that translation yourself from conditions that aren't expressed mathematically. Even though I know very little about the language details of Tutorial D, one thing I like very much is how it defines basic features in terms of the algebra. Those terse definitions could allow very quick re-casting of implementation behaviour if a flaw were found.
.
- References:
- A different definition of MINUS, Part 3
- From: paul c
- Re: A different definition of MINUS, Part 3
- From: paul c
- Re: A different definition of MINUS, Part 3
- From: Brian Selzer
- Re: A different definition of MINUS, Part 3
- From: vadimtro
- Re: A different definition of MINUS, Part 3
- From: paul c
- Re: A different definition of MINUS, Part 3
- From: vadimtro
- Re: A different definition of MINUS, Part 3
- From: vadimtro
- A different definition of MINUS, Part 3
- Prev by Date: Re: A different definition of MINUS, Part 3
- Next by Date: Re: A different definition of MINUS, Part 3
- Previous by thread: Re: A different definition of MINUS, Part 3
- Next by thread: Re: A different definition of MINUS, Part 3
- Index(es):