Re: Modelling Disjoint Subtypes

Bob Badour wrote:
> Joe Thurbon wrote:
>

[...]

>>
>> The first approach I can think of uses some sort of
>> type-discriminator, in the employee table. This seems fraught with
>> difficulties: how do you select the table to join on based on the type
>> discriminator other than using multiple queries? How do you prevent
>> nonsense data appearing, for example, in the 'commissiones' table for
>> an employee whos type discriminator is is 'salaries'. So I'm guessing
>> that a type discriminator does not work.
>>
>> The second approach is to have only one sub-type, but have two columns
>> "Type", "Amount" whereby type gives a clue as to how to interpret the
>> ammount (i.e. is it salary or commission). This seems problematic,
>> since , in some sense, the domain of commissions is different to the
>> domain of salaries (at least, according to my understanding of chapter
>> 1 of "Practical Issues..."
>>
>> The other approach requires some sort of check constraint that
>> simulates a kind of 'distributed key' (c.f. Darwen's 'Final Null In Th
>> Coffin'). I can't really work out how this would be done relationally.
>>
>> So I'm stuck. Any hints or clues?

> 
> What if you had an attribute that was a constant? How might that change 
> your analysis above?

Do you mean that I had an attribute whose domain contained only one value, or an attribute that was the value (constant) in another domain? Received on Thu Mar 22 2007 - 01:37:04 CET