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

Bob Badour wrote:
> Marshall Spight wrote:
>
> >
> > If we have a requirement to distinguish between
> > exists-but-we-don't-know
> > and doesn't-exist, then the cardinality-0 model is insufficient. But
> > there
> > are also cases where we won't need to so distinguish, and cases
> > where doesn't-exist is not a possibility. In those cases, I would
> > propose that cardinality-0 is often a better choice than SQL's NULL.
>
> Yes, well, you are not putting the bar very high. Now, are you? Besting
> SQL's NULL for handling missing information is rather like tripping over
> a shoelace.
>
> The closed world assumption is going to bite you more often than you
> seem to suppose. Presumably, if you have a relation valued attribute,
> you intend to use the relational algebra or calculus on it. However, the
> closed world assumption is central to both which means they will yield
> incorrect results in many cases unless the user takes extraordinary
> measures to account for the not-quite-closed nature of the model's world.
>
> One must consider those consequences when considering relation valued
> attributes as a means to describe missing information.

I do not disagree, but I'm not sure if I'm seeing all the consequences you refer to. I agree that how the algebra behaves is important.

Lame example:
Given a Persons relation with an Age attribute. (I know it is better to have a Birthdate attribute, but for this artifical example, this will
suffice.) The Age attribute is an RVA of a single int attribute with an empty key (that is, it is either an int or empty, indicating we don't
know the age.) If we wanted to calculate the average age of Persons, and we took sum(Age) / count(Age), (waving my hands around the nest/unnest issue), then it would seem to me that what you would most likely want to know is, of the people for whom the age is known, what is the average, which is exactly what I'd expect the RVA-Age schema to give you.

> Considering that the method basically uses the relation type generator
> to inject a new type for the attribute, I can imagine other type
> generators that would provide a more appropriate set of operations for
> the resulting type.

Yes. I propose that there ought to be a wider set of choices for attribute types, including RVAs, the subcase of RVAs that you described as having an empty key, which is sometimes called "option types", and tagged unions or "sum types" which I mentioned.

I think that although these add complexity, they also add a lot of value, and that this value will *improve* (but not *solve*) the problem of dealing with missing information. As you say, simply improving the current situtation is not necessarily setting the bar all that high.

> > I don't think it's a complete solution, though. I think some kind of
> > sum type, as in SML, is also quite desirable. This lets the
> > modeller create special values according to the requirements
> > of the domain.
>
> I could not find a comprehensive enough reference for SML online to
> decypher what you are saying above. Is a sum type similar to a union
> type of some sort?

Yes; specifically a tagged union, unlike the untagged C union. Here's a decent article:

http://en.wikipedia.org/wiki/Tagged_union

> Missing
> information requires hard work and difficult tradeoffs.

Agreed.

Marshall Received on Mon Apr 17 2006 - 03:30:59 CEST