I still think you are jumoping the gin
as this is an early db design I think it would be a good idea to go through the normalistation process... why because it helps beginners understand the process, why (relational) databases are designed the way they are

if it helps you shoudl only ever store a piece of infroamtion once... so that if you update it you only update it once (think of the possible chaos your original system will have if say someone decides to move a product from one category to another.

the number of tables is irrelevant, each table should hold infroamtion that is unique to that level. so if you were recording a sale traditionally you would have two tables recording that sale...

...one contains the date and time of the transaction plus anything else that woudl be relevant to that transaction (eg custoemr No, type of payment any dicounts, arguably any tax and possibly the transaction value if you cna justify it for performance reasons

...one contains the dealtis of the transactions ie what product(s), waht quantity, any line discount

at each level you do not store detail if that detail exists elsewhere.. so you wouldn't store the product name and description you would store a value which points to the detail of the product in the products table.

so if you need to identify a computer that handled the transaction you would want to associate that trasnaction at the order header level as its only relevant to the dtae and time of the sale, not the individual products sold. OK we don't know the business logic for you so it may make sense to do away with the order header table and store the foreign key to the computer as part of the sales detail table

So that means you need a separate table for the computer/machines which will becoem a foreign key in the sales header or sales detail table if you don't have a sales header table

one of the reasons its done that way is fer instance
data integrity... when gettign humans to look at the data your users can refer tot he computer in the style they are familar, and the dataabse can store the data in a compact form readable to itself.
data entry errors are reduced becuase instead of typing a number it become text based (look at combo boxes as a display paradigm)
if you use a text representation of the computer "MyComputer" isn't neccessarily the same as "MYCOMPUTER" or "mycomputer" so you reduce the potetnaiul risk of errors by enforcing a constraint which says to accept the the input of product category in a product definition then the product category must already exist in the prodcut categories table. furthermore you can also enforce a constrain that says you cannot delete a product category whilst there are products defined already using that category
as said before I think you need to bone up on normalisation