Newsgroups: comp.databases.theory Path: news.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!priapus.visi.com!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!xyzzy!nntp From: "D Guntermann" Subject: Re: relationship in the database X-Nntp-Posting-Host: e228711.nw.nos.boeing.com Message-ID: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Priority: 3 X-Msmail-Priority: Normal Lines: 76 Sender: nntp@news.boeing.com (Boeing NNTP News Access) Organization: The Boeing Company X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 References: <25579391.0209040451.256f3107@posting.google.com> <3d762176$1@news.uia.ac.be> <3d7653c4$1@news.uia.ac.be> Date: Fri, 20 Sep 2002 20:45:12 GMT Xref: newsfeed1.easynews.com comp.databases.theory:22554 X-Received-Date: Fri, 20 Sep 2002 13:49:31 MST (news.easynews.com) Having read the remainder of this thread, I see my previous comments have already been either stated or refuted several times over. My apologies for the redundancy. Daniel Guntermann "D Guntermann" wrote in message news:H2r6G4.n0z@news.boeing.com... > > > > > >Modelling of constraints an implementation decision? > > > > No, I meant modelling relationships between entities with foreign keys. > For > > example, suppose I have two entity types E1 and E2 and a relationship R > > between them. Let's say R is one-to-many (from E1 to E2) and E1 has two > > candidate keys. When translating this to the relational model I have to > > choose which candidate key is taken as the primary key of E1 and is added > to > > the table for E2 as a foreign key. > > Actually, a foreign key, when implemented or modeled, can establish a > relationship with *any* candidate key. A primary key does not have to be > and then always used in foreign key relationships. Thus, it might > be a better alternative to question *which* candidate key will participate > in any foreign key relationship. This question might be asked and answered > at the level of creating the conceptual model in that a user's view of the > data might be the set of criteria that actually determines which candidate > key might be best selected. So it might not necessarily be an > implementation decision. > > As a sidenote, Date briefly mentions in his book, _Introduction to Database > Systems, 7th Ed_, that the primary key is a traditionally accepted concept > of the relational model, but that choosing and abiding by one is not a > necessarily jusifiable or required condition in all situations. If I > remember correctly, this can be found in Chapter 8 in sub-section concerning > primary keys and alternate keys. And if I'm not mistaken, he notes that > Codd had previously indicated that the process of primary keys > was entirely out the scope of the relational model. > > Regards, > > Daniel Guntermann > > I would tend to see that decisions as an > > implementation decision. > > > > >I've always thought that given a particular definition of the relational > > >model (say one explicitly including the concept of FKs), then the design > of > > >the (or at least one information equivalent and complete) > > >logical/conceptual system catalog should simply be a direct consequence > of > > >the artifacts in the definition of the model. > > > > That depends upon the artifacts you choose but in general you would be > > right. Especially for the usual suspects (key constraints, functional > > dependencies, multi-valued dependencies, join dependencies, foreign keys) > > that is correct. > > > > -- Jan Hidders > > > > PS. Do you know what type of recursion is allowed in DB2's SQL? > > > > > >