Re: I think my book may be wrong about cardinality, but I'm not sure
Date: Wed, 25 Jul 2007 02:45:28 -0700
On Jul 24, 11:34 pm, beginner16 <kaja_love..._at_yahoo.com> wrote:
> >>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
> >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
> >>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?
A relationship is a row in a table. Nothing more, nothing less. A foreign key just indicates a link to where you may discover more about the items in that relationship. This is why ER modelling can be misleading to the beginner designer. I find it helps to clarify if you redraw your E/R diagram using only 0-n or 1-n links, and an "associative entity" in between. Received on Wed Jul 25 2007 - 11:45:28 CEST