Abstract:
An enterprise information system consists of two fundamental components—the data and the business logic. Relational databases can provide a stable, clear and robust implementation of transactions with ACID properties and a declarative query language (SQL) for managing data and are at the core of modern enterprise computing. But modern programming languages like Java—a compiled language, and Javascript—a scriptable language, provide a much better environment for implementing complex business logic. Object Relational Mapping (ORM) tools provide a bridge between the relational environment and the object environment, so that data can be persisted in a relational data model and business logic can be encoded using objects. An extension to the standard ORM is provided to allow an application written in an object oriented language to deal with the information it manipulates in terms of objects, rather than in terms of database-specific concepts such as rows, columns and tables.

Description:
TECHNICAL FIELD 
       [0001]    Aspects and features described herein relate to extensions to object-relational mapping (ORM) methods for enterprise systems that enable data model extensions and easy addition of business logic by an enterprise. 
       BACKGROUND 
       [0002]    In today&#39;s information-driven economy, the ability of an enterprise to efficiently store, update, and use information can be critical to the enterprise&#39;s ability to serve its customers and compete in the economy. 
         [0003]    An entity such as a business enterprise can model a concept of an entity relating to that enterprise and use such modeling information to maintain and use information relating to that entity. Some examples are of entities that can be modeled by an enterprise include user, bill of materials etc. An enterprise can maintain and model data relating to these entities in either a relational programming environment or in an object-oriented environment such as the commonly used Java environment. In a relational system, data is maintained in one or more data tables, where each row refers to an instance of the entity. In an object system, an entity concept is modeled using classes, where each instance of the class—called an object—refers to an instance of the entity, with characteristics of those objects being known as “attributes” of that object. In order to bridge the two systems, object-relational modeling (ORM) techniques are used to enable an enterprise to use data maintained in relational databases in an object-oriented environment. One popular ORM software is the open source object-relational mapping software known as “Hibernate.” 
         [0004]    The ability to work with data in both a relational and object-oriented system can be very important to an enterprise&#39;s business. For example, a provider of software as a service (“SaaS provider”) may have to install an enterprise system and provide service to multiple customers, where each customer is an enterprise in its own right. In such an environment, the system should be able to let each customer define their own extensions to the model, add their own business logic and define their own rules for attribute value computations. Ideally, the system should let each customer manage the extensions and business logic on their own, without affecting other customers in functionality and performance. 
         [0005]    To this end, an enterprise may make a large investment in an enterprise data management system that meet almost all its objectives except a few. To meet the last mile of its objectives may require a small extension to the data model, like having an additional attribute for an entity with some additional business logic. The usual solution is for the enterprise to continue with the deficient product or request the creator of the product to add additional attributes to the entity as part of the next release. Such requests may not be appropriate in a general setting, i.e. the request is very specific to the internal running of the requesting enterprise. 
         [0006]    In many cases, the enterprise data management system has to work along with other systems that are already installed and in use. For a new enterprise system to efficiently blend into an existing enterprise ecosystem, the two systems must be integrated. Such integration often is accomplished by using daily or hourly computer synchronization tasks, which, however, represent costly and inefficient use of the enterprise&#39;s computing resources. For example, the concept of “user” may exist in a user directory like Microsoft Corporation&#39;s Active Directory product, the concept of “bill of materials” (“BOM”) may exist in an enterprise resource planning (“ERP”) system like SAP™, and the new enterprise system may require the user information, the BOM information, or both. 
         [0007]    One possible scenario in this regard is where one computer job synchronizes changes to the enterprise&#39;s user directory, often known as an “Active Directory,” to the new enterprise system, and another job synchronizes the BOM information from the new system to the existing ERP system. Such synchronization is essential; if it is not done, people in the enterprise would have to manage the same concept in multiple systems—which is not only inefficient, but more importantly, could result in the presence of inconsistent data in the different systems. Usually, synchronization of data between multiple systems satisfies most of the data requirements. However, synchronization often does not fully cover all attributes of the enterprise&#39;s data. For example, the new system may have to enable a workflow based on the user&#39;s role, e.g. planner. One conventional solution to this situation has been to add an additional attribute in the Active Directory. This creates a duplication of the role concept that already existed in Active Directory but did not map exactly to the concept of role in the new enterprise system. 
       SUMMARY 
       [0008]    This summary is intended to introduce, in simplified form, a selection of concepts that are further described in the Detailed Description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
         [0009]    Aspects herein relate to a system and method to permit an enterprise to define one or more additional “extension” attributes of an its entities in addition to the core attributes already defined in the enterprise&#39;s database and to use object-relational mapping (ORM) techniques to determine the value of such extension attributes. Other aspects relate to a system and method to permit the enterprise to develop one set of business logic to access and use both the core and extension attributes without having to distinguish between the two. Other aspects relate a system and method of synchronizing an enterprise&#39;s data to permit the value of an attribute to be derived based on other attributes of the user, so that if a value of one attribute changes, the values of the other attribute follows suit without the need to independently change that value. Still other aspects relate to a system and method for use of a query processor or other mechanism to permit an enterprise to use object-oriented queries to obtain information regarding data maintained by the enterprise in relational data tables without having to know the data structure or construct cumbersome and complex relational data queries and distinguishing between core and extension attributes. Still other aspects relate to a system and method to enable a customer in an SaaS environment to add extension attributes and define business rules without affecting another customer in a multi-customer environment. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0010]      FIG. 1  depicts an exemplary relational table representing a concept of “users” modeled by an entity. 
           [0011]      FIG. 2  depicts an exemplary software code sequence representing a “Plain Old Java Object (POJO)” for the User class of object. 
           [0012]      FIG. 3  depicts an exemplary software code sequence representing a possible implementation of the class Address. 
           [0013]      FIG. 4  depicts an exemplary Hibernate XML software code sequence representing file mapping of a Java object to records in a relational table. 
           [0014]      FIG. 5  depicts an exemplary software code sequence representing a class definition for an entity type Nationality. 
           [0015]      FIG. 6  depicts an exemplary Hibernate XML software code sequence for an entity type Nationality. 
           [0016]      FIG. 7  depicts an exemplary software code sequence depicting a Plain Old Java Object (POJO) showing an entity property that maps to a foreign key. 
           [0017]      FIG. 8  depicts an exemplary set of relational database tables comprising a USER table with a foreign key NATIONALITY_ID to NATIONALITY table. 
           [0018]      FIG. 9  depicts an exemplary Hibernate XML software code sequence representing a unidirectional many-to-one relationship. 
           [0019]      FIG. 10  depicts an exemplary software code sequence for showing an attribute comprising a list of fundamental type. 
           [0020]      FIG. 11  depicts an exemplary set of relational database tables comprising a USER table and a USER_NICKNAMES table. 
           [0021]      FIG. 12  depicts an exemplary Hibernate XML software code sequence representing USER_NICKNAMES as an attribute of “collection” type. 
           [0022]      FIG. 13  depicts an exemplary relational database vertical table storing attribute values. 
           [0023]      FIG. 14  depicts an exemplary ATTRIBUTE table containing information of extension attributes in accordance with aspects described herein. 
           [0024]      FIGS. 15A and 15B  depict exemplary relational database tables showing values for the extension attribute visited_countries for instances of class User. 
           [0025]      FIG. 16  is a block diagram depicting components of an extendable Object Relational Mapping. 
           [0026]      FIG. 17  depicts an exemplary software code sequence depicting a Plain Old Java Object (POJO) showing object storage of extension attribute values. 
           [0027]      FIG. 18  depicts an exemplary Hibernate XML software code sequence representing use of a parent-child relationship to manage extension attribute values. 
           [0028]      FIG. 19  depicts an exemplary software code sequence depicting a general flow of a “get” method to obtain a value of an attribute. 
           [0029]      FIG. 20  depicts an exemplary software code sequence depicting a general flow of a “set” method to obtain a value of an attribute. 
           [0030]      FIG. 21  is a block diagram depicting an exemplary flow of user data to a Billing System from a User Directory. 
           [0031]      FIGS. 22A-22D  depicts exemplary relational database tables for use in determining rule-based attribute values in accordance with one or more aspects described herein. 
           [0032]      FIG. 23  depicts an exemplary software code sequence representing a Java object with a rule-based flag in accordance with one or more aspects described herein. 
           [0033]      FIG. 24  depicts an exemplary software code sequence representing XML mapping to capture a rule-based bit in accordance with one or more aspects described herein. 
           [0034]      FIG. 25  depicts an exemplary relational database table having a hierarchical representation of Organizations in accordance with one or more aspects described herein. 
           [0035]      FIG. 26  is a pictorial representation of Organizations as shown in  FIG. 26 . 
           [0036]      FIG. 27  depicts an exemplary software code sequence representing an organization context in accordance with one or more aspects described herein. 
           [0037]      FIG. 28  depicts an exemplary relational database table having a representation of an organization attribute in accordance with one or more aspects described herein. 
           [0038]      FIG. 29  depicts an exemplary Hibernate XML software code sequence for capturing a representation of an organization attribute in accordance with one or more aspects described herein. 
           [0039]      FIG. 30  depicts an exemplary relational database table having information of extension attributes defined at different nodes in accordance with one or more aspects described herein. 
           [0040]      FIG. 31  is a block diagram depicting exemplary Lightweight Directory Access Protocol (LDAP) schemas mapping attributes to a unified data model in accordance with one or more aspects described herein. 
           [0041]      FIG. 32  depicts an exemplary input definition to the compiler describing the entities that will be stored in the database. For each entity definition, the necessary Java code and Hibernate XML mappings are generated. 
       
    
    
     DETAILED DESCRIPTION 
       [0042]    The aspects summarized above can be embodied in various forms. The following description shows, by way of illustration, combinations and configurations in which the aspects can be practiced. It is understood that the described aspects and/or embodiments are merely examples. It is also understood that one skilled in the art may utilize other aspects and/or embodiments or make structural and functional modifications without departing from the scope of the present disclosure. 
         [0043]    For example, aspects and features of a method for modeling an object in an object-relational system are described in the context of modeling an object for use by a business, but it should be noted that the methods described herein can be used for modeling an object for use by any enterprise. In addition, although aspects relating to object-relational mapping often are described and examples are given with reference to the open source object-relational mapping software known as “Hibernate,” it should be noted that aspects described herein can be used by a person to extend any ORM software or to create a new ORM tool. 
         [0044]    As noted above, an enterprise often makes a large investment in an enterprise system that meets almost all its objectives, but fails to meet a few. To meet this last mile of its objectives, an enterprise may require a small extension to its system&#39;s data model, such as having an additional attribute for an entity or some additional business logic. Aspects and features herein relate to an extension to the standard ORM to enable an enterprise to easily make extensions of its data model or add business logic to meet all of its needs. Other aspects relate to a system and method for enabling an enterprise to convert a database query constructed using Object Query Language (OQL) to a query in Structured Query Language (SQL) without having to know all of the information regarding the enterprise&#39;s relational database tables. 
         [0045]    To build a enterprise ORM system that can support an enterprise such as Software-as-a-Service, all parts of the system, e.g., the Java object definition, the Hibernate XML coding, and the relational data table structure have to be consistent. In addition, the developer has to embed the concepts of visibility, rule based assignment and extension attributes. In accordance with aspects herein, the build environment has a code generator that takes the object structure as input and outputs the Java file, the XML mapping class and the data description language (DDL) to create the database tables. 
         [0046]    Some background concepts are presented below relating to various components of an object-relational mapping system in accordance with aspects described herein. 
         [0047]    An entity such as a business enterprise can model a concept of an entity relating to that enterprise and use such modeling information to maintain and use information relating to that entity. Some examples are of entities that can be modeled by an enterprise include user, bill of materials etc. In accordance with database principles known in the art, such entities can be modeled in either a relational programming environment or in an object-oriented environment such as the commonly used Java environment. 
         [0048]    In a relational system, data is maintained in one or more data tables, where each row refers to an instance of the entity. For example,  FIG. 1  depicts an exemplary data table in the relational environment, in this case a data table containing information regarding a database of “users.” As shown in  FIG. 1 , the USER table has a number of rows, each representing a user, and a number of columns, each containing information relating to an aspect of a user, such as “USERNAME,” containing a name of a user, “ADD_STREET,” containing street address information, “ADD_CITY,” containing city information, etc. As seen in  FIG. 1 , the record for a user named “Joe” is represented in a relational system by a row in the USER table, and is identified by an identification number, in this case ID  2 . 
         [0049]    In an object system, an entity concept is modeled using classes, where each instance of the class—called an object—refers to an instance of the entity. For example, as shown in  FIG. 2 , the class com.example.entities. User may be used to model the concept of user in an object/class environment such as Java. As seen in  FIG. 2 , the equivalent representation in an object/class environment like Java is represented by the class com.example.entities. User  201 . In a Java environment, these classes are often referred to as “Plain Old Java Objects” (POJOs). Each class has one or more attributes that characterize each instance of the class—i.e., each object. Thus, the corresponding instance of the object user in the class com.example.entities. User will have the attributes id  209 =2, username  203 =Joe, and so forth. 
         [0050]    In the object-oriented environment, object-relational mapping (ORM) software such as Hibernate can perform mapping between the table row and the corresponding attributes of the object. For example a possible specific embodiment of the mapping may be: 
         [0000]                                                    Object model                 Relational Model           id                 ID           username                 USERNAME           address                 ADD_STREET,                   ADD_CITY, and                   ADD_ZIPCODE               . . .                        
