Re: Thinking about MINUS

That was a lot to digest. I read it all twice, and I think we are mostly
on the same page. In particular I am quite convinced of the importance of names, and though you didn't mention it specifically, the value of an algebraic approach as per the Darwen article you referenced. (Which I also read, since it had been a long time since I first read it.)

There are only a few things I want to respond to.

On Jan 9, 8:58 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Agreed. In fact, if I recall correctly, someone once determined that the
> lint warning for unused local variables correlated more with bugs than
> any other warning or error message. Of course, that might be urban
> legend. (I am relying solely on a ~20 year old memory, and I doubt I
> read the original work.)

Interesting!

> > To my way of thinking, the database is a namespace that contains
> > named relvars, or in SQL we say "tables." *Each* table is itself
> > a separate namespace for attributes.
>
> When it comes to relations, I disagree, and I see no reason to
> perpetuate the sins of SQL.

Hmmm. Does this mean that you feel that all the attributes of all relations are in a single namespace, and if we use a name to mean a particular thing in one table we must necessarily use it the same way in another? Certainly I feel that they are all *potentially* in the same namespace, precisely *because* of natural join, but I'm not sure that I feel the need to impose any restrictions on the use of names across tables before any join occurs. (Particularly given the presence of a renaming mechanism.)

> We have a formalism for expressing predicates as constraints. Data types
> are merely constraints in those predicates. The manipulation rules spell
> out what to do with those constraints in various situations, and the
> rules differ from one situation (ie. operation) to another.

There are some more aspects to this. One thing that is often left out of these discussions is the difference between static and dynamic constraints. That is, constraints that may be checked merely by looking at the form of an expression without regards to the contents of the variables referenced in the expression, and those that necessitate the examination, at each evaluation of the expression, of the value of each variable.

Type constraints are typically entirely static, whereas many kinds of common database constraints, such as foreign key constraints, are necessarily runtime checks.

I mention this because, while in general I agree that type constraints are simply a kind of general constraint, I believe that it is important to distinguish between static and dynamic constraints, as they will not be handled the same. However I am not entirely clear how to expose this difference to the programmer. The traditional method, in which type constraints are exclusively static and check constraints are exclusively dynamic, does not satisfy me.

> To join the attributes, we must agree to use the intersection of their
> domains. This suggests the data type must be a subtype of both
> attributes. Joining reals with integers, one necessarily ends up with
> integers. In fact, it should be the most general common subtype or least
> specific common subtype of the declared types.
>
> Thus for completely disjoint declared types, the data type of the
> resulting attribute is the universal subtype not the universal
> supertype. The universal subtype, of course, has an empty set of values
> and the union of all operations.

If we are speaking of our mathematical analysis of a formal system, then I agree. If we are speaking of a formal system itself, then I would point out that that system may not be one in which the universal supertype or universal subtype exist. Indeed, it may not have subtyping at all.

Anyway, thanks for the lengthy reply.

Marshall Received on Wed Jan 10 2007 - 08:30:37 CET