Bill of materials database model

Question

I\'m currently working on a project which should help us with our inventory control as well as our purchases to assembly our final product.

We\'re in the stage of mo

Answer 1

It sounds like you might have two kinds of products. One is the 'atomic' part and the other is the 'compound' end product. I would store those in two separate tables, since they both need different pieces of information.

The CompoundProduct table will need a child table as well that links the part to the end product.

If you like, you can still have an 'abstract' product table that contains all products: parts as well as end products. In this table you can store a code and the name, and it is convenient to have one table of products that can be bought and displayed on an order or invoice. Both the Part table as the CompoundProduct table can then have a product id that is a foreign key to the abstract product table, but is unique in Part and CompoundProduct as well.

So in general, this database scheme is powerful and flexible, but I think it is not complete enough, or maybe too flexible for your want.

Answer 2

The models you linked fail to address some major properties BOMs normally have:

• Parts and sub-assemblies can be reused. For example, it is common for a same kind of bolt to be used in many assemblies.
• There needs to be a BOM-specific quantity. For example, it's important to know that one assembly needs (say) 50 bolts, but the other assembly might only need 30 of the same kind of bolt.

Here is a simple model that addresses these concerns:

The PART table is either a top-assembly or a sub-assembly or a leaf part. It uses a publicly known "part number" to identify its rows, which is not actually a number at all and can contain non-numeric characters.

The BOM table models many-to-many relationship of PART by itself. It's really no different from any other junction table, except both "endpoint" tables are actually the same table. This way, one sub-assembly or part can be reused in multiple parent assemblies.

On top of this model, you can fairly naturally add things like "drawing position" or "unit of measure" (e.g. a paint can be part of BOM but is measured in "kilograms" instead of "pieces").

---

There are more things you might want to do in reality, but are beyond the scope of a simple StackOverflow post like this.

For example:

• How do you handle change? Do you have part versioning? Do you version the BOM itself?
• Different suppliers might use different part numbers for the essentially same part.
• You might want to keep track of "sites" (warehouses or factories) where parts are stored or assembled/produced. A "same" assembly might even have slightly different BOM for different sites.
• You might want to differentiate between "made" and "purchased" parts.
• Do you have a lifecycle workflow (approve/release/obsolete)?
• You might want to store user-defined attributes. Attributes typically includes things such as mass, volume and material, but there may be many others that cannot be foreseen in advance.
• You might want to connect the physical CAD models to the data in the database.
• You might want to disallow certain users from doing certain changes to the database (e.g. procurement department shouldn't be able to change the assembly structure, at least not without supervision).
• Etc, etc...

These are some of the reasons why real PDM systems tend to be complex. If you actually need all that functionality, you should probably consider using a commercial product instead of trying to re-implement it yourself...