Megan, there are perhaps a gazillion ways to approach this beast. First, let me point you to the Search function of this forum, which is 3rd from the right on the thin blue ribbon that runs just underneath the box at the top of the page that tells who you are.
Your intro told in the "Welcome" topic told us you are new to Access. Let me therefore give you a reading assignment before I answer your question more directly. You might wish to search for these topics:
1. Database normalization. You can search for "normalization" inside the forum because we are a dedicated-topic site. For the general web, make that "database normalization." Then limit yourself to college sites and the ubiquitous Wikipedia.ORG article.s.
2. Modeling. Access is a way to make a data model of your business. The ideal case would be that you can make "the map the same as the territory" with a good model, and then you can track anything you need.
3. Junction tables. This will figure prominently in the answer to your question. This is a way to track many-to-many relationships - and your question contains one.
4. Assemblies - because I recall at least a few posts where the topic was similar to yours, where a company made assemblies of components, wanted to track both components and assemblies, and the relationship was ugly.
5. Synthetic keys - or you could try "autonumbers" - because the odds are that SOMEWHERE along the line you will need to have a unique but arbitrary key for table linkages (see "normalization" for what that means.)
6. JOIN queries - which will be workhorses for your inventory because you will work on queries that join tables together to merge the information from each table in a specific way. Look up Relationships when you are working on "normalization" because this topic (JOIN + relationships) is a major part of normalization.
OK, once you've satisfied the reading suggestion, or have determined that you already knew that, the way I might approach this is:
1. Table of products (assemblies) - with a suitable primary key (PK), name of the product, other data about the product AS A WHOLE but NOTHING about its parts.
2. Table of components - with a suitable PK, name of component, units of components (i.e. per unit, per kilogram, per foot, ...)
3. Junction table of "recipes" - where you have a foreign key (FK) to the product and a foreign key to the component. Plus perhaps how much of the component is consumed in making the product. You will have ONE recipe entry PER product PER ingredient. So there will be many entries for a product, one for each component. You will have many entries, one per product you make. If there is overlap of components then you will sometimes have several records for the same component, one for each product that uses that thing.
4. Transaction table - where you track arrival, consumption, sale, shrinkage, and manual corrections for components (and, for that matter, products). This is basically how you know how much is on hand. You NEVER EVER IN A GAZILLIOIN YEARS want to store the currently available amount in the component table. Instead, you build a summation query grouped by the component's PK. Each transaction is either a gain or a loss of the item being tracked, so the amount for the summation is either positive or negative. From this table, you can determine exactly how much of some component should be on hand at the beginning of the day. Every time you make a product, you have to generate a loss of components according to the recipe.
You will have transaction type (which helps you decide whether the amount is a gain or loss), the amount, the date, and if you are tracking cost, then you can store the cost of the components (usually per unit). I have run across such transactions as "Consumed" (part of the manufacturing process), "Sold", "Bought", "Returned", "Adjustment" (due to errors in inventory or due to damaged material). There could be others, it's up to you and your business model.
This basic layout (plus many bells and whistles) would allow you to write queries that sum the cost of all components in a recipe. Since you can do grouping in queries by date, you could do time-based projections of consumption. I'm sure you will find MANY good discussions using the search feature.
