Enforcement of Business Rules in Relational Databases ... - CiteSeerX

Enforcement of Business Rules in Relational Databases Using Constraints Geraldo Zimbrão1,2, Rodrigo Miranda1, Jano M. de Souza1,2, Mario H. Estolano 2, Francisco P. Neto 3 1

IM /UFRJ – Ilha do Fundão, Rio de Janeiro, Brazil COPPE/UFRJ – Ilha do Fundão, Rio de Janeiro, Brazil 3 Marinha do Brasil – Ilha das Cobras, Rio de Janeiro, Brazil email: {zimbrao,jano}@cos.ufrj.Br; [email protected] 2

Abstract. Nowadays, many authors suggest that business rules are a special class of information system requirements. Business rules should have a special handling, from the earliest analysis phases to the implementation. The related literature states many ways for business rule specification, among them, the UML Object Constraint Language (OCL). OCL is an adequate choice for formal representation of business rules. Business rules stated in OCL can be translated into pieces of code that implements the desired capability. Moreover, the system can automatically infer the events where this code must be evaluated. This paper presents the design and implementation of Athena, an OCL constraint enforcement engine built on the top of a commercial relational DBMS (Oracle). In addition, we evaluated the use of the Athena in a real application. The enforcement engine was designed to offer the highest functionality at the minimum impact in the style of database design and access. As a result, it was possible to couple a business rule layer to an existing application with little effort, in an incremental approach. The ability to quickly create and maintain business rules was greatly improved, resulting in a large improvement of productivity. The overall programming effort spent on enforcing business rules was greatly reduced, and the business rules were stated declaratively. The system automatically discovers the events where the rules must be fired. To bring this functionality to existing RDBMS represents a great progress in the evolution of relational technology. Moreover, the main result is that the business rule system assures that a buggy or ill-programmed function in the application will not accidentally violate a business rule.

1. Introduction Traditionally, we have built information systems uncoupling data from processes that access this data. This approach, however, is not efficient to carry out the New World of continuous change of business requirements. A new approach that divides the information systems in three components – data, processes and business rules – is more adequate to be used to develop the modern information systems [13]. According to this new vision, the business rules are an independent part of system requirements, and need special handling. This paper presents the design and implementation of Athena, a business rule enforcement engine built on the top of a widely accepted commercial relational database management system, the Oracle DBMS. Actually, our approach does not use any Oracle specific feature, and with minor modifications we could use almost any commercial relational database system available.

With little effort, an existing application was tailored to work according to this new paradigm. In addition, we show how business rules can be formally stated and documented, making possible to automatically generate code in the right place to enforce the business rules. We have adopted a standard language for constraint specification, the UML Object Constraint Language [17] (OCL), and used it for formally describing business rules over an object oriented data model. With an appropriate framework, rules can be enforced by automatically generated code placed inside the database or in the application itself – the developer can choose the best place for each rule. In this paper we focus in generating code that resides inside the database, but the Athena’s architecture is planned to have, as a future enhancement, modules to generate code that will reside outside the database, e.g. in the application interface or in the middle tier. We focus on putting the code for rule enforcement inside the database because this approach has the smallest impact in a conventional information system design. Also, most of the systems are still built upon a relational DBMS, using relational data models to persist data, so we decide to use a relational DBMS to implement our architecture. Existing tools that support the business rules independence are still in an early stage of its development, showing many limitations. Consequently, using them in real systems is not affordable, particularly in systems in production. Most of these tools lead to an awkwardly transition in the way people designs and implements information systems. Our approach has a very practical characteristic: it is an incremental approach with smooth transition, that is, not all rules must be specified in OCL before the application deployment. In addition, since rules are stated declaratively in a formal language, they constitute valuable business documentation independent of the system implementation. This paper has the following structure: section 2 presents the problem definition. Section 3 presents the related concepts of business rules, like active databases. Section 4 shows our contribution: the architecture of Athena, and details its functionality and implementation. Section 5 presents the results of our approach when applied to a real world production system. Section 6 shows our conclusions. 2. Problem Definition 2.1. Defining Business Rules A business rule is independent of the modeling paradigm or technical platform [7]. A rule is defined and owned by business people, but is coded and implemented by system development people. According to [15] and [13], the business and information system development communities have distinct perspectives of what business rules are. Here, we adopt an information systems view, and present a definition of what a business rule is, quoted from [15]: “A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business”. In this way, a business rule is a sentence that defines or constrains some business aspect. An example of a business rule is: “The monthly salary of an employee is at least $2000”, “Only senior engineers can be project leaders” or “At least one member of a project team must be from the same department of the project”. From an information systems perspective, business rules fall into four major categories [15]: definitions of business terms, facts that connect terms to one another, constraints, and derivations. The first two categories, terms and facts, are collectively referred to as structural assertions in the data model. Constraints are also called action assertions or restrictive rules.

