Re: I think my book may be wrong about cardinality, but I'm not sure

hello

>>1)
>>The following quote ( well I shortened it a bit ) is from a chapter
>>briefly describing MARTIN E-R notation
>> "Say we have entities ORDER and PRODUCT. One ORDER must include at
>>least one product, but it can also have more than one product. One
>>PRODUCT can be related to zero or more ORDERS. Thus cardinality of
>>PRODUCT is ( 1, N ) and cardinality of ORDER is ( 0, N )"
>>But to my understanding, the cardinality of ORDER entity should be
>>( 1,N ) --> where 1 means min number of connections and N max number
>>of connections an individual ORDER entity can have. And cardinality of
>>PRODUCT entity should be ( 0,N ). But my book claims just the
>>opposite!
>
>I would have said it differently: the cardinality of the PRODUCT-ORDER
>relationship with respect to ORDERS is (1,N). the cardinality of the
>PRODUCT-ORDER relationship with respect to PRODUCTS is (0,N). I think >you and I are on the same page, but may need to reread Martin.
>

So I was basically right? What still bothers me though is that book made the same mistake ( in the same chapter ) twice. Uh

>>2)
>>Relationship between two entities is called binary connection or
>>second degree relationship. But connection can exists between more
>>than just two entities. Level of connection is determined by the
>>number of different entity types that exist in a connection.
>>Now as far as relational DB goes, don't tables have only binary
>>connections ( second degree relationship )?
>
>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?

cheers Received on Wed Jul 25 2007 - 00:34:04 CEST