4.

2 Design Principles
 4.2.1 Faithfulness
• Example: If we define 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
incorrect to declare the relationship Stars-in to
be many-one in either direction or to be one-
one.
 4.2.2 Avoiding Redundancy
• 1. Doing so leads to repetition of a fact, with
the result that extra space is required to
represent the data, once we convert the E/R
design to a relational (or other type of)
concrete implementation.
• 2. There is an update-anomaly potential, since
we might change the rela -tionship but not the
attribute, or vice-versa.
 4.2.3 Simplicity Counts
• Example : Suppose that instead of a relationship
between Movies and Studios we postulated the
existence of "movie-holdings," the ownership of
a single movie. We might then create another
entity set Holdings. A one-one relationship
Represents could be established between each
movie and the unique holding that represents
the movie. A many-one relationship from
Holdings to Studios completes the picture shown
in Fig. 4.11.
4.2.4 Choosing the Right Relationships
• Example : Now, consider Fig. 4.2 again. In this
diagram, there is no relationship between stars
and studios. Yet we can use the two relationships
Stars-in and Owns to build a connection by the
process of composing those two relationships. That
is, a star is connected to some movies by Stars-in,
and those movies are connected to studios by
Owns. Thus, we could say that a star is connected
to the studios that own movies in which the star
has appeared.
4.2.5 Picking the Right Kind of Element
• Sometimes we have options regarding the
type of design element used to represent a
real-world concept. Many of these choices are
between using attributes and using entity
set/relationship combinations. In general, an
attribute is simpler to implement than either
an entity set or a relationship. However,
making everything an attribute will usually get
us into trouble.
 Example
• Let us consider a point where there is a
tradeoff between using a multiway
relationship and using a connecting entity set
with several binary relationships. We saw a
four-way relationship Contracts among a star,
a movie, and two studios in Fig. 4.6. In Fig. 4.9,
we mechanically converted it to an entity set
Contracts. Does it matter which we choose?