You are possibly struggling over the wrong thing first. Please take this post as one man's opinion and recognize that not everyone agrees with me. Having said that, ...
Design should never start from sources. It should start from desired destinations and work backwards. You know what you want to see. So you make lists of things you want to see. Then you start breaking down those lists to find the unique items, which is to say, anything that appears once or more in any/all of your reports, forms, or queries.
Having made that list, you now figure out where you can get each one. Like, I get the client's name from the purchase order s/he filled out. I get the line items from the detail boxes of the PO form. I get the inventory SKU numbers from my own catalog. I get the supplier for each part from my own PO (outbound) forms. I get the sales tax information from a government publication. Etc. etc. etc.
Now you organize that, not by where you get it, but what it is. Good database normalization involves identifying the business entities that you need to track as part of your daily business data flow. You allocate data elements according to the thing with which they are most closely associated.
For instance, you have a list of suppliers. Each supplier has an address. Each supplier has a point-of-contact name. Each supplier has a POC phone. So they tend to go together (unless you have more than one POC for a supplier.) Let's be simple, though, and say each supplier is a small business, one POC for each.
Now let's say you have a list of parts you can sell. This list doesn't belong with the supplier who offers it. First, you might have more than one supplier of some parts. Second, a supplier might offer more than one part that you sell. So this is a different entity that must be tracked separately.
What this kind of analysis does is start defining the separate tables that you will need to provide a place to store information about each entity. This is what you will work with when building reports and such. However, now at last we come to how you merge different data sources to give you the final tables.
Your data comes to you from spreadsheets, manual data entry, transfers of files, or some other kind of input. Each of these sources contributes to the final tables in some way. What I do when I have this situation is to import the data first and then write a bunch of Append or Update queries (as appropriate) to populate the "real" tables. And you can't do this until you have designed these tables. I.e. until you have a place to put things, there is no point in worrying about importing anything because you can't.
Read the "database design" threads for articles on how to put together databases. It is not a trivial design problem unless the underlying business problem is also trivial. Remember, this is a case where being goal-oriented is a GOOD thing.
