Re: The Practical Benefits of the Relational Model

Sorry, you lost me . Let me make myself plain

create table a(a integer not null, primary key(a)); create table b(a integer not null, primary key(a)); insert into a values (1), (2);
insert into b values (2), (3), (4);
drop view v;
create view v as (select a from a union select a from b ) except (select a from a INTERSECT select a from b);
select * from v;
A

          1
          3
          4

  3 record(s) selected

Now if I want to

    insert into v values (5);

How can I reasonably choose to place it in B rather than A, or indeed in A rather then B. Either way is arbitrary.

and why arbitrarily ban me from

    insert into v values (2);

as this would entail a delete from either A or B (but not both), however Date's rules ban an INSERT from being propagated as a DELETE on the base tables.

I guess the logical thing to do is simply ban updates to this view. But I can't see how to get from Date's rules to that conclusion for this view.

>The relations A and B must be type compatible (union compatible, have
>the same type).

Indeed. But I could have used OR if i was not interested in that.

>Assume they have relation predicates PA and PB. To be acceptable
>for insert into the view expression above, the set of tuples
>presented must satisfy the predicate for the view as a whole as
>well as satisfying the predicate for the relation(s) into which
>it is inserted separately.

And the 'predicate of the view as a whole' is in the case above

        A IS AN INGEGER
because my view V can return ANY set of integers

>Using the algorithms given in C J Date "Relational Database
>Writings 1991-1994", each tuple in the set must
>either belong to "A but not the part of A that is also in B"
>or "B but not the part of B that is also in A".
>These are completely disjoint sections of the Venn diagram for
>the the view expression, so the placement of each tuple is
>unambiguous -- it either goes into A or into B but there is no
>possibility of going into both.

So, 'either it goes in A or in B but not both' is unambigious is it!?

>So, that's what I'd expect D4 or Alphora to do...

I'll let them answer that.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Oct 02 2002 - 12:23:57 CEST