Trying to plan out a db. Plan is attached. Advice welcome. (1 Viewer)

[Colin@Toyota]

Hello all,

I have attached a rough outline of my best efforts at designing a normalized db. For anyone with some questions, rather than retype a whole page or so of information, I will direct you here first.

Thank you for any and all suggestions.

Colin

 

[CraigDolphin]

Colin,

did you look at the example db I did for you before? I think your data model fails to capture the nuances of the real-world situation which you described in your other thread. For example, you discussed wanting to track multiple vehicle parts, for each of various makes and models of vehicle, all associated with a single SETR, but you have no mechanism in your data model to handle this.

Have a look at the attached jpg. I've added a couple of tables based on your diagram where needed (engineers, venders, locations) and highlighted the junction tables so you can tell them apart. Junction tables are necessary wherever a many-to-many relationship potentially exists.

If you need to track requests by engineers as well, then another table may be necessary to list engineer with request date etc. If so, then you'd be better to store the Requestid instead of the Engineerid in the SETR table.

Incidentally, I think you misindentified the one end of the one-to-many end of your link between your tblSETRs and tblRequest