This mapping data could be specified using an xml file or a Java annotation, etc.
 
         [0051]    In general, any object-relational system consists of three elements: (1) the relational part, i.e., the table; (2) the object part, i.e., the class; and (3) the mapping, i.e., the xml document mapping the object-oriented components to their corresponding components in the relational system. 
         [0052]    One example of object-relational data mapping in the Hibernate environment is shown in  FIG. 4 .  FIG. 4  shows the User.hbm.xml file  400  that is used by Hibernate. This xml file shows the mapping  401  between the Java class com.example.entities. User and the table USER, the mapping  403  between Java ID name id and relational column “ID”, mapping  405  between Java object simple property name username and relational column USERNAME and mapping  407  between a Java object composite property address, which comprises multiple components “street,” “city,” and zipcode,” which map to relational columns “ADD_STREET,” “ADD_CITY,” and “ADD_ZIPCODE,” respectively. 
         [0053]    Hibernate provides an application programming interface (API) using the interface org.hibernate.Session to perform the standard database operations create, read, update and delete (CRUD). The following code snippets create a new object instance of user and persist the data into the relational table using the API provided by Hibernate: 
         [0000]                                                User u = new User ( );   // Creating a new User object           ...           session.save (u);   // Propagating changes to database                        
This will result in a new record in the USER table. The column ID will be automatically generated based on the policy specified for identifier generation and the underlying database.
 
         [0054]    Similarly the org.hibernate.Session provides an interface to read an object (i.e., the user Joe is loaded into memory), 
         [0000]    
       
         
               
               
             
               
             
               
               
             
               
             
               
               
             
           
               
                   
               
             
             
               
                  User u = session.load (User.class, 2); 
                 // Joe’s identifier (ID) is 2 
               
             
          
           
               
                 modify the object (Joe’s zipcode is modified to 94662), 
               
             
          
           
               
                  u.getAddress ( ).setZipcode(“94662”); 
                 // Updating Joe’s address for the object 
               
               
                  session.update (u); 
                 // Propagating changes to database 
               
             
          
           
               
                 and delete an object (Joe is removed from the system) 
               
             
          
           
               
                  session.delete (User.class, 2); 
                 // Deleting “Joe” from object-relational 
               
               
                   
                 // system. 
               
               
                   
               
             
          
         
       
     
         [0055]    An object-relational mapping system also can model attributes of an entity to information regarding a record in a relational data table. These attributes are known in the art as either a “fundamental” type attribute or a “composite” type attribute. 
         [0056]    Some fundamental data types such as “string,” “integer,” etc., correspond to a data type in a relational database as shown in the table below: 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
               
                   
                 Object Type 
                 Database Type 
               
               
                   
                   
               
             
             
               
                   
                 java.lang.String 
                 VARCHAR 
               
               
                   
                 java.lang.Integer 
                 NUMBER 
               
               
                   
                 java.lang.Double 
                 NUMBER 
               
               
                   
                 java.sql.Date 
                 DATE 
               
               
                   
                 . . . 
                 . . . 
               
               
                   
                   
               
             
          
         
       
     
         [0057]    For example, the user object defines several attributes—username, address, etc. These attributes map to one or more columns in the database. A simple attribute like username maps to a single column USERNAME in the table. The object type and the database type have to match. As shown in the table above, an object type java.lang.String maps to a data type VARCHAR in the database. The xml code snippet
       &lt;property name=“username” column=“USERNAME” type=“string”/&gt;
 
creates a mapping between the USERNAME column and the object property username and indicates that the two have the same data type, i.e., “string” in this particular case.
       
 
         [0059]    A “composite” object type is represented as a class in the object environment. For example, com.example.util.Address is a collection of three attributes of fundamental type. For example, as shown in the object code  301  in  FIG. 3 , the object property address has three attributes, city, street, and zipcode. Such attributes of composite types are mapped to multiple columns. The xml code snippet 
         [0000]                                &lt;component name=“address” class=“com.example.util.Address”  &gt;        &lt;property name=“street” type=“string” column=“ ADD_STREET”/&gt;         &lt;property name=“city” type=“string” column = “ ADD_CITY” /&gt;        &lt;property name=“zipcode” type=“string”        column=“ ADD_ZIPCODE”  /&gt;       &lt;/component&gt;                    
creates the mapping between the columns ADD_STREET, ADD_CITY, and ADD_ZIPCODE in the relational data table and the object property address.
 
         [0060]    “Entities” are persistent types that represent first-class business objects. In other words, there may be some types (or classes) that are more important then others, and those types of objects may be known as “first-class” business objects. For example, the object com.example.entities. User is a first-class business object that has an associated table USER in the database. There also are value types such as java.lang.String and com.example.util.Address that do not have an associated table. Thus, two users having the same address will refer to two different instances of com.example.util.Address, and modifying Joe&#39;s zipcode does not change the zipcode for Jane. 
         [0061]    Similarly, Nationality and Country also are examples of first-class business objects. For example,  FIG. 5  depicts an exemplary object code sequence  501  representing a class definition for an entity type Nationality. As shown in  FIG. 5 , the entity type Nationality has three attributes, name  503 , country  505 , and notes  507 .  FIG. 6  depicts an exemplary Hibernate xml code sequence  601  that maps the entity type Nationality to relational data tables NATIONALITY and COUNTRY.  FIG. 7  depicts an exemplary Java code sequence referring to an instance of a User&#39;s nationality and setting that nationality to a particular country. In addition, as shown in  FIG. 8 , both users Joe and Jane in USER table  801  refer to the same instance of Nationality, i.e., NATIONALITY ID  34 . So in the USER table, instead of storing user&#39;s actual nationality, we store a reference to the entity object com.example.entities.Nationality. Storing a reference to an object in this manner is known in the art as “having a foreign key” in the database. The xml code snippet 
         [0000]                                            &lt;many-to-one name =“nationality”             column=“ NATIONALITY_ID”             class =“com.example.entities.Nationality” /&gt;                        
