Is this type of functionality done at form level, not table?

[jdraw]

Your ERD is a reflection of your business rules. If you have rogue processes or undefined processes to change your software configurations/installs, then you have a discipline issue. And that can't be resolved by a database. This is basic data management/information management.

I doubt it is the ERD that is causing your frustration --I'd put my money on the more analysis, the more variables you're finding. Sounds to me you have some ill defined processes that are just being identified.

Your ERD can be tested before you build your database. It will become your blueprint.

See my comments on "stump the model" here. and more here.

 

[MarkK]

It seems self-evident to me that a Request and an Install are discrete and distinct objects in the real-world. They occur on different dates, they are generated and executed by different people, and the existence of one does not necessitate the existence of the other.

And you should be able to track how many requests were not fulfilled, how many were modified on consultation, and how many were generated by your admins, not your users, and so on. Then you create a tool that does more than just keeps track what happened, it also keeps track of what failed to happen.

Like, imagine if your system could tell you that 35% of requests are modified, so the Installed item ends up being different than the Requested item. This is why nothing should be deleted or overwritten. Always add a record. Build a system where every significant event is recorded, dated, and available for analysis. If 35% of requests are modified, then people making requests need more training. These are real-world facts a good system should deliver, facts that enable you to make better business decisions.

Hope this helps,

 

[NBRJ]

It seems self-evident to me that a Request and an Install are discrete and distinct objects in the real-world. They occur on different dates, they are generated and executed by different people, and the existence of one does not necessitate the existence of the other.

And you should be able to track how many requests were not fulfilled, how many were modified on consultation, and how many were generated by your admins, not your users, and so on. Then you create a tool that does more than just keeps track what happened, it also keeps track of what failed to happen.

Like, imagine if your system could tell you that 35% of requests are modified, so the Installed item ends up being different than the Requested item. This is why nothing should be deleted or overwritten. Always add a record. Build a system where every significant event is recorded, dated, and available for analysis. If 35% of requests are modified, then people making requests need more training. These are real-world facts a good system should deliver, facts that enable you to make better business decisions.

Hope this helps,

It really, really does. Thank you. I had a moment of clarity yesterday evening as a result of it. Thank you! I now have another relationships query, but that's a seperate post.