Re: NULLs

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:7dbb4504-dc08-48a1-b84f-a4c8e801aeb1_at_d4g2000prg.googlegroups.com...
> On Jan 5, 1:25 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "Marshall" <marshall.spi..._at_gmail.com> wrote in message
>>
>> > The connection between the model and what is being modeled is
>> > only in our head. We can consider the model without considering
>> > what the state of the real world is. Indeed, we can have a model
>> > that doesn't even *have* a corresponding real-world aspect. So
>> > when we talk about "missing" information, that's an attribute of
>> > the map between the model and reality in our head. It's not
>> > an aspect or an attribute of the model. At all.
>>
>> I disagree. With nulls there is an explicit indication that there is
>> information that exists but hasn't been supplied. It is not a matter of
>> interpretation. Without nulls, there is no explicit indication so it
>> becomes a matter of interpretation.
>
> The interpretation you're supplying may well be the one
> *intended* by the designers of SQL, and certainly very
> frequently used, but it definitely is *not* the only one
> possible. Furthermore we can use nulls without *any*
> interpretation. All we need is an operational semantics.
>
> Here's a relation:
>
> {(a=5, b=NULL)}
>
> Does the tuple with the b value being NULL specify that the
> b value for this tuple is missing, or does it specify inapplicable?
> Or does it specify that opening Christmas presents is nifty?
> What does b mean anyway? These questions are only sensible
> relative to a particular interpretation, and I haven't supplied one.
> And in addition to the option of supplying zero interpretations,
> I also have the possibility of supplying three, or eleven
> interpretations, each with different answers to
> the above questions.
>
> Your assertion that NULL is an explicit indication of xyz
> is exactly *your interpretation* of what NULL is. It is not
> an attribute possessed intrinsically by NULL.
>

Just a little quibble: I would call it a specification rather than an interpretation since it specifies how the language element, null, is to be interpreted--that is, as 'there is exactly one x in T' where x is an arbitrary bound variable that ranges over the column's domain, T, and which, for finite T, is equivalent to an exclusive disjunction that encompasses every element in T.

>
>> > If we have a set A, and for each member of A we have either
>> > zero or one members of set B, then we can do that in a system
>> > without nulls, or in a system with nulls. The question is, which
>> > way is better? The answer is, the way without nulls is better.
>>
>> You're oversimplifying: If we have a set A, and for each member of A we
>> /can/ have either zero or one members of set B, and for each case where
>> we
>> /can/ have one member of set B, a member /may/ have been specified.
>
> That is not what I specified. You are of course free to specify some
> other thing for the purposes of example, but specifying some
> other thing doesn't make my thing go away.
>

Let me put it another way. If there is a functional relationship from the elements in set A to the elements in set B, then even if the precise nature of that function is not specified, it can still be said that for each element in set A there is one and only one element in set B. Now, in a table with a nullable column (where null can only indicate that a value should have been supplied but hasn't), there is an implicit functional relationship between each key value and the elements of the nullable column's domain, just as in a relation there is an implicit functional relationship between each key value and the elements of the domains of each non-prime attribute. If you split up the table into a pair of relations, then that implicit functional relationship no longer exists because the resulting schema is identical to a schema for which there is no functional relationship. For example, after splitting the table,

R {{x = 1, y = 2, z is null }, {x = 2, y = 2, z = 3}},

where x is the key into the relations,

R1 {{x = 1, y = 2}, {x = 2, y = 2}}
and
R2 {{x = 2, z = 3}}

where x is the key of each and R2[x] IN R1[x],

it can no longer be determined that for every value for x there should be one and only one value for z. Indeed, a schema in which for some x there cannot be a value for z would be identical.

Thus whether or not there can always be a value for z, which can be easily determined given the schema containing R, becomes a matter of interpretation in the schema containing R1 and R2.

>
>> And yes, we can do that in a system without nulls, or in a
>> system with nulls. Which way is better? I'm not ready to
>> dismiss nulls simply because it is politic to do so.
>
> How fortunate then that no one wants you to.
>
>
> Marshall
Received on Sun Jan 06 2008 - 22:06:38 CET