Posts tagged rulegen
Implementation of a moderately complex data constraint business rule using RuleGen 3.0
Aug 14th
In a previous article, I have introduced RuleGen 3.0 – a 2nd generation business rule implementation framework for the Oracle Database: http://technology.amis.nl/blog/?p=12807. RuleGen provides a solid, structured, scalable framework for database developers to implement data constraints in. This article demonstrates how a moderately complex rule is analyzed and designed and implemented with RuleGen 3.0. If you want to try out RuleGen yourself, you can download the framework under trial conditions from http://www.rulegen.com/free-download .
This article illustrates the essential steps in the business rule design and build process:
-
describe the business in human readable format – preferably using names of entities and attributes or even better tables and columns
-
analyze the events that potentially violate the business rule and should therefore trigger evaluation of the rule
-
define the filter condition (a SQL expression) that identifies the records that should be checked for each triggering event (typically only a very small subset of the records in a table need to be explicitly validated upon an event)
-
define the rule validation logic in terms of SQL – write the SQL query that should not return any records in order for the rule to be valid
-
record the events, the filter conditions and the validation SQL in the RuleGen design time UI
-
configure additional characteristics of the rule – such as validation time (statement or transaction), enabled status and log-setting
-
generate the rule implementation code and deploy the rule to the run time environment
note that these steps only involve a minimum of programming: typically two or three relatively simple SQL queries. No PL/SQL programming is involved. No additional tools (besides the APEX UI of RuleGen or its APIs) are required.
The rule that I will implement in this article is specified in the context of a familiar data model – see the figure below:

The rule that needs to be enforced is: “Employees who are a SALESREP should not work for a department that is located in Amsterdam”. We will not be discussing the business meaning of this rule in this article – we take this rule as the outcome of careful analysis of our business. Our responsibility is to ensure that no data will enter our enterprise database that does not comply with this rule.
RuleGen 3.0 – the latest, leanest and most robust solution for complex data constraints in an Oracle Database
Jul 6th
No matter how complex the enterprise and application architectures become, no matter the number of tiers, services, devices and user interfaces – at the heart of most enterprises will be a relational database.

And no matter how hard we try to implement a fully service based architecture or a multi-purpose business tier (for example using EJBs) – we will have multiple routes to the database and the data in it. Data will be manipulated through web applications, web services, client/server applications, batch database jobs, application managers working directly against the database from the command line or TOAD-like tools. If for no other reason – that by itself is an overridding motivation for enforcing every data constraint at the lowest possible level – the one level that none of these channels can avoid: the database itself. In addition to the fact that only enforcement inside the database can provide real integrity (and what the hack would be semi-real integrity?), for most data rules (especially complex ones) implementation inside the database is the most performant, scalable, maintainable, managable, agile, elegant and easy to implement as well.
Note: I am not advocating that data rules should not be implemented in other tiers as well. For the purpose of user friendliness through quick feedback and preventing incorrect data from ever getting near the database, it is of course perfectly fine to specify required fields, fields with a certainly length or a domain with allowable values in user interfaces and/or describe and enforce data constraints in the POJO Domain Model and the XSDs for the canonical data model of the ESB. However: all of these are only supplemental. They do not provide robustness.
Implementing data rules inside the database is not trivial, despite all the clear advantages outlined above.
AMIS Query 18 Mei – Een Terugblik op Hotsos 2009
Apr 22nd
Marco