creates a mapping between the column NATIONALITY_ID and the object attribute nationality. When the attribute nationality is accessed, the corresponding entity object of the type com.example.entities.Nationality is returned rather than just an ID for the object.
 
         [0062]    In addition to having simple attributes, an entity can have attributes having a collection of values. For example a user can have multiple nicknames or multiple secondary addresses or multiple secondary nationalities. Such attributes are usually modeled as a collection in the object environment and a secondary table in a database. For example, the software code snippet  1001  in  FIG. 10  depicts an attribute nicknames whose values comprise a list of fundamental type &lt;string&gt;. See also  FIG. 11 , which depicts USER table  1101  and USER_NICKNAMES table  1102 , and Hibernate XML code snippet  1201  in  FIG. 12 , which models the object nicknames on the data in the relational tables  1101  and  1102  shown in  FIG. 11 . As seen in  FIG. 11 , the entry for “William”, which corresponds to ID  44  in USER table  1101 , has multiple values, i.e., a collection or list of values in USER_NICKNAMES table  1102 . The Hibernate XML code snippet shown in  FIG. 12  also reflects that the values for the attribute nicknames for entity com.example.entities.User comprise a list, i.e., multiple values. 
         [0063]    Of course, data in an enterprise does not exist simply to reside in a database, but instead is used by an enterprise to meet its needs. The open-source object-relational mapping software Hibernate (and other ORM technologies) provide mechanisms to query data in the database so that it can be analyzed and otherwise by an enterprise. The defacto query language for relational data systems is structured query language (SQL). However, SQL does not map cleanly to the object system. For example, the SQL query in the relational environment for finding the users living in zipcode 75025 is: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 select u. ID 
               
               
                   
                 from USER u 
               
               
                   
                 where u. ADD_ZIPCODE = 75025 
               
               
                   
                   
               
             
          
         
       
     
         [0064]    However, the SQL query is not well formed in the object world because the attribute ADD_ZIPCODE is not defined in the object world. Instead, the object-centric system has its own protocols for constructing a query for data in an object-oriented data system, such as the Hibernate Query Language (HQL). Thus, a corresponding object-centric query for finding the users living in zipcode 75025 can take the form 
         [0065]    from com.example.entities.User 
         [0066]    where equals (address.zipcode, 75025) 
         [0067]    It is much easier for programmers to write a query in an object-oriented language such as Java than in SQL, and therefore it is desirable to provide a method for converting a query constructed using an object centric language into SQL. Thus, according to aspects herein, there is provided a method and system for accomplishing such a query conversion. For purposes of the present disclosure, the object-centric query language shall be referred to as “Object Query Language (OQL)” and the module that converts an OQL to SQL shall be referred to as a “Query Processor.” 
         [0068]    A statement in OQL consists of two parts: the entity being searched for, e.g., (com.example.entities.User) and the predicate (address.zipcode=75025) that specifies the search (or filter) criteria. A predicate can be further broken down into various components, path, operator and value, as illustrated below: 
         [0000]    
       
                 
         
             
             
         
       
     
         [0069]    As discussed in more detail below, the path is only applicable within the context of the reference entity. For example, the path address.zipcode may not be applicable for the entity com.example.entities.Country. 
         [0070]    We can look at another example of OQL. In this example, a list of users with country of nationality as USA is given as 
         [0071]    from com.example.entities.User 
         [0072]    where equals (nationality.country.name, “USA”). 
         [0073]    The query processor can generate a number of possible SQL statements. 
         [0074]    A first possible statement is output in terms of relational language: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 select u.ID 
               
               
                   
                 from USER u, NATIONALITY n, COUNTRY c 
               
               
                   
                 where u.NATIONALITY_ID = n.ID and 
               
               
                   
                   n.COUNTRY_ID = c.ID   and 
               
               
                   
                   c.NAME = “USA” 
               
               
                   
                   
               
             
          
         
       
     
         [0075]    A second possible statement is output in terms of an object language: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 select u.ID 
               
               
                   
                   from USER u 
               
               
                   
                   where exists (select n.ID 
               
               
                   
                       from NATIONALITY n 
               
               
                   
                       where u.NATIONALITY_ID = n.ID and 
               
               
                   
                         exists (select c.ID 
               
               
                   
                           from COUNTRY c 
               
               
                   
                           where n.COUNTRY_ID =c.ID and 
               
               
                   
                             c.NAME = “USA”)). 
               
               
                   
                   
               
             
          
         
       
     
         [0076]    In accordance with aspects herein, the query processor generates SQL statements from the OQL statement. As shown in the example above, the SQL generated is not unique. Based on empirical data, the query processor will generate one of the multiple possible SQL statements that will be efficient to execute. The query processor will collect timing information for each of the SQL statements executed, and, depending on the tables being referenced, the list of attributes, and types of attributes being queried, will pick one of the realizations to execute. 
         [0077]    Next we discuss the concept of “path.” Any entity has a list of paths that include all the attributes of the entity. For example, the entity com.example.entities. User has the following paths. 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
               
                   
                 Path 
                 Type 
               
               
                   
                   
               
             
             
               
                   
                 username 
                 java.lang.String 
               
               
                   
                 address 
                 com.example.util.Address 
               
               
                   
                 nationality 
                 com.example.entities.Nationality 
               
               
                   
                 nicknames 
                 List[java.lang.String] 
               
               
                   
                   
               
             
          
         
       
     
         [0078]    All paths have a type that is derived from the attribute type. For example, the attribute username is of type java.lang.String, hence the type of the path is java.lang.String. 
         [0079]    The attributes of a path result in additional paths for the entity. For example the path address of type com.example.util.Address has three attributes: street, city, and zipcode as shown in the  FIG. 3 . Therefore in addition to the paths described in the above table, the table below shows additional paths for the entity com.example.entities.User: 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
               
                   
                 Path 
                 Type 
               
               
                   
                   
               
             
             
               
                   
                 address.street 
                 java.lang.String 
               
               
                   
                 address.city 
                 java.lang.String 
               
               
                   
                 address.zipcode 
                 java.lang.String 
               
               
                   
                   
               
             
          
         
       
     
         [0080]    Similarly, the entity com.example.entities.User has an attribute nationality having an entity type, i.e., the entity com.example.entities.Nationality. As shown in  FIG. 5 , the entity com.example.entities.Nationality has the attributes name  501 , notes  503 , and country  503 , and thus the table below lists some additional paths of the entity com.example.entities.User relating to the User attribute nationality. 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
               
                   
                 Path 
                 Type 
               
               
                   
                   
               
             
             
               
                   
                 nationality.name 
                 java.lang.String 
               
               
                   
                 nationality.notes 
                 java.lang.String 
               
               
                   
                 nationality.country 
                 com.example.entities.Country 
               
               
                   
                 . . . 
               
               
                   
                   
               
             
          
         
       
     
         [0081]    We now discuss the concept of a “predicate.” A predicate is the filtering condition in an OQL statement. Informally, the grammar for predicate can be given as 
         [0000]                                            predicate := &lt;binary operator&gt; (&lt;path&gt;, &lt;value&gt; )               |  &lt;unary operator&gt; (&lt;path&gt;)               |  &lt;list operator&gt; (&lt;predicate&gt;+)                        
