Re: Network Example: Sibling of Opposite Gender

On 2007-01-02, Marshall wrote:

> [Stuff on tagged unions snipped]
>
> That's basically what I was thinking.

To me this sort of thing seems suspicious, but in theory it does fit the RM: tagged unions are essentially instances of disjoint union types. As soon as you consider union domains, everything you just did becomes simply one syntax capable of representing the result.

Semantically I don't see how the result is any better than including nulls or decomposing the relations so that unknowns are fully removed. In the first case, nulls do not join for a reason: a value being unknown isn't a value so it shouldn't equal one. (Cf. Codd's rationale for 3VL and 4VL.) In the second, whenever you join you have to consider what you're joining and any domain machinery present can be used to disallow nonsensical joins. A model with tagged unions doesn't seem to have similar benefits.

OTOH I also think Darwen's exposition of the decomposition approach is a bit confused; he for instance doesn't seem to understand that normalization with respect to union/horizontal decomposition is still logically about removing ands and/or representing them consistently in terms of the relational convention of tuples being related by conjunction, and has very little to do with disjunctions.

> You also need a "match" or extended CASE construct to "pull apart" the
> branches of the union and extract any parameters, such as in the
> SALARIED case.

Wouldn't a type-aware equality predicate suffice as well? E.g.

select sum(salary) from pers_info where salary in Integer;

-- 
Sampo Syreeni, aka decoy - mailto:decoy_at_iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2