Re: The Practical Benefits of the Relational Model

"John Jacob" <jingleheimerschmitt_at_hotmail.com> skrev i en meddelelse news:72f08f6c.0209281332.3efe8b6d_at_posting.google.com...
> > 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.

Hi John

Allow me to respond even if it is not my posting, that is directly addressed. Please notice that I have not criticised the Alphora product: I am not familiar with it. My criticism was directed towards the statement in The Third Manifesto (TTM) that views are always updateable. In particular, there is an example in TTM, where the insertion of a tuple (well, loosely speaking!) may result in an insertion into one of the underlying relations or into both. This is an ad hoc solution.
>
> > 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.

I believe this statement is unfair. We should be allowed to be a little informal here, and I believe we all understood Mikitos examples here as indeed your rephrasing shows. What not all of us are familar with is the Alphora language ;-)

>
> 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.

I agree that this last view should be updateable on the given grounds. But the first view was not updateable, thus contraticting TTM - and also Nathans remark: "The Dataphor DAE fully supports view updateability". While I can not give Mikito leeway wrg. informality and demand that Nathan be concise, I believe that there is a difference between a statement and an example. Also Nathans remark does look very much as if it was taken from the marketing-department.

>
> > 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.

You have dissected this example differently than me. I believed 'VOICE' type and 'FAX' type to be the type of the telephone connection - such as "PULSE" or "TONE". I am curious as which of us had that example right.

> 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.

Yes. I agree that this view is trivially updateable. The interesting stuff comes when you remove the "Type" field above, that is:

create view ContactPhone

   Contact over { ID, Voice } rename { Voice Phone }    union
   Contact over { ID, Fax } rename { Fax Phone };

[snip]
>
> > 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

I find the above claim very marketingeese and at best very informal.

> . 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.

Speaking for myself only, I have downloaded your product. I tried to install the documentation only (I have no back-end DBMS on my system), but the installation program failed. I look forward to see your documentation, which Nathan has promised to post here.
The information on your web-side must have been written by marketing, surely?

>
> Regards,
> Bryn Rhodes
> Alphora

Bryn? A nickname for Jacob? ;-)

You criticise us for not providing an alternative mechanism than that proposed by TTM. This is not fair - it is legitimate to criticize a solution without providing an alternative. Also this is not the appropriate forum (at least not the right thread!).
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:

1. If RA or RB are not both updateable, the view can not be updated.
2. 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.
3. If RA and RB are not disjoint (based on constraints, not actual values of course), the view can not be updated.
4. The view can be updated. For each tuple, what relation to update can be determined by the constraints.

Kind regards
Peter Received on Sun Sep 29 2002 - 22:11:22 CEST