Re: more closed-world chatter

On May 3, 6:39 am, paul c <toledobythe..._at_oohay.ac> wrote:
>
> Thanks, I feel better now. Still, I'd like to know I could paraphrase
> that query a little more formally, say using D&D <AND>. But the
> stipulation "It is required that if <A,T1> is in Hr1 and <A,T2> is in
> Hr2, then T1 = T2" stymies me, eg., if pricedomain={1,2} and
> anotherdomain={3}, it seems that <AND> isn't defined.

This exact question has been in the back of my head for a long time. I lately feel like the answer is "it depends." Specifically it depends on the type system. The heart of a join (if I may wax poetic momentarily) is a bunch of tests for equality. So what is the result of:

  1:pricedomain = 3:anotherdomain

(The colon here is a type specifier.) The question is interesting in the case of disjoint types.

So, there are a variety of possible answers. Bob for example considers this within the context of a type theory that has subtyping, whereas Jon proposes a type mismatch. Both answers have their merits. Another question: what is the type of that attribute in the result relation? Possible answers include the top of the type lattice and the bottom; I am inclined to prefer the bottom.

Lately I have begun to adopt a more set-theoretic, less type-theoretic view. In this view, the *type* of a relation (or the header, if you prefer) is simply the set of attribute names, and nothing else. There is a separate construct, the constraints, and join has to consider how to combine not only the attributes and the values, but also the constraints.

A pleasing aspect to this is how the attributes and the constraints are combined. Rather than having to do any least type calculations on the headers, we simply use union. The set of attributes of the join of two relations is simply the union of the operands' attributes. The set of constraints is simply the union of the operands' constraints.

I do not claim that any one of these views is more "correct" than any other.

Let us consider your question under this view. Perhaps annoyingly, I'm going to use the latest version of my ever-changing personal notation: Attribute names are in (parentheses), constraints are in [brackets], and set members (which are always values) are in {braces}. Members of relations are further enclosed in (parentheses), with one value per attribute. The word "set" introduces a set literal; if it is followed by a parenthesized list of attribute names the set is a relation. Set membership constraints (I believe some call these "domain constraints") are written with a colon, which may be regarded as identical to ∈. The syntax employs ordering; the semantics do not.

def pricedomain = set {1, 2};
def anotherdomain = set {3};

def R1 = set(price) [price : pricedomain] {(1)}; def R2 = set(price) [price : anotherdomain] {(3)};

def R = R1 & R2;

---

At this point, what is the value of R?

  R = set(price) [price:pricedomain; price:anotherdomain] {};

Since the union of pricedomain and anotherdomain is empty:

  [pricedomain & anotherdomain = set {}]

we can further simplify this to:

  R = set(price) [price:set{}] {};



>From this we can see that, given these constraints, R will

be empty regardless of the values of R1 and R2.

Comments welcome.


Marshall