I second Pat's suggestions. I will also point out that the first thing you need to do, before you try to use Access at all (other than experimentation), is to do a deep dive into your problem so you can break it down into components. You need to specifically identify what it is that you will be tracking. Since you are in a design/search phase, I will give you a couple of useful rules.
Old Programmer's Rule #1: If you can't do it on paper, you can't do it in Access.
More specifically, Access is like a hand tool. A carpenter builds furniture with tools but has blueprints as a guideline. If you don't have a good guideline, you are not ready (yet) to build anything. Or, if you prefer another metaphor, you need a good roadmap in order to know where you are going and how to get there.
Old Programmer's Rule #2: Access won't tell you anything you didn't tell it first (or tell it how to tell you).
This means that if you want XYZ in your outputs, you need a way to get XYZ as input unless you can get X, Y, and Z separately for computation. And that means that your roadmap has to include desired outputs. Then you have to assure that every possible output has an input source. This can sometimes include working backwards for every obscure field to assure that your guidelines include how to get that info.
A good design is the sine qua non for a successful project. Success starts with a usable design. Or, there is the infamous 6-P rule: Piss poor planning produces pathetic projects. So don't be afraid to stop and THINK about your project up front. That's the right time to do it.
