Re: Thinking about MINUS

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 10 Jan 2007 14:02:29 GMT
Message-ID: <Vl6ph.43072$cz.630608@ursa-nb00s0.nbnet.nb.ca>

Marshall wrote:

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

I am saying that the relation does not determine the namespace. The context in which the relation is used determines the namespace. If two relations are never used in the same context, similarity of names has no effect, and there is no harm in using the same name for different things.

The rename operation is the mechanism by which we resolve the names to use in a given context.

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

Generic operations muddy the waters because the static analysis is not possible until one instantiates a specific operation from the generic template.

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

Agreed.

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

I suspect some products already do more static checking than that; although, I am sure they do not do all the static checking they could.

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

Agreed. Such a dbms would have no choice but to treat the result as an error due to its limitations.

> Anyway, thanks for the lengthy reply.

I apologize for the length. I was too busy yesterday to write a shorter one. Received on Wed Jan 10 2007 - 08:02:29 CST