Baz, you are in the design phase. During this time, you need to apply many principles and it will seem frustrating at times. But it is one of the two most important phases of an end-to-end DB project. (The other is thorough final testing.)
When designing something, you are modeling a real-world business process. You said you are tracking something using paper records. One would presume that the goal would include some type of reports. Perhaps you have a regulatory issue as well, since your intro said you are a commercial diving supervisor.
The trick will be that if you want to automate your process, you need to quantify the process. You keep paper records. Quantifying the process means to identify the steps along the way from initial data entry on paper through any and all forms of report generation. At each step, identify how you would want to do that in Access.
You have to assure that you gather all the data you need for any/all reports and other types of output. Look at whatever reports you need to turn in now while you do it via the paper trail and verify that what you need for each report is or will be captured. If you have to work backwards from the report to the input phrase in order to assure data completeness, that's OK.
The most important rule is actually simple. Don't let the tail wag the dog. If your paper process is "the real world" and is compliant with all rules, laws, statutes, or whatever else might apply (both corporate and government), then your DB app has to very closely parallel that paper process (in a virtual sense, of course.) Don't let the fact that Access is doing it change the process essentials, whatever they are. In the world of science, there is a hard-and-fast rule: If reality and math disagree, the math is wrong. The corresponding rule is that if the process and the DB disagree on how something is done, the DB is wrong.
Therefore, do this NOW: Take the time to analyze the steps of your process. Do some refresher reading on topics like database normalization. And as a tip, read up on the things you can do with queries. They are your friends. Just remember that for most of the structures created in Access, you need recordsets as data sources. Recordsets include but are not limited to tables.
Note that if you need to see your records in a particular order, you need to include a method by which you can impose that order. That is because the formal set theory axioms, rules, and theorems on which SQL is based operate on whole SETS of things without regard to order. While you and I know that a computer has to do things one step at a time, the SQL rules are such that you should see it as though every SQL call operates monolithically on the whole table at once.
People don't appreciate this right away, but tables have no inherent order. I could tell you why this is so from a mechanical standpoint but it is boring and you have other things to consider right now. Queries can impose an order based on dates, serial numbers, names, or other factors. So refresh yourself on how queries work. Look at normalization. And be prepared to take a deep dive into your own processes as you try to build a paper model of what you do.
Probably wouldn't hurt to keep your design in a document that will help you remember WHY you chose something as well as WHAT you chose for each step. This is because of an old rule that one of my first supervisors from 40+ years ago told me: Paper has a better memory than people. Having a design document means you would be able to work on this, then get sidetracked by the inevitable priorities of the moment, and then come back to it months later for some tweaking. The design document is how you keep that memory fresh enough to be able to pick it up quickly.
