Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/10—Office automation; Time management

Definitions

• the present invention relates to database application development.
• Database application software is layered on top of database software provided by such vendors as Oracle, Sybase, Informix, etc.
• the database application software enables the underlying database software to be used by non-experts to perform everyday business tasks, e.g., order entry, invoicing, collections, etc.
• Database application development is typically an arduous, time-consuming process performed by skilled computer programmers, and database application maintenance is often more arduous still.
• Data definition involves describing the strucmre of information in a database.
• a Data Definition Language (DDL) is a specialized language used to create new databases and specify the logical strucmre of the data (i.e., the database schema).
• DDL Data Definition Language
• One notation for representing database schemas is the "entity-relationship" (E/R) model, which is graphical in namre and uses boxes and arrows to represent the essential data elements and their relationships.
• CASE Computer Aided Software Engineering
• 4GL Screen painter
• Business rules automate data manipulation.
• An example of a business rule is "the customer balance is the sum of the unpaid orders"
• business rules are implemented using triggers and stored procedures.
• a stored procedure is a callable program that is declared as an object within a database schema.
• a trigger is a stored procedure invoked in response to an insert, update or delete SQL (Strucmred Query Language) statement. Triggers and stored procedures are manually coded by skilled programmers. Such coding can be a painstaking, error-prone process.
• EJB Ente ⁇ rise JavaBeans
• This provides various advantages and scalability (one can provide multiple application servers to balance the load), or integration (since the data is no longer restricted to SQL).
• coding an EJB is just as hard/time-consuming as coding a trigger. Both suffer from a single underlying root cause: reliance on procedural programming languages to enforce business logic.
• the present invention provides a data application development method for allowing a user to specify business rules (data requirements pertaining to one or more business functions) and for automatically generating code that enforces those business rules.
• rules may be readily specified and modified without concern for interactions between various rules.
• a business rules compiler performs rule/transaction mapping, rules ordering, rules optimization, and rules targeting to automatically generate code that enforces the business rules.
• Figure 1 is a diagram illustrating the process of developing a database application in accordance with two-tier deployment
• Figure 2 is a diagram illustrating the process of developing a database application in accordance with three-tier deployment
• Figure 3 is a screen display of a Business Rules Designer, including a Derivation tab
• Figure 4 is a screen display of a Constraints tab of the Business Rules Designer
• Figure 5 is a screen display of a Relationships tab of the Business Rules Designer
• Figure 6 is a screen display of an Events tab of the Business Rules Designer
• Figure 7 is a screen display of a Rules Builder
• Figure 8 is a partial E/R diagram useful in illustrating rule chaining.
• Figure 9 is a block diagram of a Business Rules Compiler. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
• the overall database application development environment will be described, followed by the manner in which business rules are specified in accordance with an exemplary embodiment of the invention. The manner in which business rules are compiled will then be described.
• FIG. 1 An overview of the development process using the present development tool is shown in Figure 1.
• a design-time environment is shown on the left-hand side of the figure, and a run-time environment is shown on the right-hand side of the figure.
• a local database or repository 110
• a data model 111 of the server database is created.
• additional "layers" of information including business rules 113 (described in detail hereafter) and application definition information 115.
• the application definition information 115 may be captured as the user draws the application within an application drawing area 120 (displayed on a computer screen, not shown) using drag-and-drop techniques as described more fully in U.S. Application Serial No. 08/630,020 entitled AUTOMATED CLIENT/SERVER DEVELOPMENT TOOL USING DRAG-AND-DROP METAPHOR, filed April 9, 1996, inco ⁇ orated herein by reference.
• the application definition information 115 may itself be in the logical form of a database.
• an application is described as a collection of table rows related in one-to-many fashion.
• An application describes a multi-form program and is represented by a table row within a table JadeApps 116.
• Jade stands for "Java Application Development Environment."
• a database may contain several applications, each of which is represented by an application drawing (120).
• An application may contain many forms, each of which is described by a single row within a table JadeAppForms 117.
• a form may contain multiple tables, each of which is described by a table row within a table JadeAppFormTbls 118.
• each table may respond to user input to cause a transition to another form. Each transition is described by a table row within a table Jade AppFormShows 119.
• Microsoft Access is used as the repository.
• Microsoft Access is a relational database management system that is part of the Microsoft Office Pro application suite.
• other database management systems and other target 4GL programming languages may be used.
• Generated applications can take a number of organizations.
• code generation an application contains two types of code: form-specific code and generic code. Code that pertains to a particular form is form-specific code. Other code (stored as “modules") is more general in namre. In the case of the present tool, this includes, for example generic code that, when a row becomes current, synchronizes each Dependent Recordsource (i.e., opens Dependent Recordsources using parameter values from the source Recordsource).
• the generic code constitutes a run- time library 130 (Vision
• generated applications can be a set of classes, one for each form.
• Each such form class includes a set of objects corresponding to both graphical objects (text boxes, grids and so forth) and semantic objects that provide behavior to retrieve/update data, perform form transitions, or pick foreign key values.
• the set of objects in conjunction with their property settings (set in the Design Environment) provide the desired behavior.
• this behavior is inherited from a set of VFC classes (of which objects are instances) that operate (per property settings) to provide the designated behavior. Both organizational approaches are, for this pu ⁇ ose, equivalent.
• the database code generator creates data objects within the server database based on information stored in the data model using, for example, DDL (Data Description Language).
• the database generation code generates trigger code that enforces the business rules specified in the repository. Because no manual coding is required, either on the client side or the server side, the application can be easily modified, repeatedly if necessary, and regenerated. The "coding waterfall" problem characteristic of the prior art is thus avoided.
• the business logic server includes business objects—classes that enforce business rules-and application server code.
• the application server code performs such task as load balancing, fail over, communications polling, and physical read/write transactions with the database.
• the database stores data objects-the physical data itself. Data represented by data objects (also be referred to as base components) physically reside on disk. Also of interest are query objects-SQL constructs that allow the user to, from the point of view of the user, define combination data objects, e.g., joins/projections of data objects. Query objects allow for the realization of "virtual" business objects. Data objects and query objects are subclasses of business objects within the object model hierarchy followed by one embodiment of the invention.
• Business logic server code is generated by a business logic server code generator based on the business rules specified in the repository. These may, for example, operate as Corba or EJB objects, or some equivalent distributed object protocol. The database code generator no longer generates trigger code as in the two-tier model.
• the business logic server may, for example, interface to a separate Web server. More than one business logic server may be provided for scalability reasons. Multiple business logic servers may be provided, each one implementing a particular business function, e.g., payroll, inventory, etc.
• Declarative rules provide a simple mechanism to enforce business requirements across business functions.
• a business function is an action performed by the user of an application to fulfill a specific business pu ⁇ ose, for example, the entry of a new order.
• a business requirement is a statement for objectives for part of a business function that identifies the objectives for working with data.
• a requirement usually encompasses a series of validations and computations that begin as an update on a data object and may in turn affect other data objects. For example, the entry of each order item in a new order could include the requirement that the cost of the order item must not cause the customer balance to exceed the customer's credit limit.
• the formula to determine a column value spreadsheet cell value may refer to may refer to many other column many other spreadsheet cell values, values, each determined by its own each determined by its own formula. rule.
• a change to the value or the formula A change to the value or rule for a for a spreadsheet cell, or the insertion column, or insertion or deletion of or deletion of spreadsheet rows, may records, may cause automatic change cause automatic changes to many other to many other column values that refer cell values that refer to the changed to the changed column value in their cell value in their own formulas. own rules.
• Each declarative business rule is defined in a single data object. Because cascading rules automatically trigger other rules, business rules can be combined to implement multi-data object update processing.
• a change to a single cell in a set of A change to one business rule may linked spreadsheets may cause changes affect many business processes which to cells in many other spreadsheets. are implemented through that rule.
• a further important comparison may be drawn between spreadsheet functionality and business rule functionality.
• changing a formula is straight- forward.
• business rules compiler described hereafter automates rules processing and addresses dependencies between business rules, modifying the business logic is a fairly short and simple procedure. Rules are unordered, so the user does not have to be concerned with ordering when entering (or, more importantly, altering) rules.
• Various different types of business rules are defined. The most important types for pu ⁇ oses of the present description are derivation rules, constraint rules and referential integrity rules.
• Derivation rules define how a column's value is computed when a database update occurs. Derivations can be aggregations of child record values (sums or counts— min., max., etc.), replicates (copies) of parent record values, or formulas based on values of other columns in the same record.
• a sum rule derives a parent column value by adding values of a specified column in related child data objects. A sum may be unconditional ("the total item amount is the sum of the individual item amounts") or conditional ("the customer balance is the sum of the unpaid orders," where unpaid is the condition).
• a count rule derives a parent column value by counting the number of records in related child data objects (e.g., the number of unpaid orders). Like sums, counts can be unconditional or conditional.
• Each derivation rule can cause other derivation rules to fire. That is, a change in dependent data may cause a derivation rule for "A" to fire, and since other derivations can be based on "A,” a "chain reaction” occurs. This cascading of rules enables complex, multi-data object update processing.
• Constraint rules are used to enforce conditions (boolean expressions) that refer to multiple columns for data validation.
• a constraint may refer to an account balance column, ActBalance, and a credit limit column, CreditLimit. Whenever one of these columns is updated, the constraint then validates the result (e.g., the update is rejected when the ActBalance > CreditLimit).
• Constraints can refer to the results of derivation rules and can thus govern derived columns.
• Referential integrity rules preserve relationships between data objects when updates occur.
• a referential integrity rule may prevent parent update if children are present, prevent parent delete if children are present, prevent child insert/update if parent is not present, etc.
• cascade referential integrity rules may be specified, including cascade update (update child foreign keys on parent update of primary key), cascade delete (delete children on parent delete), cascade insert (insert parent if none on child insert/update), and cascade nullify (null child foreign keys on parent delete).
• Business rules may be specified in various different ways.
• a Business Rules Designer provides a graphical user interface to define business logic in the form of declarative business rules. Referring to Figure 3, the Business Rules Designer may consist of several overlapping tab sheets used to define different types of business rules, and a Rule Builder tool used for graphically building expressions.
• the Columns tab of the Business Rules Designer has a read-only grid of all the columns in a selected data object, with their column-level rule information. Rules are displayed within the grid but are not input directly into the grid.
• the Derivation tab allows a user to enter rules that define how a column's value is derived when update occur. Various options may be selected from the derivation-type box. Types of derivations include sums and counts, parent replicates, formulas and defaults (described above). For sums and counts, two buttons are available, a browser button that invokes the Rules Builder, described hereafter, and a syntax checker button.
• the Constraints tab allows the user to define data object-level constraints that enforce multiple-column conditions for data validation. This tab provides a grid that lists information for all constraints defined for the selected data object.
• the Constraint Name field allows the user to specify a unique name for a constraint.
• the Condition field allows the user to enter an expression describing the constraint's condition, optionally using the Rule Builder.
• the Relationships tab provides information about parent-child relationships for the selected data object. This tab also allows the user to modify referential integrity rules.
• a relationships outline lists the parent and child relationships for the selected data object, and lists the primary and foreign keys for each relationship. The user selects a relationship from this outline to modify its rules.
• a referential integrity frame allows the user to modify the system's default referential integrity rules to preserve relationships between data objects when updates occur.
• An Enforce referential integrity checkbox provides separate sets of referential integrity rule options buttons for parent updates, parent deletes, and child insert/updates.
• the Events tab allows the user to inco ⁇ orate custom code into system-generated application code.
• a grid lists a name and description for each business rule event defined for a selected data object.
• Events may be of different types, e.g., an in-line trigger code event, a conditional action event, or a user-defined modification event. Of particular interest are conditional action events.
• a conditional action event call a specified action (function or stored procedure) to be executed when a defined condition evaluates to true.
• Condition/ Action box allows the user to enter an expression to specify the function or stored procedure to be executed and any arguments to be passed.
• a Rule Builder tool may be used to complete these fields if desired.
• a Rule Builder screen display is shown in Figure 7.
• the Rule Builder is used to create expressions graphically.
• the Rule Builder provides lists of columns, functions, and keywords, as well as buttons with expression elements.
• the list of columns uses outline controls for explorer-like expansion of column information.
• the list of functions includes built-in RDBMS functions and any custom functions such as stored procedures (2 tiered), or Java functions (3 tiered) that have been registered.
• the user when entering conditional expressions for sum, count, column validation or constraint rules, etc., may select from the functions in the list box.
• the list of functions is extensible; i.e., the user may define new functions as methods in Java, for example, and register those methods with an External Object Manager, after which they will be listed as functions in the list box for use within the Rules Builder.
• the list of keywords includes Inserting, Updating, and ":Old".
• the :Old keyword allows the user to differentiate between a changed column value and its value before the transaction that caused the change.
• Defining business rules is basically the same whether a declarative approach or a procedural approach is followed, and involves identifying business functions and the requirements of those functions, then defining one or more rules that implement each requirement.
• the main difference between the two approaches is that, in the declarative approach, designing the business logic rule is the implementation; i.e., declaring the rules allows the code to be automatically implemented.
• the procedural approach such rules are, by contrast, merely an excellent specification for the code to be built by a programmer.
• the business rules implementation process has two important characteristics.
• rules are unordered: the system automatically detects rule dependencies and computes an order of execution that is correct and optimal. Optimization is repeated when rules are changed, so performance remains high over maintenance changes. In the same manner, ordering analysis assures that rule enforcement remains correct (i.e., independent data is calculated first).
• rules are transaction-independent: the system automatically computes which transactions are affected by a rule and builds logic for those transactions to implement the rule. For example, a rule regarding customer balance is automatically reused for many transactions, e.g., insert orders, delete orders, pay orders, etc.
• FIG. 9 a simplified block diagram is shown of a business rules compiler that automatically generates code to implement the foregoing business logic rules.
• Input to the business rules compiler may be in the form of a Business Rules Report, an example of which is shown in Appendix A.
• the business rules compiler is divided into four stages, a rule/ transaction mapping stage, a rule ordering stage, a rule optimization stage, and a rule targeting (code generation) stage. The operation of each of these stages will be described in turn.
• the function of the rule/transaction mapping stage is to determine the conditions under which data changes must "chain" to fire dependent rules.
• the attribute Amount has a Derivation Rule of Price times Quantity.
• the rules compiler must generate code to recompute Amount if a transaction occurs in which updates are made to Price or Quantity.
• the Customer Balance attribute's derivation depends on the Order's Amount and Paid attributes.
• the system must detect transactions that alter an Order's Amount or Paid attribute, and recompute the Customer Balance.
• the system must also detect transactions that insert Orders (increase the balance) or delete Orders (decrease the balance). While such transaction analysis may seem straightforward, it is a frequent source of error since the number of such cases to be analyzed is very large, and because changes to requirements result in subtle side-effects that render prior transaction analyses incorrect.
• the rules ordering stage computes a correct order in which to perform the business logic operations identified during the rules mapping stage.
• a dependency graph algorithm is used for this pu ⁇ ose.
• the use of dependency graphs is well-known. Given a two-column table of derived and referenced attributes of the type described, the algorithm essentially looks for attributes that are referenced but are not themselves derived, i.e., attributes that appear on the left side of the table with no entries on the right side of the table. The corresponding derivation expression is then placed in order and removed wherever found from right side of the table, and the process is repeated. In this manner the table is progressively reduced.
• A X*Y
• B 5*A.
• X and Y appear on the left side of the table with no entries in the right side of the table.
• A is referenced but is derived. Since X and Y have no entries on the right side of the table, they are removed from the right side of the table. As a consequence, A then has no entries on the right side of the table and is therefore removed from the right side of the table and code is generated to derive it.
• the rules mapping and rules ordering stages identify operations and an execution order to achieve correct results in accordance with the rules.
• the optimization stage then computes an efficient implementation of these functionally correct operations. More particularly, Base Components (data objects physically residing on disk) provide insert(), update() and delete() methods which enforce Business Rules. This execution is highly optimized for good performance.
• the system buffers updates made during a transaction and re-uses these cached data for subsequent processing.
• updates to two items within the same order The first order update causes the order component to be retrieved and updated. Instead of saving the row to the database server, it is saved into cache.
• the second order update may therefore update the cached row without retrieving the order.
• the cached order row is the written to disk at the conclusion of Save All processing, when all rows have been processed.
• Another optimization involves aggregation.
• the customer balance may be defined as the sum of the unpaid orders. Assume that an order is changed, e.g., increased from 100 to 120.
• An inefficient implementation of the foregoing rule would be to, whenever an order is changed, re-sum all of the unpaid orders. Instead, child objects generate adjustments to parent aggregate data in order to persistently maintain the aggregate data. Hence, when the order amount is increased from 100 to 120, 20 is added to the customer balance.
• a further optimization involves rule by-pass. Because the business rules compiler analyzes all dependencies inferred by the rules, it can use this knowledge to build code that bypasses processing when underlying dependencies have not been affected. For example, altering an order's date requires no adjustment to the related customers balance. Similarly, altering an order ⁇ s date requires no re-validation of an existing customer number (i.e., referential integrity). Various other optimization may be performed.
• the business rules compiler will have computed a correct and efficient order in which to enforce the business rules.
• the rule targeting stage then generates actual code to enforce the business rules.
• the code generation process may be better understood by considering what code needs to be generated for each of various kinds of rules, i.e., derivation rules, constraints, and referential integrity rules.
• derivation rules may be based on formulas entered by the user or on aggregates or replicates.
• the code generated is essentially of the form: IF any-referenced-attribute-changed THEN do ⁇ calculate drivation formula ⁇ .
• Table 2 depicts the Requirements (bold text) and resultant rules (bulleted points) as they might have been conceived by a developer and entered into the system.
• the circled numbers and arrows represent the rules that fire in response to the change, per the IF ⁇ reference fields changed > tests for each of the rules types described above. Recall that the order of firing (represented by the arrows) is made correct by the Dependency Graph Analysis described above.
• the rules targeting stage In the case of aggregations, the rules targeting stage generates code to, if a "hot" field (i.e., a field referred to in a derivation rule) changed, get the appropriate related record and add a "delta" to the aggregate, then make the object update itself.
• a "hot" field i.e., a field referred to in a derivation rule
• the customer balance is the sum of the unpaid order s,o for example, the paid flag and the order amount are "hot.” If a paid flag is changed, then the customer balance is decreased by the corresponding order amount.
• the rules targeting stage In the case of replicates, the rules targeting stage generates code to, if the replicate field is changed, copy a field to related fields. In the previous example, when an order is marked as paid, then order items belonging to that order may also be marked as paid.
• the rules targeting stage In the case of constraints, the rules targeting stage generates code to check basic attributes. If a change satisfies a constraint, then the change is allowed. Otherwise, the change is not allowed, all partially complete updates are rolled back, and a message is returned to the client. Similarly in the case of referential integrity rules, the rules targeting stage generates code to check whether a change satisfies the rule. If a change satisfies the rule, then the change is allowed. Otherwise, the change is not allowed, and an error is signalled.
• a three- tiered architecture using application servers allows data sources such as legacy (e.g., mainframe) applications and package solutions (e.g., PeopleSoft or SAP) to be used in conjunction with new data to support a custom business process.
• legacy e.g., mainframe
• package solutions e.g., PeopleSoft or SAP
• Current products provide basic capabilities to manipulate multiple data sources.
• Such products are unable to integrate multiple data sources into a common data model together with new data, and to build composite applications using declarative business rules.
• This business requirement is met using an extensible Data Access (XDA) architecture that allows a user to define data objects whose data is not retrieved/written by SQL commands, but by any API (Application Program Interface).
• XDA extensible Data Access
• a user may define data objects that are based on CICS APIs, PeopleSoft APIs, etc.
• Such data objects can co-exist in a repository describing data from multiple data sources, including local SQL data.
• the repository integrates multiple disparate data sources into a common data model.
• the declarative business rules methodology described heretofore may be extended to XDA data objects, allowing a user to define business rules on such data objects just as for SQL objects.
• One aspect of the XDA architecture is retrieval and another is update.
• the application server instead of routing the request as normal to a default data manager, calls XDA code identified by the user in the repository definition of the Data object.
• the application components instead of emitting SQL, emit calls to user-supplied XDA code to read/write data.
• XDA code e.g., a Java class
• Busness Rules Designer to designate this XDA Driver by specifying its name as a property value of desired Data Objects.
• the XDA code is required to start a query, retrieve a row, and handle insert/update/delete operations.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Entrepreneurship & Innovation (AREA)
• Human Resources & Organizations (AREA)
• Operations Research (AREA)
• Economics (AREA)
• Marketing (AREA)
• Data Mining & Analysis (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (4)

Publications (1)

Family

ID=22527220

Family Applications (1)

Country Status (2)

Families Citing this family (7)

Family Cites Families (3)

• 2000
  • 2000-08-15 EP EP00959235A patent/EP1208512A1/de not_active Withdrawn
  • 2000-08-15 WO PCT/US2000/022318 patent/WO2001013303A1/en not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events