Difficult to say without understanding exactly what the db is supposed to support. Doesn't help me that I can't read the names - not saying that's something you should rectify, just saying my suggestions are somewhat hampered by those factors. The first you could 'fix' the latter you are not expected to fix. So -
perhaps what you should have is your 2 field table (I interpret that as a SAP identifier and a field that denotes what part that is for. If that isn't "Tubie" or "endplates" then I don't know)
then a table of materials used in every part
then one table for parts
then junction table for materials to parts (assuming material is used in more than one part). Not sure what else due to lack of understanding the process.
With properly designed form(s) you should be able to select (combo) SAP#, get the part info and show a list for all the materials used in that part. I'm not seeing a way to connect the drawing number related to the part (I'm assuming a part is a given thing, like a product, and not an instance or reproduction of a part. That would be a "job" or "order" to my way of thinking).
Your design won't pass the 'acid' test for normalization because you're creating a table for each iteration of an entity (part). Say you have a query that relates SAP to a part. You need x queries for x parts, or if you add a table for a new part and there is a basic query that joins all your current tables, then you must add this new part table and modify the query design, as well as any forms and reports that rely on it. That is an acid test for normalization. All parts should be in one table. If you need to relate attributes of parts that are not universal (e.g. something square has no diameter) that's where junction tables come in.
EDIT - forgot to say that in addition to comments about 1 to 1 relationships it is usually a sign of improper design where a table has nothing but primary keys.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.