Re: Does Codd's view of a relational database differ from that of Date & Darwin? [M.Gittens]

From: Jon Heggland <heggland_at_idi.ntnu.no>
Date: Fri, 10 Jun 2005 10:18:01 +0200
Message-ID: <MPG.1d136b1fc1207086989691_at_news.ntnu.no>


In article <42a829dc$0$28531$ed2619ec_at_ptn-nntp-reader02.plus.net>, paul_at_test.com says...
> Here's a thought though:
>
> Suppose I have a column "col" of a integer type that has an UNKNOWN
> special value using Date & Darwen's scheme.
>
> Then I do "SELECT COUNT(*) FROM rel WHERE col != 2"
>
> Now the DBMS will have to understand the semantics of this UNKNOWN
> special value to return a result. Should it return a count ignoring any
> rows that have an UNKNOWN value in that column? I would argue it
> shouldn't, but should return some kind of "unknown" result instead. But

It should return the number of tuples produced by the restriction "rel WHERE col != 2". Anything else would mess up the algebra. In my opinion, the (implementer of the) type for col must determine whether UNKNOWN != 2 evaluates to true or false.

The best answer to this query (though not as it stands, of course) would perhaps be a range. Anyway, the query as given is really underspecified given the presence of UNKNOWNs. What is the user really asking? S/he should be more explicit whether s/he wants the number of tuples where we *know* that col != 2, or those where col *may be* != 2. That may be an argument for rejecting the query, or giving a warning.

> what type does it use for the answer? The COUNT aggregate function
> presupposes there exists an integer domain (specifially, a non-negative
> integer domain).

Yes, non-negative integer.

> What about "SELECT SUM(col1) FROM rel where col2 != 5" ?
>
> If the column col2 (of type type2) can contain special values like
> unknown, then also the type (type1) of column col1 would need a
> "unknown" special value, *even if it was never used directly as an
> attribute*.

No. SUM(col1) should not care how the relation it is summing (rel WHERE col2 != 5) came into existence. This is important for closure.

-- 
Jon
Received on Fri Jun 10 2005 - 10:18:01 CEST

Original text of this message