Re: The Practical Benefits of the Relational Model

>> Out of interest, how does D4 insert into this view?
>>
>> (A UNION B) MINUS (A INTERSECT B)
>>
>> It seems to me to be entirely arbitrary to insert into A rather than B,
or
>> vis-versa, and only slightly less arbitrary to not allow any inserts at

>> all.

>I would suggest an analogy between your equation
>V = (A UNION B) MINUS (A INTERSECT B)
>and algebraic equation
>Z = X + Y

I was thinking of XOR, but you point stands

>In the second case if we know Z, we cant solve it unambiguously for X
>and Y values. In order to resolve ambiguity, we have to add a second
>equation.

>Likewise, if we add a second view
>W = A minus B
>then the view set {V,W} is perfectly updateable.

Hey, you are well on the ball Mikito. That was pretty much exaclty my next question for the view updating rules.

>For example, if we see a transaction
>insert 1 into V;
>insert 1 into W;
>commit;
>then it's definetely an insert into A. On the other hand,
>insert 1 into V;
>commit;
>is certainly an insert into B.

Exactly.

Off topic for a sec. Transactions are very stupid things (there, that should spark a debate).
Just use a multiple update statement. D&D's comma syntax is passable:

insert 1 into V, insert 1 into W;

which obviously is a shorthand for
 V := V UNION (1), W := W UNION (1); The view updating rules make no special mention of multiple update statements. They do say they are 'recursively defined', so if we created a view such as

X = (SELECT a, 'V' as view FROM V) UNION (SELECT a, 'W' as view FROM W)

Then, do
insert into X (values (1, 'V'), (1, 'W'))

then I guess it will still fail on the hidden insert to the 'XOR' view V.

??!?

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Sat Oct 05 2002 - 19:40:59 CEST