Re: Network Example: Sibling of Opposite Gender

Marshall wrote:

> On Jan 3, 2:49 am, Sampo Syreeni <d..._at_iki.fi> wrote:
> 

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

>>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. Received on Wed Jan 03 2007 - 18:08:09 CET