This paper focuses on business rules that are constraints. A constraint is a statement that must be satisfied all the time. In [13] and [14], Ross says that the data model of a business denotes all the information that an organization can retain about the business. Business rules are closely attached to the data model, since the rules are about terms and facts. Ross affirms that a business rule should be anchored to some business entity – which, in any time, will be mapped into one or more entities in some data model. Therefore, business rules should be anchored to the data model. [16] says that all business rules are about data, following the same reasoning. Constraints are fired by events, in an m×n relation. That is, one event can fire many rules, and one rule can be fired by many events. In the previous example, we should check the third rule in the following events: when we remove someone from a project team, when we move someone from one department to another, or when we move the project from one department to another. 2.2. Managing Business Rules A business rule denotes some knowledge about a business process. Every business rule must be documented in some way: the business process and/or the system documentation must include all business rules description. Generally, the business rule documentation is written in natural language, and it is an explicit statement of the rule. Also, every business rule, to be enforced by the system and perceived by the user, must be coded somewhere in the system – in the application or in the database – and it is an implicit statement of the rule. Every change in a business rule must be reflected in two different places: in the system and in the documentation. Many times we have to reason about every business rule to discover where to put the code that validates the rule. So, there is a list of events that can fire a rule. If the rule changes then the list of events that fires this rule can change also, and we have many places in the application where the change in the rule must be reflected – a simple mechanical tedious task that is manually done by programmers. This is the usual way we build information systems, but this kind of business rule maintenance waste valuable resources and it is a potential source for errors. Fig. 1 illustrates this process. Business Rule hand-coded Event list where the BR must be evaluated

Places in application code where the events occurs and BR must be handled

Application Code

Fig. 1 – Hand-coding of business rule stated in natural language

In order to implement a business rule stated in natural language the following activities are necessary: write the code that evaluates the rule, possibly in more than one programming language; find out the events where the rule must be evaluated; discover the places where these events can occurs in the application code; put the code (or a procedure call) that evaluates the rule in the right places; and, if necessary, carry out little adjustments in the code being inserted. Additionally, when a rule changes, it is necessary to check if the events list was also changed. If so, for each event E removed from this list it is necessary to remove the rule evaluation code from the places where the event E occurs. 2.3. Improving the Business Rules Management A simple idea that can help business rules maintenance is to create an auxiliary table that shows where each event can occurs in the application code. Then, the system documentation should include the business rule and the events that can fire this rule, from which one can lookup in the auxiliary table and locates where to put the code that handle that rule. Clearly, all these documentation structures and the system code must be kept consistent to be useful. With the Athena system, we propose a more sophisticated approach: a business rule management system that centralizes all the business rule maintenance in one place. Using the Athena system, a business rule is stated in a high level declarative language, and the system carries out all the mechanical tasks: generates the code that evaluates the rule, find the events that can fire this rule and put the code in the right places where these events can occurs. When a business rule changes, the new code replaces the old one in the right places. Additionally, the Athena system links the rule to its documentation in natural language. 3. Related Topics 3.1. Business Rules, Database Constraints and Active Databases As [13] points out, all the business rules are anchored to facts, that is, to the data model. It is especially true for business rules that are constraints. In this way, it would be possible to map business rules to constraints in databases, or database assertions to be more comprehensive. A database assertion is a check constraint that is not specific to a single table, and can be used to create multi-table constraints [9]. But even this approach may not be viable: as pointed out by [2], most commercial databases system does not implement assertions as defined in the SQL92/99 standard. So, when business rules are implemented as constraints in databases, handcrafted database triggers must be used – an error prone solution, as [2] says. Also, there will be an abstract level gap: even programmers do not easily understand business rules stated in SQL. That is, it is easy to know what the SQL code does, but it is not easy to understand what it means in the business vocabulary. This occurs mainly because the logical structure of tables is exposed in a SQL statement, that is, the joined fields, primary keys etc. The research done in the 90’s in the field of Active Database Systems [1,2,6,21] presents a model of event-condition-action rules, or ECA-rules, that are the essence of active databases. The ECA-rule provides a mechanism for modifying the database state in response to some condition reached, the action part of a rule. In its turn, as a side effect of an action, other ECA-rule can be fired, and so on. As mentioned in [1], an algorithm to identify and prevent loops must be used.

