In short can you please look at my ERD to see if the relationships look proper, and it looks like good design?

http://www.mysticfields.com/database/ERD.jpg

More details:

Hi new user, first time poster here,

I am a college student, aspiring IT guy studying databases. I am trying to make a database for a company who creates hermetically sealed connectors. I plan on using Filemaker pro 9 to eventually develop the database but right now I am trying to create an ERD. Currently they are using an old legacy Dbase2 non-relational database, non-networked database, which they back up to floppies and share among a few computers where they access the database.

So you can see how this networked, relational database is going to be a big improvement, if done right. The scope of the database will be limited to the order entry process, and keeping track of inventory.

My vision is to have a customer call in to place an order for let’s say 50 part X. The employee will take the order, and the database will check current inventory, and tell the employee we have 25 part X in stock, we need to create additional 25 part X to complete order.

It will then check to see which components are needed to make part X, and check the current component inventory, then give a similar breakdown of available components / components needed.

It will also handle general billing, shipping, and keep track of suppliers who supply components when they are needed for reorder.

So with this in mind, I was wondering if you experts out there could look at the general ERD and tell me if the relationships look correct, and I have the appropriate tables needed to make my vision come to life. I am about 75% through with reading Database Design for Mere Mortals by Michal J. Hernandez and about 35% into FileMaker Pro 9 The Missing Manual. I want to do this thing right before I start actually creating forms and the-such. Many, many thanks!!!

Relationships

One - Many
A customer can make one or more orders.
An order can only be made by one customer.

One - Many
An order can only have one shipping method.
A shipping method can be associated with many orders.

Many - Many
A person can order one or more parts.
A part can be associated with one or more orders.

Many - Many
A part consists of many components.
A component can be used in the creation of many parts.

One - Many
A series can be associated with many different parts.
A part can only be associated with one series.

One - Many
A type of part can be associated with many different parts.
A part can only be of one type.

Many - Many
A supplier can supply one or more components.
A component can have one or more suppliers.

looks fabulous

except i wouldn't have a separate table for components, i would just use the parts table

so instead of

PART ---< PART-DETAILS >--- COMPONENT

i would have

PART
| |
^ ^
PART_DETAIL

with two one-to-many relationships, one for "part uses part (as component)" and the other for "part used by part (as component)"

Thank you for your response that makes good sense to just have a part details table and get rid of the component table. Much thanks!