Re: The Practical Benefits of the Relational Model

Try to look at it from a semantic perspective.

What's the meaning of a tuple ? It is that a particular proposition is true.

As such when the user inserts a tuple into a base table, the user declares that to he best of his knowledge some proposition is true. So all the tuples in the base tables are propositions asserted by users to be true.

Next, what's the meaning of a tuple in a view. it is a proposition that the system _derived_ from the base facts (those asserted by the user), we can say also it's the conclusion of a proof, the system can prove that all the propositions in the view are true, given that the base propositions (over which the system has very little control) are true.

Now let's analyze what's the natural semantic of the user trying to insert a tuple into a view. It is equivalent to him saying: I'm not sure what the base facts are, but it is my observation that this conclusion is true.

It is quite natural, then that the system should update the fact base (the base tables) _only_ if it can prove the reciproque of the theorem given by the tuple in the view. In other words, given that this conclusion is true it can _only_ be that this base facts are as such. Of course, this is not generally possible, therefore there is an important natural semantic distinction between base tables and views.

That's why Mikito's proposal (I believe it's been presented in "The Alice book", but don't have it on hand to verify), is that the user (or the DBA) should be able to assist the DB system in going backward with the deduction. You can't find a proof of the reciproque, but here's the proof, please verify it and take it into account.

It's mr. Date's observation that view updatability is primarily a semantic issue.

Now let's see what happens with the semantics for a UNION view.

Let's say V = A UNION B, that translates into predicate logic

PV(x)= PA(x) OR PB(x) where x is a tuple variable , PV, PA, PB are the predicates for V, A, B.

Therefore when I insert a tuple c, I declare to the database:

"I know that PV(c)" <=> "I know that PA(c) OR PB(c)".

What happens by Date's updatability rules in the general case (c doesn't break any integrity constraints on A and B). The tuple c gets inserted both into A and B, therefore the DBMS takes my words and transforms them into "I know that PA(c) AND PB(c)".

Which is, in the general case, an unacceptable outcome.

In other words, Mr. Date's update rules make a lot of sense on their own, and they're quite consistent and well defined on their own, but they also mean that the semantic intepretation is fixed and you can't change it. And being a semantic issue, it becomes the responsibility of the database designer to provide the correct semantics, adequate to each particular case.

I'm pretty sure that Date's proposed semantics don't fit _all_ situations in database management and database application, therefore I feel it would be a mistake if they were imposed on the user as the _only_ possible solution.

They are not the only possible solution, and the choice of the adequate semantic solution to a semantic problem should be in the hands of the database designer. Therefore I'd rather see from my point of view a DBMS

   that at the very least allows me to choose between some good alternatives (one of which being Date's proposal), and does not make a particular choice for me.

Have you considered this alternative ?

best regards,
Costin Cozianu

John Jacob wrote:
> Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<ank09n$1606$1_at_sp15at20.hursley.ibm.com>...
>

>>Does setting the view V to it's current value fail? 
>>
>>I.e. does
>>
>>        SET V := V
>>
>>fail? 
>>
>>And if so, do you think that that is justifiable, and/or desirable?
>>
>>Also do all possible DELETES and UPDATES also fail on the XOR view in 
>>question? If not, would you think that such incongruity is justifiable?
>>