Path: utzoo!attcan!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases Subject: Re: Outerjoin implementation? Message-ID: Date: 2 Oct 90 17:54:09 GMT References: <5803@plains.NoDak.edu> <30203@netnews.upenn.edu> <30357@netnews.upenn.edu> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 83 In-reply-to: aaron@grad2.cis.upenn.edu's message of 1 Oct 90 12:56:06 GMT In article <30357@netnews.upenn.edu> aaron@grad2.cis.upenn.edu (Aaron Watters) writes: In article (I) write: > > all people who definitely have an age = 24 > or > all people who MAYBE have an age = 24 ? > First, why do you say these are not different aspects to the correct answer to a single query? First, I'm not sure I understand your statement. Second, the answer to the first query is a subset of the answer to the second query. These two queries have different meanings where it just so happens that their results are in the same domain. If the second query had been "all people who definitely have an age = 36", then they would have been recognized as two different queries. The same is true of the above queries. Imagine, if you will, that I pose a very complex query built up from complex views whose definitions I do not know. Then, as far as you (or the model) are concerned, the views can (and should) be treated as basic relations. Suppose I want to know those tuples known to satisfy the query and those not-known to not-satisfy the query. The double negative here is throwing me. Do I have to pose two queries? Perhaps, depending on what the double negative means. On the other hand, MAYBE qualification results in a superset of definite answer. Do each of the views I use have to be defined twice, once for definiteness and once for maybeness? Why? The VIEW construction is done with primitive operations (like those at the beginning of the message). If you want values in the view that are not precise, then use the MAYBE qualifier, but that will still include the definite subset. Roughly, I would argue that it's okay if the system allows the user to ask for maybes and definites, but if s/he doesn't specify s/he should get both. Precisely. Second, note that according to the `semantic completeness' metric no reasonable database system will fill the bill -- because the problem is NP-complete for a fixed query and varying data. (Teaser.) You seem to have been making the assumption that definitiveness and maybeness are distinct sets. I contend that maybeness is a superset of definitiveness. What does that do to the NP-complete problem (I never really understood NP terminology). I disagree that the `relational paradigm' includes `three valued logic' any more sensibly than Pascal `includes Prolog.' (IE, you can certainly implement one in the other, but that's beside the point.) Set theory, by definition, must contend with NULL (especially where domains are concerned) and the NULL-set. If operations are defined upon sets (as the relational model does), then those operations must be consistent where NULL is concerned. Three-valued logic is the expression of how to specify the results of standard operators with "unknown" (NULL) operands. Therefore, three-valued logic should be a part of the definition of operations against sets. So, to be consistent, the relational 'paradigm' should deal with NULLs completely and consistently. Having said that, I must say that I am speaking only of the model and not any one particular implementation. No implementation (to my knowledge) is yet complete where NULLs are concerned (can they, therefore, be called "completely relational"?). -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"