3.2. Statement of Business Rules in OCL Many authors claim that business rules should be stated declaratively in some formal language [3,4,13,16]. Diagrams and other tools provided by UML has been widely established as a standard for modeling software systems. One of the tools suggested by UML is the Object Constraint Language [17]. OCL is the UML language for specifying constraints. OCL can be used to express business rules, both derivative and restrictive ones as pointed by [4,5]. Documentation in natural language can be generated from OCL expressions, as showed in [11] and [19]. OCL looks at first very much like a notational variant of first-order logic, and in [17] is stated that it has the same expressive power of first-order logic. In [10] is presented a relational logic able to handle all OCL constructs. In this work we adopt the proposals stated in [12] to define more precisely the Object Constraint Language. OCL is a more concise language than SQL, mainly because of dot-navigation style. Moreover, OCL is a modeling language to be used in early phases of system analysis. To state OCL constraints only the UML class model is required. Conversely, to model business rules in SQL the database logical data model must be ready – typically a task accomplished only at design phase. An OCL expression must be connected to an object of some class, called context class, and can refer to the object itself (through the self variable) or to any of its attributes or query methods. In the business rule terminology, we call the context class the rule anchor. A derivative business rule can be expressed in OCL as a query method of some class. As an example, we show the following rule that calculates the age of an employee. Context Employee::age(): Integer Post: result = year( systemDate() – birthDate )

A restrictive business rule (a constraint) can be expressed in OCL as an invariant. An invariant is a Boolean expression that must be true for all instances of a class. As an example, we show the rule that states that the employee monthly salary cannot be less than $2000. Context Employee inv: monthlySalary >= 2000

While most of derivative business rules are explicitly called by the application, the restrictive rules are implicitly linked to events – we say that an event fire some rules. The above rule must be checked in two distinct system events: when hiring a new employee or when updating the salary of an existing employee. All persistent information will be stored, and we assume that a relational DBMS will be used for this purpose. This database has a schema, or data model. We will formulate the business rules based on the class model, and we will describe the mapping from class model to database model using a XML document. In our approach, we will only handle the events that change the stored data, so a restrictive business rule will prevent some information from being inserted, updated or deleted from the database. To illustrate the expressiveness of OCL, we give in the following some examples of business rules stated in OCL, and a brief explanation of them. The Athena Business Rule Management System can handle all these rules. 1. At least one member of a project team must be from the same department of the project: Context Project inv: team->select(x | x.project == self.project)->size >= 1

This rule can also be stated as: team->exists(x | self.project.employees->includes(x))

2. If the pending items list is not empty then it must include all the executing items of a project. context Project inv: pendingItems.isnotempty implies pendingItems->includesAll( executingItems )

3. The members of a project team can not be married with other member of the same team (suppose that we have a function that tells if two people are married): context Project inv: team->forAll( x, y | not married( x, y ) )

