Picking the Right Kind of Element

Picking the Right Kind of Element

Sometimes we have options about the type of design element used to represent a real-world conception. Many of these choices are between using attributes and using entity set/relationship combinations. Generally an attribute is simpler to implement than either an entity set or a relationship. However, making everything an attribute will generally get us into trouble.

Example :
Let us think about a specific problem. In "Entity-Relationship Diagrams" figure, were we wise to make studios an entity set? Should we instead have made the name and address of the studio be attributes of movies and removed the Studio entity set? One problem with doing so is that we repeat the address of the studio for each movie. This situation is another example of redundancy, similar to those seen in "Avoiding Redundancy" and "Choosing the Right Relationships". In addition to the disadvantages of redundancy discussed there, we also face the risk that, should we not have any movies owned by a given studio, we lose the studio's address.

On the other hand, if we did not record addresses of studios, then there is no harm in making the studio name an attribute of movies. We do not have redundancy due to repeating addresses. The fact that we have to say the name of a studio like Disney for each movie owned by Disney is not true redundancy, since we must represent the owner of each movie somehow, and saying the name is a reasonable way to do so.

We can summarize what we have observed in above example to give the conditions under which we prefer to use an attribute instead of an entity set. Suppose E is an entity set. Here are conditions that E must obey, in order for us to replace E by an attribute or attributes of numerous other entity sets.

1. All relationships in which E is involved must have arrows entering E. That is, E must be the "one" in many-one relationships, or its generalization for the case of multiway relationships.

2. The attributes for E must jointly identify an entity. Typically, there will be only one attribute, in which case this condition is surely met. However, if there are various attributes, then no attribute must depend on the other attributes, the way address depends on name for Studios.

3. No relationship involves E more than once.

If these conditions are met, then we can replace entity set E as follows:

a) If there is a many-one relationship R from some entity set F to E, then remove R and make the attributes of E be attributes of F, suitably re- named if they conflict with attribute names for F. In effect, each F-entity takes, as attributes, the name of the unique, related E-entity as movie objects could take their studio name as an attribute, should we dispense with studio addresses.

b) If there is a multiway relationship R with an arrow to E, make the attributes of E be attributes of R and delete the arc from R to E. An example of transformation is replacing "Converting Multiway Relationships to Binary" figure, where we had introduced a new entity set Salaries, with a number as its lone attribute, by its original diagram, in "Attributes on Relationships" figure.

Example : Let us think about a point where there is a tradeoff  between using a multiway relationship and using a connecting entity set with various binary relationships. We saw a four-way relationship Contracts among a star, a movie, and two studios in "Roles in Relationships" figure. In "Subclasses in the E/R Model" figure, we mechanically converted it to an entity set Contracts. Does it matter which we choose?

As the problem was stated, either is suitable. However, should we change the problem just a little, then we are almost forced to choose a connecting entity set. Let us assume that contracts involve one star, one movie, but any set of studios. This situation is more complicated than the one in "Roles in Relationships" figure, where we had two studios playing two roles. In this case, we can have any number of studios involved, perhaps one to do production, one for special effects, one for distribution, and so on. In this way, we cannot assign roles for studios.

It appears that a relationship set for the relationship Contracts must contain triples of the form

(star, movie, set-of-studios)

and the relationship Contracts itself involves not only the usual Stars and Movies entity sets, but a new entity set whose entities are sets of studios. While this technique is unavoidable, it seems unnatural to think of sets of studios as basic entities, and we do not suggest it.

A better technique is to think of contracts as an entity set. As in "Subclasses in the E/R Model" figure, a contract entity connects a star, a movie and a set of studios, but now there must be no limit on the number of studios. In this way, the relationship between contracts and studios is many-many, rather than many-one as it would be if contracts were a true "connecting" entity set. The following figure sketches the E/R diagram. Note that a contract is linked with a single star and a single movie, but any number of studios.

Contracts connecting a star, a movie, and a set of studios