Define This Entity Relationship

Question

First and foremost, please forgive me for my ignorance. I am having trouble grasping how to define a particular relationship in an inventory database i am trying to design.

I intend to keep inventory on cardboard packaging. For the most part, the packaging company supplies us with one cardboard component per case design. For example, Case type x requires only 1 unit of cardboard type y to complete assembly. This was a simple "many to many" relationship for me to define. Take primary keys from tblCase and tblCardboard and create a new table tblCaseCardboard, etc...

The trouble for me is stemming from case types that require multiple components. Example: Case Type z requires cardboard components a,b,c to complete the assembly. Obviously, my previous many to many table will not solve this for me.

Im sure there is an effective way to define this relatively, instead of a crude conditional statement list to catch exceptions. Any input would be greatly appreciated! Thanks.

Answer 1

Thanks for the various input! Both @Aleks and @SJuan76 helped me see the ligh. @SJuan76 put everything into perspective in one of his comments. And @Aleks helped me realize the abstraction.

The original model was designed for 2 entities (case and cardboard). The addition of cardboard components was really the addition of a third entity. I was trying to model still the literal 2 entities.

I've just turned the finished_cardboard into an abstract, 3rd entity. The finished_cardboard is a one-to-many relationship with cardboard_components and finished_case. Thus allowing me to interact with _components from finished_case via the link from finished_cardboard.

Thanks again everyone!

Answer 2

Here you should consider modelling packaging rules, in additional to real packaging data. As you said yourself, the rules are not always trivial (n..n), but rather depend on case and component types. This fact naturally brings up the need to model rules and based on these rules be able to check the validity of a packaging structure.

In other words... IN your example you speak about "tvpes" that are not part of your model. If you want to move the correspondingn verification logic out of "a crude conditional statement", you simply need to bring it to the DB (kind of meta-modeling :))

Here is an example diagram that models your situation, as decribed.

Be sure to analyse well all possible rules, in order to cover them all. You can remove the association class if the rules are simpler than that.

Answer 3

An idealisitc many-to-many relationship between 2 entities, really means 3 entities, where there is a one-to-many relationship on onse side, and, a reversal many-to-one relationship int the other.

Usually, the two end-point entities are catalogs, or work tables, while the entity in the middle, of the two, only stores keys to the other tables, plus its own key.

Your post, is a case, where catalog tables ("Province" Table) can be confused with work tables ("Customers" Table reference "Province" Table).

...........................
..+---------------------+..
..|     <<Catalog>>     |..
..|         Case        |..
..+----------+----------+..
.............|.1...........
.............^.............
............/.\............
...........<...>...........
............\./............
.............v.............
.............|.*...........
..+----------+----------+..
..|     <<Catalog>>     |..
..|  ComponentForCase   |..
..+---------------------+..
.............|.*...........
.............^.............
............/.\............
...........<...>...........
............\./............
.............v.............
.............|.1...........
..+----------+----------+..
..|     <<Catalog>>     |..
..|  CardboardComponent |..
..+---------------------+..
...........................

This is a case, where a catalog means a header table plus a detail table, not just a single table.

Case = {CaseID, CaseEtc};

CardboardComponent = {CCID, CCShortName, CCLongDescr};

ComponentForCase = {CFCID, CaseID, CCID, Qty};

And, that only the catalogs.

Cheers.