Emma,
I was not suggesting Personnel records etc per se. I was simply trying to identify clearly the subjects you are dealing with and how they are related. You can assign attributes to the entities/tables as appropriate. My intent was only to separate the entities and name them so their purpose was clear.
In my view if you start programming/interfacing before you have a data model that can support the business area and can satisfy some test data/sample general info, you will get lost in the details of Access and syntax.
If you read posts in most forums, people do not do their design effort up front. To me that is data model, normalization, naming and playing "stump the model with some general test data". It isn't the only approach, but it is one tested and tried that works.
If you step back and take a broad view, personnel is dealing with the "employee", and you are dealing with that same "employee" and his her qualifications for positions and the requirements of those positions. Information in the 2 systems may be brought together to understand this "employee" and his/her training, job history, training plans....
Good luck with your project.