Re: Network Example: Sibling of Opposite Gender

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 04 Jan 2007 13:38:19 GMT
Message-ID: <fr7nh.40416$cz.596122@ursa-nb00s0.nbnet.nb.ca>

Marshall wrote:

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

Please accept my sincere apologies.

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

Thus, the employee is either unpaid or not unpaid--fair enough. I suppose there must be an implicit constraints that

DEE = SALARIED[] union CREDIT[] union UNPAID[]
DUM = SALARIED[] join CREDIT[]
DUM = SALARIED[] join UNPAID[]
DUM = CREDIT[] join UNPAID[]

(using [] for project onto zero attributes)

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.

In a sense, your case statement instantiated such a tuple by providing the missing name, x.

select sum( case SALARY WHEN SALARIED(x) then x WHEN ...)

Writing a complex case statement every time one wants to use an attribute seems cumbersome. Might another syntax provide the necessary naming during declaration? And might another syntax allow for some sort of shortcut?

I can see problems with the shortcut idea already. Hmmm.... Received on Thu Jan 04 2007 - 07:38:19 CST