JPH08161208A - Object structure converter - Google Patents

Abstract

PURPOSE: To transfer data mutually between data bases whose data models are different by extracting the difference of an object definition extracted front a conversion request and the object definition of a conversion destination and copying data based on converted definition information. CONSTITUTION: An object definition extraction means 13 extracts the object definition from the conversion request, an object conversion means 15 extracts the difference of the extracted object definition of a conversion source and the object definition of the conversion destination, performs a conversion operation for canceling the difference and performs conversion to the object definition information of the conversion destination and the data are converted based on the converted object definition or an object definition sentence for which the converted object definition is turned to the language of the conversion destination. In such a manner, the conversion to the definition information of the conversion destination is performed, constraints are generated as needed further and the copying or the like of the data is performed based on the converted definition information and the constraints.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an object structure conversion device for converting an object structure.

Due to changes in the environment surrounding computers, the computer environment that uses an object management system is also a centralized environment centered around object servers, and an object management system that operates on a plurality of workstations connected by a high-speed network. Is moving to.

Taking a database management system as an example, for example, a number of standards have been established, and a relational database system, which is maturing in terms of performance and reliability, is mainly used, and is created on the relational database system. Many applications are accumulated as assets. On the other hand, the sophistication of database applications has advanced, and the need for storing data with a more complicated structure in a database has increased expectations for object-oriented database systems.
Along with this, some object-oriented database systems have been implemented and commercialized. At this time, it is desired to convert the schema that can be expressed by one model and the schema that can be expressed by another model so that data can be transferred even if it is difficult to completely express it in another model. .

[0004]

2. Description of the Related Art Normally, when a company manages product information and customer information using a database, various database management systems are mixed unless all departments in the company cooperate to create a database. In many cases, different databases are built for each department. This is not a problem if each department manages and uses only the necessary information within the department.

However, even if the management department or the like wants to use information across a plurality of departments, the database cannot be integrated due to the difference in the database system and its data model, and the information cannot be used mutually. To do.

When sharing a database between database systems having different data models, the user of each database system views the schema by a representation method according to the data model (definable schema type) of the database system to which the user belongs. Would like to. At this time, there is a problem that a schema that can be expressed by one data model cannot be completely expressed by another data model because of the difference in the expression capability of the data model. For example, in one data model, the aggregate relationship between objects
uct type). If there is no concept of structural type in another data model, the schema based on the former data model cannot be expressed as it is in the latter.

When such a problem occurs, conventionally,
It is impossible to convert the schema of a data model with a high expression capability (for example, an object-oriented data model) to a data demol with a low expression capability due to the difference in the expression capability of the data models, and only the common parts of both sides are used. I was done with it.

[0008]

However, there is a case in which the usefulness of the schema conversion can be enhanced by making it possible to convert even if a part of the meaning of the schema expression is changed by stepping on one side. For example, by expressing the aggregate without using the structural type, it is possible to convert the data model into a data model that does not have the concept of the structural type. However, when a conversion that changes the meaning of the schema expression is performed, it is necessary to guarantee that the constraint condition newly generated by the conversion is satisfied.

The present invention solves these problems.
The difference between the object definition extracted from the conversion request and the object definition of the conversion destination is extracted, the conversion operation that cancels this difference is performed to convert to the definition information of the conversion destination, and constraint conditions are generated as necessary. The purpose is to realize mutual data transfer between databases with different data models, which was impossible in the past, by copying data based on the converted definition information and constraints.

[0010]

[Means for Solving the Problems] Means for solving the problems will be described with reference to FIG. In FIG. 1, the object definition extracting means 13 extracts the object definition of the conversion source.

The object definition sending means 14 sends the converted object definition after conversion (or the object definition statement in the converted language) to the conversion destination.

The object conversion means 15 extracts a difference between the object definition of the conversion source and the object definition of the conversion destination, performs a conversion operation for canceling the difference and generates a constraint condition, and converts the object definition of the conversion destination. Is.

[0013]

