Re: The Practical Benefits of the Relational Model

> I agree: those are just a set of ad-hock rules hardly illuminating
> anything about the problem.
This sounds like a criticism of the view updatability research of Date, McGoveran, Darwen, and many others. If you have a better mechanism for updating views, one that is less "ad hock" by all means enlighten us. Otherwise, you are not contributing to the solution of the problem.

> If we allow domain operators, however,
> (and D4 allows them, right?)
D4 allows operators to be defined for all types, scalar types are just a special case.

> then the problem becomes more
> challenging. Telling the rules for relational operators is not enough
> anymore, we have to be able to solve equations. For example, is a view
>
> select x+y, x-y from point
>
> updateable? If it is, then how about
>
> select arccos(x/(x*x+y*y)), sqrt(x*x+y*y) from point
>
> ?
First, let me point out that you are not defining views here, nor indeed are these relation-valued expressions. Let me frame the argument in a relational language before I respond to it.

create table Point { X : Integer, Y : Integer, key { X, Y } };

create view PointView
 Point
  add { X + Y XPlusY, X - Y XMinusY }
  over { XPlusY, XMinusY };

The projection is not updatable because not enough information can be obtained from the result to construct an update against the base relation variable. This is true for projections in general, unless of course, the base relation variable defines default values to fill in the missing information. If we remove the projection:

create view PointView
 Point
  add { X + Y XPlusY, X - Y XMinusY };

The view most certainly is updatable and the update will only fail if the constraints for the view are not satisfied, namely, the value for the column XPlusY must be equal to the evaluation of X + Y, and the value of the column XMinusY must be equal to the evaluation of X - Y. If you are implying by these examples that the system should somehow be able to infer the values of X and Y, you are no longer talking about view updatability, rather you are talking about theorem proving. We made no such claims. Please restrict your criticisms of our product to claims we have made.

> Even if we don't allow domain operators, what can we infer about
>
> select id, 'VOICE' type, voice phone
> from contact
> union
> select id, 'FAX' type, fax phone
> from contact
>
> ?
It is with particular pleasure that I dissect this example as it is a perfect illustration of the power of our view updatability mechanism, precisely because of the "ad hock" theories on which it based. Again let me frame the argument in a relational context:

create table Contact
{
 ID : Integer,
 Voice : String { default "" },
 Fax : String { default "" },
 key { ID }
};

create view ContactPhone
 Contact over { ID, Voice } rename { Voice Phone } add { "VOICE" Type }
 union
 Contact over { ID, Fax } rename { Fax Phone } add { "FAX" Type };

Not only is this view updatable, but I would argue that it has precisely the desired affect your example implies is impossible to determine. The insertion of the row row { 1 ID, "VOICE" Type, "123-4567" Phone } satisfies the predicate for the left side of the union, and so is inserted there. The update through the add is successful because the value of the Type column is indeed "VOICE". The update through the rename, obviously, succeeds, and the update through the project succeeds as well (because of the default definitions). The effect is then the insertion of the row row { 1 ID, "123-4567" Voice, "" Fax } into the Contact table. A similar deconstruction can be given for the row row { 2 ID, "FAX" Type, "555-5555" }.

> Therefore, claim like "The Dataphor DAE fully supports view
> updateability" is just naive marketing.

Therefore, we stand by our claim that the Dataphor DAE fully supports view updatability. Furthermore, it is apparent from your remarks that you have not even attempted to test your hypotheses against the Dataphor product. So your claim that we do not support updatability is just naive criticism. The Dataphor product is available for public evaluation from our site www.alphora.com. If you doubt the validity of our claims, by all means, try it out. Please refrain from making public criticisms of a product which you clearly know nothing about.

Regards,
Bryn Rhodes
Alphora Received on Sat Sep 28 2002 - 23:32:57 CEST