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

Jon Heggland wrote:
> In article <1133896860.912140.197720@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> boston103@xxxxxxxxxxx says...
[...]
> > What has the '<->' connective got to do with the idea of storing
> > logical values in the database ?
>
> create table test ( a boolean, b boolean );
> select * from test where a = not b;
>
> '=' here obviously means equivalence, not equality.

Yes, that's a reasonable interpretation.

>
> > > > > 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.
>
> You don't know what they mean? That does explain a few things.

Sure, I know what the words mean in a specific context, but throwing
them around in a technical argument smells a bit of marketing talk.

>
> Consider this example:
>
> create table test2 ( a integer, b integer );
> select * from test2 where (a < 12) = (b > 15);
>
> This query is a syntax error in SQL, or at least in Oracle. You can
> reformulate the condition to an equivalent, syntactically allowed
> expression, but why should we have to?

Apparently, the language designer(s) decided that the demand for the
built-in equivalence won't be stong enough. Besides, it's trivial to
write a custom function in major SQL dialects that implements any of
your favourite connectives missing from the vendor-supplied set, as it
is equally trivial in any major PL. Can you name many PLs that support
equivalence (biconditional) ?

> Do you know how hard (and
> embarrassing) it is to teach SQL, due to its lack of consistency,
> orthogonality and lack of adherence to simple language design
> guidelines? Do you know how hard it is to create a parser for SQL, for
> the same reasons? But this is a different discussion.
>
[...]

> > > > 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,
>
> Hey! This may actually have been enlightening. Let me try to summarise
> your position:
>
> 1. Logical values don't need to be stored in the database.

I do not see a compelling reason to, yes, but I'd be glad to be
educated by my betters in case I am missing something.

> 2. If we nevertheless were to store 3VL logical values in a database, it
> makes sense to use NULL for UNKNOWN.

Not quite.

It makes sense to use any words you like to represent more truth
degrees than just two. If you need more truth degrees (interpreted
according to your needs), naturally, you have to use more truth values
to represent those truth degrees. Additionally (or in the first
place), you have to extend your various data domains with desired
markers to represent missing, unknown, or some other values besides
non-pathological values. The names for such markers may be the same
as, or different from, the logical truth values. Also, you'd want
to extend various predicates (e.g. equality, greater than, etc) so
that they would accepte the new markers as arguments and produced truth
values that make sense in your model.

Alternatively, you might not want anything of the kind and just do
what Date and other relational purists suggest one should do.


> 3. Attributes of the type "(3VL) logical value" cannot be 'missing'
> NULL, only UNKNOWN NULL.

They can mean anything that makes sense in your model. In particular,
if it makes sense, the 3VL NULL (or if you choose the name UNKNOWN) can
represent the notion of undefined, senseless, contradictory,
whatever you have in mind. By themselves, they represent nothing but
a bunch of symbols and rules to combine them into WFFs.

[...]

> > and now you blame someone else for
> > your failure to comunicate what exacly you've meant.
>
> FWIW: You have also failed to communicate that you mean to forbid the
> usage of NULL for 'missing' when you use it for something else.

You've apparently misundestood me. What NULL or any other symbol means
is irrelevant as long as they unambiguously denote things/ideas in
various domains. So, you can choose to use NULL both to represent a a
missing value in one domain and an unknown or undefined logical outcome
in another domain. If it's confusing, then just use different symbols
in order to avoid such confusion.

E.g. you might have a mini-integer set INT ={0,1,NULL} with the usual
operations extended so that they could accept NULL. Also, you might
have a 3VL domain L = {TRUE, FALSE, NULL} Also, you might have
defined the equality or whatever predicate whose domain is INT and its
co-domain is L. Now, obviously, INT.NULL is not the same as L.NULL,
they have different rules of game and represent different notions
(existing in you mind). If you find using NULL confusing in a
situation like that, by all means, using different names, e.g.
MISSING for the former and UNKNOWN for the latter.


>
> > 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.
>
> Very well, but that precludes the use of 'missing' NULL for "logical
> value" attributes.

See above.

> --
> Jon

.

Relevant Pages

  • Re: So whats null then if its not nothing?
    ... > This query is a syntax error in SQL, ... educated by my betters in case I am missing something. ... > makes sense to use NULL for UNKNOWN. ... It makes sense to use any words you like to represent more truth ...
    (comp.databases.theory)
  • Re: So whats null then if its not nothing?
    ... token indicating a missing value. ... > not a requirement for a data model, ... > special handling of unknown values. ... > As far as my take on "SQL vs. PICK", ...
    (comp.databases.theory)
  • Re: So whats null then if its not nothing?
    ... >true/false column that can have nulls in it which gives us a 3VL so ... but that means that an unknown equals another unknown. ... the three truth values True, ... well as the "missing value indicator" NULL. ...
    (comp.databases.theory)
  • Re: Why does 1:3 relationsihp require another table?
    ... that makes it always violate 1NF when it's allowed? ... >desire to make NULL a good representation of a real-world unknown more than ... >implementation of NULLs in SQL, then SQL avoids far too many kinds of ... >missing information which is quite common in the real world. ...
    (microsoft.public.sqlserver.programming)
  • Re: So whats null then if its not nothing?
    ... Hugo Kornelis wrote: ... >>> rules that form the foundation of SQL is this ... See the original Codd's truth tables. ... denote both NULL as a missing/unknown value and UNKNOWN as a truth ...
    (comp.databases.theory)