I'd like to see if someone could clue me in on whatever it is that prevents me from being able to understand how to work with multiple tables and relationships?
Probably not. Likely could only try to explain it, but it's been extensively documented so there's lots for you to read. I think fundamental is to think in terms of entities (tables) and attributes (fields). This is just an example for illustration:
A PO is an entity with attributes like number id, date created, status, who created, etc. A line item ordered on that PO is not an attribute of the PO, it is an attribute of the entity POLine. One way to tell is that the PO can exist and have no line items yet. Another is that you'd need a field for every line item (repeating fields) and that is a huge no-no. You link the line items to the PO by including the primary key field from PO table in the line items table as a foreign key and the items table has its own primary key.
That's somewhat simplistic but I'll stop there since the subject is too big for covering in a forum thread. Deciding what is an entity and what is an attribute is often the hardest part of designing, and it really depends on the business that a db is going to support. A flat file is mainly for data storage and makes for a very poor relational db design. If you do that, I'm confident that you'll regret it - and we'll see a lot of your posts here and there.
I have links for other important topics but they're much use if you follow the flat file approach. See if these help with normalization.
Normalization Parts I, II, III, IV, and V
http://rogersaccessblog.blogspot.com...on-part-i.html
and/or
http://holowczak.com/database-normalization/
Entity-Relationship Diagramming: Part I, II, III and IV
http://rogersaccessblog.blogspot.com...ng-part-i.html
How do I Create an Application in Microsoft Access?
http://rogersaccessblog.blogspot.com...cation-in.html
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.