Customizable metadata merging framework

One embodiment of the present invention provides a system that facilitates merging different versions of a database object. During operation, the system receives metadata associated with a first version of a database object and a second version of the database object. The system then compares metadata associated with the first version with metadata associated with the second version to create a difference report. Next, the system uses the different report to create an action plan that specifies how to merge the metadata associated with the first and second versions of the metadata object.

BACKGROUND

1. Field of the Invention

The present invention relates to metadata that is used to define objects in databases. More specifically, the present invention relates to a method and an apparatus that facilitates merging metadata associated with different versions of objects of a database in a customizable manner.

2. Related Art

Databases typically form the backbone of modern electronic business solutions. As business requirements change over time or are modified to meet local requirements, corresponding modifications may need to occur in the structure of an underlying database. These modifications can cause different versions of the same database to diverge over time. This can cause problems when divergent versions of a database need to be subsequently reconciled or updated.

Database objects are typically defined using metadata. The properties, attributes, and relationship of a database object with other database objects can be described using the unified modeling language (UML). The structure of metadata can be modeled using UML (Unified Modeling Language) to define a series of classes, associations, and attributes. For instance, a Table is a Class, a Column is a Class, and a Partition is a Class. ‘Name’ is an Attribute that exists for a Table, Column, and a Partition Class. A relationship exists between Table and Column (a table owns a column), and so we say there is an Association between the Table Class and Column Class. An end user typically receives metadata that defines a database object, for example a table, from a solutions provider. After receiving this metadata, the end user can typically customize the metadata to change the structure of the metadata object. For example, an end user may customize the metadata to add an additional column to a table or to change a property of the table.

It is possible for different end users to customize the same metadata in different ways. For example, end users in a multi-national corporation located in different jurisdictions may customize metadata to allow a corresponding database to accommodate specific data items required by their local jurisdictions.

In some circumstances, it is desirable to merge different versions of metadata. For example, a solutions provider may generate a new version of the metadata to enhance the database object, or management may want the metadata for two or more databases to be merged. This merging process is presently performed manually, and consequently involves a significant amount of time and effort.

Hence, what is needed is a method and an apparatus that facilitates merging different versions of a database without the problems described above.

SUMMARY

One embodiment of the present invention provides a system that facilitates merging different versions of a database object. During operation, the system receives metadata associated with a first version of a database object and a second version of the database object. The system then compares metadata associated with the first version with metadata associated with the second version to create a difference report. Next, the system uses the different report to create an action plan that specifies how to merge the metadata associated with the first and second versions of the metadata object.

In a variation of this embodiment, metadata associated with the database objects are represented in Unified Modeling Language (UML).

In a further variation, comparing the metadata associated with the first and second versions of the database object involves allowing a user to specify which associations of the database object needs to be compared.

In a further variation, comparing the metadata associated with the first and second versions of the database object involves allowing the user to specify how to compare the metadata for each association in the database object.

In a further variation, creating the action plan involves allowing a user to select which actions to take in merging the metadata in order to produce merged metadata with the desired properties and attributes.

In a further variation, creating the action plan involves examining the difference report to determine what actions to take in bringing the metadata associated with the first version and second versions of the database object into agreement.

In a variation of this embodiment, the metadata associated with the first and second versions of the database object can define Oracle database objects like Dimensions, Cubes, Tables, Views, Materialized views, Transformations, and their associated objects. An example of associated objects is that Column, Foreign Keys, and Unique Keys can be associated with table metadata definition. Oracle is a trademark or registered trademark of Oracle International Corporation.

In a variation of this embodiment, the action plan can specify a number of actions including creating, updating, and deleting of database objects.

DETAILED DESCRIPTION

Metadata Exchange Strategy Framework

FIG. 1illustrates a metadata exchange strategy framework102in accordance with an embodiment of the present invention. Metadata exchange strategy framework102includes metadata change manager110, metadata exchange strategy112, and execution engine114. Metadata change manager110provides functions for creating difference reports, such as difference report111, as described below in conjunction withFIGS. 2,3,5, and8. Metadata exchange strategy112provides functions for creating an action plan, such as action plan113, as described below in conjunction withFIGS. 4,6,7, and8. Execution engine114provides functions for executing the action plan as described below in conjunctions withFIGS. 4 and 8.

Metadata exchange strategy framework102accepts source object104and target object106and creates merged object108. Source object104, target object106, and merged object108contain metadata describing respective database objects. Source object104and target object106are descriptions of the same database object that differ, possibly because their metadata definition may have been updated or customized by different users.

