Re: CJ Date on Missing Information
Date: Mon, 20 Mar 2006 08:17:45 GMT
Message-ID: <JytTf.2919$HW2.531_at_newsread3.news.pas.earthlink.net>
paul c wrote:
> Jonathan Leffler wrote:
>> Paul Mansour wrote:
>>
>>> I've just read "The Default Values Approach to Missing Information" in
>>> Date's Database Writings 1989-1991. I've also noted that in the 8th
>>> edition of Date's main textbook, he refers to the "special values
>>> scheme' for handling missing information, and points to an article in
>>> Database Writings 1994-1997. I don't have the 94-97 book, though I am
>>> trying to track down a copy, and I'm curious to know if Date's view on
>>> handling missing information has changed since the 89-91 writings, or
>>> is it more or less the same. Any comments on this would be appreciated.
>>
>>
>> The 94-97 book has a set of 5 articles from DBP&D on 'Faults and
>> Defaults' (Nov 1996 - Apr 1997), which elaborates on the other
>> article. I'm not certain, but my impression is that the scheme has
>> been largely discarded. ...
> > Maybe it's largely discarded, and I don't have those articles anymore, > but one thing that I remember that intrigued me was McGoveran's question > about whether multiple relational results mightn't be useful, sorry I > forget just how he put it.
That was, I think, a different series of papers (also published in both DBP&D and Date's book). You'd be talking about "Nothing from Nothing: It's in the Way That You Use It" (chapter 8), and the section on "Types and subtypes".
To quote the possibly relevant section:
The possibility of such results suggests some extensions to the relational algebra to support more general versions of the relational operators. In particular, relational union is a restricted version of the general set union. I propose that the system should automatically create several tables in the output (when appropriate), grouping like rows together by performing the "restrict and project away nulls" operation in [sic] the user's behalf. This capability would help users distinguish the entity types and recognize their interrelationships. In effect, such set operations would be many-table-result versions of existing relational operations; they would avoid the need for users to simulate such operations manually, via several SQL statements. Whether many-table operands (as opposed to results) should be permitted deserves additional and careful consideration, however. For the time being, I propose that such many-table values be supported only for output.
Note: Whereas the relational model per se does not permit the union of operands of distinct types (such as apples and oranges), the outer union operator does, and so does the proposal I am making here. The difference is that outer union creates a bizarre kind of combined result in which every apple is given orange properties and every orange is given apple properties. By contrast, my proposal creates a result in which apples and oranges retain their respective identity and the user is not encouraged to confuse them. Similar remarks apply to the other set operations.
(End quote)
This is interesting - one of the recent mewsings by Dawn on the subject of pizzas could very well be handled by what I think David McGoveran is proposing here.
-- Jonathan Leffler #include <disclaimer.h> Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/Received on Mon Mar 20 2006 - 09:17:45 CET