According to the present invention, as shown in FIG. 1, the object definition extracting means 13 extracts the object definition from the conversion request, and the object converting means 15 extracts the object definition of the conversion source and the object definition of the conversion destination. Extract the difference, perform the conversion operation to cancel this difference and convert it to the object definition information of the conversion destination, and also convert this object definition or the object definition statement that makes this converted object definition the language of the conversion destination. I am trying to convert the data to and.

At this time, in the conversion operation, when an operation that changes the meaning of the object definition is performed, a constraint condition to be supplemented to guarantee the identity of the conversion operation is generated, and the constraint condition and the converted object definition are generated. Alternatively, data conversion is performed based on this constraint condition and the object definition statement in which the converted object definition is in the conversion destination language.

Further, when performing the conversion operation for canceling the difference, the one corresponding to the difference is selected from the previously registered conversion pattern information, and the conversion operation is performed according to the selected conversion pattern information.

Therefore, the difference between the object definition extracted from the conversion request and the object definition of the conversion destination is extracted,
By performing a conversion operation that cancels this difference and converting it to the definition information of the conversion destination, further generating constraint conditions as necessary, and copying data etc. based on this converted definition information and constraint conditions, It has become possible to realize mutual data transfer between databases with different data models, which was impossible in the past.

[0017]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, the construction and operation of an embodiment of the present invention will be sequentially described in detail with reference to FIGS.

FIG. 1 shows a block diagram of an embodiment of the present invention.
1, objects 1, 2, ... N are objects stored in the object management system 1, 2 ,.

Object management systems 1, 2, ...
n is a system for managing the objects 1, 2, ... N, and manages each object under its own data model.

The communication control device 31 communicates with other communication control devices 31 and 11 via a communication line to mutually transfer data. The heterogeneous object conversion device 12 includes object management systems 1, 2, ... N having heterogeneous data models connected via communication lines.
To convert the object definition of the conversion source to an object definition of the conversion destination and notify the converted data, and to transfer and store the data of the conversion source to the conversion destination. It comprises an object definition sending means 14, an object converting means 15, an object language generating function 18, and the like.

The object definition extraction means 13 extracts the object definition of the conversion source from the conversion request. The object definition sending means 14 defines the object definition (or the object definition statement in the conversion destination language).
Is sent to the conversion destination.

The object conversion means 15 extracts a difference between the object definition of the conversion source and the object definition of the conversion destination, performs a conversion operation for canceling the difference, and converts the object definition of the conversion destination. It comprises a schema conversion function 16 and a constraint condition generation function 17.

The schema conversion function 16 converts the schema information of the conversion source object of a certain object management system into the schema information of the conversion destination object (described in detail with reference to FIGS. 2 and 3).

The constraint condition generation function 17 is for generating a constraint condition to be supplemented in order to guarantee the identity of the conversion operation when the schema conversion function 16 performs an operation that changes the meaning of the object definition.

The object language generation function 18 is for generating a definition sentence in the conversion destination language from the converted conversion destination object definition and constraint conditions. The data model information 19 corresponds to each object management system 1, 2, ...
-It is information about the data model of n.

The conversion pattern information 20 is information on the conversion pattern of the schema (see FIG. 11). The object language syntax information 21 is the syntax information of the object language required when generating the object language.

The output device 22 is various output devices (display device, printing device, etc.). The input device 23 is various input devices (keyboard, mouse, etc.). Next, the operation of the configuration of FIG. 1 will be described in detail according to the order shown in the flowchart of FIG.

In FIG. 2, S1 receives a conversion request. For this, the heterogeneous object conversion device 12 of FIG. 1 receives a conversion request, for example, "copy schema 1 of database system 1 to database system 2" via a communication line.

In step S2, the object definition is extracted. This is to extract the conversion source object definition from the conversion request of S1, for example, the object definition information of the schema 1 from the database 1 "table 1 (attribute a: type a, attribute b: type b.
・ ・) Is extracted.

In step S3, the data models of the conversion source and conversion destination database systems are compared to extract a difference. In this case, the data models of the conversion source and conversion destination database systems are respectively extracted from the data model information 19 of FIG. 1, and the difference between them is extracted.

In step S4, a conversion operation for canceling the difference is selected from the conversion pattern information and determined. This is
The conversion pattern information corresponding to the difference extracted in S3 is selected and determined from the conversion pattern information 20.

