Normalization is the process that lets you look at an object and say, what are its properties? I.e. how do I describe it? The item's record needs a unique and permanent identifier, which in this discussion will be AID. The other properties might not be unique, but the important takeaway is that one record describes one example of whatever it is that the table represents. We are saying, for discussion, that the table represents cars. So each record in A is one car.
Let's say you have your table A (describing cars) with fields like this:
A.AID - autonumber, LONG integer. Think of the name as "A's ID" but just shorten it so you type less. And besides, apostrophes don't work in field names very well. Using "ID" as the name would work but has no hint (to a casual reader) as to "an ID ... of what?"
A.AName - some kind of name for an object described in table A. This is "A's Name" but again, we shorten it. But we don't shorten it down to "Name" because that is a reserved word.
A.AType - text, for which the expected values will be Ford, Toyota, Ferrarri. "A's Type" but "Type" is another reserved word...
A.ABody - text, might be COUPE or SEDAN or SUV or PICKUP or 18-WHEELER-TRACTOR or FARM TRACTOR or GOLF CART ...
A.AColor - text, might be RED or BLUE or GREEN or FUSCIA or PUCE or UGLY BROWN or ...
A.....whatever else - but NOT the status.
When you want to work only on Fords, your query will include "WHERE A.AType = 'Ford' AND AID = {some number} AND ..." - but here is the important part. You don't pick a record purely because it is a Ford. You pick an item because of its AID - which HAPPENS to be a Ford. AND if it happens in that little WHERE clause that the AID doesn't select a Ford, you would get back nothing.
Note that if someday, someone sneaks in a Lexus, you merely type in "Lexus" and the rest of the car description. That is ALL you have to do - except for those things you think are unique.
Why isn't the status in A? Because unlike the properties shown in A, the status of the item changes based on an ACTION. Table A doesn't describe actions. It describes cars.
You want to track what happens to the cars. Based on "purity of purpose" (or perhaps you might prefer "purity of representation"), table A does NOT track actions. So you need a new table, called B in this example, to track what happens to the cars. You associate the actions to the right vehicle by tagging B records with the correct AID as a FOREIGN key, a pointer back to the object - the car - for which the action occurred. You track properties of the actions in the action table, B. Because records in B match up to a record in A, and can't exist if there IS no record in A to act as a reference, we say that A is the independent table and B is the dependent table. You will also see A as the parent and B as the child based on the preferences of whoever is writing.
In your B table, you have
B.AID - LONG integer, foreign key
B.BDate - date of most recent transaction. "B's Date" but "Date" is a reserved word... (by now I'm sure you get the idea.)
B.BStatus - text, status of most recent transaction
B.BWho - text, name of person performing the transaction
B.BMileage - number, mileage on the system as of the BDate
B.....whatever else describes the action.
That query we talked about earlier would JOIN A and B on the AID field. You can get information about the object from A and about the most recent action from B using that JOIN. If you use the matching AID record with the highest date (MAX(BDate)) you will know the current status of the item referenced by the number in AID. In the B table with a WHERE clause for a given AID, you would have the chronological history of status changes for that item selected by AID.
Think about what this would look like in a spreadsheet. Half the row would be about the car; the other half would be about an action. But if the next entry is about the same AID, half the next row would repeat the information about the car; the other half would be a new action. By splitting the tables (part of the normalization process), you isolate static vs. changing descriptions. This takes up less space and makes it easier to work with the parts.
Here is the reason you have to split the tables when normalizing. There is a rule that in a table, every property must depend uniquely on the prime key (in our example, AID). The Color and Type and Body depend on the AID. No problem there. BUT the status depends on AID and the date because when someone takes an action the status changes - based on the AID AND THE DATE! So leaving the status in the A table violates the property-dependence rule. Doesn't matter if you don't store the date. Whether it is stored or not, the status depends on more than just the AID field. And that's how you know you need another table. Talking again about spreadsheets, when you see yourself having to repeat data already in a previous row, that is a sign that you need to split the table when you convert the spreadsheet to Access.
This is the start of normalization. There is SO much more to discuss, but this gives you the idea of HOW you look at your data. I would strongly advise that you do some reading before you drive yourself crazy. (Note that such an action would be in the B table...)
