Re: Storing data and code in a Db with LISP-like interface

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 16 Apr 2006 21:43:13 GMT
Message-ID: <RTy0g.60990$VV4.1131463_at_ursa-nb00s0.nbnet.nb.ca>


Marshall Spight wrote:

> Bob Badour wrote:
>

>>JOG wrote:
>>
>>>topmind wrote:
>>>

>
>>Obviously, missing information is a difficult problem no matter what
>>data model one uses. We currently have no theory regarding missing
>>information which means we have no theory to overcome the practical
>>problem in any data model.

>
> Well, I would propose that we understand cardinality-0 relations
> pretty well, and I think that provides a lot of value as far as
> a theoretical basis goes. (This doesn't help us when using SQL,
> though.)

I think you overstate the value of empty sets. The closed world assumption limits the usefulness of empty sets with respect to missing information.

The most common situation where people demand NULL is the situation where we know a true statement exists for some value of an attribute, but we do not know for which value.

One proposed solution for modelling such a situation is to replace the simple valued attribute that is possibly unknown with a relation valued attribute having an empty candidate key. Then, when the value is known, the relation valued attribute will have a single tuple with the known value, and when the value is unknown, the relation valued attribute will have zero tuples.

But if we accept the closed world assumption, the cardinality-0 relation says we know that no instances of the predicate are true. This, of course, contradicts the initial condition where we know some value satisfies the predicate, but we do not know which value.

And if we use this trick to model the missing information, how do we distinguish it from the situation where we genuinely know that no value satisfies the predicate?

I really see no way around knowing all of the requirements and reluctantly choosing the least among evils for each individual situation. I admit this is ad hoc and risky, but I find it less risky and no more ad hoc than the known alternatives. Received on Sun Apr 16 2006 - 23:43:13 CEST

Original text of this message