>I posted an example of dnormalization in another message. You remployee name is
>wexample is denormalized and it has nothing to do with redundant fields. The rule that is broken is the 3rd Normal form, "All fields are dependent on ONLY the primary key and not on any non-key attribute other than alternate keys." The employee name field in the travle table are dependent on the primary key, yes. But they are also dependent on the emp_id which is not an alternate key for that table. Thus the design is denormalized.

There is one denormalized thing I intend to introduce here ASAP, that's the person's fullname. I've discovered that the full name (like Nedeljkovic, Dragan A.) is constructed from lastname, firstname, middlename fields hundreds of times - and for mere performance reasons I intend it to be stored as a separate field, and recalculated only in event on any edits on any part of the name. This field would never be editable directly, so I think I'll be able to keep it in sync with the fields it's derived from, and it would be recalculated only once, instead of hundreds of times for each report.

Other than such speed issues, I don't really see any good reason to keep denormalized data.