Common Design Problems

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 by manual calculation). 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 this CHILD?” you can directly access “age” and get an answer, or you can subtract “birth-date” from “today's-date.” If you did the subtraction, you would always get the right answer. If

“age” was not recently updated, 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 or do so only sparingly, break the rules when you must and at least record the fact that the attribute is derived and state the derivation algorithm.

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.

Chapter 7: Normalization Problems and Solutions 77

Common Design Problems

The following three tables are sample instance tables for EMPLOYEE, CHILD, and

SPOUSE:

EMPLOYEE

SPOUSE

However, the normalization of this model is not complete. In order to complete it, you must ensure that you can represent all possible relationships between employees and children, including those where both parents are employees.

78 Methods Guide