I have a growing respect for the business rules approach to system design. For instance, entities and relationships as drawn in a traditional entity/relationship (E/R) diagram are representations of business rules about what data your system will read, update, store and write and how various pieces of that data are related. This is implemented as tables, columns, keys, referencial integrity, constraints, and triggers. However, these same implementation methods and languages also need to include implementations of other business rules that cannot be easily depicted on E/R diagrams, such as entity life cycles and use cases.
The trouble is in translating rules to code, mostly because the code can vary in language and place of implementatation according to what kind of business rule you are trying to implement. One approach that is seeing some success, is to include all business rules in a rule database, and using generators to translate the rules into code. One interesting thing to note is that most of the code associated with the rules has nothing to do with the presentation layer - the GUI that most users see. This means that once you have defined the logical subset of data that a module will use, you can set developers free to "just code" a simple module based on that data - providing that it has good error handling for whatever informational, warning and error messages the code enforcing the rules may send back. Where is this code? In the database and/or application server, not in the Forms or Java or whatever code that provides the GUI. -----Original Message----- Sent: Friday, August 22, 2003 9:49 AM To: Multiple recipients of list ORACLE-L I know this is big in the ODTUG circles. Has anyone used this approach to design databases? Seems promising. Though the hardest part would be in convincing the 'i just want to code' folks to adapt it. I havent really read that much into it. It also appears that the level of skill and experience required at the upper levels of the project would have to be quite high to make this work. anyone have an opinion? (see jared, now we have a database design post). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Flack INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
