This forum has an excellent search function. Try the following topics:
Inventory, Normalization, Design (separate topics, not combined)
Pat's advice is on the mark, but perhaps you need another viewpoint.
To build a database that relates to you business, you are building a MODEL of that business. You must identify the entities (perhaps you would prefer OBJECTS) and their properties. Here is an example of the thought process.
If you track PCs, an obvious entity is the PC table. If you also sell parts, you need a Parts table. If you sell pre-packaged software, you need a SWPackage table. If you sell services, you will also need to consider service contracts and work orders, stuff like that. Identify what your business works with.
If you sell things, you need sales orders (sales invoices?). If you buy things, you need purchace orders. These represent transactions to raise or lower your inventory levels.
In other words, imagine your business transacted on paper FIRST. Because there is an "old programmer's rule" that says, "If you can't do it on paper, you won't do it in Access."