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

From: Paul <paul_at_test.com>
Date: Mon, 06 Jun 2005 17:01:07 +0100
Message-ID: <42a47344$0$8715$ed2619ec@ptn-nntp-reader02.plus.net>

Alexandr Savinov wrote:
> Assume that we have a set of 3 values S = {1, 3, 10}. We want to
> aggreage them and apply some function func: A = func(S). Do we have a
> problem? No. Now remove some item from the set so that we have S = {1,
> 3} and then apply again the aggregation function. Do we have a problem? No.
>
> Having null values is actually a way of removing data items from
> consideration. In this example we apply the aggregation function to the
> set {1, 3} which is equivalent to applying it to the set {1, 3, null}.

Wouldn't it be "1 + 3 + unknown", say, which should be unknown also?

>> Why not say then that all aggregates that involve a NULL return NULL?

>
> It is possible but I do not find it very natural because we need the
> properties of NULLs and aggregations to be consistent with other
> properties of the model being developed. We cannot say "let's do it so"
> - but need to have a kind of global consistency. For example, take a row
> <1, 3> and then consider this point in 3-dimensional space by adding one
> new dimension. How it will look like (represented)? I find it very
> natural to write it as follows: <1, 3, null>. This actually says that
> this object does not exist in this dimension, it is not visible, it
> cannot be counted or aggregated.

To me it says we know the x & y coordinates but at the moment the z coordinate is unknown. So if we are working with a geometric projection that collapses the z axis, we have perfect knowledge. But if we need the z coordinate, everything becomes unknown.

Paul. Received on Mon Jun 06 2005 - 11:01:07 CDT