Patent Application
20100299372
The present invention generally relates to data processing and more particularly to migrating entity relationship data from an object oriented program environment to a relational database. The present invention further relates to providing functionality to efficiently search and reconstruct the entity relationship data in the relational database.
Databases are computerized information storage and retrieval systems. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.
A relational database management system (RDBMS) is a computer database management system that uses relational techniques and is capable of storing and retrieving large volumes of data. Further, large scale relational database management systems can be implemented to support thousands of users accessing databases via a wide assortment of applications. An RDBMS can be structured to support a variety of different types of operations for a requesting entity (e.g., an application, the operating system or an end user). Such operations can be configured to retrieve, add, modify and delete information being stored and managed by the RDBMS. Standard database access methods support these operations using high-level query languages, such as the Structured Query Language (SQL).
The functionality provided by relational databases is especially useful for MicroArray Analysis, one of the domains within Life Sciences. The MicroArray research community has architected a specification for MicroArray Gene Expression (MAGE) data which incorporates the different entities and relationships that are involved in MicroArray research. Large volumes of MAGE data are present in a variety of applications implemented in numerous object oriented programming environments. It is very important for researchers to be able to query and manipulate this data in order to appropriately analyze the data. However, due to issues such as large volumes of data (in the order of terabytes), it is technically cumbersome for researchers to work with data in an object oriented program environment. It would be advantageous to manage this data in a relational database environment.
However, there are numerous difficulties related to migrating MAGE data to a relational database implementation. One of the greatest difficulties is the reconstruction of all aspects of data entity relationships within the relational database. Object oriented program environments and relational database environments rely on considerably different conceptual bases. For this reason, those skilled in the art will appreciate that relationships between entities in an object oriented program environment and the corresponding relationships in a relational environment are represented in very different ways. For instance, in the case of MAGE implementations, large numbers of relational database objects are required to represent all the necessary MAGE entities and the relationships between the entities. The MAGE relational database footprint may span hundreds of tables (and other data structures), which makes the importing of data and reconstruction of entity relationships nontrivial.
Therefore, what is needed is an improved system and method for transferring entity relationship data from an object oriented program environment to a relational database. Once in the relational database, there is a further need to facilitate the searching and reconstruction of entity relationships.
The present invention is generally directed to a method, system and article of manufacture for migrating entity relationship data residing in an object oriented program environment to a relational database. The present invention further directed to facilitating improved searching of entity relationship data in the relational database.
One embodiment of the present invention provides a computer implemented method for creating a table populated with information derived from an object oriented program environment. The method generally includes providing data structures residing in a relational database managed by a relational database management system, the data structures containing data related to entities and entity relationships in the object oriented program environment, and populating a lookup table within the relational database with metadata of the entity relationships, wherein the metadata includes descriptions of the hierarchical relationships between entities in the entity relationships.
Another embodiment provides a computer implemented method for creating a table. The method generally includes providing entity relationships between entities in an object oriented program environment, wherein entities are instances of objects, creating a document in a text-based markup language format containing data related to the entities and entity relationships in the object oriented program environment. The method also includes extracting data related to the entities and the entity relationships from the document in the text-based markup language and loading the data into data structures residing in a relational database, and populating a lookup table in the relational database with metadata of the entity relationships, wherein the metadata includes description of hierarchical relationships between entities in the entity relationships.
Another embodiment provides a computer-readable medium containing a data structure for storing metadata corresponding to data related to entities and entity relationships comprising a lookup table containing an entry for each of a plurality of entity relationships, each entry containing a parent ID string, a child ID string and a tree ID string.
Another embodiment provides a method in a computer system for displaying entity relationship data. The method generally includes displaying a first graphical object for selecting an entity type, displaying a second graphical object for selecting an entity, and in response to selection of an entity type via the first graphical object and selection of an entity via the second graphical object, querying entity relationship data in a relational database based on the selected entity type and entity.
Another embodiment provides a computer implemented method for creating a table populated with information derived from an object oriented program environment. The method generally includes providing data structures residing in a relational database, the data structures containing data related to entities and entity relationships in the object oriented program environment. The method also includes populating a lookup table within the relational database with metadata of the entity relationships, wherein the metadata includes descriptions of the hierarchical relationships between entities in the entity relationships, and querying entity relationship data in the relational database via a query building application that utilizes a data abstraction model for logically representing physical data structures in the relational database.
So that the manner in which the above recited features, advantages and objects of the present invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.
It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
The present invention is generally directed to methods, systems and articles of manufacture for migrating entity relationship data residing in an object oriented program environment to a relational database. Further, functionality is provided to facilitate more efficient searching and manipulation of the entity data in the relational database.
Further, in the following, reference is made to embodiments of the invention. The invention is not, however, limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, in various embodiments the invention provides numerous advantages over the prior art. Although embodiments of the invention may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in the claims. Similarly, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims, except where explicitly recited in a specific claim.
As used herein, the term user may generally apply to any entity utilizing the data processing system described herein, such as a person (e.g., an individual) interacting with an application program or an application program itself, for example, performing automated tasks. While the following description may often refer to a graphical user interface (GUI) intended to present information to and receive information from a person, it should be understood that in many cases, the same functionality may be provided through a non-graphical user interface, such as a command line and, further, similar information may be exchanged with a non-person user via a programming interface.
As used herein, the term object model may generally apply to a collection of descriptions of classes or interfaces, together with their member data, member functions and class-static operations. Further, the term object tree may generally apply to a hierarchical arrangement of objects in accordance with requirements for a specific implementation. Accordingly, the term object tree may also refer to herein as hierarchical structures. Also, the term entity relationship data may also be referred to herein as hierarchical data.
As used herein, the term relational database generally refers to a collection of data arranged for ease and speed of search and retrieval. Further, a relational database comprises logical and physical structures managed by a relational database management system (RDBMS).
One embodiment of the invention is implemented as a program product for use with a computer system. The program(s) of the program product defines functions of the embodiments (including the methods described herein) and can be contained on a variety of signal-bearing media. Illustrative signal-bearing media include, but are not limited to: (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive); (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive); or (iii) information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless communications. The latter embodiment specifically includes information downloaded from the Internet and other networks. Such signal-bearing media, when carrying computer-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.
In general, the routines executed to implement the embodiments of the invention, may be part of an operating system or a specific application, component, program, module, object, or sequence of instructions. The software of the present invention typically is comprised of a multitude of instructions that will be translated by the native computer into a machine-readable format and hence executable instructions. Also, programs are comprised of variables and data structures that either reside locally to the program or are found in memory or on storage devices. In addition, various programs described hereinafter may be identified based upon the application for which they are implemented in a specific embodiment of the invention. However, it should be appreciated that any particular nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature.
Embodiments of the invention can be implemented in a hardware/software configuration including at least one networked client computer and at least one server computer. Furthermore, embodiments of the present invention can apply to any comparable hardware configuration, regardless of whether the computer systems are complicated, multi-user computing apparatus, single-user workstations or network appliances that do not have non-volatile storage of their own. Further, it is understood that while reference may be made to particular query languages, including SQL, the invention is not limited to a particular language, standard or version. Accordingly, persons skilled in the art will recognize that the invention is adaptable to other query languages and that the invention is also adaptable to future changes in a particular query language as well as to other query languages presently unknown.
In the following, reference is made to embodiments of the invention. However, it should be understood that the invention is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, in various embodiments the invention provides numerous advantages over the prior art. However, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and, unless explicitly present, are not considered elements or limitations of the appended claims.
Referring now to
As stated above, it may not be technically suitable for users to work with entity relationship data in an object oriented program environment 120. However, it is advantageous to utilize relational databases to facilitate robust querying ability of such entity relationship data. Robust querying ability can constitute accommodating large numbers of users querying the database concurrently. Further, the database may comprise voluminous data residing in a network of data structures. As such, it is desirable to migrate entity relationship data arranged in hierarchical structures (also referred to herein as object trees) in an object oriented program environment to a relational database.
In an object oriented program environment 120, available entities, or instances of objects, and the relationship between the entities are often presented with the use of an object model 210. The object model 210 can include a large number of entities. Further, the object model 210 shows that there are numerous relationships between the entities. The numerous relationships between the different entities can be thought of as a network of relationships; often the network can become complex. Object models will be described in more detail with reference to
As stated earlier, it is not convenient to store or query data in the object environment. Accordingly, data associated with entities is extracted and placed into XML documents. XML is able to represent the object model in a format that is similar to the relationship of objects in the object oriented program environment. The entity relationships extracted from the object oriented program environment are left intact. One reason for this is that XML documents are not restricted to data integrity constraints associated with relational databases. XML documents are simply text files that are designed to store various types of data including hierarchical data. In addition, XML formatted documents make it is easier to load data into relational databases.
Unfortunately, while XML documents can accurately represent the object model, it is not very convenient to query data in the XML format. As mentioned above, for querying purposes, it is advantageous to have the entities represented in a relational database 250, and more specifically, in a relational database schema 251. Database schemas are generally defined as collections of logical structures and physical structures of data, or schema objects. It is well known by those skilled in the art that relational databases provide exceptional functionality and performance for querying purposes. However, because of the inherent differences in the manner in which entity relationships are maintained in the object oriented/XML and relational database environments, a certain amount of data transformation is needed to populate entity relationship data into a corresponding relational database schema.
A relationship manager 230 is utilized to facilitate data transformation and loading of entity relationship data into a relational database schema 251. The relationship manager 230 references mappings to load entity relationship data from XML into the appropriate tables (or other data structures) in the relational database 141. Further, the relationship manager 230 analyzes the entity relationships and populates a TreeID lookup table 260 with metadata describing the entity relationships loaded into the relational database 141. Metadata is commonly defined as “data about the data.” For instance, in the context of entity relationship data, metadata would comprise hierarchical information about a particular entity and its relationships with other entities within the hierarchy. Examples of entity relationship based metadata will be described with reference to
While the intermediate operations of extracting data to XML documents and then migrating the data from XML to the relational database 140 is described, it should be understood that any suitable markup language which facilitates the storing of hierarchical data may be used rather than XML. Further, it should also be understood, that embodiments of the current invention may accommodate direct transfer of data from an object oriented program environment to a relational database. In other words, there may not be a need for the intermediate step of extracting from the object environment with the use of a markup language.
To further clarify the process described with reference to
During the application building process, objects are utilized in a hierarchical manner. For instance certain calling objects (or referencing objects) will reference other objects (also referred to as referenced objects). In turn, the called objects may themselves reference other objects, and so on. This hierarchy of called objects may be referred to as an object tree 450. In other words, an object tree represents an implementation of a group of objects; the objects are implemented in a specified hierarchical order to provide the desired functionality.
The nodes of the trees are labeled in the form of “entity type: entity name.” For example, one of the trees includes an object (reference number 403) labeled in the following manner: “Person:Anderson, miko.” In this case, the entity type is “Person” and the entity name is “Anderson, miko.” Each of the tree structures 450 has a specific root node, also referred to herein as a TreeID. The three different TreeID values shown are: “BioAssay: Amya MAF STD CEL PROTOCOL” 401, “BioAssay: Amya MAF STD CDF” 402 and “Experiment: Gene Logic U512—Table 1” 408. It should be noted that entities related to both experiments and bioassays are included. Further,
For simplicity of notation, some entity relationships are described as parent/child relationships. However, it should be understood that these are not meant to convey a parent/child relationship as understood with reference to relational databases. For a particular relationship, the “parent” node may be an instance of the referencing object and the “child” node may be an instance of the referenced object. For instance, “BioAssay: Amya MAF STD CEL PROTOCOL” 401 serves as a parent node to “Person: Anderson, Miko” 403. Further, “Person: Anderson, Miko” 403 serves as the parent node for “Organization: Amya Foundation” 404. Again, the use of the parent and child is used to convey the location of an entity within a tree hierarchy and its relationship with other entities.
For some embodiments, an intermediate step that is taken during the migration of data from an object environment 120 to a relational database 141 is extracting the object data into XML documents 130. Table I below includes a sample extract of the object oriented program environment 120 described with reference to
Table I above includes a sample extract of the object oriented program environment 120 described thus far. Portions of Table 1 correspond directly to several of the objects and entities described with reference to
Table II below shows additional XML code that corresponds to the BioAssay related trees illustrated in
Once the entity relationship data is extracted and placed into XML documents, the relationship manager 230 inserts the contents of the XML documents into a corresponding relational database schema 251.
The particular ERD illustrated in
The splintering of data as it is loaded into a relational database makes it difficult for users to work with the data. One of the problems faced by users is that they are unaware of all the different tables that contain records that define relationships between specific entities. For example, if a user was trying to determine all the relationships the entity “Miko Anderson” is a part of, the user may not know which tables to check for such information. Accordingly, embodiments of the invention provide the TreeID lookup table 260, which is a standard relational table that contains information on the entity relationship data loaded into the relational database schema 251. Persons skilled in the art will understand that the use of a single lookup table, such as the TreeID lookup table 260, allows for improved speed and efficiency in the context of building and analyzing relationships. For instance, with this approach, users would only need to interrogate one table with one simple query to determine a series of relationships rather than having to interrogate numerous tables many times to determine the same relationships. Further, a simple query against the TreeID lookup table 260 for a specific entity can provide a complete view of all relationships the entity is a part of, and can describe the hierarchies within which that relationship is defined.
As the relationship manager 230 processes each new entity relationship extracted from the object oriented program environment 120, a corresponding record (or entry) is added to the TreeID lookup table 260. For some embodiments, as entity relationship data is extracted from the object oriented program environment 120 and loaded into the relational database schema 251, metadata (including hierarchical data) representing each entity relationship is populated into the TreeID lookup table 260. Each record may contain a parent ID string representing a parent node of an entity relationship, a child ID string representing a child node of an entity relationship, and a tree ID string representing a root node of a hierarchy that contains the entity relationship.
It should be noted that while the TreeID lookup table 260 is shown with only three columns, in other embodiments this table may include several other columns for storing additional attributes of the entity relationships. Further, additional columns may also facilitate improved querying ability against the TreeID lookup table 260.
As stated earlier, the TreeID lookup table 260 is managed by the relationship manager 230. The interaction of the relationship manager 230 and the TreeID lookup table 260 is described in more detail with reference to
At step 905, the XML is analyzed to determine if the present entity has any relationships with other entities. If it is determined that one or more relationships exist between the present entity and other entities, then processing proceeds to step 906 where the TreeID lookup table 260 is queried to determine if these particular relationships are recorded. If it is found that the present relationship is recorded, processing returns to step 905 to handle any other relationships. If the answer to the question of step 906 is “No,” the attributes of the present relationship are recorded in the TreeID lookup table 260 during step 907. Next, processing returns to step 905 where the next relationship for the present entity is processed.
However, if no more relationships are included in the XML for the current entity, processing proceeds to step 908. At step 908, it is determined if the XML contains any other entities that need to be imported into the relational database schema. If the answer to the question of step 908 is “Yes,” processing returns to step 902. Once all the entities in the XML file are analyzed, the processing is complete.
It should be understood that the steps described above with reference to operations 1000 are an exemplary set of operations according to one embodiment of the present invention. A variety of intermediate steps can be added to this process according to requirements of a particular application.
Following is an example query performed according to operations 1000. Suppose a user wants to perform a search on the entity “Miko Anderson,” to determine what relationships this entity has with other entities, and also to determine which tables from the relational database schema 251 would need to be queried. Operations 1000 are performed with the user supplied entity of “Miko Anderson.” Suppose that the TreeID table described with reference to
A drop down box 1101 is provided and shows a list of all available entity types in the database. It should be noted that features of this form including the drop down box 1101 and text box 1102 are based upon running queries against the TreeID lookup table 260. For example, the entity type values shown via the dropdown box 1101 may be based upon the result set received from running a query for a list of unique entity types present in the TreeID lookup table 260.
A text box 1102 that accepts the user's input for an entity, such as “Miko Anderson,” is provided. Based on the selected entity type and entity value that was input, a list of appropriate tables 1103 where relationships exist between the user specified entity and other entities is presented. This allows the user to quickly determine that records pertaining to relationships between the input entity (“Miko Anderson”) and other entities exist in the presented tables (e.g., Experiment, Bioassay and Security).
Once the user has gathered the appropriate information, such as a list of appropriate tables to query, a freeform text box 1104 is provided for the user to enter a SQL query. Once the user is satisfied with the query entered in the freeform text box 1104, the user can select a submit button 1105 to run the entered query. If the user wishes to exit the form without performing any action, the cancel button 1106 can be selected.
In one embodiment, the base queries are composed and issued as abstract, or logical, queries. An abstract query is composed using logical fields defined by a data abstraction model. Each logical field is mapped to one or more physical entities of data of an underlying data representation (e.g., XML, SQL, or other type representation) being used in the database being queried. Furthermore, in the data abstraction model the logical fields are defined independently from the underlying data representation, thereby allowing queries to be formed that are loosely coupled to the underlying data representation. The abstract query can be configured to access the data and return query results, or to modify (i.e., insert, delete or update) the data. For execution against the database, the abstract query is transformed into a form (referred to herein as a concrete query) consistent with the underlying data representation of the data 162. Abstract queries and transformation of abstract queries into concrete queries is described in detail in the commonly owned, U.S. patent application Ser. No. 10/083,075, entitled, “Application Portability and Extensibility through Database Schema and Query Abstraction,” filed Feb. 26, 2002, now issued U.S. Pat. No. 6,996,558 issued Feb. 7, 2006, which is incorporated by reference in its entirety.
In general, the data abstraction model 1208 exposes information as a set of logical fields that may be used within a query (e.g., the abstract query 1206) issued by the application 1202 to specify criteria for data selection and specify the form of result data returned from a query operation. The logical fields are defined independently of the underlying data representation 1220 being used in the databases, thereby allowing queries to be formed that are loosely coupled to the underlying data representation 1220. The data to which logical fields of the DAM 1208 are mapped may be located in a single repository (i.e., source) of data or a plurality of different data repositories. Thus, the DAM 1208 may provide a logical view of one or more underlying data repositories. By using an abstract representation 1210 of a data repository, the underlying physical representation 1220 can be more easily changed or replaced without affecting the application 1202 making the changes. Instead, the abstract representation 1210 is changed with no changes required by the application 1202. In addition, multiple abstract data representations can be defined to support different applications against the same underlying database schema that may have different default values or required fields.
In general, the data abstraction model 1208 comprises a plurality of field specifications. Specifically, a field specification is provided for each logical field available for composition of an abstract query 1206. Each field specification comprises a logical field name and an associated access method. The access methods associate (i.e., map) the logical field names to a particular physical data representation 12141, 12142 . . . 1214N in a database according to parameters referred to herein as physical location parameters. By way of illustration, two data representations are shown, an XML data representation 12141 and a relational data representation 12142. However, the physical data representation 1214N indicates that any other data representations, known or unknown, are contemplated.
The logical fields and access methods in each abstract query 1206 are processed by a runtime component 1230 which transforms the abstract queries into a form (referred to as a concrete query) consistent with the physical representation 1220 of the data contained in one or more of the databases. A concrete query is a query represented in languages like SQL 12122, XML Query 12121, and other query languages 1212N and is consistent with the data of a given data representation 1220 (e.g., a relational data representation 12142, XML data representation, 12141, or other data representation 1214N). Accordingly, the concrete query is used to locate and retrieve data from a given data representation 1220.
A drop down box 1301 is provided to allow the user to select an entity type. Another drop down box 1302 is provided to allow the user to select a particular entity that is of the element type selected via dropdown box 1301. Based on the entity type and entity value selected, a list of contextually appropriate saved abstract queries 1303 are presented to the user. The user can select the desired saved abstract query by selecting the check box adjacent to the particular saved abstract query. Once a saved abstract query 1303 is selected, it can be submitted to the database for execution by selecting the Submit button 1305. The user can exit the form by selecting Cancel 1306.
The examples described above are presented in the context of micro array gene expression (MAGE) data. However, those skilled in the art will recognize the methods described herein may be utilized for entity relationship data residing in any object oriented programming environment.
While the examples described herein have referred to relationships from only one schema, those skilled in the art will appreciate that embodiments of the present invention can support multiple schemas. In fact, implementing the methods described herein is even more advantageous in an environment comprising numerous schemas, with each schema containing a large number of entity relationships (i.e., an environment with disparate and voluminous data). In such an environment, embodiments of the present invention can be configured to facilitate data mining efforts, which may include the collection of statistics and performing trend analysis related to entity relationships.
It should be noted that any reference herein to particular values, definitions, programming languages and examples is merely for purposes of illustration. Accordingly, the invention is not limited by any particular illustrations and examples. Furthermore, while the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof and the scope thereof is determined by the claims that follow.
This application is a divisional of co-pending U.S. patent application Ser. No. 10/901,591 filed Jul. 29, 2004, entitled, “Method and System for Reconstruction of Object Model Data in a Relational Database,” which is incorporated herein by reference in its entirety. This application is also related to the following commonly owned application: U.S. patent application Ser. No. 10/083,075 filed Feb. 26, 2002, entitled, “Application Portability and Extensibility through Database Schema and Query Abstraction,” now U.S. Pat. No. 6,996,558 issued Feb. 7, 2006, which is hereby incorporated herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10901591 | Jul 2004 | US |
| Child | 12852288 | US |
