Handling Weak Entity Sets

Handling Weak Entity Sets

When a weak entity set appears in an E/R diagram, we need to do three things in different ways.

1. The relation for the weak entity set W itself must contain not only the attributes of W but also the key attributes of the other entity sets that help form the key of W. These helping entity sets are easily recognized because they are reached by supporting (double-diamond) relationships from W.

2. The relation for any relationship in which the weak entity set W appears must use as a key for W all of its key attributes, including those of other entity sets that contribute to W's key.

3. However, a supporting relationship R, from the weak entity set W to another entity set that helps provide the key for W, need not be converted to a relation at all. The justification is that, as discussed in "Combining Relations", the attributes of many-one relationship R's relation will either be attributes of the relation for W, or (in the case of attributes on R) can be combined with the schema for W's relation.

Of course, when introducing additional attributes to build the key of a weak entity set, we must be careful not to use the same name twice. If necessary, we rename some or all of these attributes.

Example (a) : Let us examine the weak entity set Crews from figure "A weak entity set for crews, and its connections" in article "Weak Entity Sets", which we reproduce here as Figure 1. From this diagram we get three relations, whose schemas are:

Studios(name, addr)
Crews (number, studioName)
Unit-of (number, studioName, name)

The first relation, Studios, is constructed in a straightforward manner from the entity set of the same name. The second, Crews, comes from the weak entity set Crews. The attributes of this relation are the key attributes of Crews; if there were any nonkey attributes for Crews, they would be included in the relation schema as well. We have chosen studioName as the attribute in relation Crews that corresponds to the attribute name in the entity set Studios.

The crews example of a weak entity set

The third relation, Unit-of, comes from the relationship of the same name. As always, we represent an E/R relationship in the relational model by a relation whose schema has the key attributes of the related entity sets. In this case, Unit-of has attributes number and studioName, the key for weak entity set Crews, and attribute name, the key for entity set Studios. However, notice that since Unit-of is a many-one relationship, the studio studioName is surely the same as the studio name.

For example, suppose Disney crew #3 is one of the crews of the Disney studio. Then the relationship set for E/R relationship Unit-of includes the pair

Relations With Subset Schemas

(Disney-crew-#3, Disney)

This pair gives rise to the tuple

(3, Disney, Disney)

for the relation Unit-of.

Notice that, as must be the case, the elements of this tuple for attributes studioName and name are the same. As a result, we can "merge" the attributes studioName and name of Unit-of: giving us the simpler schema:

Unit-of (number, name)

However, now we can dispense with the relation Unit-of altogether, since it is now identical to the relation Crews.
The weak entity set Contracts

Example (b) : Now consider the weak entity set Contracts from Example (c) & figure in "Weak Entity Sets". We reproduce this diagram as Figure 2. The schema for relation Contracts is

Contracts(starName, studioName, title, year, salary)

These attributes are the key for Stars, suitably renamed, the key for Studios, suitably renamed, the two attributes that form the key for Movies, and the lone attribute, salary, belonging to the entity set Contracts itself. There are no relations constructed for the relationships Star-of, Studio-of, or Movie-of. Each would have a schema that is a proper subset of that for Contracts above.

Incidentally, notice that the relation we obtain is exactly the same as what we would obtain had we started from the E/R diagram of "Attributes on Relationships" figure. Recall that figure treats contracts as a three-way relationship among stars, movies, and studios, with a salary attribute attached to Contracts.

The phenomenon observed in Examples (a) and (b) - that a supporting relationship needs no relation - is universal for weak entity sets. The following is a modified rule for converting to relations entity sets that are weak.

●  If W is a weak entity set, construct for W a relation whose schema consists of:

1. All attributes of W.

2. All attributes of supporting relationships for W.

3. For each supporting relationship for W, say a many-one relationship from W to entity set E, all the key attributes of E.

Rename attributes, if necessary, to avoid name conflicts.

●  Do not construct a relation for any supporting relationship for W.