Design Principles

Design Principles

We have yet to learn many of the details of the E/R model, but we have enough to begin study of very important issue of what forms a good design and what should  be avoided. In this section, we offer some useful design principles.


Primarily, the design must be faithful to the specifications of the application. That is, entity sets and their attributes should reflect reality. You can't connect an attribute number-of-cylinders to Stars, though that attribute would make sense for an entity set Automobiles. Whatever relationships are declared should make sense given what we know about the part of the real world being modeled.

Example : If we describe a relationship Stars-in between Stars and Movies, it should be a many-many relationship. The reason is that an observation of the real world tells us that stars can appear in more than one movie, and movies can have more than one star. It is wrong to declare the relationship Stars-in to be many-one in either direction or to be one-one.

Example : On the other hand, sometimes it is less obvious what the real world requires us to do in our E/R model. Suppose, for example, entity sets Courses and Instructors, with a relationship Teaches between them. Is Teaches many-one from Courses to Instructors? The answer lies in the policy and intentions of the organization creating the database. It is possible that the school has a policy that there can be only one instructor for any course. Even if several instructors may "team-teach" a course, the school may need that exactly one of them be listed in the database as the instructor responsible for the course. In either of these cases, we would make Teaches a many-one relationship from Courses to Instructors.

On the other hand, the school may use teams of instructors on a regular basis and wish its database to permit several instructors to be associated with a course. Or, the intent of the Teaches relationship may not be to reflect the current teacher of a course, but rather those who have ever taught the course, or those who are capable of teaching the course; we cannot tell simply from the name of the relationship. In either of these cases, it would be proper to make Teaches be many-many.