Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Does Codd's view of a relational database differ from that ofDate&Darwin? [M.Gittens]

Re: Does Codd's view of a relational database differ from that ofDate&Darwin? [M.Gittens]

From: Alexandr Savinov <savinov_at_host.com>
Date: Mon, 06 Jun 2005 17:07:02 +0200
Message-ID: <42a466a8$1@news.fhg.de>


Paul schrieb:
> Alexandr Savinov wrote:
>

>>The situation with NULLs clearly demonstrates some serious problems of
>>the relational model. I personally do not see any problem with NULLs but
>>I am not thinking in terms of relational model. I've read this paper
>>
>>http://www.hughdarwen.freeola.com/TheThirdManifesto.web/Missing-info-without-nulls.pdf
>>
>>
>>and I am really surprised - it provides completely unacceptable
>>"solution" - it compomises the whole relational model IMO. NULL values
>>have an absolutely concrete meaning and it does not matter how we call
>>them after that. And this meaning, the things with such a semantics, is
>>the basis of the model. This semantics can be expressed as "the absence"
>>of thing. Any model starts from empty state before it can be populated
>>with other kind of things and this initial state is strongly associated
>>with the semantics of absence. If something disappears, if something is
>>deleted then acutally we get null.

>
>
> But the absence of something is done at the row level, not at the
> attribute level. If a proposition is true, it gets represented by a row
> in a table of the database. If not, it is absent from the database.

Yes, you are right, especially from the point of view of logic where we consider rows as statements. But existence and presence of things can be viewed as follows. Objects (rows) need to exhibit themselves somehow in order exist. There are two ways how it can be done: 1. using references (or some other kind of a dedicated representation mechanism like names or primary keys),
2. using object contents (by value).
Both mechanisms have their advantages and disadvantages, which will not be described here. Assume now that we have only the second mechanism. In this case if an object has all nulls in its description then the whole object is qualified as null and non-existing. Formally, it is NULL. In other words, we may take our special NULL element and then add to it more fields (dimensions) with NULL values and it will be still the same NULL object. If some dimension is not NULL then the object exhibts itself in this way. One way to delete objects consists in assigning all NULLs to its fields.

If we use only the first mechanism (object life cycle is defined by its reference) then NULLs do not play so important role (in contrast to theory). However, in practice these two mechanisms should be connected. These means that we need to specify when an object has to be really deleted (by removing its reference) depending on its NULLs. It can be implemented as constraints.

> Here's some discussion of a very concrete example of a NULL problem in
> SQL: http://www.firstsql.com/iexist2.htm
>
> The author says that his RDBMS solves this problem though, and that is
> just a problem with SQL and NULLs, not with the relational model and NULLs.
>
> Are there any rebuttals of this claim that anyone has? Any concrete
> examples of logical inconsistencies caused by NULLs?

The main problem with NULLs is that they have very concrete meaning however RM does not rely on it heavily. As a consequence everybody uses NULLs as a convenience technique by overloading its formal semantics. For example, in the above article (http://www.firstsql.com/iexist2.htm) the authour write:

"The null in the row (S1,P1,NULL) means value unknown; in other words, supplier S1 does supply part P1, but the relevant quantity is not known, missing."

Interpreting NULL as UNKNOWN is a typical and the most serious problem because UNKNOWN has also special and very concrete meaning. If NULL means "nothing (is possible)" then UNKNOWN means "everything (is possible)". In terms of possibility distribution this means that NULL is constant 0 while UNKNOWN is constant 1. UNKNOWN can be useful only in deductive databases while NULL is useful in normal databases.

Problems with NULLs appear when users start using NULL as a convenience method for encoding their own semantics (unsalaried, partially salaried etc.) The result is that DBMS has its own interpretation while users may get their own interpretation.

> I guess the other claim against NULLs is that they make things more
> complex and less intuitive, which is a more subjective point. You could
> argue that Darwen's method of avoiding NULLs is more complex that using
> NULLs in the first place.

May be the method of avoiding NULLs at all is not so bad taking into account possible errors. In other words, once NULLs cannot be used appropriately it is more reliable to disable them at all. In this case I would probably also adivce to implement any custom special states and values by using dedicated fields rather than reusing NULLs. It is then the database that uses the mechanism of NULLs for its internal purposes without intervention of users. However, from theoretical point of view we need to eventually understand what NULLs mean and how they have to be used.

-- 
alex
http://conceptoriented.com
Received on Mon Jun 06 2005 - 10:07:02 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US