Re: Modelling Disjoint Subtypes

Joe Thurbon wrote:

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

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

That depends on what you mean by domain. Suppose an attribute has a specific type and is constrained to a single value within that type. Received on Thu Mar 22 2007 - 02:19:33 CET