Re: Network Example: Sibling of Opposite Gender

On Jan 3, 2:49 am, Sampo Syreeni <d..._at_iki.fi> wrote:
> 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.

Well, sure; semantically the two solutions are equivalent, but that's kinda the point: to produce the *same* information in a form more convenient for querying and updating.

> 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.

I don't follow. If your domain model specifies things to a greater degree
than NULL can, then I don't see why you *wouldn't* want to join on equality. One thing I like about tagged union values is that, unlike null,
they always really are values. You get more expressiveness yet simpler semantics.

> 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;

No, because what if two of the tags use the same type? Maybe you have people paid with dollars and people paid with store credit:

SALARY{ SALARIED(integer), CREDIT(integer), UNPAID }

In fact, I like to think of the parameters to each tag as being a tuple, with named attributes, and tags with no parameters as being parameterized by the 0-ary tuple.

Marshall Received on Wed Jan 03 2007 - 17:40:18 CET