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

From: Alexandr Savinov <spam_at_conceptoriented.com>
Date: Fri, 18 Nov 2005 18:16:30 +0100
Message-ID: <437e0c7f$1_at_news.fhg.de>


David Portas schrieb:
> Alexandr Savinov wrote:
>

>>These unnecessary slots need not be filled in because initially they are
>>nulls. If we do not specify a value for an entity then it can be also
>>assumed to be null. Another reason is that even if we need to do it then
>>it can be automated. The thirds reason is that it is not clear what is
>>more difficult: to fill in "unnecessary" slots or to insert a huge
>>number of "unnecessary" link records in intermediate tables and
>>auxiliary columns. It is always a trade off. So I think that
>>1. using null values, and
>>2. using intermediate link records
>>are things of the same level. These mechanisms are *both* of crucial
>>importance and in some sense they serve the same purpose. The difference
>>is only in physical packing. In the first case we write null value in
>>slots while in the second case we use intermediate link records
>>(non-primitive entities which reflect the existence). If we are setting
>>non-null value to an attribute then in the second case it is equivalent
>>to inserting one (or more for more complex relationships) link record.
>>If we set to null some attribute then in the second case it is
>>equivalent to deleting some link records.
>>

>
>
> When you say that both methods are equivalent you are ignoring an
> absolutely crucial point about nulls - that they are not values. That
> is, they don't have some fundamental and important properties that we
> require other values to have. For this reason, using nulls is NOT
> equivalent to some other system for representing missing data if that
> other system uses values and values alone. In particular, if you allow
> nulls you will have to modify your system of types and evaluation rules
> in order to support nulls as "special" data (data that is not a value).
> This is the reason that nulls violate the Information Principle in RM.

I wanted to say that
- assigning null value, and
- deleting a link record
is one and the same (in the context of our discussion). If we set some attribute to null then we say that this object has nothing to do with the value object - we delete the relationship between them. Alternatively, if the relationship is implemented via an intermediate table, we will need to delete one record from it. And agin we say that the source record has nothing to do with the target value record.

The equivalence more clear if we use add/remove or relate operations insteand of insert/delete. Then we do not know what attribute and values are. Instead we can relate records by adding them to other records and removing them. In this case we hide the implementatin mechansim which can be either primitive null/non-null values in slots or complex intermediate records.

What null means for object and its value, that the physical absence of a link record means for a pair of linked objects. In other words, adding/remove a link record is equivalent to assigning non-null/null value.

> Coping with special data has major implications for your data model. It
> is precisely because of the complexity of solving this problem that
> values are preferred to nulls.
>
> At any rate, I think you have acknowledged that nulls are an optional
> feature. We can ALWAYS model ALL information without them, including
> information about missing data.

Yes, I acknowledge that we can deal with data without nulls but such an approach would be very restricted and inconvenient. It is as optional as using link records to establish relationships. We also can create a model without link records.

-- 
http://conceptoriented.com
Received on Fri Nov 18 2005 - 18:16:30 CET

Original text of this message