Re: So what's null then if it's not nothing?

Jon Heggland wrote:
> In article <1133798068.172086.7660_at_g44g2000cwa.googlegroups.com>,
> boston103_at_hotmail.com says...
> >
> > > > Sorry, one cannot get more specific than defining truth table as
> > > > that's the only way to describe what the logical operations mean.
> > >
> > > Of course one can. One can define the truth table for equivalence, for
> > > one thing!
> >
> > So what ? What substance does equivalence as a logical connective add
> > to the game ? It's just another truth table, that's all.
>
> Now you really boggle my mind. One minute, you claim that truth tables
> are the end all, be all desideratum for Codd's meaning; the other, you
> say they don't have any substance!

I do not understand that, especially the part about my claiming that "they don't have any substance".

I'll try to re-phrase. The usual way to define what a logical connective is about is to provide its truth table. The truth table uses logical constants to do so. Therefore, it's immaterial whether or not the logic designer gave a complete set of such tables in order to *see* that some strings of characters indeed are logical constants.

>
> AND, OR and NOT is not sufficient to infer or define equivalence in 3VL.

It's intersting that you've mentioned that. In Lukasiewicz's 3VL, they are not, but in Kleene's style 3VL, they are. Since we do not know what 3VL variety Codd used, it would be prudent to refrain from trying to criticize him for alleged 'oversights' with respect to the 3VL.

>
> > >Or one can say "Despite using the same symbol w for both the
> > > unknown truth value and 'value at present unknown' nulls, and saying
> > > they should be treated uniformly, we treat them differently."
> >
> > Supplying truth tables carries much more weight that the vague words
>
> No, the three truth tables carry no weight at all with regard to
> equivalence.

See above.

>You can *assume* that he uses the same definition / truth
> table for equivalence as Lukasiewicz, but the text suggests otherwise,
> and he does not provide the missing truth table.

He need not if he uses Kleene's 3VL.

>
> > "they should be treated uniformly" because the latter begs the question
> > "what do you mean by 'uniformly' ?" whilst the former does not.
>
> No, *your* interpretation begs the question "what do you mean by
> 'uniformly'?". My interpretation does not.

Your interpretation is based on what ?

>
> > > > > And it seems a curious omission indeed. TTM considers boolean the *only*
> > > > > datatype/domain that *must* be supported.
> > > >
> > > > I imagine that TTM just does not need unknown because it uses the 2vl.
> > >
> > > That's not my point. The point is that a DBMS should support a truth
> > > value datatype.
> >
> > I am not sure, as I said before, that the data type is so terribly
> > important for storing data. TTM does not provide any rationale for the
> > must-be-supported data type.
>
> Constraints depend on truth values. The restrict operator depends on
> truth values. You cannot define the relational model without truth
> values.

Gee, I wonder how SQL manages to define constraints, then. The values are used implicitely, you've not provided sufficient rationale for storing them in the database.

>
> > > You have a SQL table with a (3VL) boolean column. You want to put NULL
> > > (UNKNOWN) into one row, and NULL (missing) into another.
> >
> > Forgetting for a moment about you bizzare insistence on calling a
> > non-Boolean value Boolean,
>
> Then suggest another name you'd prefer I use. I've asked you for such a
> name three or four times. I'll call it Lukasiewiczian, if you don't come
> up with anything easier to type.

Why not call it a logical value ?

>
> > if I were to store a 3VL constant I would
> > just do so regardless of what's it called NULL, UNKNOWN, 1/2, or
> > something entirely different.
>
> "Just do so", as if by magic? Please. If NULL is used both as 'missing'
> and as a normal value for a data type, how do you formulate your DML
> statement?

Please provide an example of a statement that one cannot formulate if NULL is used as a logical constant.

>
> > > > > I'd agree if Codd hadn't used the same symbol for reasons of uniform
> > > > > treatment.
> > > >
> > > > "Uniform" is indeed an unfortunate word here.
> > >
> > > What do *you* think it means?
> >
> > I have no clue.
>
> But you are certain it does not mean what I think it means? Why, if you
> have no better alternative?

How do you know what it means ? Codd did not dwell too much on what he meant by it.

>
> > > No. He doesn't define equivalence;
> >
> > So what ? It's enough to define a *single* truth table, say, for
> > AND, and it would have been clear that the strings he uses {true,
> > false, w} are indeed logical constants.
>
> Irrelevant. They may be logical constants, but that has no bearing at
> all on whether or not he uses the conventional 3VL equivalence relation.
> In fact, as I may have said before, the text suggests that he doesn't.

What do you mean by "3VL equivalence relation" ? '<->' is not a relation.

>
> > > AND, OR and NOT is not sufficient. He
> > > could very well have envisioned an equivalence truth table where w<->w
> > > is w, not T.

Then he would be using Kleene's 3VL. We just do not know since he never had need to define or use '<->' anywhere. Besides, I hope you realize that whilst 'w<->w' may be defined as evaluating to UNKNOWN, 'w=w' always evaluates to TRUE by virtue of being a logical constant denoting the same thing/notion.

>
> > It's unclear what use such connective ['<->'] might have.
>
> No, it's very clear. "Truth values can be stored in databases and we
> want the treatment of all unknown or null values to be uniform."

What has the '<->' connective got to do with the idea of storing logical values in the database ?

>
> > > It is strange to suggest that a DBMS should have the capability to store
> > > the result of the evaluation of a condition?!
> >
> > What utility storing "the result of the evaluation of a condition"
> > might have except leading to data redundancy ? Presumably, all the
> > true facts are already in the database.
>
> Orthogonality, completeness, simplicity, power.

Please, elaborate on each of the those four words.

>
> > > For the exact same reason that we don't call zero NULL for the integer
> > > domain.
> >
> > Not calling zero NULL is a matter of convention/tradition, nothing
> > else.
>
> And you don't see any problems at all if we called zero NULL in SQL? I
> am beginning to find it hard to take you seriously.

That's your problem. You did not specify the context or in other words did not mention that you wanted to use the word NULL *both* to represent the integer 0 *and* to represent a missing value in the same domain which is clearly impossible, and now you blame someone else for your failure to comunicate what exacly you've meant.

>
> > >Come on, you should substantiate your claims.
> >
> > A very simple example, integer 3 and 4 are not the same as rational 3
> > and 4 for obvious reasons, and yet using the same name for both does
> > not cause any confusion. Why using NULL as logical constant and NULL
> > as 'missing value' should present a problem ?
>
> Your example is disingenuous. Integer 3 is not the same as 'missing', so
> using the same name for both *would* cause confusion.

If using the same name for different entities (3I vs. 3R) belonging to different domains is OK in one case, why is it a problem in the other ? NULL in Codd's 3VL does not denote a missing value, but rather a logical constant, so there should be no confusion as long as one knows in what context the name NULL is used.

>
> Does "SET SomeAttribute = NULL" mean setting it missing, or setting it
> to a "logical constant"? (Or the empty string, or zero, depending on the
> declared type of SomeAttribute.)
> --
> Jon
Received on Tue Dec 06 2005 - 20:21:00 CET