While Bullschmidt's suggestion would work, and I am a known pragmatist, there IS a relatively minor objection. Putting the pay rate in the paycheck is TECHNICALLY a normalization violation because the pay check and the pay rate are two different entities that don't have a two-way dependency on each other. It is a one-way dependency.
The pay rate depends on the employee number and the date whereas other basic employee data would only depend on the employee number. Therefore, the pay rate should not be in the employee table. (Dependency differences mean "not the same class of entity.") But if you put the rate in the paycheck record, the problem is that strictly speaking, the rate doesn't depend on the paycheck number AND one can legitimitely discuss the pay rate in the absence of the paycheck. And the other side of that coin is that more than one paycheck would have the same rate, thus meaning that to identify the pay rate, you would have a non-unique selector because you would have to pick a paycheck having that rate. There is the impurity.
The TECHNICALLY correct structure is a pay-rate table with the employee ID, the starting date, the ending date, and the pay rate for all days between the two dates. Plus, if you needed it, any descriptive info or codes about the cause for the change in pay rates. Like simple merit raise, cost of living raise, raise concomitant with promotion, etc. And for the record with the current pay rate, you don't have an ending date so you FAKE one. For instance, you could make the ending date 31-Dec-9999, which works in an Access date field and is a legal, legit, and consistent value to use. Then the current rate for a given employee is that ray-rate record where the starting date is less than the current date and the ending date is greater than the current date.