Avoiding Pitfalls in Data Modeling - High-Performance Web Databases: Design, Development, and Deployment - page 277

Exhibit 18-2. A redundant relationship.

A relationship is redundant when its exclusion
would not cause a loss in the representation of any business rules in the
model. The diagram in Exhibit 2 contains a redundant relationship. In the
exhibit, the relationship customer places order for product is clearly
redundant. The relationship customer gets quote for product, however, is
not necessarily redundant. The meaning of the relationships provides use-
ful clues to help decipher whether a relationship is redundant. A more sub-
tle clue is the cardinality.

Redundant Relationships.

The problems of redundant relationships are not as easy to identify
because the modeler is generally reluctant to run the risk of missing signif-
icant relationships. Again, the modeler could ask users how effectively the
relationship can help answer business questions, as is done with relation-
ship identification.

It is tempting to draw relationships between two
entities that should not be related. What appears to be a significant rela-
tionship often does not even exist. Exhibit 3 illustrates such a case. In this
exhibit, it might be a requirement that the data model shows the historical
connection between the published market price and negotiated price.
There may be a correlation between the two, but there is no real relation-
ship needed to model this correlation. It would be incorrect to insert a rela-
tionship that directly links Published Market Price History and Negotiated
Price History entities.

Spurious Relationships.

Spurious relationships happen occasionally, but they are not as common
as redundant relationships. However, it is difficult to explain to users why a
relationship is spurious without resorting to a technical data modeling dis-
cussion. One helpful approach is to avoid the discussion at a technical level
and simply demonstrate to the users that their information needs can be met.