# Re: Two-valued logic

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Tue, 30 Dec 2003 11:07:48 -0600
Message-ID: <bssbd7\$gr3\$1_at_news.netins.net>

> Dawn M. Wolthuis wrote:
>
> > I work with a model that uses a two-valued logic. A NULL value under
this
> > scenario can be handled logically as a null set value. With this model,
a
> > NULL then = a NULL because a null set equals a null set..
>
> Is your use of the indefinite article ('a two-valued logic')
> significant - that is, does the model you work with use one of a
> number of possible two-valued logics, but by implication not the
> familiar Boolean (Aristotelean) logic? (I'm just nit-picking, unless
> the answer is that 'a' is significant - but then I'm very puzzled!)

Sorry for the lack of precision -- I was just talking to a mathematics historian who is writing about Boole and told me that associating Boole with two-valued logic is not accurate (or something like that). In order to avoid any discussion about whether two-valued logic should be termed Boolean, I avoided that, but YES, what I meant was two-valued Boolean logic.

>
> I don't dispute that null sets are equal. What does puzzle me is how
> you are storing a null set (as an alternative to some sort of NULL
> marker) in a single-valued attribute. Or are all attributes in
> relations actually set valued?

In this model (Nelson-Pick), one can consider every value a set, thus a null value can stand for the null set and the value of "12345" can stand for {"12345"}. This is simply one way to model it, but it is the one that makes it the most clear to relational theorists why it is OK to view null as a value such that null = null.

> > My impression from reading Date and others is that the three-valued
logic of
> > SQL that is proliferated in RDBMS's does not have a lot of fans.
However, I
> > don't know if that is really the case or if I just happen to be reading
the
> > pro-two-valued logic folks.
>
> Date would argue that SQL DBMS are not RDBMS (or, at any rate, not
> TRDBMS, where the T stands for True). However, that's nit-picking, again.
>
> I don't like 3-valued logic; it is harder to do right than 2-valued
> logic. There are undeniably occasions when the value represented in
> SQL as a NULL would be better represented by an empty set.
>
> If you want to find a proponent of 3-valued logic, look at some of Don
> Chamberlain's books on DB2/UDB -- at least one of them contains a
> defense of 3-valued logic as found in SQL, and it is moderately
> clearly a riposte to some of Date's arguments.
>
> > Who is out there that will still defend three-valued logic within
databases
> > and suggest that it is a better strategy than using a two-valued
approach?
>
> Not me.
>
> > Would it be accurate to state that most database theorists agree that a
> > two-valued logic provides significant benefits?
>
> The proponents of 3-valued logic argue that the performance benefits
> claimed for 2-valued logic over 3-valued logic are over-stated. I've
> not done the experimentation to justify that. The clarity of 2-valued
> logic is better than 3-valued logic. The rules (and things like
> tautologies) are more familiar, so people would probably make fewer
> mistakes using a 2-valued logic. And when an empty set is appropriate
> as the 'unknown' answer, using an empty set instead of a third logic
> value would be a lot more sensible.

Agreed! --dawn

> --
> Jonathan Leffler #include <disclaimer.h>