what do you see as wrong? the ERD looks fine to me
to implement a many-to-many relationship, an intermediate association or relationship table is required, which has columns that are FKs to the respective many-to-many tables, and a composite PK for the relationship table
Hey R937, Thanks for your reply, im just having trouble understanding.
Well if i create this database using the entities in the ERD. What would happen if i just stored the OrderID in the Materials Table with the QTY and the CustomerID?
Woudl this not achieve the same results in access?
No because then the key of Materials would presumably have to be (MaterialCode, OrderId, CustomerId) and you would therefore have to populate a Qty for each combination of MaterialCode, OrderId and CustomerId. Is that what you intended? If so, then your current diagram is wrong because it only has ONE Qty per MaterialCode.
This is an example of what data modellers call a dependency: "x determines Qty". To be sure you model your database correctly you need to identify dependencies before you start.
The rules being applied by your CASE tool are the principles of Normalization. Roughly speaking, the relevant rule is that the determinant for every (non-trivial) dependency should be a super key (the "determinant" is what I referred to as "x" above). If you aren't familiar with that idea then it would be a good idea to study a decent book on database modelling to help you understand what your CASE tool is trying to do.
Again thank you for your response.
I think your right. My ERD is wrong. I want to have multiple QTY for each material, ie could have 500 Screws related to this OrderID.
Then again, wouldnt it be many to many as i can place another order for some screws again? (MANY screws can be on MANY Orders?)
All i want is to create a database where i can see what "materials" and/or "Tools" a Order associated to and Which customer Ordered it.