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, you can derive the �age� of the CHILD.

Derived attributes are those that may be computed from other attributes, such as totals, and therefore you do not need to directly store them. To be accurate, derived attributes need to be updated every time their derivation sources are 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 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.