Rx_
Nothing In Moderation
- Local time
- Today, 11:05
- Joined
- Oct 22, 2009
- Messages
- 2,803
This book was published 10 years ago. At the time they had a link to download the MS Access DB that it references in the chapters. Well, the link was broken so I had the book but no example.
After many hours of searching, the mdb was posted at some old college site.
For anyone who buys the book, here is the sample DB discussed.
This isn't a small database. The example shows how to make a very simple Expense Report that is bound by business rules.
Overall, the book helped define the concept of Business Rules. It is the only Business Rule design that I found that actually uses MSAccess for a demo. Be advised, they recommend using a language such as C++ to create objects inside of functions.
Also included is a sample PDF for another book on the subject. Different writer style but the same concepts.
Is writing a Business Rule advisable using MSAccess?
The short answer is yes.
There are different levels of certified Business Rule Engine developers. The author of this one gets into the details of the design. Much like a Database design requires the different levels of Normalization and Naming Conventions, there are concepts for Metadata and Rule Language development. When someone looks at a modern Assembly Line production, every bit of efficiency really counts. So the dollars spent on this kind of design are huge. Look at the size and details of this Expense Report. it isn't anything a client would ask us to do.
My task was to take the very complex oil/gas regulatory (permit, right-of-way, minerals, environmental, GIS, and much more) assembly line for a dozen government agencies and work-flow-management and create a Rule Engine.
Using Access to go to the level this book defines would be near impossible without creating some class objects in C# that Access could reference in code. However, the infinite details described can be done in a combination of Access and SQL Server at a lesser level. The advantage of Access was the extremely rapid prototype to show results. My task included showing results to a group of SME (Subject Matter Experts) and getting feedback.
The Regulatory process is not constant. Different States have different conditions. Then there are all of the regulatory agencies (Federal, Tribal, EPA, ... even the FAA) that have conditions. Process documentation hardly exist. Then there is the GIS interface and much more.
If I were to equate this with Normalization, the first level was followed.
The rule engine allows a user to make whatever change in one of 16 forms that each have massive rules on what fields can be used or what values can be entered in some combination. At the end, a series of functions against the DB back-end evaluate metadata and automatically change specific Status values as needed.
The first version had a lot of hard coded functions. But, it was a rapid prototype and verified by the SME. It served to show how many exceptions to combinations there could be. Lets estimate 300 screens of code functions.
Once that was working, the second version took all of the code into account and was defined with set diagrams. The code on the second version is much, much smaller. There are now meta-data tables (results) created that return only a True/False in each column for each Rule. Now there is the introduction of Profile tables that evaluate the meta-data results. They compare a True/False/Neither against the meta-data results.
This means that the end user (SME) can define new profiles or modify existing outcome with a form tied to these tables.
This book was the inspiration for this concept.
While I can't take all of the credit. The automation has added a new level of Quality Control and Work-Flow-Management for efficiently assigning task.
In the end, the Rule Engine might be better written (third version) in something like dot Net.
In the mean-time, an Access version can run off on the side, stand-alone since it evaluates data independent of any form. While some of the system wide full DB evaluations take 20 to 40 minutes they save untold hours of time and mistakes when compared to user audits.
Lets say a company DB with under 100 users would benefit with using Access as a Rule Engine. For huge projects like an assembly line, Access would not be the choice for an enterprise application.
How to Build a Business Rules Engine: Extending Application Functionality through Metadata Engineering
Business rules engines can make organizations more agile by allowing them to manage diverse sets of operating rules, such as many different contracts for goods and services with different clients. For example, business rules engines can contain interfaces that allow users to define business rules to add specific functionality to software applications in order to take advantage of particular business arrangements. This enables organizations to overcome the barriers of time, money, and reliability that traditional programming approaches present when trying to include variable business situations within information systems. Rules engines can also speed software implementation, provide increased auditability, and ensure engineering compliance. The capacity to understand and manage business rules outside of the "black box" of program code can improve the overall quality of IT infrastructures.
ISBN: 1558609180
ISBN-13: 9781558609181
After many hours of searching, the mdb was posted at some old college site.
For anyone who buys the book, here is the sample DB discussed.
This isn't a small database. The example shows how to make a very simple Expense Report that is bound by business rules.
Overall, the book helped define the concept of Business Rules. It is the only Business Rule design that I found that actually uses MSAccess for a demo. Be advised, they recommend using a language such as C++ to create objects inside of functions.
Also included is a sample PDF for another book on the subject. Different writer style but the same concepts.
Is writing a Business Rule advisable using MSAccess?
The short answer is yes.
There are different levels of certified Business Rule Engine developers. The author of this one gets into the details of the design. Much like a Database design requires the different levels of Normalization and Naming Conventions, there are concepts for Metadata and Rule Language development. When someone looks at a modern Assembly Line production, every bit of efficiency really counts. So the dollars spent on this kind of design are huge. Look at the size and details of this Expense Report. it isn't anything a client would ask us to do.
My task was to take the very complex oil/gas regulatory (permit, right-of-way, minerals, environmental, GIS, and much more) assembly line for a dozen government agencies and work-flow-management and create a Rule Engine.
Using Access to go to the level this book defines would be near impossible without creating some class objects in C# that Access could reference in code. However, the infinite details described can be done in a combination of Access and SQL Server at a lesser level. The advantage of Access was the extremely rapid prototype to show results. My task included showing results to a group of SME (Subject Matter Experts) and getting feedback.
The Regulatory process is not constant. Different States have different conditions. Then there are all of the regulatory agencies (Federal, Tribal, EPA, ... even the FAA) that have conditions. Process documentation hardly exist. Then there is the GIS interface and much more.
If I were to equate this with Normalization, the first level was followed.
The rule engine allows a user to make whatever change in one of 16 forms that each have massive rules on what fields can be used or what values can be entered in some combination. At the end, a series of functions against the DB back-end evaluate metadata and automatically change specific Status values as needed.
The first version had a lot of hard coded functions. But, it was a rapid prototype and verified by the SME. It served to show how many exceptions to combinations there could be. Lets estimate 300 screens of code functions.
Once that was working, the second version took all of the code into account and was defined with set diagrams. The code on the second version is much, much smaller. There are now meta-data tables (results) created that return only a True/False in each column for each Rule. Now there is the introduction of Profile tables that evaluate the meta-data results. They compare a True/False/Neither against the meta-data results.
This means that the end user (SME) can define new profiles or modify existing outcome with a form tied to these tables.
This book was the inspiration for this concept.
While I can't take all of the credit. The automation has added a new level of Quality Control and Work-Flow-Management for efficiently assigning task.
In the end, the Rule Engine might be better written (third version) in something like dot Net.
In the mean-time, an Access version can run off on the side, stand-alone since it evaluates data independent of any form. While some of the system wide full DB evaluations take 20 to 40 minutes they save untold hours of time and mistakes when compared to user audits.
Lets say a company DB with under 100 users would benefit with using Access as a Rule Engine. For huge projects like an assembly line, Access would not be the choice for an enterprise application.
How to Build a Business Rules Engine: Extending Application Functionality through Metadata Engineering
Business rules engines can make organizations more agile by allowing them to manage diverse sets of operating rules, such as many different contracts for goods and services with different clients. For example, business rules engines can contain interfaces that allow users to define business rules to add specific functionality to software applications in order to take advantage of particular business arrangements. This enables organizations to overcome the barriers of time, money, and reliability that traditional programming approaches present when trying to include variable business situations within information systems. Rules engines can also speed software implementation, provide increased auditability, and ensure engineering compliance. The capacity to understand and manage business rules outside of the "black box" of program code can improve the overall quality of IT infrastructures.
ISBN: 1558609180
ISBN-13: 9781558609181