Re: I think my book may be wrong about cardinality, but I'm not sure
Date: Wed, 25 Jul 2007 01:10:28 +0100
Message-ID: <SvydnVx4p8trCTvb4p2dnAA_at_giganews.com>
"beginner16" <kaja_love160_at_yahoo.com> wrote in message
news:1185316444.726002.242770_at_b79g2000hse.googlegroups.com...
>>
>>No. An N-degree table implements an N-ary relationship between
>>attributes -
>>attributes which may well identify other entities. Do not assume
>>relationship = foreign key. A foreign key is just one type of constraint
>>(not necessarily the only one) for enforcing referential integrity in RM.
>>
>
> I'm not sure I understand what you are saying here!
> I know that for ternary relationship we can create additional table
> with three foreign keys ( which in a way is still made of two binary
> connections ), but are you saying we can create ternary relationship
> without foreign key constrains?
>
The point is that relationships of whatever kind are represented by the values within the tables themselves. The foreign key is one of several constraints that may or may not exist to keep order - so to speak - but a foreign key is just the name given to one fairly restrictive type of constraint. For example a foreign key isn't good enough to enforce an N-cardinality relationship, where N is some fixed value greater than 1 - so you would need some other constraint(s) for that purpose. That doesn't mean it isn't a relationship.
As a matter of detail the constraint that SQL calls a "foreign key" differs in some subtle ways from what the relational model calls a foreign key. The relational definition is that a foreign key references only a candidate key, whereas SQL permits "foreign keys" to reference super-keys as well.
-- David PortasReceived on Wed Jul 25 2007 - 02:10:28 CEST
