Re: The Practical Benefits of the Relational Model

"Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message news:<3d975e6e$0$69051$edfadb0f_at_dspool01.news.tele.dk>...
> Still, I will provide a loose sketch of an alternative proposal of the
> semantics of a union update: an alternative that I find more logical than
> the example in TTM.
>
> Let RA and RB be relations or views. In this case the meaning of an update
> of the view RA UNION RB is as follows:
>
> a) If RA or RB are not both updateable, the view can not be updated.
> b) If RA UNION RB can be rewritten without using the union operator (E.g.
> Contacts WHERE ID < 10 UNION Contacts WHERE ID > 100 can be rewritten as
> Contacts WHERE ID < 10 OR ID > 100) the update will be the update of the
> rewritten expression.
> c) If RA and RB are not disjoint (based on constraints, not actual values of
> course), the view can not be updated.
> d) The view can be updated. For each tuple, what relation to update can be
> determined by the constraints.

Sorry, I kept the posting in this thread because several other messages have been posted on this issue specifically :)

The only objection I have to these rules is that they introduce the concept of an updatable view. In my view :) this is not necessary, and only complicates the matter. All views are updatable, regardless of the expression on which they are based. If a base table is referenced in an integrity constraint, for example, not exists (T), is T updatable? Yes. There is no update that will succeed, but that does not mean that the table itself is not updatable. This is an important distinction that must be maintained by any view updatability mechanism that is to maintain logical data independence. Indeed, it was this aspect of the view update mechanism in TTM which made it so attractive from our point of view, because as an application developer, I can always assume that a given update is possible, at least in theory. This is critical to ensuring that a general purpose user interface can be built on top of the system. No special case development is necessary in the client applications to manipulate the data in the database.

If we eliminate the notion of updatable vs. non-updatable views, then I see little difference between what you have proposed, and the updatability rules for union described in an Introduction to Database Systems. The update is made against either side of the union if it satisfies the predicate of either side. This is equivalent to your updatability rules, except that you have made the distinction that if a given update satisfies both predicates, it is not allowed, but this is precisely what the union is, an or. In that light, what you have described is the updatability rules for an xor, which is actually still being discussed elsewhere in this thread.

Regards,
Bryn Rhodes
Alphora Received on Mon Oct 07 2002 - 20:20:19 CEST