where the operators are
 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
               
               
                 Type 
                 Operator 
                 Example 
                 SQL Mapping 
               
               
                   
               
             
             
               
                 List 
                 and 
                 and (&lt;a list of predicates&gt;, . . . ) 
                 AND 
               
               
                 List 
                 or 
                 or (&lt;a list of predicates&gt;, . . . ) 
                 OR 
               
               
                 Binary 
                 Equals 
                 equals (&lt;lhs path&gt;, &lt;rhs&gt;) 
                 = 
               
               
                 Binary 
                 startsWith 
                 startsWith (&lt;lhs path&gt;, &lt;rhs&gt;) 
                 LIKE 
               
               
                 Binary 
                 endsWith 
                 endsWith (&lt;lhs path&gt;, &lt;rhs&gt;) 
                 LIKE 
               
               
                 Binary 
                 Less 
                 less (&lt;lhs path&gt;, &lt;rhs&gt;) 
                 &lt; 
               
               
                 Binary 
                 Greater 
                 greater (&lt;lhs path&gt;, &lt;rhs&gt;) 
                 &gt; 
               
               
                 Unary 
                 Nil 
                 nil (&lt;lhs path&gt;) 
                 IS NULL 
               
               
                 . . . 
               
               
                   
               
             
          
         
       
     
         [0082]    Some examples of predicates for the entity com.example.entities.User are set forth in the following paragraphs. 
         [0083]    For example, a predicate in OQL to obtain a list of users with username starting with “A” can be an object-oriented expression such as: 
         [0084]    startsWith (username, A) 
         [0000]    where starts With is an operator, username is a path of the entity com.example.entities.User, and A is the filtering condition. 
         [0085]    The corresponding SQL query might be 
         [0086]    select USER.ID 
         [0087]    from USER u 
         [0088]    where u.USERNAME like ‘A %’ 
         [0089]    Similarly, a predicate in OQL to obtain list of users who have a nickname starting with “A” can be an object-oriented expression: 
         [0090]    startsWith (nicknames, A) 
         [0091]    In the relational database, there are two data tables that must be referenced in order to obtain this information, the USER table and a second table of USER_NICKNAMES. Thus, the corresponding SQL query might be 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 select USER.ID 
               
               
                   
                 from USER u 
               
               
                   
                 where exists (select 1 
               
               
                   
                     from USER_NICKNAMES n 
               
               
                   
                     where u.ID = n .USER_ID and 
               
               
                   
                      n.VALUE like ’A%’). 
               
               
                   
                   
               
             
          
         
       
     
         [0092]    As another example, a predicate in OQL to obtain a list of users in the USA and having a username starting with “A” can be the object-oriented expression: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 and ( 
               
               
                   
                  startsWith (username, “A”), 
               
               
                   
                  equals (nationality.country.name, “USA”)); 
               
               
                   
                   
               
             
          
         
       
     
         [0093]    The corresponding SQL might be 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 select USER.ID 
               
               
                   
                 from USER u 
               
               
                   
                 where exists (select 1 
               
               
                   
                     from USER_NICKNAMES n 
               
               
                   
                     where u.ID = n.USER_ID and 
               
               
                   
                  n.VALUE like ’A%’) 
               
               
                   
                   AND 
               
               
                   
                   exists (select 1 
               
               
                   
                      from NATIONALITY n 
               
               
                   
                      where u.NATIONALITY_ID = n.ID and 
               
               
                   
                       exists (select 1 
               
               
                   
                         from COUNTRY c 
               
               
                   
                         where n.COUNTRY_ID = c.ID and 
               
               
                   
                          c.NAME = USA)). 
               
               
                   
                   
               
             
          
         
       
     
         [0094]    All of these concepts are used in a business object modeling system and method in accordance with aspects and features described herein. 
         [0095]    As noted above, some aspects described herein relate to a method and system that can implement entity extensions. Attributes that are part of an extension of an entity are called data-driven attributes. Attributes that are specified in the code, e.g., java class definition, xml and database columns and tables, are henceforth called the “core attributes” of an entity. Attributes that are specified after the deployment through data are called “extension attributes.” 
         [0096]    The values of extension attributes are often stored in the format of name-value pairs or in a vertical schema such as vertical table  1301  shown in  FIG. 13 . As shown in vertical table  1301 , in the vertical schema there are three columns: the first column  1301   a  uniquely identifies the entity, the second column  1301   b  identifies the extension attribute, i.e., the attribute name, and the third column stores the value of the attribute as either a string value  1301   c , a float value  1301   d , or an integer value  1301   e.    
         [0097]    In conventional object-oriented programming, a programmer using the object-centric interface has to access/modify the core attributes using one set of interfaces and access/modify the extension attributes using a different set of interfaces. For example, if a programmer wanted to obtain a list of users born after the year 2000, she may wish to write a query to obtain such information. However, a query such as 
         [0098]    from.com.example.entities.User 
         [0099]    where birth_year&gt;2000 
         [0000]    is not supported in standard OQL because birth_year is not a core attribute but is instead an extension attribute, and so the programmer would have to write the query using SQL. However, SQL is more complicated to write. To write an SQL query, a programmer would have to use the name-value pair tables for storing attribute values, know the structure of the data tables containing information for both core and extension attributes and know the mappings between attributes and the relational tables. By using the name-value pair tables for storing attribute values, the standard query languages provided by ORMs break the fundamental tenets of object-oriented programming. i.e., encapsulation of data and hiding of the way in which the data is implemented. The loss of implementation hiding (that is, how the hiding extension attributes are stored) curtails the future enhancement and may change or inhibit the development of storage mapping logic that may provide better performance. 
         [0100]    To address these problems between object-oriented and relational database-oriented programming, aspects and features described herein provide a uniform object-centric interface to both core and extension attributes. Thus an enterprise application built using an extended ORM as described herein can provide: 
         [0101]    a uniform mechanism to access and edit core and extension attributes, 
         [0102]    an object-oriented programming interface to encode business logic, and 
         [0103]    a uniform mechanism to query entities. 
         [0104]    The way in which core attributes of various types (fundamental, composite, entity and collection) can be specified and the way in which their values can be mapped to the relational system using an ORM were described above. 
         [0105]    We now present an embodiment of how extension attributes of various types can be specified and how their values can be mapped to the relational system in accordance with one or more aspects and features of an object modeling system and method described herein. 
         [0106]    The attribute values for entities are stored in attribute value tables. Each entity has an associated attribute table. The specification of extension attributes are stored in an ATTRIBUTE table that maps to the object type com.example.entities.Attribute. The tables that start with an “EXT_” prefix store values for extension attributes for that entity (the prefix EXT_is a convention). For example, the core attribute values for the entity com.example.entities.User are stored in the USER table and the extension attribute values are stored in an EXT_USER table such as EXT_USER Table  1501  shown in  FIG. 15A . 
         [0107]    As shown in  FIG. 14 , each record in the ATTRIBUTE table  1401  denotes an exemplary extension attribute for an entity. 
         [0108]    The fields of ATTRIBUTE table  1401  shown in  FIG. 14  include: 
         [0109]    ID  1401   a : An identifier for the attribute (a primary key). The ID field is used in attribute value tables like EXT_USER where the values of the attributes for com.example.entities.User are stored. 
         [0110]    NAME  1401   b : Name of the attribute, for example, birth_country  1403   a , birth ear  1403   b , home  1403   c , visited_countries  1403   d , or region  1403   e . This attribute name can be used in generation of path and predicates. 
         [0111]    ENTITY  1401   c : Name of the entity that is being extended, for example, com.example.entities.User  1405   a  or com.example.entities.Country  1405   b.    
         [0112]    TYPE  1401   d : The object type of the extension attribute. This dictates where the information regarding the attribute value is stored in the attribute value tables. For example, if the type is Integer, then the value of the attribute is stored in the V_INT_ 0  column. If the type is String, then the value of the attribute is stored in the V_STR_ 0  column. If the attribute is of composite type, then the value is stored in one or more columns, each having data of the attributes relating to that entity. 
         [0113]    In accordance with aspects described herein, an entity object can be extended with attributes of either a fundamental or a composite type as described above. As noted above, the values of the extension attributes for the entity com.example.entities.User—both fundamental and composite types—can be stored in a table such as the EXT_USER table  1501  shown in  FIG. 15A . 
         [0114]    Thus, as shown in the exemplary ATTRIBUTE table  1401  in  FIG. 14 , the entity com.example.entities.User  1405   a  has been extended by adding attributes in ATTRIBUTE table  1401  such as birth country  1403   a , birth_year  1403   b , home  1403   c , and visited_countries  1403   d , and the entity com.examples.entities.Country  1403   e  can be extended by adding an attribute region  1403   e . These attributes can be of types com.examples.entities.Country  1407   a  (i.e., an entity type), Integer  1407   b  (i.e., an integer type), com.example.util.Address  1407   c  (i.e., a composite type), List[com.examples.entities.Country]  1407   d , and String  1407   e , respectively. 
         [0115]    As shown in  FIG. 15A , the value of an attribute of fundamental type is given by a record in the EXT_USER table  1501  with the attribute&#39;s identifier in ATTR_ID and user&#39;s identifier in USER_ID. For example, as shown in EXT_USER table  1501 , the value of birth year (ATTR_ID=23) for a particular user (USER ID=19) is 2002, and because this value is an integer, it is stored in the column  1503   d  labeled V_INT_ 0 . 
         [0116]    An entity object also can be extended by adding collections of fundamental types. For example, as shown in ATTRIBUTE Table  1401  in  FIG. 14 , the record with ID  25  can add an extension attribute of collection type named visited_countries  1403   d  to the entity com.example.entities.User  1405   a . The values of this extension attribute comprise a list of entities, shown in  FIG. 14  as List[com.example.entities.Country]  1407   d . The values for this attribute of the entity com.example.entities.User  1405   a  are stored in multiple records in the EXT_USER Table shown in  FIG. 15A . For example, as shown in  FIG. 15 , the value of visited_countries (ATTR ID=25) for a user (USER ID=44) is the set {76, 79, 32} of the identifiers from the COUNTRY Table  1505  shown in  FIG. 15B  stored in V_ID_ 0 . As shown in  FIG. 15A  the records with ID=43, 545 and 543, William (USER ID=44) has visited India, Egypt and UK. The ATTR_ID=25 correspond to the attribute visited_countries and as shown in  FIG. 15B , the values  76 ,  79  and  32  respectively, correspond to the countries India, UK and Egypt. Given that visited_countries is a List, the field INDEX  1503   c  specifies order in which the values are stored in the list. 
         [0117]    An entity object also can be extended with attributes of an entity type. For example, as shown in ATTRIBUTE Table  1401  in  FIG. 14 , the record with ID  22  adds an extension attribute of entity type named birth country  1403   a  to the entity com.example.entities.User, and this extension attribute is of entity type com.example.entities.Country  1407   a . The value of this attribute can be given by a record in an EXT_USER Table in column  1503   e  V_ID_ 0 . As shown in  FIG. 15A  and  FIG. 15B , the record with ID=478, William (user with ID=44) was born in Brazil. The ATTR_ID=22 corresponds to the attribute birth country and the value of 80 in V_ID_ 0  corresponds to the country Brazil. 
         [0118]    In the case of the attribute home  1403   c  having an attribute of composite type com.example.util.Address  1407   c , the value of home comprises the attributes of com.example.util.Address, and the values of those attributes are stored in one or more appropriate columns in an EXT_ATTRIBUTE table such as EXT_USER Table  1501  shown in  FIG. 15A . The entity com.example.util.Address has three attributes, zipcode, city, and street, each of type java.lang.String. Consequently, the value of the extension attribute in the ATTRIBUTE table of type com.example.util.Address is stored in one or more columns V_STR_ 0 , V_STR_ 1  and V STR_ 2  in EXT_USER Table  1501 , each containing the value of one of the three attributes zipcode, city, and street. 
         [0119]    Features of an extendable ORM described herein also provide a uniform interface to interact with both core and extension attributes. These and other features can enable an enterprise to interact with both core and extension attributes of entities corresponding to records in an enterprise database and can enable enterprise personnel to write business logic that is not dependent on the storage mechanism of the attribute values. 
         [0120]    Exemplary components of an extendable ORM method and system in accordance with aspects and features described herein are shown in  FIG. 16 . As shown in  FIG. 16 , an extendable ORM can include a standard ORM toolkit  1611 , a component  1605  that encapsulates the concept of “path” hiding the implementation differences between extension and core attributes, a query processor  1607  that takes an OQL and generates the corresponding SQL, a java interface  1609  to access the attributes (get function) and modify the attributes (set function). In addition, a java-javascript bridge  1603  (like rhino, an open source implementation of javascript scripting language) that provides a Javascript Scripting environment. 
         [0121]    Features of an extendable ORM method and system in accordance with one or more aspects and features described herein can be used to extend the concept of “path” discussed above. In accordance with aspects herein, the concept of path can be extended with the concept of extension attributes discussed just above. As shown in  FIG. 14 , an entity com.example.entities.User  1405   b  has extension attributes birth_country  1403   a , birth ear  1403   b , home  1403   c  and visited_countries  1403   d . The entity com.example.entities.Country  1405   b  has an extension attribute region  1403   e . Thus, in addition to the core paths for the entity com.example.entities. User such as “username,” “address,” “nationality,” “nickname,” “address.zipcode,” etc., as described above, the following additional paths can also be defined for the entity com.example.entities.User: 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
               
                   
                 Path 
                 Type 
               
               
                   
                   
               
             
             
               
                   
                 birth year 
                 java.lang.Integer 
               
               
                   
                 Home 
                 com.example.util.Address 
               
               
                   
                 home.street 
                 java.lang.String 
               
               
                   
                 . . . 
               
               
                   
                 visited_countries 
                 List[com.example.entities.Country] 
               
               
                   
                 visited_countries.name . . . 
                 java.lang.String 
               
               
                   
                 nationality.country 
                 Com.example.entities.Country 
               
               
                   
                   
               
             
          
         
       
     
         [0122]    In the definition of path, the system provides an interface where the user does not need to be aware of whether an attribute is a core attribute or an extension attribute. 
         [0123]    In the above table, we have paths visited_countries and nationality country of type com.example.entities.Country (or a collection of com.example.entities.Country). Table  1401  defines an extension attribute region for entity com.example.entities.Country. Thus the following are also valid paths for the entity com.example.entities.User: 
         [0000]                                            Path   Type                           [visited_countries.region   java.lang.String           nationality.country.region   java.lang.String                        
Note that in the above table, the paths ending with region are a result of the extension of the entity com.example.entitiesCountry.
 
         [0124]    In the definition of path, the system provides an interface where the user does not need to be aware of whether an attribute is a core attribute or an extension attribute. 
         [0125]    As discussed in more detail below, using an extension of the path in accordance with aspects herein can enable an enterprise to:
       implement a unified query mechanism, i.e., OQL statements can be used without the need to write SQL queries;   implement a unified interface for accessing and modifying attributes of an entity, and   implement a unified interface for writing business logic in a scripting environment, where paths are first-class object properties.       
 
         [0129]    As noted above, features described herein can enable an enterprise implement a unified query mechanism, i.e., to more easily query its databases by using OQL rather than SQL queries. The interface to the query specification to obtain values of both extension and core attributes is the same. For example, the predicate for a list of users with birth year after 2000 can be given as
       greater (birth_year, 2000)
 
Such a query seeks information regarding the extension attribute birth_year. However, as noted above, the standard query languages provided by conventional ORMs do not support such a query, and an SQL query would have to be written instead. In accordance with aspects described herein, a query processor such as Query Processor  1607  shown in  FIG. 16  can generate the SQL query that is executed on the database looking for birth year in the attribute value table.
       
 
         [0131]    Exemplary ways in which such an SQL query can be generated from a query presented as an OQL query are discussed below. 
         [0132]    A first example is generation of an SQL query from the OQL query for a list of users having a birth year after 2000. The predicate for this query is specified as 
         [0133]    greater (birth_year, 2000) 
         [0134]    The corresponding SQL query generated by the Query Processor might be 
         [0000]                                              select u.ID             from USER u           where exists (select 1                 from EXT_USER e                 where e.USER_ID = u.ID and                   e.ATTR_ID = 23 and                   e.V_INT_0 &gt; 2000)                        
where the attribute identifier in an extension attribute table such as ATTRIBUTE Table  1401  shown in  FIG. 14  for the extension attribute birth ear is e.ATTR_ID is 23 and the value for that attribute is stored in the V_INT_ 0  column  1503   e  in ATTRIBUTE Table  1401 .
 
         [0135]    A second example is a query to obtain a list of users who have a country in the “Europe, Middle East, and Africa” region, often abbreviated as “EMEA”. The predicate for such a list can be expressed as 
         [0136]    equals (visited_countries.region, “emea”) 
         [0137]    The equivalent SQL query that can be generated by the Query Processor to obtain this same information from ATTRIBUTE Table  1401  might be 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 select u.ID 
               
               
                 from USER u 
               
               
                 where exists (select 1 
               
               
                      from EXT_USER eu 
               
               
                     where eu.USER_ID = u.ID and 
               
               
                       eu.ATTR_ID = 25 and 
               
               
                         exists (select 1 
               
               
                             from COUNTRY c 
               
               
                             where eu.V_ID_0 = c.ID and 
               
               
                               exists (select 1 
               
               
                                   from EXT_COUNTRY ec 
               
               
                                 where c.ID = ec.ID and 
               
               
                                   ec.ATTR_ID = 26 and 
               
               
                                  ec.V_STR_0 =“emea”))) 
               
               
                   
               
             
          
         
       
     
         [0138]    A third example is a composite query to obtain a list of who have both a country in the “EMEA” region and a birth year after 2000. In OQL language, this is just a concatenation of the predicates shown above: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 and ( 
               
               
                   
                 equals (visited_countries.region, “emea”), 
               
               
                   
                 greater (birth_year, 2000) 
               
               
                   
                 ); 
               
               
                   
                   
               
             
          
         
       
     
         [0139]    The equivalent SQL query generated by Query Processor  1607  also is a combination of the previous queries: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 select u.ID 
               
               
                 from USER u 
               
               
                 where exists ( 
               
               
                   select 1 
               
               
                  from EXT_USER e 
               
               
                     where e.USER_ID = u.ID and 
               
               
                       e.ATTR_ID = 23 and 
               
               
                       e.V_INT_0 &gt; 2000 and 
               
               
                          exists ( 
               
               
                         select 1 
               
               
                         from EXT_USER eu 
               
               
                         where eu.USER_ID = u.ID and 
               
               
                           eu.ATTR_ID = 25 and 
               
               
                           exists ( 
               
               
                            select 1 
               
               
                        from COUNTRY c 
               
               
                       where eu.V_ID_0=c.ID and 
               
               
                                 exists ( 
               
               
                                  select 1 
               
               
                                   from EXT_COUNTRY ec 
               
               
                                   where c.ID = ec.ID and 
               
               
                                     ec.ATTR_ID = 26 and 
               
               
                                    ec.V_STR_0 = “emea”)))) 
               
               
                   
               
             
          
         
       
     
         [0140]    Other features of a business object modeling system and method as described herein provide a mechanism to access/update the value for both core and extension attributes using a uniform interface. 
         [0141]    The exemplary software code portion  1701  shown in  FIG. 17  illustrates the use of class variables to store the extension values. For each of the core attributes an field is declared for the class, and the values for extension attributes are stored in the variable extension_values  1703 . 
         [0142]    Whenever the ORM loads an entity object, it loads the values for the extension attributes into the field “extension_values.” When the entity object is updated/saved to the database, the extension attributes in the field extension_values are stored in the database. For example, as shown in  FIG. 17 , the field extension_values for the entity type com.example.entities.User is a collection of values for com.example.entities.UserAttributeValue  1705 .  FIG. 18  depicts an exemplary xml hibernate mapping between the java object com.example.entities.UserAttributeValue and the corresponding database table EXT_USER  1803  and the mapping between the field extension_values for the java object com.example.entities.User and the database relationship between the two. 
         [0143]    A uniform interface in accordance with aspects herein can provide attribute-type-independent methods to get and set the values of attributes rather than the conventional methods used in standard ORM implementation such as getusername( ) and set UserName( . . . ). 
         [0144]      FIGS. 19 and 20  illustrate an exemplary implementation of the uniform interface. As shown in the exemplary code sequence  1901  in  FIG. 19 , the get method inspects the attribute path being passed. If the path references a core attribute, then the corresponding getter method is called. For example, for the attribute username, the corresponding conventional command to get the value is getUsername( ) and that is the command that the system calls. However, if the path references an extension attribute rather than a core attribute, then the value is looked up from the class member “extension_values.” Similarly, as shown in the exemplary code sequence  2001  in  FIG. 20 , the set method inspects the attribute path and decides to either call the corresponding setter method for core attributes, for example, setUsername( ), or update the value in the member field “extension_values” if the attribute is an extension attribute. 
         [0145]    For example, an exemplary code sequence to get the value of a core attribute using the type-independent get function described above is: 
         [0000]                                            User u = session.load (2);           value = u.get (“address.zipcode”);   // accessing a core attribute                        
The code sequence to get the value of an extension attribute is the same, i.e., does not depend on whether the attribute is a core attribute or an extension attribute:
 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 value = u.get (“birth_year”);    // accessing an extension attribute 
               
               
                   
               
             
          
         
       
     
         [0146]    Similarly, an exemplary code sequence to set the value of a core attribute is: 
         [0000]                                User u = session.load (2);       value=u.set (“address.zipcode”, 75025);   // modifying a core attribute                    
and the same code sequence is used to set the value of an extension attribute:
 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 value=u.set (“birth_year”, 2005);   // modifying an extension attribute 
               
               
                   
               
             
          
         
       
     
         [0147]    Thus, in accordance with aspects described herein, at the user interface level, there is no need to differentiate between a core attribute and extension attribute. The commands entered by a user are the same for both a core attribute and an extension attribute. 
         [0148]    Other features of a business object modeling system and method described herein provide a scripting interface that enables an enterprise to write business logic that works with both core and extension attributes. The scripting engine is a standard Javascript implementation in Java (Rhino). Some of the interfaces necessary to enable the scripting are 
         [0149]    Interface to perform read, save and delete operations on entities, 
         [0150]    Interface for predicate and query generation and 
         [0151]    Interface to the get and set functions of the entities. 
         [0152]    An exemplary script to obtain a list of users born after the year 2000 is as follows: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                   var users = query (“from com.example.entities.User 
               
               
                   where birth_year &gt; 2000”); 
               
               
                   for (var u in users) { 
               
               
                    for (var c in u.visited_countries) { // referencing user’s extension 
               
               
                                  // attribute “visited_countries” 
               
               
                     print (u.name + ’ : ’ + c.region) //referencing user’s core 
               
               
                                  // attribute “name” and countries’ 
               
               
                                // extension attribute“region” 
               
               
                    } 
               
               
                 } 
               
               
                   
               
             
          
         
       
     
         [0153]    The query method referred in the script call the query processor to return the list if users satisfying the predicate. The access functions such as “u.visited_countries”, “u.name,” and “c.region” invoke the corresponding attribute type-independent get method described above. 
         [0154]    Note that the scripting interface gives us a uniform interface to core and extension attributes. In other words, the user can write a simple script that will enable the user to query both core and extension attributes without the need to distinguish between the two or know which type of attribute, core or extension, the enterprise considers a particular attribute to be. 
         [0155]    Another embodiment of a business object modeling system and method in accordance with aspects and features described herein provides an ability to perform rule-based evaluation of attributes of an entity. For example, an enterprise system can have some embedded business logic based on the enterprise entities&#39; core attributes. 
         [0156]    When an enterprise system is deployed, almost all the major entities (or concepts) also exist in some other enterprise data system. For example, the concept of user exists in a User Directory such as Microsoft Corporation&#39;s ACTIVE DIRECTORY product or some other LDAP-based product. The concept of bill of materials (BOM) exists in some supply chain data management system such as SAP™. When additional systems are deployed, the data requirements for deploying the new systems can be greatly reduced if those new systems provide efficient data integration with these existing enterprise data systems. 
         [0157]    For example, the entity com.example.entities.User may have an attribute plan that is used by the enterprise system to create a monthly bill for its users. Consider a service provider that provides connectivity services (Dial-up, Internet, Wi-fi, etc.) to its clients. The provider installs an enterprise system that understands connectivity and is responsible for creating a monthly bill for its client. The provider has a list of predefined plans, where each plan has a rate per minute of connectivity for each region of the world. For example, a plan named “european plan” may cost $0.10 per minute for all connections from Europe and $0.50 per minute for the rest of the world. The system creates a monthly bill based on various parameters such as a user&#39;s connection duration, plan, etc. Thus, in the billing system each user has an attribute plan that is used to compute the cost incurred for the usage of connectivity services. The provider is interested in providing a cost-effective service, for example by assigning a european_plan for users from “Europe”, an asian_plan for users from “Asia,” etc. The provider may also be interested in providing an efficient service that allows users to change plan assignments when they move from one region to another. In addition, the provider may want to reduce the maintenance of users in two systems—an already existing user data store (Active Directory) and users in the billing system. 
         [0158]    In accordance with a business object modeling system and method according to aspects and features herein, as shown in  FIG. 21 , billing system  2101  in such an enterprise can get user data  2103  from the enterprise&#39;s Active Directory  2105 , and the value of the attribute plan for the enterprise&#39;s users can be computed using one or more rules. 
         [0159]    Thus, instead of directly specifying a user&#39;s plan, the administrator can specify a set of rules that dictate the value for the attribute plan. Each attribute whose value can be rule-based has an associated object entity and relational table that can be used to evaluate the attribute. 
         [0160]    For example, if the plan attribute of com.example.entities.User is rule-based then the associated object entity is com.example.entities.UserPlanRule and the relational table is USER_PLAN_RULE  2209  shown in  FIG. 22B . The table USER_PLAN_RULE  2209  has the following fields: ID  2211 , which contains an identifier of the record; ORDER  2213 , the order in which the rules are evaluated; RULE_ID  2215 , a reference (foreign key) to the rule being evaluated; and PLAN_ID  2207 , the value used when the rule evaluates to “true” for a particular user. Thus, for integrating the new enterprise system, the user information (username etc.) can be synchronized from an existing user directory like Active Directory with rules specified for the plan without having to modify the user information itself. This enables the life-cycle of the user records to be managed through an existing system. 
         [0161]    The system implements the rule-based evaluation of attribute values for query processing and in memory evaluation. 
         [0162]    The database schema includes addition of a flag to indicate whether the value of the core field is specific or should be evaluated using rules. Thus, as shown in  FIG. 22A , for the USER with ID  24 , the value of the user&#39;s plan attribute is given by the value in PLAN_ID field  2207 , as indicated by the 0 value in the column RULE_BASE_PLAN  2205 . For the USER with ID  42  the value of the attribute plan is computed using rules since the value in the field RULE_BASE_PLAN  2205  is 1.  FIGS. 22B-22C  show the rules that are evaluated to compute the value of the plan attribute. For example, as shown in  FIG. 22B , the rules specified by the field RULE_ID  2215  in USER_PLAN_RULE table  2209  are evaluated in order (based on ORDER field  2213 ). For the user in question (in this case user with ID  42 ) the rules with ID  3  and  4  as given in the field RULE_ID  2215  are evaluated in order. If rule with ID  3  evaluates to true then the corresponding value in PLAN_ID  2207  that is a plan with ID  23  is assigned to the user in question otherwise the next rule is evaluated. 
         [0163]      FIG. 22C  specifies the rules in column VALUE  2219  and their corresponding ID  2215 . As seen in  FIG. 22C , ID  2215  shown in  FIG. 22B  correlates to a predicate expressed in VALUE field  2219  in RULE table  2217 . For example, the value of the rule with ID  3  in the field ID  2215  corresponds to the predicate “equals (nationality.country.region, “europe”)” in VALUE field  2219 , and the value of the rule with ID  4  corresponds to the predicate “equals (nationality.country.region, “asia”).”  FIG. 22D  specifies the plans in column VALUE  2223  and the corresponding ID  2207 . Thus, as seen in  FIG. 22D , the value of plan ID  43  in ID field  2207  in the PLAN table  2221  is “asian plan,” and user number  24  shown in  FIG. 22A , whose plan ID number is  43 , is covered by the enterprise under the enterprise&#39;s asian plan. The user number  42  whose plan ID number is unspecified is covered by one of the plans depending on which rule evaluates to “true.” 
         [0164]    In the object-oriented environment,  FIG. 23  shows the addition of a corresponding Boolean field in the definition  2301  of the entity com.examples.entities. User for evaluating whether a user is subject to a rule-based plan.  FIG. 24  shows an exemplary mapping  2401  between the relational environment for rule-based evaluation described above and the object environment 
         [0165]    Using the object-relational mapping between the object environment and the relational environment, evaluation of the plan attribute involves modifying the getter methods to check the Boolean field to return the value. For example, if the “rule_base_plan” flag is true, then the rules are evaluated in order to compute the value of the field. 
         [0166]    For query processing relating to rule evaluation as discussed above, the generation of SQL from OQL by the query processor embeds the rules for the result set computation. For example, for the list of users with a plan attribute value of European_plan the predicate can be given by 
         [0167]    equals (plan.name, “european_plan”) 
         [0168]    The SQL query generated by Query Processor  1607  shown in  FIG. 16  can be in the form: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 select u.ID 
               
               
                 from USER u 
               
               
                 where (u.RULE_BASED_PLAN = 0 and 
               
               
                   exists (select 1 
               
               
                     from PLAN p 
               
               
                     where u.PLAN_ID = p.ID and 
               
               
                     p.NAME = “european_plan”)) 
               
               
                   OR 
               
               
                     (u.RULE_BASED_PLAN = 1 and 
               
               
                     /* Expanding RULE_ID = 3 from USER_PLAN_RULE */ 
               
               
                     /* equals (nationality.country.region, “europe”) */ 
               
               
                     (exists (select 1 
               
               
                       from NATIONALITY n 
               
               
                       where n.ID = u.NATIONALITY_ID and 
               
               
                        exists (select 1 
               
               
                          from COUNTRY c 
               
               
                           where n.COUNTRY_ID = c.ID and 
               
               
                               exists (select 1 
               
               
                         from EXT_COUNTRY ec 
               
               
                           where c.ID = ec.ID AND 
               
               
                             ec.ATTR_ID-26 AND 
               
               
                           ec.V_STR_0=“europe”))) 
               
               
                     AND 
               
               
                     /* The PLAN_ID corresponding to first rule from 
               
               
                     USER_PLAN_RULE is 23 */ 
               
               
                     (select 1 from PLAN where ID = 23 and 
               
               
                     NAME = “european_plan)) 
               
               
                 OR 
               
               
                 ... 
               
               
                 ) 
               
               
                   
               
             
          
         
       
     
         [0169]    Another embodiment of a business object modeling system and method having one or more features described herein relates to a system that can be used to support Software-as-a-Service provisioning. The value proposition of a SaaS provider is two-fold. Use of an SaaS provider enables an organization to outsource the activities that are not part of its core competency, thus allowing it to concentrate on its core offerings. In addition, by using an SaaS provider, an organization is able to get a better quality of service since the provider&#39;s sole focus is the service, enabling it to innovate and invest in the focused area. 
         [0170]    However, such outsourcing of services can induce inefficiencies in data management unless they are addressed. For example, an organization may have to manage two user management systems, or management of data may become a two step process—the organization has to instruct a representative of the provider, who then makes the necessary changes in the enterprise system. Another inefficiency stems from the inability to extend the model or add custom business logic. Thus, data management in an SaaS environment requires a flexible data model design. The system should allow customer specific extensions to the data model to enable modeling a customer specific objectives. 
         [0171]    Aspects and features of a business object modeling system and method described herein can provide a mechanism that can allow a provider such as an SaaS provider to extend a standard data model and so meet the specific needs of a customer or reseller. 
         [0172]    An enterprise system for a SaaS provider should enable creation of an environment that can replicate an in-house deployment of the service. Therefore, the enterprise system should provide an environment where a customer can create extensions to the model and add business logic. The environment thus created for the customer should be insulated from changes (e.g., extensions of the model and addition of business logic) enabled for another customer. 
         [0173]    These two elements of an business object modeling system and method in accordance with aspects described here in can be enabled using two concepts: Hierarchical Namespace and Visibility. 
         [0174]    A business object modeling system and method having one or more features and aspects described herein can provides a hierarchical representation of data, that is, every entity can be associated with an organization tree. As shown in  FIG. 25 , data in data table  2501  can be shown wherein each record having a name  2601   c  in the organization&#39;s database has an associated ID  2501   a . In addition, each record is shown as having a PARENT_ID  2501   b . For example, as shown in  FIG. 25 , the record for “SaaS provider” is given ID number  1  and is shown as having no PARENT_ID; in contrast, the record for Customer A is given ID number  2  and is shown as having PARENT_ID number  1 . Similarly the record for Medical Equipment is shown as having ID number  6  and PARENT_ID number  5 . The hierarchical nature of the record ID numbers and PARENT_IDs is shown more clearly in schematic  2601  in  FIG. 26 . 
         [0175]    This hierarchical structure forms the basis for all other entities. Therefore, as shown in  FIG. 27 , the entity com.example.entities.User has an additional attribute (i.e., the code snippet “{Organization organization}”) that refers to an organization (or node) in the tree. As shown in  FIG. 28 , the USER table  2801  has an additional field  2803  ORGANIZATION_ID (a foreign key to the ORGANIZATION table), and  FIG. 29  shows the mapping  2901  between the attribute organization of the class com.example.entities.User and the field ORGANIZATION_ID of the table ORGANIZATION. Similarly, an attribute object com.example.entities.Attribute has an attribute organization and the corresponding ATTRIBUTE table  3001  shown in  FIG. 30  has a field ORGANIZATION_ID  3003 . 
         [0176]    A business object modeling system and method having features and aspects is described herein also defines the concept of visibility. All processing (through queries, etc.) has an organization context associated with it. There are two fundamental types of visibility, bottom-up and top down. Entities that are managed (e.g. users, computers) follow bottom-up visibility and entities that define how other entities are managed (e.g. configuration, service plans) follow top-down visibility. 
         [0177]    For bottom-up visibility, the set of visible entities at a node comprises the set of entities that belong to the context node (the node where we are defining the visibility set) or to the subtree rooted at the context node. For example, if a query is executed in the context of node  3  (Reseller) as shown in  FIG. 26 , then the result set from that query is a subset of all the entities defined for 3—the context node—and the subtree i.e. 4, 5, 6, and 7. This can be alternatively specified using SQL as “select*from USER where ORGANIZATION_ID in (3, 4, 5, 6, 7).” For top down visibility, the set of visible entities at a node comprises the set of entities that belong to the context node in addition to the set of entities visible to the context&#39;s parent node. For example, if a query is executed in the context of node  5  (Customer Y) shown in FIG.  26 , then the result set is a subset of all the entities defined for 5—the context node—and its parents (3 and 1). 
         [0178]    The concepts of hierarchy and visibility implicitly provide data partitioning. Whenever any business process is run, a projection of the data is presented to the system. The projection is dictated by the visibility type of the entity. The entities that have “top down” visibility affect the entities that are defined only within their subtrees. The result is that an object such as com.example.entities.Attributes defines entity extensions that are valid only in the subtree where they are defined and can be referred in rules defined only in the subtree where they are defined. Top-down visibility of entities allows providers (SaaS providers or Resellers) to define services like connectivity plans and make them available to the bottom-up entities defined in the subtree. The concept of visibility, for example, as seen in the tree structure shown in  FIG. 26 , brings the concept of isolation between two customers such as Customer X and Customer Y shown in  FIG. 26 . A entity (instance of com.example.entities.Attribute or com.example.entities.Plan) that follows top-down visibility defined at node  2  (Customer A) is not visible to the subtree rooted at the node  3  (Reseller) and vice-versa. Therefore an administrator belonging to the organization “Customer A” can create, modify entities without effecting the organization “Reseller” and its subtree (or its managed customers). We will illustrate the concept of isolation with respect to com.example.entities.Attribute (hence extension attributes) in the discussion below. 
         [0179]    In a SaaS environment, the system should enable localized configuration of the system by one customer without affecting another. Say, the Reseller (node  3 ) wants to capture an additional attribute (thus an extension attribute) named “common” for all its users. Therefore the Reseller can define an instance of com.example.entities.Attributes that corresponds to the record ID=1 in the ATTRIBUTE table  3001  shown in  FIG. 30 . Note that the ORGANIZATION_ID=3. Therefore all instances of com.example.entities.User defined at node  3  or its subtree will have an attributes “common” and any other instance of com.example.entities.User are not affected (that is, a user defined at node  2  does not have an attribute “common”). This provides an isolation between how the Reseller wants to configure the system and how Customer A (node  2 ) wants to configure the system. 
         [0180]    The extension attributes of an entity are defined by the set of com.example.entities.Attributes visible at the context node. For example, an instance of com.example.entities.User defined at node  5  for Customer Y as shown in  FIG. 26  has extension attributes defined by the subset of com.example.entities.Attributes in which organization is one of node  1  (SaaS Provider), node  3  (Reseller), or node  5  (Customer Y).  FIG. 30  shows a possible scenario where an instance of the entity com.example.entities.User defined at nodes  5  or  6  or  7  will have the extension attributes 
         [0000]                                                Name   Type   Notes                           common   String   Defined at organization Reseller/3           Same   Integer   Defined at organization Customer Y/5           Five   Integer   Defined at organization Customer Y/5                        
whereas an instance defined at 4 (Customer X) will have the extension attributes
 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 Name 
                 Type 
                 Notes 
               
               
                   
                   
               
             
             
               
                   
                 common 
                 String 
                 Defined at organization Reseller/3 
               
               
                   
                 Same 
                 String 
                 Defined at organization Customer X/4 
               
               
                   
                 Four 
                 Integer 
                 Defined at organization Customer X/4 
               
               
                   
                   
               
             
          
         
       
     
         [0181]    As can be seen in this example, entities can be extended by two customers independent of each other. For example, the set of valid paths for com.example.entities.User defined at node  4  are different from the set of valid paths for com.example.entities. User defined at node  5 :
       a) The path “four” is valid for users defined at node  4  but not for users defined node  5 , and the path “five” is valid at node  5  but not at node  4 .   b) The path “same” is valid for users defined at both node  4  and node  5 , but probably have completely different meaning, given one is an Integer and another is a String value.   c) The path “common:” is valid for users defined at both node  4  and node  5  and have the same meaning/significance, but is an invalid path for users defined at node  2 .
 
