Common Design Problems

Derived Attributes

Another example of conflicting facts occurs when third normal form is violated. For example, if you included both a “birth-date” and an “age” attribute as nonkey attributes in the CHILD entity, you violate third normal form. This is because “age” is functionally dependent on “birth-date.” By knowing “birth-date” and the date today, you can derive the “age” of the CHILD.

Derived attributes are those that may be computed from other attributes, such as totals, and therefore need not be stored directly. To be accurate, derived attributes need to be updated every time their derivation source(s) is updated. This creates a large overhead in an application that does batch loads or updates, for example, and puts the responsibility on application designers and coders to ensure that the updates to derived facts are performed.

A goal of normalization is to ensure that there is only one way to know each fact recorded in the database. If you know the value of a derived attribute, and you know the algorithm by which it is derived and the values of the attributes used by the algorithm, then there are two ways to know the fact (look at the value of the derived attribute, or derive it from scratch). If you can get an answer two different ways, it is possible that the two answers will be different.

For example, you can choose to record both the “birth-date” and the “age” for CHILD. And suppose that the “age” attribute is only changed in the database during an end of month maintenance job. Then, when you ask the question, “How old is such and such CHILD?” you can directly access “age” and get an answer, or you can, at that point, subtract “birth-date” from “today’s-date.” If you did the subtraction, you would always get the right answer. If “age” has not been updated recently, it might give you the wrong answer, and there would always be the potential for conflicting answers.

There are situations, where it makes sense to record derived data in the model, particularly if the data is expensive to compute. It can also be very useful in discussing the model with those in the business. Although the theory of modeling says that you should never include derived data (and you should do so only sparingly), break the rules when you must. But at least record the fact that the attribute is derived and state the derivation algorithm.

7–12 ERwin Methods Guide

Common Design Problems

Missing Information

Missing information in a model can sometimes result from efforts to normalize the data. In the example, adding the SPOUSE entity to the EMPLOYEE-CHILD model improves the design, but destroys the implicit relationship between the CHILD entity and the SPOUSE address. It is possible that the reason that “emp- spouse-address” was stored in the CHILD entity in the first place was to represent the address of the other parent of the child (which was assumed to be the spouse). If you need to know the other “parent” of each of the children, then you must add this information to the CHILD entity.

Replacing Missing Information Using a New Relationship

EMPLOYEE

Sample Instance Tables for EMPLOYEE, CHILD, and SPOUSE

Normalization 7–13