4. Our Approach: Athena, a Business Rule Management System 4.1. Athena Description A first prototype of an OCL-to-SQL compiler was presented in [18]. From there, many enhancements were done in the compiler, mainly to improve rule evaluation performance, to implement more OCL language constructs and to maintain more information about rules. Also, another modules of Athena were implemented [19]. The Athena system is a repository for business rules, linking the representation of a rule in natural language with its formal statement in OCL, following the model presented in [15]. Also, the Athena implements an alternative to database integrity constraints as defined in the SQL99 standard [9]. That is, Athena is a tool that extends the functionality of a relational DBMS to support database integrity constraints stated in OCL and documents them. Finally, Athena can handle any constraint that can be expressed in OCL, except for “iterate” and “@pre” operators. According to [4] the “iterate” operator can be cumbersome to implement in a declarative way. Also, in this version of Athena, we implement the operator “@pre” only for single-row rules. The Athena system has a small data repository including basically facts, rules and events. This repository stores the documentation of business rule and links it to the related entities or attributes in the application data model. We present here the basic structure of these tables, omitting some attributes. Event_Type(ID,Type,Table_ID,Column_ID) Fact(ID,Type,Name) Rule(ID,Anchor_ID,OCL_Expr,SQL_Expr,Author_Name) Event_List(Rule_ID,Event_ID)

Facts can be table, attributes, relations or subtypes. Events can be insert in a table, update of an attribute of a table, or delete of a foreign key – we will explain in detail these operations in subsection 4.3. Once a business rule is stated in OCL, the Athena compiler updates its repository, produces the events list that can fire this rule, and a SQL statement that verifies if all records in the database satisfy this rule. If not, the system states that this rule does not hold for old data, but all new inserted or updated data will be rule-compliant: once a rule is stated, no operation is allowed that violate this rule. Also, the Athena system generates code – actually, database triggers – that monitors all the data events that can potentially break a business rule. Inside a transaction, these triggers collect all the data events occurred, together with row keys of modified data. Just before the commit (or in a user defined check-point), a rule validation procedure in the Athena system verifies which events occurred inside this transaction, and searches for rules that can be fired by these events. All these rules are verified by the generated SQL code, using the information stored to speed up the evaluation – that is,

only potentially involved tuples are investigated, in the same way pointed out by [1]. If any rule is violated, an exception is raised to the application holding the data involved and the rule details, its documentation etc. Thus, the application is responsible for taking the appropriate action: a rollback or any other action to correct the situation. To the programmer, the only overhead introduced by Athena system is, instead of directly committing a transaction, calling a procedure that calls the rule validation procedure and only after that commits the transaction. The Athena business rules repository actually is the heart of the business rule management system. It has a searchable interface and centralizes the rule maintenance, keeping track of rule history. A browser allows navigation across related rules, and information about the rule itself is kept: author, official documents, creation date etc. Queries like “what rules are fired by what events?” or “what rules relates to class X?” are easily answered. 4.2. Athena System and Active Databases The Athena compiler could generate checks constraints and assertions and rely on database management system to enforce the business rules. However, as stated before, most of commercial DBMSs do not implement assertions. On the other hand, active databases present a powerful framework for implementing assertions using ECA-rules. But they pay the price of poor performance when compared to traditional DBMSs [2]. Thus, we decided to implement a rule enforcement system that relies on common features available in practically all DBMSs. We had successfully implemented the Athena system in Oracle with acceptable performance. One of the key success factors is that OCL is a language with no side effects, that is, the evaluation of an OCL expression is not allowed to modify the database state. In other words, when a rule is fired, it will not fire another rule as a side effect. On the other hand, in the ECA-rule model when a rule is fired the database state can be modified by the execution of its associated action, firing another rule and so on in a cascade style, which is the main performance problem of active databases approach [2,20]. So, how Athena system differs from the active database approach? There are four main differences. First, we use OCL to specify business rules in a higher abstraction level than SQL. Second, the performance: since our approach is less generic, allowing only constraints validations, we can reach an acceptable performance. Third, the Athena system provides a browser and a searchable interface to centralize business rule management. Fourth, the business rule stated in OCL could be translated to other programming languages and be located outside the database: a simple business rule can be translated to JavaScript and be sent in a HTML form, for example. 4.3. The Athena Architecture As stated before, the main focus of this work is business rules that are constraints. The derivative rules can be straightforward implemented by views in any database. Only the restrictive rules will require a more sophisticated database implementation. To make the implementation easy, we split the restrictive rules in two groups: the simple ones that can be implemented by existing check constraints mechanism, and the complex ones that cannot. According to [16] the restrictive rules can be checked in two distinct moments: after each operation (insert, update, delete) or just before committing the transaction. The main difference between the two approaches is that in the second intermediate states inside a transaction will be allowed to violate some rules – a more flexible rule enforcement mode.