Thus, each customer may extend its entities using extension attributes without affecting other customers.
       
 
         [0185]    For rule-based evaluation of attributes, the order of evaluation is up the hierarchy until the root of the organizational tree is reached, or a rule is found. For example, for a rule-based attribute plan for entity com.example.entities.User defined at node  5 , the rules specified at node  5  are evaluated, and then those at node  3  and then those at node  1 . This enables the two organizations Customer X and Customer Y to have two completely different set of rules to evaluate a rule-based attribute. 
         [0186]    We shall illustrate the process of rule-based evaluation in a hierarchical setting using an example. Consider the following rules to be defined at the reseller node, node  3 : 
         [0000]                                        Organization   #   Rule or Predicate   Value                   3   1   equals (nationality.country.region,   european plan               “europe”)       3   2   equals (nationality.country.region,   asian plan               “asia”)       3   3   True   standard plan                    
Customer X can override the rules by defining a new set of rules for Customer X, node  4 :
 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
               
               
                 Organization 
                 # 
                 Rule or Predicate 
                 Value 
               
               
                   
               
             
             
               
                 4 
                 1 
                 or (equals (four, 42), 
                 european plan 
               
               
                   
                   
                 equals (nationality.country.region, 
               
               
                   
                   
                 “europe”)) 
               
               
                 4 
                 2 
                 True 
                 standard plan 
               
               
                   
               
             
          
         
       
     
         [0187]    In the context of the assignment of “plans” as described above, the resulting evaluation of the rules for users defined at 4 or its subtree is 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 if (or (equals (four, 42), 
               
               
                  equals (nationality.country.region, “europe”))) assign “european_plan” 
               
               
                 else 
               
               
                 assign “standard_plan” 
               
               
                   
               
             
          
         
       
     
         [0188]    The organization/client Customer X defined a rule that referred to an model extension applicable to its subtree—four, and modified the logic for computing the value of plan attribute completely. Customer Y can partially override the rules by defining a new set of rules at node  5 : 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
               
               
                 Organization 
                 # 
                 Rule or Predicate 
                 Value 
               
               
                   
               
             
             
               
                 5 
                 1 
                 or (equals (five, 42), 
                 european plan 
               
               
                   
                   
                 equals (nationality.country.region, 
               
               
                   
                   
                 “europe”)) 
               
               
                   
               
             
          
         
       
     
         [0189]    The resulting evaluation of the rules for users defined at 5 or its subtree is 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 if (or (equals (five, 42), 
               
               
                   equals (nationality. country .region, “europe”))) 
               
               
                   assign “european_plan” 
               
               
                 else if (equals (nationality.country.region, “europe”)) 
               
               
                 assign “european_plan” 
               
               
                 else if (equals (nationality.country.region, “asia”)) assign “asian_plan” 
               
               
                 else 
               
               
                   assign “standard_plan” 
               
               
                   
               
             
          
         
       
     
         [0190]    In conclusion, a client of the SaaS provider (an organization) can define their own rules for rule-based attributes without affecting the rules of another customer. In addition, a customer can use all of the entity attribute extensions that are visible to it from a top-down perspective. 
         [0191]    Other aspects of a business object modeling system and method described herein can relate to the way in which an LDAP-based product like Active Directory, openLDAP, iPlanet, etc. plays a central role in user management for a SaaS provider&#39;s typical customers. IT (and non-IT) administrators want to manage all aspects of user management from their standard user repository like Active Directory or LDAP. Aspects of a business object modeling system and method described herein can assist such administrators to meet these goals. 
         [0192]    In any SaaS system, user management is one of the critical functions provided by the platform. User life cycle management is necessary for enabling the services provided by a provider. In addition, the user identities are stored in a data repository, e.g., a relational database management system (RDBMS). Synchronizing user identities from a customer&#39;s LDAP to the platform is a seamless way to manage the lifecycle of a user. Thus, a customer administrator creates, updates, or deletes a user in their corporate LDAP and at the next sync cycle the action is reflected in provider&#39;s repository. The synchronization can be provided using bulk load processes or through the use of virtual directory technology. 
         [0193]    An embodiment of a business object modeling system and method described herein can provide a mechanism to allow an enterprise to map multiple LDAP schemas, where each customer may have a different schema, into a unified relational data model. 
         [0194]    A customer can extend any business object (User, Location, Currency etc) in the system to represent an attribute from their corporate LDAP. The value of that business object can be stored in a non-normalized data table. In this way, a customer&#39;s user attributes can be stored in the enterprise&#39;s data system. 
         [0195]    The organizational information relating to a customer can be stored in a hierarchical model. As described above, a node can be created for each customer and the particular customer&#39;s LDAP tree is copied as a subtree branching from that customer&#39;s node. Model extensions can be anchored on the hierarchical organizational tree. For example, extension of the user model with an attribute location for customer A is defined and anchored at the node defined for customer A and the extension of that attribute is only applicable to the nodes in the subtree extending from that node in a manner similar to that shown in  FIG. 31 . When an administrator from customer A logs into the system, the session is anchored to the customer A&#39;s node  3101 , hence the extensions defined for a different customer are not applicable and not accessible. 
         [0196]    Similarly, when an administrator from customer B logs into the system, she can see only customer B&#39;s node  3103  and any subtrees extending from that node. Thus, customer A and customer B can be kept separate and independent. 
         [0197]    The synchronization of multiple directories can allow an enterprise to provide more useful services to its customers. For example, an SaaS provider may need to include the option of user management as a function to be provided by the enterprise system to its customers. For example, in one embodiment of the concept of user management, the value of a plan attribute for a user (for example, a value of a connectivity plan) is relevant to the provider. The instances of users and their life-cycle management can be accomplished through Active Directory (or any other user repository) synchronization process. In a specific embodiment, if the user does not have the attribute plan in Active Directory, the synchronization process cannot provide a value of the plan attribute necessary for the provider to service the client. Hence, the enterprise system has to provide a workflow to manage attribute assignments such as plan that are relevant to the provider. 
         [0198]    Aspects and features of a business object modeling system and method described herein can permit the value of the attribute, for example, the plan attribute, to be dictated by some rule in the corporation. The rule may be based on the department or level in the management ladder or a combination of some attributes for that person that already exist and are actively managed in Active Directory (or user repository). In this way the customer does not need to extend their own Active Directory (or user repository) to capture/manage provider-required attributes. 
         [0199]    As noted earlier, in accordance with aspects described herein, a customer can extend entities with attributes that are relevant only within their corporation. The assignment of values for a provider&#39;s attributes (like plan) can be accomplished by defining one or more rules that can determine the value. For example, a customer wants to assign plans based on two attributes that are stored in their LDAP—(department and years of service). The customer can extend user based attributes by defining two new attributes (the values for these attributes are populated during LDAP synchronization): 
         [0200]    String department; 
         [0201]    Integer yearsOfService. 
         [0202]    Now she can define rules for plan assignment: 
         [0000]    
       
         
               
               
             
           
               
                   
               
             
             
               
                 if (department = Sales and yearsOf Service &gt; 10) 
                 plan = Platinum 
               
               
                 if (department = Dev and yearsOf Service &gt; 10) 
                 plan = Gold 
               
               
                 if (department = Sales and yearsOf Service &gt; 5) 
                 plan = Gold 
               
               
                 ... 
               
               
                   
               
             
          
         
       
     
         [0203]    The result is a seamless management of an enterprise&#39;s user population vis-à-vis a service provider without having to make any changes to the customer&#39;s user management system. When a user moves from dev to sales or completes ten years of service she is automatically assigned a higher plan. This seamless management can be provided by at least the following components of a business object modeling system and method in accordance with aspects herein: 
         [0204]    LDAP integration, 
         [0205]    extension of user attributes in the SaaS system, 
         [0206]    assignment of attribute values using rules. 
         [0207]    When using various aspects described in this document, it may be desirable to have various tables and the necessary mappings specified. The structure of the tables (table names, field names, relationships) dictate the output SQL from the query processor. Therefore, instead of a developer making sure that all the mappings are correct, a compiler can be written whose input is a business object description. Based on the input definitions, this compiler can generate all necessary tables, mapping files and POJO descriptions for use in the methods described herein.  FIG. 32  depicts an example input to such a compiler. 
         [0208]    It should be noted that aspects of a business object modeling method and system described herein can be accomplished by executing one or more sequences of one or more computer-readable instructions read into a memory of one or more computers from volatile or non-volatile computer-readable media capable of storing and/or transferring computer programs or computer-readable instructions for execution by one or more computers. Volatile computer readable media that can be used can include a compact disk, hard disk, floppy disk, tape, magneto-optical disk, PROM (EPROM, EEPROM, flash EPROM), DRAM, SRAM, SDRAM, or any other magnetic medium; punch card, paper tape, or any other physical medium. Non-volatile media can include a memory such as a dynamic memory in a computer. In addition, computer readable media that can be used to store and/or transmit instructions for carrying out methods described herein can include non-physical media such as an electromagnetic carrier wave, acoustic wave, or light wave such as those generated during radio wave and infrared data communications. 
         [0209]    Although particular embodiments, aspects, and features have been described and illustrated, it should be noted that the invention described herein is not limited to only those embodiments, aspects, and features. It should be readily appreciated that modifications may be made by persons skilled in the art, and the present application contemplates any and all modifications within the spirit and scope of the underlying invention described and claimed herein. Such embodiments are also contemplated to be within the scope and spirit of the present disclosure.