In step S5, the determined conversion operation is executed. If there are multiple conversion operations, repeat multiple times. In step S6, a database definition statement (object definition statement) for the conversion destination system is generated from the finally obtained object definition information based on the object language syntax information.

In step S7, the generated database definition statement (object definition statement) is sent to the conversion destination database system. In S8, the data is transferred from the conversion source to the conversion destination.

In step S9, the data is stored in the database defined by the database definition statement (object definition statement) at the transfer destination. As described above, the heterogeneous object conversion device 11 of FIG. 1 that receives the conversion request extracts the object definition of the conversion source, extracts the difference between the extracted object definition and the object definition of the conversion destination, and cancels this difference. Perform the conversion operation and generate the constraint condition to compensate for guaranteeing the identity of the conversion operation, generate the object definition statement in the destination language based on the converted object definition and the constraint condition, and After sending, the data is transferred from the conversion source to the conversion destination and stored in the database based on the object definition statement. As a result, data can be mutually transferred and copied between database systems (object management systems) having different data models.

FIG. 3 is a diagram illustrating a specific example of the present invention. In FIG. 3, in S11, the data model A of the conversion source object management system A is set to the data model information 19 of FIG.
The data model B of the object management system B of the conversion destination is extracted from the data model information 19 of FIG.

In step S12, the difference between the conversion source data model A extracted in step S11 and the conversion destination data model B is extracted. S13 is the schema 1 of the object before conversion
And constraint condition 1 are shown. These are before conversion of the object management system A.

S14 shows the schema 2 of the object being converted and the constraint condition 1 + the constraint condition associated with the conversion operation 1. These are obtained by subjecting the schema 1 and constraint condition 1 of the object before the conversion in S13 to the conversion operation 1 necessary for canceling the difference in S12.

S15 shows the schema 3 of the converted object and the constraint condition 1 + the constraint condition associated with the conversion operation 1 + the constraint condition associated with the conversion operation 2. These are the schema 2 and constraint condition 1+ of the object being converted in S14.
The constraint condition associated with the conversion operation 1 is the conversion operation 2 necessary for canceling the difference in S12.

In step S16, the schema 3 of the object after the conversion in step S15 and the constraint condition 1 + the constraint condition associated with the conversion operation 1 + the constraint condition associated with the conversion operation 2 are sent to the object management system B. As a result, thereafter, in the object management system B, the object management is performed using the schema 3 and the constraint condition 1 + the constraint condition associated with the conversion operation 1 + the constraint condition associated with the conversion operation 2 of the converted object that has been sent. The data transferred from the system A is processed (for example, written in a database).

As described above, the conversion source data model A
And the data model B of the conversion destination are extracted, the conversion operation 1 is performed for the schema 1 and the constraint condition 1 of the object before conversion, and the schema 2 and the constraint condition 1 + the conversion operation 1 of the object in the middle of conversion are constrained. A condition is generated, a conversion operation 2 is further performed, and a schema 3 of the object after conversion and a constraint condition 1 + a constraint condition associated with the conversion operation 1 + a constraint condition associated with the conversion operation 2 are generated. The data transferred from the conversion source can be converted and stored in the database, and the data can be transferred between databases having different data models.

FIG. 4 shows a schema conversion example of the present invention.
4A shows the state before the conversion, and FIG. 4B shows the state after the conversion. Here, (a) of FIG. 4 is a schema of a nested structure, and (b) of FIG. 4 is a flattened schema, which is an example in which the former is converted into the latter. More specifically, as shown in the schema of FIG. 4A as the conversion source schema, the schema is represented by a data model in which an aggregate is expressed by a structural type and an association is expressed by using a set type structurator. . In addition, the human-type attribute “face” refers to a photo-type entity by using the distinctiveness of the object. This schema is represented by a data model that does not have a structural type or a set type constructor,
In addition, let us consider a case where it is desired to perform reference using the attribute value for the reference from the human-type attribute “face” to the photo type. Then, the result of the schema conversion becomes as shown in FIG.
The schema conversion description in this case is shown in FIG.