Also, in the first approach a rule will be evaluated every time it is fired by an event, and in the second approach it will be evaluated only once. Potentially, this could be a performance bottleneck, mainly for complex rules. The first prototype of OCL-to-SQL compiler of Athena system used this approach [18]. Except for rules that can be implemented by simple database check constraints, we have implemented the second approach. If any rule is violated an exception is raised. This exception has an ID of the broken business rule, and allows the application to retrieve the specific message error – that is, the rule description in natural language and any further information. To implement this approach, we create, for each table, a straightforward trigger that collects in an auxiliary table all the insert, update and delete events that occurs inside a transaction. This table is the table of collected events. For simplicity, we assume that all primary keys are integer surrogates (ID). The table structure is: Collected_Events(Event_Type,Row_ID)

These triggers can be implemented in any database system that offers minimal support for triggers. To the insert and update operation, it records the event type and the rows affected (using its primary key). To the delete operation, it keeps all the foreign keys that may exist in the deleted row. In the following example, 17 is the ID of event “insert in table Employee”: CREATE OR REPLACE TRIGGER TRG_BI_EMPLOYEE AFTER INSERT ON EMPLOYEE FOR EACH ROW BEGIN INSERT INTO COLLECTED_EVENTS(EVENT_TYPE,ROW_ID) VALUES(17,:NEW.ID); END;

Before committing a transaction, the application must call the Athena rule validation procedure. Basically, this procedure accesses the table of collected events and produces a list of rules that must be checked, according to each event occurred. In this list, each rule appears just once, and a list of affected rows is built merging the related IDs. The procedure verifies if all selected rules hold on the affect rows listed. If so, the transaction is committed; otherwise an exception is raised. 4.3.1. The OCL Compiler. The OCL compiler was implemented using a Delphi port of LEX and YACC known as TPLY, available in the Internet [8], and using the original OCL grammar. The OCL statement for a rule will be compiled and translated to a base query in SQL. The base query will return the rows in the anchor table that violates this business rule. In addition, the compiler produces an event list where this rule must be checked. In the following examples, we will assume that the data model has four tables: Employee(ID,name,address,monthly_salary,division_ID, position_ID) Division(ID,name,manager_ID,department_ID) Department(ID,name,director_ID) Position(ID,name,base_salary)

Each event in the event list corresponds to a database event like insert/delete of a row or update of an attribute. Consequently, the base query will be tailored according to each event to be checked. The goal is to reduce the number of evaluated rows of the base query – we have to check only the potentially changed rows by the occurred event, in the same way done by [1]. For example, if we have changed the monthly salary of Peter, we don’t need to check any other row of table Employee – just the Peter’s row. We can modify the base query to

restrict the investigated rows to the ones collected by the appropriate trigger in the Collected_Event table. We have to be more careful with delete events: if we use the same restriction, no rows will be ever checked since the record was deleted. Instead, we should use the values of foreign keys in the deleted row. A more detailed discussion on how to generate the event list can be found in [1], and it is proven to be correct. 4.3.2. OCL to SQL Mapping. We have implemented all the patterns pointed out in [4] for mapping from OCL to SQL. We have used a slightly different mapping for the navigation pattern – we used join operations instead of the “in” operator. We assume that if a constraint is evaluated to “undefined” (null values) then it is satisfied, like in SQL three-valued logic. Finally, all collections are flattened, that is, there is no collection of collection. 4.3.3. Data Model Mapping. Each pair attribute/class is mapped to a pair column/table in the database. So, if an expression in OCL in the context of Employee uses the attribute “monthly_Salary”, the following SQL will be produced: SELECT MONTHLY_SALARY FROM EMPLOYEE

