OK, I'll give you the "professorial" response since you can't supply a detailed explanation of the data you are storing.
In general, you are mapping something when you design a database. If it is related to business, you are mapping tables to business entities. If it is your home CD collection, you are mapping tables to entertainment entities. Etc.
So start by looking at what you are trying to do. Here is Doc's Rule: If you can't represent it on paper, you will NEVER represent it in Access. Sometimes I use sticky notes to design tables, using a white-board with dry markers to draw relationship lines. OK, the next questions are RHETORICAL and you don't have to answer them to me. Only to yourself.
First question: What are you representing? Abstractions? Concretia? Both? Each time you identify a new thing to be represented, it will either be a new record in a "thing" table or a candidate for being the basis of a new table.
Second question: How many distinct types of things are you representing? You should never have more basic tables than you have types of things, and often you have less tables.
Third question: How often does a descriptive term come up in your records? When you can identify a commonly-used description or attribute, you just found a candidate for a table listing those attributes.
In the final analysis, you are building tables to represent entities related to the real-world business or process you are defining. For instance, in a business you would have employees, leading pretty quickly to an employee table. You might have sales, leading to a sales-order table. You might have departments at your office, leading to a department table.
Let's try another topic. Suppose you are cataloging your CD collection. You have a bunch of CDs. OK, there's a candidate table. They tend to be spread over several categories of music. There's a candidate (attribute) table - the category/genre. They are by various artists. There's another candidate table - the artist list. Each one has several tracks with distinct titles. There's a candidate - the selection-title table.
Do you see the mind-set you have to use? Things in tables can be concrete (the CD) or abstract (the genre). But they represent discrete things or facts or attributes you want to track. And they almost automatically indicate relationships. I.e. CDs have tracks, genres, and artists.
This is the first step in defining tables. Spend some time up front before you try to write too much or cast too much into stone. Because it makes a big difference down the road if you get it right quickly and don't have to go back to retrofit every few days or weeks.
. BUT (and this goes against the grain) is it an issue for you 
. But if it works fine the way it is, why fix something that aint broke 
?
