Re: Date, Darwen, Pascal and the alternative to Nulls in the RM



"Paul Mansour" <paul@xxxxxxxxxxxxxxxxx> wrote in message
news:1142991689.461215.270180@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Assume one accepts, as I do, the argument against nulls put forward by
Date et al. Would it be fair to say that at this point in time they
really don't have a solution to missing information?


Its outside their theoretical scope.


In the latest edition, just published, of the Third Manifesto (TTM)
Date and Darwen do not include any recommendations on handling missing
information other than pointing to a set of PowerPoint slides by
Darwen, dated 2003. In fact, as the years go by, each of Date's
books seem to have stronger and stronger proscriptions against nulls,
and fewer and fewer ideas about how to handle missing information. The
fact that at least 3 years after Darwen's slides on distributed keys
they still did not include the concept in the new TTM book seems a
pretty clear indication that they are really not that confident in the
concept.


They lack any form of viable reality check in their theorising.


Meanwhile, Pascal has 2005 paper "The Final Null in the Coffin",
which seems a bit prematurely named (I haven't read it yet)
considering the fact that it is advertised on his website as only a
starting point or recommendation on how to avoid nulls, and that much
research needs to be done.


The only way to avoid nulls is to avoid change management.
That's it really. End of story. Change management will eventually
breed the occurrence of nulls.

As change management is not incorporated into their theories,
they are able to sustain a static rant endlessly. Nothing much has
changed in the 30 years concerning their RM mantra.

Look at it as a 30 y/o cultivated blind eye.



So, where does that leave an implementer who does not want to implement
nulls? The leading theorists don't seem to have answers. Their
proposed solutions may well cause more long run damage, just as nulls
did, to the relational model. From nulls to special values, the
proposed cures to missing information may well be worse than the
disease. At this point in time, it seems that the prudent implementer
would prohibit nulls, and essentially leave it up to users to design
well, avoiding inapplicable information, and using application logic
where necessary to handle missing information . Obviously this is not a
good solution, but Date, Darwen and Pascal can't seem to offer
anything better. Am I wrong here?


They lack integrity of experience in change management.
They dream in a land of perfect design and no changes.
Their world and your world are two separate universes.

My advice is to engineer provision within a database
environment for the routine (automated) identification
of specific data integrity exceptions, which will include
the problems associated with nulls, but not restricted
to this class of data integrity issues, and may include
application related integrity exceptions [unless you write
or purchace software which is always perfect].

It is important to design this data integrity exception
management system in such a way that the users
themselves perceive its benefits, and maintain its
evolution through all change management scenarios.

There is no generic theory for this yet, neither for change
management, neither for the consideration of the
union of the data and the code. (The RM looks
cycloptically at the data exclusively).


The above theorists are too busy elsewhere chasing the
elusive non existent nulls, and writing commentaries
upon commentaries upon commentaries.

What's new?





--
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
http://www.mountainman.com.au/software/Theory_of_Organizational_Intelligence.htm





.



Relevant Pages

  • Re: All hail Neo!
    ... Bags and nulls are quite apparently not but from where I am now the null at least seems the lesser of evils viz my post in the "beautiful mind" thread. ... With null or without logical identity, ... If the practitioner never considers where the pitfalls lie, he will only discover them from the bottom of the pit. ... They have correctly identified that missing information as of yet has no theory to address it. ...
    (comp.databases.theory)
  • Re: Examples of SQL anomalies?
    ... If you don't spend enough time on design, ... NULLs are only one way to deal with missing information. ... I tend to believe that interpretation of the meaning of data should be ...
    (comp.databases.theory)
  • Re: Examples of SQL anomalies?
    ... If you don't spend enough time on design, ... NULLs are only one way to deal with missing information. ... the introduction of flag ...
    (comp.databases.theory)
  • Re: SQL WHERE help
    ... "Tom Ellison" wrote: ... > want some other rule for averaging missing information. ... > have missing information allow nulls. ... >>From this table I made a simple query that shows averages for each column. ...
    (microsoft.public.access.queries)
  • Re: Date, Darwen, Pascal and the alternative to Nulls in the RM
    ... breed the occurrence of nulls. ... As change management is not incorporated into their theories, ... upon commentaries upon commentaries. ... I agree that theorists work in a pure, ...
    (comp.databases.theory)

Loading