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

David Portas schrieb:
> Alexandr Savinov wrote:
>

>>>An RDBMS as a set of know facts. If I have dogs with
>>>and without colour then I have at least two relvars one with and one
>>>without a colour attribute. If I need to distinguish between colourless
>>>dogs and dogs of which I don't know the colour then I add an attribute
>>>to indicate that fact. I don't need to add a null.
>>
>>Sometimes you need. For example, if you are not allowed to create more
>>tables.

>>Such design can be more or less attractive but nothing changes
>>semantically: removing an attribute from a table (into the second table)
>>  and storing nulls is one and the same thing.

Maybe, so what do you propose?

>>For example, assume you
>>create a separate table T2 for colourless dogs because you do not want
>>to write nulls into T1 (where normal dogs are stored). What if you now
>>ask: what colour has a dog from T2 (a colourless dog)? RM says that this
>>question does make sense so it is illigal (effectively it prohibits such
>>questions from being asked). But I think it is more natural to answer:
>>the colour is null.

User and developers are not part of a data model.

>>Thus adding new table does change anything except
>>that it imposes addition constraints on objects in T2 (they physically
>>cannot be assigned a colour which is guaranteed to be null). Right?
>>
>>Another example, we have two tables Apples and Oranges with different
>>attributes. Ask a question: What value takes an Orange attribute for an
>>object from Apples? Again my answer is null. Having two tables is only a
>>structural constraint and nothing else. We can get an equivalent design
>>with only one tables and combined set of attributes.

What would be a key is another problem because it belongs to identity modeling rahter than entity modeling (in RM it is in great extent one and the same).

> the high level of redundancy in your "super-table" and the extereme

It is not my table. I am not proposing to use it or this design. This example is used exclusively for demonstration purposes in the context of this thread. In particular, we do not discuss redundancy issues, performance issues etc. We discuss null values and their semantics in data modleing (not in relational model).

> difficulty of applying constraints to such a design I would say that,
> except for trivial cases, this probably *cannot* be equivalent to a
> normalized relational data model. Integrity is fundamental. You can't
> forget integrity and then say the two models are equivalent.

I did not forgot integrity. We simply do not discuss it in this thread.

I just claimed that nulls reflect non-existence or absence of a thing/fact as such (not necissarily a primtive value). You can delete a thing physically or, equivalently, you can use null for that. It is one and the same because effectively it will not be visible. Why do we need to mark things/facts as absent by means of nulls if we can simply delete them physically? Because things exist in multidimensional hierarchical space so they exhibit themselves in a more complex manner than exist/non-exist. And of course it is differs from what RM teaches.

-- 
http://conceptoriented.com