Here are a couple of thoughts for you.
will a database structure like that allow me to go back show a history of employee compensation from when they were hired
If you want to SHOW a history of compensation, you must KEEP a history of compensation. Access can only show you what you kept. Therefore, your design must include a place to put this information. If you want everything since the person became an employee, you must KEEP everything since the person became an employee. No magic is involved. If you will want to see it later, you must keep it NOW.
Pat's suggestion of an employee salary-action table is one solution. It means you have the chance of dealing with at least a two-table join to build your report. (employee base record, employee salary-action record, joined across employee ID number as PK in base table, FK in action table)
have already created one version but I'm having trouble with it so I'm beginning to think I should rethink my structure.
Not surprising. At least 35 years ago, Nicklaus Wirth (the father of the Pascal language) said that 80%+ of all program problems were related to poor data design. I've never yet had reason to dispute him - other than perhaps his percentage estimate might have a been a bit LOW.
My best advice to you is to Google-search the term "Database Normalization" and wade through the roughly one GAZILLION references for some scholarly articles. At least 20 colleges have posts on the subject. No less than a dozen makers of databases have on-line manuals and white papers. You will get the best results from going through a normalization exercise. If you cannot get to at least 3rd normal form, you will continue to have problems. DBs requiring normalization all the way to 5th normal form are rare though not unheard-of. There are some specialized normalizations, too, that rate a name instead of a number. Trust me, it's all in Google.
