Home -> Usenet -> comp.databases.theory -> Re: more closed-world chatter

Re: more closed-world chatter

From: Jon Heggland <jon.heggland_at_idi.ntnu.no>
Date: Thu, 03 May 2007 16:30:10 +0200
Message-ID: <f1croj$oii$1_at_orkan.itea.ntnu.no> 






paul c wrote:

> Bob Badour wrote:




>> paul c wrote:

>>> paul c wrote:

>>>

>>>> If I have a domain of items consisting of the values "a" and "b" and


>>>> a domain of item prices consisting of the values "1" and "2" and an

>>>> empty relation {ItemID, Price} known by the relvar name "Items", I

>>>> take it that the logical complement of "Items" has four tuples -

>>>> loosely, <a,1>,<a,2>,<b,1>,<b,2>.

>>>>

>>>> If I select from Items where Price = 3, should a dbms answer with an

>>>> empty relation or should it take exception, such as "illegal

>>>> question"?  If it doesn't take exception, then I'd guess it is

>>>> supposing a complement that has an infinite number of tuples which

>>>> couldn't be implemented on a finite computer.

>>>>

>>>> As unhappy as this makes me, I'm now thinking exceptions can't be

>>>> avoided in practice.

>>>

>>> Ie., is it a logical mistake to allow the query in the first place?

>>

>> No, it is not a logical mistake. Equality evaluates to false for

>> values of disjoint types. Because 3 is not in your type, the

>> comparison evaluates to false.

> 
> Thanks, I feel better now.  Still, I'd like to know I could paraphrase
> that query a little more formally, say using D&D <AND>.  But the
> stipulation "It is required that if <A,T1> is in Hr1 and <A,T2> is in
> Hr2, then T1 = T2" stymies me, eg., if pricedomain={1,2} and
> anotherdomain={3}, it seems that <AND> isn't defined.





Yes, so your query would fail on a type mismatch in A. If it is
desirable for such a query to succeed (with an empty result), /and/ to
be equivalent to an <AND>, I believe the (declared) type of the Price
attribute in the result would have to be a common supertype of the Price
types in the operands. And that may be slightly counter-intuitive if you
formulate the query as a RESTRICT.



But why are you unhappy about treating such a query as an error? It can
be caught at compile-time, and isn't all that different from the error
I'd expect if I declare a variable of type Price and try to assign it
the value "red".



> (I realize I could get the "false" answer suggested if only one side of
> the <AND> used the "Items" attribute 



The Price attribute, you mean? Then the <AND> would be a product, and
the result empty ("false"?) only by virtue of the Items relation being
empty. I don't see how this helps in any way.

-- 
Jon


Received on Thu May 03 2007 - 16:30:10 CEST












Original text of this message