Avoiding Redundancy

Avoiding Redundancy

We should be careful to say everything once only. For example, we have used a relationship Owns between movies and studios. We might also choose to have an attribute studioName of entity set Movies. Although there is nothing illegal about doing so, it is unsafe for some reasons.

1. The two representations of the same owning-studio fact occupy more space, when the data is stored, than either representation alone.

2. If a movie were sold, we might change the owning studio to which it is related by relationship Owns but forget to change the value of its studioName attribute, or vice versa. Certainly one could argue that one should never do such careless things, but in practice, errors are common, and by trying to say the same thing in two different ways, we are inviting trouble.

These problems will be explained more properly in "Design of Relational Database Schemas" and we shall also learn there some tools for redesigning database diagrams so the redundancy and its attendant problems go away.