Whenever a “path” is specified in OCL, using the object-oriented style, (i.e. the dot-notation) we will map to the appropriate join with related tables. For example, in the context of an Employee, “position.name” is translated into: SELECT T1.NAME FROM EMPLOYEE T0, POSITION T1 WHERE (T1.ID = T0.POSITION_ID)

One should note that the table names are replaced by Tn, where n is a sequential number. This is done because a table can appears more than once in the “from” list. We are using an XML document to describe the mapping from attributes to database columns. Also, it shows how to map a dot-navigation. The structure of this XML file is very simple: there are table tags and relation tags. The table tag has a name, and an internal tag to describe its attributes. Since it is straightforward mapping, we will not show the table tag. The tag relation has a name and a table name. Within this tag, there is a path list showing: order, source attribute, target table and target attribute. The tag order establishes the join order of the tables: each source attribute is related to the previous target table, and the first source attribute is located in the table that contains this relation. In the following is a relation tag example.

We use a list of tuples in order to allow a single dot-navigation to be mapped to a join across many tables. This mapping schema is expressive enough to allow intermediate tables, like the auxiliary tables used in relational databases to implement the m × n relationships. Compound keys can be handled by putting more than one “key” tag in the same “path item”. In the context of an employee, to retrieve the department name of an employee we can write “department.name”. This path expression is translated into:

SELECT T2.NAME FROM EMPLOYEE T0, DIVISION T1, DEPARTMENT T2 WHERE (T1.ID = T0.DIVISION_ID) AND (T2.ID = T1.DEPARTMENT_ID)

4.3.4. Base Query. Each OCL expression results in a value – a single value or a collection. This value is obtained by dot-navigation starting in the context of the OCL expression. An invariant is a logical OCL expression. The base query for derivative rules is a select statement in SQL with two columns: the first one is the key of the context table (that represents the anchor class); the second is the value that the OCL expression should return. The base query for restrictive rules just checks for rows that violate this rule, that is, it checks if exists any row where the negation of the OCL expression is true. We use the SQL clause “exists” to do this. Since in Oracle the “exists” clause must be inside a SQL statement, we perform a query in the DUAL table and put the “exists” clause in the “where” condition. The DUAL table is a dummy table with just one row and one column. That is, the following query is used: SELECT COUNT(*) FROM DUAL WHERE EXISTS( query returning the rows that violates the rule )

If there is at least one row that violates the rule, this query will return 1. Otherwise, it will return 0. The main advantage of this approach is performance: if there are many rows violating the rule, the optimizer stops the execution of the query in the first row returned. Since each invariant in OCL is a logical expression obtained by dot-navigation or function calls, we should negate only the OCL-related expression, not the join-related expression. That is, the following pattern was adopted. Each logical expression like “ ” is translated into: SELECT COUNT(*) FROM DUAL WHERE EXISTS (SELECT * FROM WHERE AND NOT ( ))

Where value-1 and value-2 are the values returned by path-expression-1 and path-expression2, respectively. So, consider the following OCL invariant: Context Department inv: leader.monthlySalary >= 5000

Will generate the base SQL statement: SELECT COUNT(*) FROM DUAL WHERE EXISTS (SELECT * FROM DEPARTMENT T0, EMPLOYEE T1 WHERE (T1.ID = T0.LEADER_ID) -- join expression AND NOT (T1.MONTHLY_SALARY >= 5000)) -- negation of rule

4.3.5 Examples. The compiler works in order to optimize the generated code. If two path expressions have a common part, the compiler will merge the resulting query. This common path must be identical from the beginning of the path, that is, a common part on the right side can’t be merged. So, in the context of a Department, if we have an expression like “leader.monthlySalary >= 5000” and “leader.position == ‘Manager’”, the compiler will output the following: SELECT COUNT(*) FROM DEPARTMENT T0, EMPLOYEE T1, POSITION T2 WHERE (T1.ID = T0.LEADER_ID) AND (T2.ID = T1.POSITION_ID) AND NOT ((T1.MONTHLY_SALARY >= 5000) AND (T2.NAME = 'Manager'))