Source object104and target object106are typically Oracle database objects and not just tables and columns (i.e. cubes, transformations, and the like). Also source object104and target object106may include other objects such as files in a file system or records in a file that have been captured using UML and stored in the database during design time. This is typically achieved by having a table called “file” and a table called “record.” The metadata of external table objects refers to the record metadata in the record table. These are not database objects, but still dictate the structure of some database objects. For example, the structure of an external table is dictated by the file and record that it is referring to. Hence, there exists a requirement that external tables have to be merged from the record during design time, although the record is not a database object. Hence, this is not just restricted to database objects but also to others that are marked in UML and stored in the database as classes, attributes, and associations.

Difference Report

FIG. 2illustrates the process of creating a difference report from compatible objects in accordance with an embodiment of the present invention. Metadata change manager110receives external tables202and204and creates a difference report208, which describes the differences between external tables202and204. For example, external tables202and204contain metadata describing the same object that differ possibly because one of the external tables is an updated version of the other external table, or because the external tables have been customized by different individuals.

Difference Report from Non-Compatible Objects

FIG. 3illustrates the process of creating a difference report from non-compatible objects in accordance with an embodiment of the present invention. In the example illustrated inFIG. 3, a difference report between external table202and record302is desired. Note that external table202may have been originally created from record302.

Adapter304first converts record302into compatible external table306. Metadata change manager110then receives external tables202and306and creates a difference report308, which describes the differences between external tables202and record306, which are ultimately the differences between external table202and record302.

Action Plan and Merged Object

FIG. 4illustrates the process of creating an action plan and a merged object in accordance with an embodiment of the present invention. Metadata exchange strategy112receives a difference report208created by metadata change manager110. During this process, metadata exchange strategy112is used to examine difference report208and to create an action plan404for merging the two objects used in creating difference report208.

Next, execution engine114receives action plan404. After a user selects which items of action404are to be performed, execution engine114creates merged object108.

Creation of an action plan requires the user to specify if a merge or a replace plan is preferred. The replace plan means deleting everything from the target that does not have a match in the source, while the merge plan would not allow deletion of anything from the target.

After the action plan has been created, the user can customize the action plan to apply the specific actions that are desired. Applying the action plan causes creation, deletion, or updates of the target object. Also, the user has the ability to specify which attributes in the target need to be updated in the event of a create action or an update action. The user can also change the values to suit the required needs. This is determined at the time when the user wants to execute the created action plan.

Source and Target Objects

FIG. 5illustrates source and target objects in accordance with an embodiment of the present invention. These source and target objects include metadata for table508and table502, respectively, and originated from the same metadata. Source table508includes a description509of table508. Additionally, source table508is associated with columns512and properties510. Properties510include property2and property3, and columns512include column1, column2, and column3. Together, table508, properties510, and columns512describe a corresponding database table.

Difference Report

FIG. 6illustrates a difference report208in accordance with an embodiment of the present invention. Note that there are many ways to compare different components of the metadata. In this example, tables are being compared by name, columns are being compared by position, and properties are being compared by name.

Difference report208includes data for the parameters being compared, in this example table name, column position, and properties. The comparison of the table names indicates that the target and source have the same name; therefore the input into the action plan is to update the table.

The comparison of the columns indicates that column1in the target includes the same data as column2in the source and that column2in the target includes the same data as column1in the source. The input to the action plan is to update the column descriptions. Since column3exists in the source but not in the destination, the input to the action plan is to create column3in the target.

The comparison of the properties indicates that property1exists in the target but not in the source, while properties2and3exist in the source but not in the destination. The action plan for the properties includes deleting property1and creating properties2and3. These actions will bring the target into alignment with the source if the user selects all of the actions as described below in conjunction withFIG. 7.

Action Plan

FIG. 7illustrates an action plan404in accordance with an embodiment of the present invention. Action plan404includes actions derived from difference report208described above in conjunction withFIG. 6. Each line of action plan404includes a checkbox702, a description of the action704, and an action706. A user can select which actions are required by checking the checkbox in column702. After the user checks the actions, execution engine114performs the checked actions.

Merging Metadata

FIG. 8presents a flowchart illustrating the process of merging metadata associated with a first object and metadata associated with a second object in accordance with an embodiment of the present invention. The system starts when a first metadata associated with the first version of an object is received (step802). Next, the system receives the second metadata associated with the second version of the object (step804). Note that steps802and804can occur in the opposite order or simultaneously. If needed, the system converts the second metadata to be compatible with the first metadata (step806).

After receiving the first metadata and the second metadata, the system examines the first metadata and the second metadata to create a difference report (step808). The system then creates an action plan from the difference report (step810).

Next, the system allows a user to select portions of the action plan to implement by checking checkboxes in the action plan (step812). Finally, the system uses the selected actions to merge the first metadata and the second metadata to create merged metadata (step814).