Re: candidate keys in abstract parent relations

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:jOPzf.284260$2k.234827_at_pd7tw1no...
> Forrest L Norvell wrote:
> > ...
> > Also, on a more abstract level, I'm trying to derive a method for
> > dealing with similar problems in the future. It seems to me like this
> > is a common problem when trying to model real-world domains,...
>
>
> Right, I think. Very common for "keys" to be re-used. That's why the
> biggest Canuck 'phone company used to send two bills if a customer had
> two phones and airline systems are complicated because IATA allows a
> flight number to be re-used the next day and cash registers re-use
> transaction numbers if the power cord is pulled.
>
> The original post mentioned candidate keys which seems to me to be the
> important ingredient. I can't see anything wrong with having two of
> them in the same relation, eg., {Number} and {Title, Label,
> ReleaseDate}, ie., they are 'one-to-one'. Use {Number} in the other
> tables. If you ever discover that the other candidate key is
> insufficient, you can 'extend' it with a single table change. Depending
> on what users want to know, you might not even have to change any queries.
>

Agreed. And if you have a table with no candidate keys (two rows mean something different, but are duplicates of each other) then you haven't got a relational model, yet. It seems to me that the OP has yet to identify a track. Received on Fri Jan 20 2006 - 22:41:06 CET