Table 1 shows the events that will fire this rule and specific expressions for the above query. Table 1. Event list for above example Update Update Update Update Insert

of of of of of

Event Department.leader_id Employee.position_ID Employee.monthly_salary Position.name Department

The event “insert on Employee” does not fire this rule since, when it occurs, it is impossible to exist a row in table Department with the attribute leader_id equals to the ID of the new row of Employee. In the same way, we don’ need to check this rule for the event “insert on Position”. On the other hand, all the delete operations will be constrained by foreign keys – that is, to delete a row from Position, it can’t be used by any row of Employee; and so on. Finally, for each event on the Table 1 a restrictive subquery will be appended to the base query in order to restrict the rule evaluation to the affected rows. That is, for the “Update of Department.leader_id” event, the subquery would be (assuming nn as the code of this event): …AND T1.ID IN (SELECT ROW_ID FROM COLLECTED_EVENTS WHERE EVENT_TYPE = nn)

So, the final query tailored for this event would be:

SELECT COUNT(*) FROM DEPARTMENT T0, EMPLOYEE T1, POSITION T2 WHERE (T1.ID = T0.LEADER_ID) AND (T2.ID = T1.POSITION_ID) AND NOT ((T1.MONTHLY_SALARY >= 5000) AND (T2.NAME = 'Manager')) AND T1.ID IN (SELECT ROW_ID FROM COLLECTED_EVENTS WHERE EVENT_TYPE=nn)

5. Tests To validate our approach we have implemented and tested this architecture in a real application on a government organization. We had built a restricted scope (a small module) version of the running application where all the rules are stated in the Athena Business Rule management System. We had no difficult to implement any business rule. This new application yields performance results a bit inferior (an average of 25% for some transactions) than the original application, but only when occurs some data change. More tests are being carried out to better quantify these results. We implemented 37 complex business rules. The average number of tables accessed from a single rule was four, many times including one or two auxiliary tables used for implementing a many to many association. This leads to an average of six to seven database events where each rule must be checked. The average number of lines of PL/SQL code produced for each rule was 57. Whenever a rule was changed, the average number of lines of code rewritten was about 1500 – of course, only a minor fraction of this code has changed, but we have to recreate all affected triggers. After stating a rule in OCL, the time spent on recreating the affected triggers and recompiling them was less than one minute – that is, the time spent on changing a business rule is entirely dominated by the rule specification in OCL.