FIG. 4C shows a description example of schema conversion. Here, a description example of the schema when the schema of the nested structure of FIG. 4A is converted into the flattened schema structure of FIG. 4B is shown.

FIG. 4D shows an example of the constraint condition newly generated by the schema conversion. This is because the schema of the nested structure of FIG. 4A is converted to the flattened schema of FIG. 4B, and therefore cannot be expressed in the state after this conversion (to guarantee the sameness of the conversion operation. An example of a constraint condition is shown below.

FIG. 5 shows an example of classification of schema conversion operations according to the present invention. This is a classification example of conversion operations for canceling the difference between the data model A of the conversion source and the data model B of the conversion destination in S12 of FIG. Hierarchy conversion ■ Type conversion ■ Type relationship conversion Specific examples will be described below with reference to FIGS. 6 to 10.

(1) Conversion of type content definition: FIG. 6 shows an example of adding a key field and a reference field of the present invention. This is an example of conversion of the content definition of a type, that is, an example of conversion operation related to addition / deletion or modification of attributes or methods defined in the type. In this example, the addition of the key field and the addition of the reference field to the key field are performed between the data model that guarantees the identity of the object and the data model that uses the key field to identify the object based on the value. This is an operation that is required when performing schema conversion.

(2) Conversion of inheritance hierarchy: FIG. 7 shows an example of conversion of the inheritance hierarchy of the present invention. This is an example of conversion of the inheritance hierarchy, that is, an example of a conversion operation required for schema conversion between a data model that can define an inheritance hierarchy between types and a data model that does not. The operation of flattening the inheritance relationship shown in this example redefines the attributes of a type higher in the inheritance hierarchy as those defined in the type. If this operation does not guarantee the collective inclusive relation of the entities belonging to the type or the propagation of the type change in the upper hierarchy before the conversion, the meaning of the schema may be different before and after the schema conversion. is there.

As an inverse operation of this operation, an operation of extracting a common attribute and defining an inheritance hierarchy also involves similar constraint management. (3) Conversion of type itself: This is a conversion operation that accompanies type replacement when schema conversion is performed between data models having different type systems. The operations categorized here deal with replacement and reading between basic types such as literals. Conversion of a composite type using an abstract data type or a type constructor is handled in (4) conversion of relation between types.

(4) Transformation of relationships between types: FIG. 8 shows an example of expansion of nested items according to the present invention. This is an example of conversion of relationships between types, that is, an example of conversion operation required when the representation method of aggregation or association is different when performing schema conversion between different data models of different type systems. The expansion of the nested items shown in this example is used when the schema in which the attribute of the structural type is expressed by using the type constructor is emphasized and expressed.

For example, in FIG. 8, the human-type attribute “address” is expressed using the structural type. By expanding this structure type using attributes (columns), it is possible to represent it in a data model that does not have a structure type.

In another example, it is also possible to develop a structure type representation of the attribute "family" as a record without expanding it as an attribute. In this case, the schema before conversion expresses a set of human-type entities (instances), whereas the schema after conversion expresses the family relation of a person as an entity. That is, each entity represents a set of a set of "a person" and "a person in the family."

Since this conversion operation changes the meaning of the schema, it is necessary to guarantee the consistency of the reference and the consistency of the foreign key by the constraint. Also, the reverse operation of expanding a structured type to a column can be defined using only structural transformation, but the reverse operation when expanding to a record is aggregated in some way because the meaning of the aggregate is lost from the schema. Must be extracted.

In a schema expressing a set (association) by using a type constructor, it is possible to define an operation for expanding mainly with attributes as shown in FIG.
This can also be expanded by using columns and records as in the case of aggregation described above, but the attributes (columns)
When expanded to, the property that the number of elements of the set is variable is lost from the schema. Also, if there is a constraint that duplicates are not allowed within the elements of the set, it must be guaranteed. The reverse of this operation is definable.

On the other hand, when expanding to a record, the meaning of the schema changes because the entity expressed by the schema changes as in the case of the structure type. The reverse operation of this operation has the same problem as the structural type.

Further, as shown in FIG. 10, it is possible to define the type division by using a schema conversion operation for performing normalization based on the functional dependency of the relational data model. This operation splits a type into two types by separating the attributes that have a functional dependency within the attributes of the type, defining it as a new type, and adding a key field and a reference field to the key to it. Define the operation to be performed.

Among the examples of the conversion patterns taken up in FIGS. 6 to 10, some conversions require constraint conditions for keeping the meanings of the object schemas equivalent before and after conversion. There is something. A constraint condition newly generated by such a conversion operation is generated using the constraint condition generation function 17.

FIG. 11 shows an example of the schema conversion function (part) of the present invention. The schema conversion language is a language in which one schema operation is associated with one function based on the classification of schema conversion operations shown in FIG. Therefore, a series of schema operations can be expressed by a set of schema conversion functions. An example of this conversion function is shown in FIG. As a description example,
A description of the schema conversion language of FIG. 4B in which the schema conversion is applied to the above-described FIG. 4A is shown in FIG. 4C.

[0057]

As described above, according to the present invention,
The difference between the object definition extracted from the conversion request and the object definition of the conversion destination is extracted, the conversion operation is performed to cancel this difference, the conversion is performed to the definition information of the conversion destination, and data is copied based on this converted definition information. By adopting a configuration for performing such as, it has become possible to realize mutual data transfer between databases with different data models, which was impossible in the past. In addition, when performing an operation that changes the meaning of an object definition during a conversion operation, a constraint condition that is supplemented to ensure the sameness of the conversion operation is generated,
The meaning of the schema expression is because a structure is adopted in which data is converted based on this constraint condition and the converted object definition, or the object definition statement in which this constraint condition and the converted object definition are in the target language. Even when a conversion operation that changes the is performed, the sameness can be guaranteed before and after the conversion. As a result, (1) it becomes possible to mutually transfer the schema of an object between object management systems having different data models, and the work of reconstructing an object can be reduced.

(2) Since object schemas can be mutually transferred between object management systems of different data models, objects can be standardized and reused.

[Brief description of drawings]

FIG. 1 is a configuration diagram of an embodiment of the present invention.

FIG. 2 is a flowchart explaining the operation of the present invention.

FIG. 3 is a diagram illustrating a specific example of the present invention.

FIG. 4 is a schema conversion example of the present invention.

FIG. 5 is a classification example of the schema conversion operation of the present invention.

FIG. 6 is an example of adding a key field and a reference field according to the present invention.

FIG. 7 is an example of conversion of an inheritance hierarchy according to the present invention.

FIG. 8 is an example of expansion of nested items according to the present invention.

FIG. 9 is an example of expanding set items according to the present invention.

FIG. 10 is an example of a mold division and combination of the present invention.

FIG. 11 is an example of a schema conversion function (part) of the present invention.

[Explanation of symbols]

 11, 31: communication control device 12: heterogeneous object conversion device 13: object definition extraction means 14: object definition transmission means 15: object conversion means 16: schema conversion function 17: constraint condition generation function 18: object language generation function 19: data Model information 20: Conversion pattern information 21: Object language syntax information 22: Output device 23: Input device

Claims (3)

[Claims] 1. An object structure conversion device for converting an object structure, wherein an object definition extracting means for extracting an object definition from a conversion request, and a difference between the extracted source definition object definition and the conversion destination object definition are extracted. , Object conversion means for converting by performing a conversion operation for canceling this difference, and converting the data based on the converted object definition or the object definition statement in which the converted object definition is converted into the target language. An object structure conversion device characterized by performing. 2. In the conversion operation, when an operation that changes the meaning of the object definition is performed, a constraint condition to be supplemented to guarantee the identity of the conversion operation is generated, and the constraint condition and the converted object definition are generated. 2. The object structure conversion device according to claim 1, wherein the data conversion is performed based on an object definition statement in which the constraint condition and the converted object definition are in a conversion destination language. 3. When performing a conversion operation for canceling the difference,
3. The object structure conversion apparatus according to claim 1, wherein a conversion pattern information registered in advance is selected corresponding to the difference and a conversion operation is performed according to the selected conversion pattern information.