Alfredo Novoa wrote:
Yes - what is your concern?

My primary concern is the rules for difference views; specifically,
the part that says that the row to be inserted cannot satisfy the
predicate for B in V = (A MINUS B). Suppose a row is presented for
insertion into V that does not appear in either A or B at the moment,
but could be valid in either. Does that mean that it is impossible to
insert the row into the view? If the CJD and DMcG rules are as I
understand them, I think the answer is "yes, it is impossible to
insert into the view". I think I want the answer to be "no, you can
insert the row because it satisfies the predicate for A (so it will
show up in the view) and because it does not actually appear in B (so
it won't cancel the appearance of the row in V)". This is a less
stringent criterion than insisting that the row cannot appear in B.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler <jleffler (AT) earthlink (DOT) net> wrote


Sorry for the delay. I am trying to clean my ideas, and it is more
complex than I expected. I will keep you informed.

I agree with you, it is one of the problems I found.

Another is:

You want to insert a relation in V = A union B and the relation value
satisfies P(A) and P(B). D&McG rules say: yes the relation must be
insterted in both relvars, but why in both? No reasons are given. If
you insert the relation in only in one relvar the view is updated
correctly. It seems an arbitrary rule to me, and it causes strange
behaviours that they tried to fix with the now dropped Principle of
Orthogonal Design. In my opinion the correct result is: the update is
invalid because there is not a unique solution, the insert proposition
is ambiguous.

Eg:

var Dead real relvar { Name Char } key { Name };
var Missing SameTypeAs( Dead ) key { Name };
var DeadOrMissing virtual Dead union Missing;

insert DeadOrMissing relation { tuple { Name ‘John Doe' } };

The DBMS can not deduce if Doe is dead, missing or both, therefore the
update must be rejected.

Imagine we drop the POOD and we follow D&McG rules. The DBMS would
deduce that Doe is dead and missing, what is clearly an absurd
specially if Doe is found alive later :-)

Another problem is: they say that a view insert always map to inserts
on the base but in the case of difference views a deletion in the B
relvar cause a view insert if the row is also in A.

var x real relation { a integer } key { a };
var y SameTypeAs( x ) key { a };
var z virtual x minus y;
x := relation { tuple { a 1 } },
y := x;

insert into z relation { tuple { a 1 } };

This should be mapped to:

delete y where a = 1;


I will post my alternative approach when I finish it.


Regards
Alfredo

"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote

Symmetry.


And if you insert the tuple(s) in both relvars, the view is also updated
correctly.


And this is any less arbitrary?


If you do not declare all of your constraints to the dbms, the dbms cannot
enforce them. Had you declared the appropriate mutual exclusion constraint,
the dbms would attempt to insert the tuple to both relations and then balk
on the constraint violation.

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote


Symmetry is a principle of beauty, but not a principle of logic :-)

Of course, but the DBMS does not have enough information in order to
decide which is the true solution.

Yes, it is. If a problem is undecidable it is better to say "the
problem is undecidable" rather than inventing a possible false result
without any warning.

It is even clearer with project views;

var x real relvar { a Integer, b Integer} key { a, b };
var vx virtual x { b };

insert into vx relation { tuple { b 1 } };

We can deduce infinite possible solutions. Which solution should we
choose? All?

I declared all my constraints, but probably the example was not very
good.

Imagine another example:

You have two relvars Fat and Tall, with this type: relation { Name
Char }

Relvar Fat holds the relation of people we know they are fat and
relvar Tall holds the relation of people we know they are tall.

You don't know if they are views or base relvars.

We create a view:

FatOrTall virtual Fat union Tall;

Imagine that a guy called Quixote is thin and tall, and a guy called
Sancho Panza is fat and short.

We try to insert a relation:

insert FatOrTall
relation { tuple { Name 'Quixote' },
tuple { Name 'Sancho Panza' } };

This operation means: Quixote and Sancho Panza are fat or tall. This
is a true proposition.

If we use the D&McG approach we would deduce that Quixote and Sancho
Panza are fat AND tall, what is a false proposition.

If you make this query:

Fat where Name = 'Quixote';

The DBMS will lie to you saying that Quixote is fat.

Is this reasonible?

The POOD was created in order to elude problems like this, but it is
only a patch. If the POOD falls, the D&McG view updating approach
falls with it.

Although this is an easy to solve flaw.


Regards
Alfredo

"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote

http://dictionary.reference.com/search?q=symmetry

symmetry

n 1: (mathematics) an attribute of a shape; exact correspondence of form on
opposite sides of a dividing line or plane [syn: symmetricalness,
correspondence, balance] [ant: asymmetry] 2: balance among the parts of
something [syn: proportion] [ant: disproportion]


If it inserts the tuple into only one relvar, it must decide which. If it
inserts the tuple into both relvars, it eliminates an arbitrary decision
while preserving important mathematical properties.


It is not undecidable. The only way it can create a false result without
warning is if the designer omitted an important integrity constraint. If the
designer completes his job, the problem goes away.

See principle #4 at: http://www.dbdebunk.com/page/page/622150.htm


Choose the default if any exists; if no default exists, the insert is an
error.


No, you did not declare all of your constraints. You did not declare the
mutual exclusion between dead and missing, which you later assumed by noting
an absurdity.


How is your example a straw man? Let me count the ways:

1. You start with an objectively and principly bad design by ignoring POOD.
2. You assume the user has knowledge the user intentionally ignores.

If the user knows Quixote is tall, why doesn't the user insert the tuple
into Tall?
If the user knows Sancho Panza is fat, why doesn't the user insert the tuple
into Fat?


No, the example is not reasonable. It is a straw man, but it burns
beautifully.


Even without POOD, your example assumes the user ignores available
knowledge.


I agree. I can think of several ways to solve the flaw without changing the
view updating rules. The easiest way is to assume the user acts on his or
her knowledge.

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

In language of view equations that translates into an equation

Ax=b

having more than one solution.

There is a clear method of making equation solution unique: add more
equations!

Given

table X (
a integer,
b integer
)

the view

view A as
select a from X

is not updateable, since the equation

Ax=y

has nonunique solution no matter what value relation y has. If we throw in
more equations, for example

view A1 as
select b from X

then, the view that combines A and A1 together is updateable.

Constraints are views that evaluate to constants, they could be added to
disambiguate the original view the same way as the "normal" views.


All these ideas are parallel to equations solving in algebra. Given 2
variables x1 and x2, the equation

x1 = y1

doesn't have unique solution since x2 can be chosen arbitrarily. However, if
we add

x2 = y2

then our system of equation has unique solution (no matter what values
variables y1 and y2 have). Alternatively, we can add a constraint

x2 = 0

which disambiguates our system of equations as well.

"Mikito Harakiri" <mikharakiri (AT) ywho (DOT) com> wrote

I am not certain what you mean. Are you saying that in the case of ignoring
symmetry and arbitrarily deciding to insert to only one base relvar there is
more than one solution? Or are you comparing the entire situation to an
equation with multiple roots?


I assume you are agreeing with my suggestion to declare the constraints.


Suppose we extend the syntax for view definition to allow systematic default
values:

view A as
select a from X
default X set b = 0 on insert to A


The constraint method basically restates POOD. Or alternatively, POOD states
a good design has sufficient constraints declared to disambiguate the
systems of equations.

The default value method constrains specific operations without constraining
the base relvars.

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

No, your update policy allows one solution only.

Union view update has 3 solutions: insert into the first relation, insert
into the second, and insert into the both. You just arbitrarily chosen one
of them. Your choice formally is just [arbitrary] constraint that you add to
the view.

Yes. Suppose we have a system of equations

x1+x2 = y1
x1+x3 = y2
2*x1+x2+x3 = y3

and being asked to find x1, x2, and x3 given y1, y2, and y3. It is easy to
see that if y1+y2!=y3, then there is no solutions, while if y1+y2=y3, then
there is a continum of solutions. This continuum of solutions would be
disambiguated if we add one more independent linear equation.

Constraint, or additional view. For example, we certainly have not enough
information to disambiguate union view alone, but can disambiguate union
view if also know (symmetric) difference.

select x1, x2 from (
select x as x1 from A
union
select x as x1 from B
), (
select x as x2 from A
minus
select x as x2 from B
union
select x as x2 from B
minus
select x as x2 from A
)

If the value (1,1) is inserted, then we certainly aren't allowed to insert
it into both A and B. Otherwise the second operand of the CP would be empty.

The ambiguity between inserting into A and inserting into B is still
unresolved. We eliminated one possibility out of 3 only, but I hope that the
idea is clear.

Not general enough.

Constraints are one possibility. Extending views (aka adding more equations)
like in the "union" example above is more general approach.

Here is alternative suggestion:

Given a set of views

V1, V2, ... VN

and a set of insert/delete operations upon those views, for example

insert ('John', 20) into V1
delete from V2 where name = 'Mary'
....

translate those view updates into the base relations.

Comments.
1. We need to consider more than one view in order to be able solve
ambiguous cases.
2. It is not clear if artificially combining views like in the example of
union&symmetric difference is a good idea.
3. Constraints are views that evaluate to constants. For example, if we
define

view V3
select max(sal) from (
select sal from emp
union
select 1000 from DEE
)

then constraint "each emp has salary no more than 1000" can algebraically be
written as

V3*x = 1000

where "V3*x" means view V3 applied to a set of base relations x, and "1000"
means an output relation that has one tuple with a single value 1000.

"Mikito Harakiri" <mikharakiri (AT) ywho (DOT) com> wrote

Small increment, sorry.

It is even better to write constraint equation as

view V3
select max(sal)/1000 from (
select sal from emp
union
select 1000 from DEE
)

V3*x = DEE

or still even better

view V3
select 1000 from DEE
minus
select max(sal) from (
select sal from emp
union
select 1000 from DEE
)

V3*x = DUM

(Equations that evaluate to 0 are math favorits:-)