Re: Network Example: Sibling of Opposite Gender

On Jan 3, 9:08 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Marshall wrote:
> > 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.
>
> Bite your tongue! At best, NULL is semantically meaningless due to it's
> arbitrary inconsistencies. Neither is the tagged union semantically
> equivalent to simply decomposing to remove unkowns. One would have to
> decompose each of your tags into separate relations.

I thought that's what I *was* comparing: the tagged union version of EARNS (p. 7) vs. the 3 decomposed tables EARNS, SALARY_UNK, and UNSALARIED (p. 9). Do they not have the same information content? Do they not record the identical set of facts?

> >>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.
> Indeed, in a natural join of two relations that include id and job,
> unpaid employee #10 is the same unpaid employee, and employee #20 with
> the unknown job is the same employee #20 with an unknown job.
>
>
>
> >>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.
>
> Except it is not exactly a tuple. A tuple value would have all three
> whereas any SALARY value has only one of the three.

That's not what I meant. I meant *each* tag has an associated tuple type. There are three tuple types; one for each tag. The UNPAID tag's associated type is the 0-ary tuple type. Of course if we want to say this for the SALARIED tag then we have to assign a name to the associated integer; otherwise it's not our standard named-tuple type.

Marshall Received on Thu Jan 04 2007 - 06:21:05 CET