Too many replies while I was out... Very helpful tips from all of you though... I will comment on all of your points:
"Dealers" class is too limiting. Actually, they're not the only "people" the user is going to interact with. You have customers, suppliers, contacts, ...
I initially had it as "Suppliers" and "Customers", but they both have the same exact attributes, so I thought I'd put them both into the same table and distinguish them by a "type" attribute. The name "Dealers" is only because I couldn't find some other name, I guess "Partners" should do.
The second one, I recommend, create an abstract class Partner and work some inheritance magic to create different classes like "Customer", "Suppliers", ... In this case you should absolutely look into JOIN tables
That's exactly what should be done IMHO. I'll worry about the code later on though, it's going to cause some issues with class mapping and the Flash remoting stuff but I'll figure it out.
Where's your inventory? Aren't you supposed to manage the stock?
The inventory is basically the Categories and the Products which belong to these categories. Do I really need an Inventory table? What should go there?
Review your Product -> Products_Invoices -> Invoices relationship. Invoices should contain the product_id.
I'm still trying to find a suitable solution for this issue. I believe this is similar to the HABTM relationship in CakePHP. The invoice might contain a single product, and may contain several products. I cannot just use the product_id inside the Invoices table.
What is a Operation? If by that you mean the purchase of products from suppliers, you should not separate them. A purchase should be seen as a Transaction, just like a Sale. Both actions have a lot in common, you don't want to duplicate the code.
Ah right! I should've called it "Transactions". Basically, the concept of Operations as I intended it to be is buying products from suppliers and selling products to customers.
Learn UML. I have no idea what you diagram is supposed to represent. Classes? Tables? ... UML is great for these matters.
I do know the basics of UML. The diagram I've provided is supposed to represent tables. I wanted to do something similar to what Ayman provided, but the tool I used did not contain these shapes.
@arithma: I think I got your point but to be honest that wasn't very helpful. What do you mean by Modules A,B and C? Do you intend to say that the logic of each one of the three should be separate from the other while they can still interact using parameters?
@Ayman: You are missing a few things in your diagram, and adding a few actually. I think a Categories table is mandatory, because just like rahmu said in his last post, the user (my relative) might need to add a new category (which will most likely happen). Plus I find it a better way to organize things into tables rather than using attributes. Moreover, the category isn't actually an attribute or a characteristic of a product, a category is the parent of a product, hence it needs to have its own table.
Ok so what now? How can I fix my models? Any ideas?