>Physicly the tables are certainly not normalized, logically they are (because logically the fields are related one to one).
>
>Since you look at denormalization from the logical design. Can you give me an example of denormalization ?
>

Walter,

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.

However, having an Employee and an EmpHistory table which both have an Emp_PayRate field is not denormalized. Emp_payrate in the employee table is dependent on the Emp_id which is the primary key for the table, but Emp_PayRate in the EmpHistory is not dependent on the emp_id field but trahter on the primary key of the EmpHistory table because a given Emp_id may have different rates for different records. This si the long wasy of saving that the two Emp_PayRate fields do not have the same domain. The domain for one is "The employee's current pay rate" and the other is "The employee's pay rate at some point in time".

The design problem that I ahve with the "stacked" approach you suggest has nothing to do with normalization, it has to do with another relational design objective altogether and that is each entity should have a single discrete thing about which it records information. With the stacked approach a single entity is trying to be both current data and historical data at the same time. While with a second history table one is current and the other is historical.

Also if you carry the design requirement a little further and discover that there are more than one table that needs to track history of changes, you then need to adapt all the tables that need it for stacked tracking, while with my approach there is still only one history table that simply has to be used by mroe than one other table. Also if the data to be tracked is only poart of the full record, using the same table uses space for all fields instead of just those that require tracking, while my approach is able to be adpated to handle the decision of which field s to track.

I am not porporting that my suggested design is the only good one, only that it has advantages over the stacked design. It also has disadvantages as well, there are now two tables to deal with instead of one.