# Re: NULLs

Date: Sun, 06 Jan 2008 21:06:38 GMT

Message-ID: <ypbgj.33945$JD.19748_at_newssvr21.news.prodigy.net>

"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