6. Conclusion In this paper, we show an incremental approach to design and implement information systems with the paradigm of business rule independence. This approach is suitable for gradual migration of an existing application with little effort, provided that the RDBMS does not change. We have designed, implemented and tested the Athena Business Rule Management System. This Athena version shows that is possible to build a BRMS on top of a RDBMS. The Athena rule engine was designed to offer highest functionality at minimum impact in the style of database design and access. As a result, it was possible to develop (or change) an application with business rules independence in mind. There was a small impact in the overall application performance, but the ability to quickly create and maintain business rules was greatly improved. Perhaps, the main result is that the Athena system assures that a buggy or ill-programmed function in the application will not accidentally violate a business rule. The inferior performance should not be viewed as a terrible problem because of the advantages gained. The same performance arguments were used when the first relational DBMS starts to offer the integrity constraints like primary keys, foreign keys and others. For each new step in the technology, there will be ever a trade-off between performance, functionality and semantic power. Moreover, the SQL code produced by Athena can be used in SQL analyzers to suggest a list of indexes to be created, resulting in a better performance. Also, the Athena system enhances the productivity of programmers. With little effort, a new Business Rule can be introduced in the system, compiled and hosted in the right places of the application – that is, in the right events with the slightly modifications that each event imposes. There is a great amount of generated code that otherwise should be write by hand. References 1. Ceri, S. and Widom, J. “Deriving Production Rules for Constraint Maintainance”. Proceedings of 16th Int. Conf. on VLDB, August 13-16, Brisbane, Australia, p. 566-577, 1990. 2. Ceri, S., Cochrane, R., and Widom, J. “Practical Applications of Triggers and Constraints: Success and Lingering Issues”. Proceedings of 26th Int. Conf. on VLDB, September 1014, Cairo, Egypt, p. 254-262, 2000. 3. Date,C. J. “What not How: The Business Rules Approach to Application Development”. Addison-Wesley longman Inc, 2000. 4. Demuth, B. and Hussmann, H. “Using OCL Constraints for Relational Database Design”. UML' 99 2nd Intl. Conf. Unified Modeling Language, Fort Collins, CO, USA, October 1999. 5. Demuth, B. Hussmann, H. and Loecher, S. “OCL as a Specification Language For business Rules in Database Applications”. UML' 01 4th Intl. Conf Unified Modeling Language,. Toronto, Ontario, Canada, October 2001. 6. Dittrich, K. R., Gatziu, S. and Geppert, A. “The Active Database Management System Manifesto: A Rulebase of ADBMS Features”. Proceedings of Rules in Database Systems, Second International Workshop, RIDS' 95, September 25 - 27, Athens, Greece, Lecture Notes in Computer Science, vol. 985, p. 3-20, 1995. 7. Gottesdiener, E. “Business Rules Show Power and Promise”. Application Programming Trends, vol. 4, n. 3, March 1997.

8. Graef, Albert. TPLY: Turbo Pascal Lex/Yacc. Free software available online at http://www.musikwissenschaft.uni-mainz.de/~ag/tply. 9. ISO. “Final Draft International Standard, Database Language SQL – Part 2: Foundation”, ISO/IEC FDIS 9075-2:1999, March 1999. 10. Jackson, D. "Automating First-Order Relational Logic." ACM Foundations of Software Engineering, p. 130-139, 2000. 11. R. Hähnle and A. Ranta, "Connecting OCL with the Rest of the World", ETAPS 2001 Workshop on Transformations in UML (WTUML), Genova, 2001 12. Richters, Mark and Gogolla, Martin. “On formalizing the UML object constraint language OCL”. In Proc. of 17th Int. Conf. Conceptual Modeling (ER' 98). Springer, Berlin, Lecture Notes in Computer Science vol. 1507, 1998. 13. Ross, Ronald G. “Business Rule Concepts”. Business Rule Solutions Inc, 1998. 14. Ross, Ronald G. “The Business Rule Book: Classifying, Defining and Modeling Rules”. Database Research Group, Boston, MA, 1997. 15. The Business Rules Group, "Defining Business Rules – What Are They Really?" rev. 1.3, July, 2000 – available online at http://www.BusinessRulesGroup.org. 16. von Halle, Barbara. “Building a Business Rule System, Part 1”. Data Management Review, Faulkner & Gray, January 2001. 17. Warmer, J. B. and Kleppe, A. G. The object Constraint Language. Addison-Wesley, 1999. 18. Zimbrão, G. et al. “ATENAS: Um Sistema Gerenciador de Regras de Negócio”, in Portuguese. TOOLs – Seção Técnica de Ferramentas do XV Simpósio Brasileiro de Engenharia de Software, Rio de Janeiro, Brasil, outubro de 2001. 19. Zimbrão, G. et al. “FalaOCL: Uma Ferramenta para Parafrasear OCL”, in Portuguese. TOOLs – Seção Técnica de Ferramentas do XVI Simpósio Brasileiro de Engenharia de Software, Gramado, RS, Brasil, outubro de 2002 20. Bailey, J; Dong, G. and Ramamohanarao, K. “Decidability and Undecidability Results for the Termination Problem of Active Database Rules”. PODS 1998: 21. Tanaka, A. K., Navathe, S., Chakravarthy, S., Karlapalem, K. “ER-R: an enhanced ER model with situation-action rules to capture application semantics”. In: 10th International Conference on Entity-Relationship Approach, San Mateo – EUA, 1991.