Re: 3 value logic. Why is SQL so special?
Date: Tue, 19 Sep 2006 14:01:10 GMT
Message-ID: <GKSPg.22866$9u.274032_at_ursa-nb00s0.nbnet.nb.ca>
peter koch wrote:
> Bob Badour wrote:
>
>>peter koch wrote: >> >>>Bob Badour wrote: >>> >>>>Chris Lim wrote: >>>> >>>>>Roy Hann wrote: >>> >>>[snip] >>> >>>>Then why have I had to spend so much time in my career explaining to >>>>reasonably intelligent people why their queries returned the wrong answer? >>> >>>[snip] >>> >>>>I must insist you back up that statement quantitatively and >>>>qualitatively. It is far easier to deal with two names than with >>>>surprisingly inconsistent semantics for the same reason it is far easier >>>>to deal with a compile-time error than a run-time error. >>> >>>[snip] >>> >>>> But a >>>> >>>>>database without NULLs? It might be theorectically correct, but it >>>>>would be a nightmare to write queries against. >>>> >>>>I disagree. My personal experience dealing with scores of intelligent >>>>database users suggests that NULL is the nightmare. >>> >>>All these arguments against NULL are only valid against some specific >>>implementations of that concept - here SQL in its various dialects. >>>They are not arguments against the concept of having null-values (e.g. >>>to represent unknown values) in some database system. And this is >>>comp.databases.theory after all. >> >>I have found the arguments against 3VL and NVL for N > 2 compelling. For >>example, if DEE and DUM are canonical relations for true and false, what >>are the canonical relations for the other logical values?
>
> Other logical values? I believe I miss your point here.
What is NULL if not the basis for 3 valued logic or 4 valued logic?
If we can agree
> that there is a basic boolean type which can take the values true and
> false (this is all we need in order to create other, more complex
> types), there could be a nullable type named e.g. nullable<boolean>
> consisting of a pair of booleans.
Can we agree that the algebra of nullable<boolean> is not boolean algebra and is not 2-valued logic? Similarly, we can create a string type or an integer type whose algebras are neither boolean algebra nor 2-valued logic.
> If you prefer to see this as tables/relations this is alright with me -
> but why on earth the names DEE resp. DUM - and how do you describe
> anything at all if the logical types are not primitive?
Relations are primitive in the relational model. DEE and DUM are the values of a canonical relation type.
>>We currently have no theory that I am aware of for dealing with missing >>information. At this time, I cannot even imagine what such a theory >>would look like because science and the scientific method have such >>strong roots in empiricism. Hopefully someone much smarter than me will >>come up with a sound one, though.
>
> That I do not understand either. Somewhere else in this thread you gave
> an example where missing information was involved. Do you mean to say
> that that example was meaningless?
No, not at all. My example demonstrated a succinct syntax for explicit expression of how to treat missing information in a specific context. The example was basically an explicit override of the default closed world assumption. The example used neither defaults nor markers.
>>The whole point of NULL is to have something other than a value to >>represent missing information. To use a value to represent unknown, what >>we really need are extensible data type systems that as much as possible >>enforce consistency. For example, if SUM is an aggregate of +, an >>extensible data type system should enforce consistent semantics + >>semantics for SUM.
>
> I would say that "+" was defined with respect to a type (or a set of
> types) and that SUM (in its least generic form) must be defined in
> terms of +.
How does saying "one defines it with respect to a type" change what I said about using a data type system? It sounds to me like you agree vehemently.
Of course since for a given type T, nullable<T> extends T
I don't necessarily agree. Whether one creates a union type as a proper supertype of T or a disjoint type is a matter of design. In both cases, one extends the type system but only the former extends T.
> and depending on both nullable and T the meaning of SUM could be given
> different interpretations (as could SUM also for a given T)
If one expresses the semantics of SUM as an aggregate over + with identity element 0, the type system will enforce consistency. Of course, since SUM and + are merely symbols, one could express entirely different semantics (as questionable as doing so might be.) Received on Tue Sep 19 2006 - 16:01:10 CEST