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 non-key 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, we can derive the “age” of the CHILD.

Derived attributes are those that may be computed from other attributes (e.g., 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 we know the value of a derived attribute, and we 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, we 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 we ask the question, “How old is such and such CHILD?” we can directly access “age” and get an answer, or we can, at that point, subtract “birth-date” from “today’s-date.” If we did the subtraction, we would always get the right answer. If “age” has not been updated recently, it might give us 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 the business. Although the theory of modeling says that you should never include derived data (and we urge you to 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.

Normalization ∙ 81

Missing Information

Missing information in a model can sometimes result from efforts to normalize the data. In our 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 we need to know the other “parent” of each of the children, then we must add this information to the CHILD entity.

Replacing Missing Information Using a New Relationship

EMPLOYEE

CHILD

Sample Instance Tables for EMPLOYEE, CHILD, and SPOUSE

82 ∙ Normalization

SPOUSE

Sample Instance Tables for EMPLOYEE, CHILD, and SPOUSE

The normalization of this model is not completed, however. In order to complete it you must ensure that you can represent all possible relationships between employees and children, including those in which both parents are employees.

Normalization ∙ 83