Re: One to One Relationship

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 19 Mar 2003 20:37:08 -0600
Message-ID: <u3cliu5ou.fsf@standardandpoors.com>

On 19 Mar 2003, wizofoz2k_at_yahoo.com.au wrote:
> Galen Boyer <galenboyer_at_hotpop.com> wrote in message
> news:<u4r5z1o3e.fsf_at_standardandpoors.com>...
>

>> 
>> The one issue is that the "Aircraft Table" now has an id that
>> can, by the design of the model, be found in both the P3-C
>> Orion subtable as well as the F18 subtable.  An aircraft, of
>> course, can't be both types, but the model says this is
>> allowed and there is no referential integrity rule to protect
>> this from happening.
>> 

>
>
> Not in my case. Aircraft type is the entity. That has a
> unique ID, for a FA18. And a P3. There may now be a row with
> the same ID in the FA18 table, but ONLY for the FA18 row in the
> aircraft type table. Same surrogate key ID. Note that these
> are "types", not actual "elements". Ie, not individual
> aircraft. Those are handled somewhere else.

The Aircraft type can't have relationships with other entities? Hm... Its a lookup only. (my term)

My problem is that the a particular subtype can have relationships with a bunch of other subtypes, as well as other entities in other relationship hierarchies. (A portfolio of financial instruments can contain ids at many different levels in the finance hierarchy). The best way I think I can represent this is to have a relationship table hang off the appropriate parent's table. But, then, a commercial loan and a personal loan would have the same key found in the loan table. Some other entity, maybe porfolio could be a collection of any derivatives of those things. Then, have a union view to bring them all back nice and tidy.

-- 
Galen Boyer

Received on Wed Mar 19 2003 - 20:37:08 CST