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

Alexandr Savinov wrote:
> David Portas schrieb:
> > Alexandr Savinov wrote:
> >
> >>David Portas schrieb:
> >>
> >>>Alexandr Savinov wrote:
> >>>
> >>>
> >>>>JOG schrieb:
> >>>
> >>>
> >>>>But what if some
> >>>>other object we need to add is known in advance to have no colour at
> >>>>all? A formal criteria for "does not have a colour" is that we do not
> >>>>want to see it when we select objects along dimension COLOUR.
> >>>>
> >>>>Theoretically, we might define such a structure of tables that this
> >>>>situation is excluded. Practially, it is almost impossible so we need to
> >>>> permit null value as an indication that some column is inappropriate
> >>>>for this object (and this object will be invisible from the side of this
> >>>>column).
> >>>>
> >>>
> >>>
> >>>If an "object" lacks the attribute of colour then surely it ought to be
> >>>modelled by a relvar that doesn't have a colour attribute. Can you
> >>>explain why this would be "almost impossible" given that you also said
> >>>this fact is known in advance?
> >>
> >>I meant that it is practically impossible taking into account complexity
> >>of real-world systems. The final design where null values will be made
> >>unnecessary may well be too granular (many tables with a few or even
> >>only one column).
> >>
> >
> >
> > This is the heart of the problem you have in mind I think: That a model
> > without nulls is more expensive to implement than one with. In many
> > current database products that is true, but it isn't a fundamental
> > objection. It says more about those database products than about the
> > theory.
> >
> >
> >>Another reason is that we may well lack information about our problem
> >>domain so that we cannot guarantee that objects will have all attributes
> >>assinged to them in our schema. For example, assume that we have table
> >>Persons with the company employees. But today we had to hire a Marsian.
> >>Are you sure that it will have such a characteristics as sex? Maybe if
> >>we ask him then it will answer that he does not understand what we are
> >>talking about. Should we then take Marsians into account when we count
> >>the number of women and men in the company?
> >>
> >
> >
> > If your reality changes then your logical model of it does too. This is
> > entirely to be expected. Nulls don't change the picture.
>
> One point is that it is always to predict especially about future. So
> that any model allows for some degree of flexibility. We cannot hard
> code into its structure all possible situations.
>
> But even if it would be possible there is another (fundamental) problem.
> We need nulls. It is a very important mechanism of data modeling. We
> need to somehow designate the fact of absence of an object. So nulls
> cannot be avoided -- they can be only ignored, hidden or discredited.
> Because NULL IS A FACT OF ABSENCE OR NON-EXISTENCE.
>
> >>And the third reason is theoretical. Independent what happens in
> >>practice we would like our theory (data model) be general enough to
> >>explain very exotic cases. This inclues such extremes as one wide table
> >>with all possible columns and many narrow tables with a few columns.
> >>
> >
> >
> > That is a pretty bizarre argument. The relational model is general
> > enough to represent entities with any non-negative number of
> > attributes. It doesn't need nulls to do this. The question of
> > "explaining" tables with all possible columns or with few columns
> > doesn't arise. We model the real world facts - we don't model tables.
>
> The problem is that there exist different equivalent design for each
> real world problem domain (a set of facts). So the problem is what
> concrete structure of tables to choose. One schema might be very simple
> but needs sparse values (a lot of null values). Another schema has many
> tables. But note again that all of them are equivalent because have the
> same number of dimensions by means of which we position our objects. The
> difference is the way how we pack our facts, in what kind of container
> structure.
>
> What people cannot understand is that we cannot simply disable nulls. It
> is too simplistic point of view. It is not possible to say that we will
> not use nulls and that is all. Why? Because the notion of absence exists
> in almost any data model. We need to know if an object exists or not. If
> yes, then we get some value. If not then we get null.
>
> Currently the null construct is only a primitive mechanism for dealing
> with absence. Namely, we use nulls when we want to store the fact of
> absence of *primitive* values. However, in general case all types of
> objects---not only primitive values---can be absent. So in a good model
> the notion of absence has to be formalized by means of a first level
> construct. It is an illusion (simplification) that we can build a model
> without a mechanism for expressing the fact of absence.
>
> --
> http://conceptoriented.com

You are making some abrupt changes of terminology and reference - or maybe we were always talking about different things! I might accept that there may be a need for nulls in some "object oriented data model" - a model which you haven't yet named or described. Not so in the relational model. That was my point. Nothing stops you representing *facts* about "absence" or "non-existence" in the relational model (without nulls). 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.

-- 
David Portas 
SQL Server MVP 
--