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

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Sun, 05 Jun 2005 23:57:23 GMT
Message-ID: <DjMoe.3691$F7.1513_at_news-server.bigpond.net.au>


"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:jMzoe.111207$SI7.6632478_at_phobos.telenet-ops.be...
> mountain man wrote:
>>
>> The model cannot be complicated by essences of reality.
>
> Since everything in reality can be described without them, I don't see how
> null values can be considered "essences of reality" under any reasonable
> definition of that term.

While everything in reality may be descibed in an infinite number of ways what has this got to do with simple databases? The database may also hold things in it, for example names and addresses, which are in fact elements of a "postal address reality".

What is the point of your argument?

>> In reality, information may be partial, and thus have elements
>> in it which have null values.

> You don't need null values to represent partial information.

http://www.hughdarwen.freeola.com/TheThirdManifesto.web/Missing-info-without-nulls.pdf

Thanks Paul for the above reference which I have just read.

According to this reference we can replace a null in the salary field with "Salary not known" and/or "Unsalaried". This has taken some work to do, by a database professional, to derive an "improved" version of the personnel table (when needed).

So what? The original design schema is simply missing information for these elements, and this information needs to be entered, and/or determined and entered.

Why should a qualified database professional spend time on such a problem when the only real and viable solution to this problem is to identify the missing information and then to get it into the database?

A simple workflow routine, channelling the appearances of any critical nulls (not taken care of by the constraints!) to the people in the organisation that are directlt responsible for the entry of that element of data, also fixes the problem.

Normalisation appears to be a theoretical sledge hammer trying to cover up underlying integrity issues without actually solving the integrity issue at its fundamental level. At least this is the impression I get after reading the above reference.

It's the long way around a problem, and does not in fact ultimately solve the problem of the missing information, which the original schema -- by the guidance of the RM presumeably at implementation - should have been required as mandatory.

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software
Received on Mon Jun 06 2005 - 01:57:23 CEST

Original text of this message