There shouldn't be multiple instances of benefits. There should just be on instance of each benefit in a Benefit table. Obviously there should be only one instance of each Employee. The relationship between the two tables would then become a many-to-many relationship with constraints. Each employee could have zero to all benefits and each benefit could have zero to all employee in the relationship. That would (should) be represented by a separate "bridge table" (probably called Employee_Benefit... I typically use the underscore only to name such bridge tables) with an Employee identifier, a Benefit identifier, and a start and end date for each Employee/Benefit pair. The table would have to have a constraint that would allow only one instance of each benefit to be active for an given employee.

A level of sophistication could be added to the Benefit table as start and end dates for the given benefit with a trigger on the table that would update the bridge table end dates when a benefit was end dated. The same would hold true for the Employee table. If an employee is "end dated", then all benefits except those must continue by law should have the same end date.