A tuple is a set of (field-name, field-value) pairs.
I’ve been fairly negative about the extended set theory concept – but in fairness, that may be because I misunderstood how other people thought of tuples. Any time I’ve had to formalize what I thought of a tuple as being, I came up with something very much like the above, except that if one wants to be relational one needs a requirement like:
In any one tuple, each field-name must be unique.
In line with that definition, I’d say a table is something like:
- A set of tuples, such that any two tuples in the set can be put into one-to-one correspondence with each other in such a way that the field-names of corresponding pairs are the same, plus
- (Optionally!) A convention for consistently arranging the members of a tuple in a certain order according to field-name.
If you buy that, then the next step is to define a join along the lines of
Definition: f is a field-name for table T if for any tuple t in T, t contains a pair (f,v) for some v.
Definition: Let T and U be tables. Define pseudocart(T,U) to be the image of the Cartesian product T x U under the amazingly simple mapping that sends (t,u) to the union of t and u.
Definition: Let T and U be tables with field-names f and g respectively. The join of T and U on fields f and g is the subset J of pseudocart(T,U) such that, for all s in pseudocart(T,U), s is in J if and only if, for (f,v) and (g,w) in s, v=w.
Note: s is of course itself a set. (f,v) and (g,w) must each exist in s and be unique, by the definitions. That’s why I didn’t say “for all”.
Note: I came up with all of the above by myself. No doubt the whole thing has been done better many times before — or at least with different, possibly more scalable, terminology. Links to same in the comment thread would be appreciated.
The net result is that joins are commutative, associative, and generally nicely behaved, which extended set theory proponents say they aren’t in a standard relational algebra.
In fairness to the extended set theory folks, Wikipedia shows us some common definitions of tuple are rather different from what I gave above. But so what? Use any other definition. Then there’s a one-to-one mapping between the tables and tuples you have and the ones I outlined above. Use that mapping, plus the definition of join I outlined above, to induce a join operation on the tables you defined. It will have the same nice algebraic properties as mine.
A second claim made for extended set theory is that it doesn’t just cover the relational case. I.e, if you relax the rule “In any one tuple, each field-name must be unique,” then all of a sudden the same set-theoretic model can be used to describe XML as well. Coolness. But I’ll admit to not yet knowing of any reasons why that description would actually be useful for anything, unless somebody (e.g., Algebraix) really comes out with a general, extended-set-theory-inspired software engine that does a great job of managing multiple kinds of data.