1. Technical Field
The present invention relates generally to an improved data processing system. In particular, the present invention relates to a method, apparatus, and computer instructions for providing a single set of object/relational (OR) mappings across different instances of the same relational database schemas.
2. Description of Related Art
Object-relational mapping tools are used to facilitate development of application programs that utilize a relational database. A relational database stores data in tables having rows (records) and columns (fields). The tables are usually interrelated, and thus, there is a logical structure imposed on the database. This logical structure is known as a schema. However, developers who use object oriented programming languages work with objects rather than tables. Objects represent data differently than tables. As such, object-relational mapping tools are used to map objects and object relationships to tables and table relationships. Object-relational-mapping tools read meta-data information from the database schema and object model and automatically generate source code to connect them. This source code contains a number of classes that manages moving data between the data and objects.
Much like a table is a template for rows, a class is a template for objects. Classes are mapped to tables to allow in memory objects to represent rows in a table. Having one set of classes for multiple data sources is necessary in many applications. However, with existing object relational (OR) mapping technology, there is currently no easy way to have one set of classes for multiple data sources, other than to create a set of classes for each set of tables. Thus, one set of domain classes must be mapped to one set of relational tables. This requirement is problematic when a relational database is partitioned. Many companies divide up their databases by creating copies of the same schema across many boxes and partitioning the data based on a set of users. Requests for data are then routed to the database based on the requesting user. For example, FIG. 1 illustrates an example of partitioned data in two physical databases, DB1 102 and DB2 104. Each class in application 106 is mapped to a relational schema instance. For example, class 1 108 is mapped to schema instance 1 110, class 2 112 is mapped to schema instance 2 114, etc. In this situation where multiple copies of a schema are present, each relational schema must be mapped to a different set of classes, even though the schema may just be an instance of the same data model. These additional mappings require extra work, repetition, and coding.
In order to reduce the number of mappings in the situation above, applications need to know the location of a particular database based on the end user. For example, based on a user ID, an application knows that a box contains the database with a particular user's data. Although some existing applications comprise routing logic for identifying the database containing a particular user's data, this method to reduce the number of mappings still has several drawbacks. For example, in Java 2, Enterprise Edition (J2EE) environments, resource references are bound at deployment time (i.e., at the time the application is installed). Thus, the total number databases defined in the local namespace must be known ahead of time if a custom code is used to implement the user to database mapping. In addition, as OR mappers are bound to one data source at deployment time, one set of objects per database schema would be needed to make this work. This is an unrealistic deployment nightmare if there are many schemas.
Therefore, it would be advantageous to have a method and apparatus for providing a single set of object relational mappings across different instances of the same schemas.