Re: The Practical Benefits of the Relational Model

Peter,

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

We welcome criticism of the product and of the theory on which it is based as long as that criticism is well founded. This was the reason for my retort to Mikito. We actively search for solutions.

> > 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 ;-)

The statement is referring to the ommission of column names in the SQL syntax, a point which Mikito seems to have picked up on in his subsequent postings. I do not mean to suggest that we should not use SQL for examples, merely that if we do, we should at least attempt to use it relationally. I firmly believe we must maintain some degree of precision in these discussions. Sorry if I used D4 syntax, but I feel it is fairly clear, perhaps even more so than SQL because it explicitly outlines the operations taking place.

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

The first view is updatable, at least in theory. It is just that there is no update that will succeed because there is not enough information. There is a _big_ logical difference between the two statements, and I believe this difference is fundamental to Mr. Date's proposals. It is just like constraint enforcement. The existence of some constraint does not mean that the table variables involved are not updatable, rather that some updates will fail because they would introduce data which is in violation of the constraint.

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

While I must admit that the statement does sound like a bullet from a data sheet, it is in no way a vacuous remark. Perhaps we could rephrase it thus: all the operators of the relational algebra have well-defined semantics regarding updatability. These semantics work in concert with each other to effect updatability no matter what operators are involved in a given expression, just as the retrieval operations have a specific affect, so the update operations have a specific effect, meaning that there is a kind of updatability closure over the operators of the relational algebra. Therefore, for any combination of relational operators used to define a given view, including ones involving scalar expressions such as extend, we can determine the effect of an update against that view. One of those effects is obviously an error. The reason we find this distinction between saying a view is updatable and saying that the update would fail so important is that as soon as we regard a given view as not updatable for some reason, we have to treat that view differently than a base table variable, and we lose logical data independence. This independence is critical for applications. All applications can deal with errors during updates, any given update could fail for a variety of reasons, but it is quite another matter for the application to determine whether or not what it is dealing with is updatable.

> 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? ;-)

I post with my spammail account to avoid scanners. I am sorry to hear that you had problems with the installation. If you would like to contact me directly I would be happy to help you work through them. I can be reached at bryn_at_alphora.com.

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

I regret that I do not have time to respond to this portion of your message at this time. I will do so later, and in another thread ;)

Regards
Bryn Rhodes
Alphora Received on Tue Oct 01 2002 - 05:59:42 CEST