Re: relationship in the database
Date: Fri, 20 Sep 2002 20:04:53 GMT
> >Modelling of constraints an implementation decision?
> No, I meant modelling relationships between entities with foreign keys.
> 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
> 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 <chosen> 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 <choosing> primary keys was entirely out the scope of the relational model.
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
> >the (or at least one information equivalent and complete)
> >logical/conceptual system catalog should simply be a direct consequence
> >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?
Received on Fri Sep 20 2002 - 22:04:53 CEST